On 2021-11-24, Chris Townley <news@cct-net.co.uk> wrote:
> On 24/11/2021 21:45, Hunter Goatley wrote:
>> On 11/24/2021 1:14 PM, Simon Clubley wrote:
>>>
>>> VMS should have been designed 5-10 years later on than when it was.
>>>
>>
>> In a thread of backpedaling inanities, that has to be the most inane.
>>
>> Hunter
>
> +1
>

I am seriously annoyed by that comment Hunter because you have
completely missed (either accidentally or deliberately) the point
I am making (and have made before).

Compared to later operating system designs the internal design
of VMS is a direct product of the 1970s mindset because it is
ugly, hard to alter, not modular, full of internal hacks such
as jumping internally all over the place and was designed when
it was getting close to the end of when assembly language was
considered to be both an acceptable system implementation language
and an application language.

VMS has given us great things such as world-leading clustering,
but that doesn't change the ugly nature of its internal design.

This has caused major problems going forward as people tried to
enhance VMS. One such example is the need for a combined 32-bit/64-bit
address space.

Another such example is playing out right now as we speak.

The engineers at VSI are talented, experienced and generally skilled
overall. However, due to how VMS was designed, it has taken even these
skilled people over 7 years so far to port VMS to x86-64 and they will
not be finished until the middle of next year at the earliest.

As far as porting operating systems to a new architecture goes, that's
pathetic (but due to no fault of the above skilled engineers I hasten to add).

And even then, the port is not finished. After that, they need to provide
a filesystem that's suitable for today's hardware and today's disk sizes.

They have already had two goes at this and abandoned them. At current
schedules, you can easily add another couple of years for a new filesystem.

For comparison, I would expect a port of Linux to a new architecture to
take about 6-12 months to achieve first boot (if you also had to do
the compiler work as well) and about another 6-9 months after that
to deliver initial versions of the port into the hands of the customers.

How many people would have stayed with VMS if they knew in 2014 that
it would take another 8 years before they had VMS on x86-64 and another
couple of years after that before they had a filesystem suitable for
today's hardware ?

I say things that people don't like to hear. They are also the same
things that need to be said.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 11/25/2021 9:01 AM, Simon Clubley wrote:
> On 2021-11-24, Chris Townley <news@cct-net.co.uk> wrote:
>> On 24/11/2021 21:45, Hunter Goatley wrote:
>>> On 11/24/2021 1:14 PM, Simon Clubley wrote:
>>>>
>>>> VMS should have been designed 5-10 years later on than when it was.
>>>>
>>>
>>> In a thread of backpedaling inanities, that has to be the most inane.
>>>
>>> Hunter
>>
>> +1
>>
>
> I am seriously annoyed by that comment Hunter because you have
> completely missed (either accidentally or deliberately) the point
> I am making (and have made before).

You may not be the only one who can be annoyed ...

> Compared to later operating system designs the internal design
> of VMS is a direct product of the 1970s mindset because it is
> ugly, hard to alter, not modular, full of internal hacks such
> as jumping internally all over the place and was designed when
> it was getting close to the end of when assembly language was
> considered to be both an acceptable system implementation language
> and an application language.

Two statements clearly at odds, and both totally accurate:

1) The VAX 11/780 was a wonderful computer offering greatly enhanced
capabilities and performance.

2) The VAX 11/780 was a slow pig of a computer and wasted way too much floor
space and cost way too much, and had almost no memory.

It all depends on one's perspective, doesn't it? The perspective of 1978 or the
perspective of 2021. If ugly hacks and jumping around were implemented to
attempt to get a bit of performance out of the pig, well what's wrong with that?
But no, you Simon wish to judge VMS (which was written specifically for the
VAX) from the perspective of 2021. You're of course free to do so, but those
who lived the years of VMS can see and announce your prejudice.

> VMS has given us great things such as world-leading clustering,
> but that doesn't change the ugly nature of its internal design.
>
> This has caused major problems going forward as people tried to
> enhance VMS. One such example is the need for a combined 32-bit/64-bit
> address space.

Solving a "need" is a problem?

> Another such example is playing out right now as we speak.
>
> The engineers at VSI are talented, experienced and generally skilled
> overall. However, due to how VMS was designed, it has taken even these
> skilled people over 7 years so far to port VMS to x86-64 and they will
> not be finished until the middle of next year at the earliest.

VMS was designed and implemented for VAX, not generic computers.

> As far as porting operating systems to a new architecture goes, that's
> pathetic (but due to no fault of the above skilled engineers I hasten to add).
>
> And even then, the port is not finished. After that, they need to provide
> a filesystem that's suitable for today's hardware and today's disk sizes.
>
> They have already had two goes at this and abandoned them. At current
> schedules, you can easily add another couple of years for a new filesystem.
>
> For comparison, I would expect a port of Linux to a new architecture to
> take about 6-12 months to achieve first boot (if you also had to do
> the compiler work as well) and about another 6-9 months after that
> to deliver initial versions of the port into the hands of the customers.

Don't want no stinkin Linux ...

> How many people would have stayed with VMS if they knew in 2014 that
> it would take another 8 years before they had VMS on x86-64

Me! Me me me me me me ....

> and another
> couple of years after that before they had a filesystem suitable for
> today's hardware ?

ODS2 works for me ....

> I say things that people don't like to hear. They are also the same
> things that need to be said.

What need? And what makes you think we don't already know?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2021-11-25, Dave Froble <davef@tsoft-inc.com> wrote:
> On 11/25/2021 9:01 AM, Simon Clubley wrote:
>> VMS has given us great things such as world-leading clustering,
>> but that doesn't change the ugly nature of its internal design.
>>
>> This has caused major problems going forward as people tried to
>> enhance VMS. One such example is the need for a combined 32-bit/64-bit
>> address space.
>
> Solving a "need" is a problem?
>

In the way the underlying VMS design forced it do be done, yes, big time.

In other 64-bit operating systems, you have a mixture of pure 32-bit
ABI processes and pure 64-bit ABI processes running in the same
operating system. Far more cleaner and elegant.

>> Another such example is playing out right now as we speak.
>>
>> The engineers at VSI are talented, experienced and generally skilled
>> overall. However, due to how VMS was designed, it has taken even these
>> skilled people over 7 years so far to port VMS to x86-64 and they will
>> not be finished until the middle of next year at the earliest.
>
> VMS was designed and implemented for VAX, not generic computers.
>

And that, along with the Macro-32 implementation language, is one of
the reasons why we still don't have a production-ready port for x86-64
after 7 years of porting effort, even though VMS has already been through
ports to 2 different architectures.

>> As far as porting operating systems to a new architecture goes, that's
>> pathetic (but due to no fault of the above skilled engineers I hasten to add).
>>
>> And even then, the port is not finished. After that, they need to provide
>> a filesystem that's suitable for today's hardware and today's disk sizes.
>>
>> They have already had two goes at this and abandoned them. At current
>> schedules, you can easily add another couple of years for a new filesystem.
>>
>> For comparison, I would expect a port of Linux to a new architecture to
>> take about 6-12 months to achieve first boot (if you also had to do
>> the compiler work as well) and about another 6-9 months after that
>> to deliver initial versions of the port into the hands of the customers.
>
> Don't want no stinkin Linux ...
>

The comparison is to show what the expected timescale is for porting
to a new architecture.

>> How many people would have stayed with VMS if they knew in 2014 that
>> it would take another 8 years before they had VMS on x86-64
>
> Me! Me me me me me me ....
>

I doubt many would have joined you.

That would be like saying a port is being started here in 2021 and will
be ready in 2029 (probably). How many other people would have gone for that ?

>> and another
>> couple of years after that before they had a filesystem suitable for
>> today's hardware ?
>
> ODS2 works for me ....
>

What happens when you need to start working with multi-TB drives ?

>> I say things that people don't like to hear. They are also the same
>> things that need to be said.
>
> What need? And what makes you think we don't already know?
>

Your own comments above suggest you might not.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 11/25/2021 1:25 PM, Simon Clubley wrote:
> On 2021-11-25, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 11/25/2021 9:01 AM, Simon Clubley wrote:
>>> VMS has given us great things such as world-leading clustering,
>>> but that doesn't change the ugly nature of its internal design.
>>>
>>> This has caused major problems going forward as people tried to
>>> enhance VMS. One such example is the need for a combined 32-bit/64-bit
>>> address space.
>>
>> Solving a "need" is a problem?
>>
>
> In the way the underlying VMS design forced it do be done, yes, big time.
>
> In other 64-bit operating systems, you have a mixture of pure 32-bit
> ABI processes and pure 64-bit ABI processes running in the same
> operating system. Far more cleaner and elegant.

I do not see that design as so clean.

Just look at Windows where the 64 bit stuff is in C:\Windows\System32
and the 32 bit stuff is in C:\Windows\SysWOW64 and in registry
HKEY_CLASSES_ROOT vs HKEY_CLASSES_ROOT\Wow6432Node and the fun with
ODBC drivers.

But even if we consider it a clean design, then it really does
not matter. It is all facilitated by the fact that the x86-64
CPU have a 32 bit mode and a 64 bit mode. Alpha did not have
two modes. So it was not an option for VMS.

For a handful of reasons it was decided to support
both 32 bit pointers and 64 bit pointers on VMS.

>>> Another such example is playing out right now as we speak.
>>>
>>> The engineers at VSI are talented, experienced and generally skilled
>>> overall. However, due to how VMS was designed, it has taken even these
>>> skilled people over 7 years so far to port VMS to x86-64 and they will
>>> not be finished until the middle of next year at the earliest.
>>
>> VMS was designed and implemented for VAX, not generic computers.
>
> And that, along with the Macro-32 implementation language, is one of
> the reasons why we still don't have a production-ready port for x86-64
> after 7 years of porting effort, even though VMS has already been through
> ports to 2 different architectures.

I am not so sure that the Macro-32 is a major reason. When the
Macro-32 compiler is done and no changes are needed then
it is just compile. It is only when the code need to be modified
that it takes longer to understand and change Macro-32 than a HLL.

And regarding the 7 years, then I would consider it very interesting
to know how many people worked on the VAX->Alpha migration and how
many people work on the Itanium->x86-64 migration. I have a strong
suspicion that the latest migration has spent a lot less man years.

>>> How many people would have stayed with VMS if they knew in 2014 that
>>> it would take another 8 years before they had VMS on x86-64
>>
>> Me! Me me me me me me ....
>
> I doubt many would have joined you.

I think most would.

Those running VMS today are mostly those without an easy way off
VMS.

Continuing with VMS is what they want.

They are very interested in that VMS has a future. If not then
migration becomes necessary at some point in time.

So the confidence in VSI completing the port is very important.
But the timeline is less important.

Sure a x86-64 box is way more powerful and way cheaper than
Itanium and old Alpha's. But the Itanium's and Alpha's can
still do the job those VMS users need.

The drop dead time is when IslandCo can no longer deliver
Itanium's and Alpha's.

Arne

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>Just look at Windows where the 64 bit stuff is in C:\Windows\System32
>and the 32 bit stuff is in C:\Windows\SysWOW64 and in registry
>HKEY_CLASSES_ROOT vs HKEY_CLASSES_ROOT\Wow6432Node and the fun with
>ODBC drivers.
>
>But even if we consider it a clean design, then it really does
>not matter. It is all facilitated by the fact that the x86-64
>CPU have a 32 bit mode and a 64 bit mode. Alpha did not have
>two modes. So it was not an option for VMS.

Windows did it very very badly. Solaris is a much better example of
how it can be done right.

Remember the 11/780 had a 16-bit mode and could run RSX binaries too.
So we have been through all this before.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 11/25/21 2:20 PM, Arne Vajhøj wrote:
>
> Those running VMS today are mostly those without an easy way off
> VMS.
>

I would really like to know what people could be running on
VMS on an Itanic that would be so difficult to move to a
totally different system. Any applications are almost
guaranteed to be written in an HLL. Just what is it that
they are doing on VMS that can not be done on another
system?

bill

In article <j0ac3aFojqmU1@mid.individual.net>, Bill Gunshannon
<bill.gunshannon@gmail.com> writes:

> On 11/25/21 2:20 PM, Arne VajhÞj wrote:
> >
> > Those running VMS today are mostly those without an easy way off
> > VMS.
>
> I would really like to know what people could be running on
> VMS on an Itanic that would be so difficult to move to a
> totally different system. Any applications are almost
> guaranteed to be written in an HLL. Just what is it that
> they are doing on VMS that can not be done on another
> system?

Rdb. Sure, if you use standard SQL, you could port it to another
database without much trouble. But there is also RMU for things such as
backups and unloads. Yes, can be done in another way. Any Turing
machine can emulate another. :-) But those who have worked with Rdb,
especially those who can compare it with other databases, know how good
it is.

Clustering. Real clustering.

The two together. The database is open on all nodes in the cluster,
processes running on all nodes. It works. Lose a node? Reconnect to a
generic interface and continue.

Good documentation.

Built-in file versions.

EDT. :-)

On Friday, November 26, 2021 at 10:04:46 AM UTC+13, Bill Gunshannon wrote:
> On 11/25/21 2:20 PM, Arne Vajhøj wrote:
> >
> > Those running VMS today are mostly those without an easy way off
> > VMS.
> >
> I would really like to know what people could be running on
> VMS on an Itanic that would be so difficult to move to a
> totally different system. Any applications are almost
> guaranteed to be written in an HLL. Just what is it that
> they are doing on VMS that can not be done on another
> system?

Same things people are doing on Windows or MacOS that make a move
to a totally different system like Linux difficult. Calling APIs provided by
the operating system.

On 11/25/2021 4:04 PM, Bill Gunshannon wrote:
> On 11/25/21 2:20 PM, Arne Vajhøj wrote:
>> Those running VMS today are mostly those without an easy way off
>> VMS.
>
> I would really like to know what people could be running on
> VMS on an Itanic that would be so difficult to move to a
> totally different system.  Any applications are almost
> guaranteed to be written in an HLL.  Just what is it that
> they are doing on VMS that can not be done on another
> system?

It can be done on another OS.

But the cost and risk migrating can be significant.

VMS specific language extensions, SYS$ and LIB$ calls,
reliance on special features in Rdb or index-sequential
files not available in other RDBMS or ISAM, huge amount
of DCL scripts, Macro-32 pieces etc.etc..

A thousand easily solvable problems can when combined
be a very problematic cost and risk (risk may very
well be considered a bigger problem than cost).

It obviously depend on how the code is written. Some
C or Cobol programs may be pretty easy to migrate.
Most Pascal and Basic programs would be a rewrite from
scratch to migrate.

Arne

On 11/25/2021 4:24 PM, Phillip Helbig (undress to reply) wrote:
> In article <j0ac3aFojqmU1@mid.individual.net>, Bill Gunshannon
> <bill.gunshannon@gmail.com> writes:
>> On 11/25/21 2:20 PM, Arne VajhÞj wrote:
>>> Those running VMS today are mostly those without an easy way off
>>> VMS.
>>
>> I would really like to know what people could be running on
>> VMS on an Itanic that would be so difficult to move to a
>> totally different system. Any applications are almost
>> guaranteed to be written in an HLL. Just what is it that
>> they are doing on VMS that can not be done on another
>> system?
>
> Rdb. Sure, if you use standard SQL, you could port it to another
> database without much trouble. But there is also RMU for things such as
> backups and unloads. Yes, can be done in another way. Any Turing
> machine can emulate another. :-) But those who have worked with Rdb,
> especially those who can compare it with other databases, know how good
> it is.

I don't know if it is better.

But it is different.

You mention tools, but there is also the entire performance tuning.

> Clustering. Real clustering.
>
> The two together. The database is open on all nodes in the cluster,
> processes running on all nodes. It works. Lose a node? Reconnect to a
> generic interface and continue.

Active/Active database cluster is not unique for VMS and Rdb.

Oracle DB RAC, IBM DB2 PureScale and various NoSQL databases
(Cassandra, HBase, Voldemort etc.) all do it.

But differently.

Arne

In article <sno4v1$efp$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-11-24, Chris Townley <news@cct-net.co.uk> wrote:
>> On 24/11/2021 21:45, Hunter Goatley wrote:
>>> On 11/24/2021 1:14 PM, Simon Clubley wrote:
>>>>
>>>> VMS should have been designed 5-10 years later on than when it was.
>>>>
>>>
>>> In a thread of backpedaling inanities, that has to be the most inane.
>>>
>>> Hunter
>>
>> +1
>>
>
>I am seriously annoyed by that comment Hunter because you have
>completely missed (either accidentally or deliberately) the point
>I am making (and have made before).
>
>Compared to later operating system designs the internal design
>of VMS is a direct product of the 1970s mindset because it is
>ugly, hard to alter, not modular, full of internal hacks such
>as jumping internally all over the place and was designed when
>it was getting close to the end of when assembly language was
>considered to be both an acceptable system implementation language
>and an application language.

What's hard to alter? Many people say an alternator is difficult to
replace. I did one two weeks ago.

>VMS has given us great things such as world-leading clustering,
>but that doesn't change the ugly nature of its internal design.

It's design in elegant. You just can't get past the fact that it's not
unix.

>This has caused major problems going forward as people tried to
>enhance VMS. One such example is the need for a combined 32-bit/64-bit
>address space.

I don't find that all that much of an issue.

>Another such example is playing out right now as we speak.
>
>The engineers at VSI are talented, experienced and generally skilled
>overall. However, due to how VMS was designed, it has taken even these
>skilled people over 7 years so far to port VMS to x86-64 and they will
>not be finished until the middle of next year at the earliest.

LOL. I suppose you could do it in a week. I bow to your greatness.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

In article <sno4v1$efp$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-11-24, Chris Townley <news@cct-net.co.uk> wrote:
>> On 24/11/2021 21:45, Hunter Goatley wrote:
>>> On 11/24/2021 1:14 PM, Simon Clubley wrote:
>>>>
>>>> VMS should have been designed 5-10 years later on than when it was.
>>>>
>>>
>>> In a thread of backpedaling inanities, that has to be the most inane.
>>>
>>> Hunter
>>
>> +1
>>
>
>I am seriously annoyed by that comment Hunter because you have
>completely missed (either accidentally or deliberately) the point
>I am making (and have made before).

Trolling and changing the thread subject line does not excuse you from
answering the question I asked. <crickets... in November nonetheless>

Troll, troll troll, the troll is marching...

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 11/25/2021 6:34 PM, VAXman-@SendSpamHere.ORG wrote:
> In article <sno4v1$efp$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>> This has caused major problems going forward as people tried to
>> enhance VMS. One such example is the need for a combined 32-bit/64-bit
>> address space.
>
> I don't find that all that much of an issue.

Having P0 and P2 is not an issue in itself.

But having 32 and 64 bit pointers can be an issue.

Maybe not that often, but it comes up occasionally.

Arne

On 11/25/2021 5:07 PM, Arne Vajhøj wrote:
> On 11/25/2021 4:04 PM, Bill Gunshannon wrote:
>> On 11/25/21 2:20 PM, Arne Vajhøj wrote:
>>> Those running VMS today are mostly those without an easy way off
>>> VMS.
>>
>> I would really like to know what people could be running on
>> VMS on an Itanic that would be so difficult to move to a
>> totally different system.  Any applications are almost
>> guaranteed to be written in an HLL.  Just what is it that
>> they are doing on VMS that can not be done on another
>> system?
>
> It can be done on another OS.
>
> But the cost and risk migrating can be significant.
>
> VMS specific language extensions, SYS$ and LIB$ calls,
> reliance on special features in Rdb or index-sequential
> files not available in other RDBMS or ISAM, huge amount
> of DCL scripts, Macro-32 pieces etc.etc..
>
> A thousand easily solvable problems can when combined
> be a very problematic cost and risk (risk may very
> well be considered a bigger problem than cost).
>
> It obviously depend on how the code is written. Some
> C or Cobol programs may be pretty easy to migrate.
> Most Pascal and Basic programs would be a rewrite from
> scratch to migrate.

The main reason that C programs are not ported off VMS
is probably that the authors went overboard with VMS
specifics instead of sticking to standard C.

I suspect that the main reason that Cobol programs are
not ported off VMS is that Cobol/VMS -> Cobol/Linux is
not considered good enough so that the migration is
Cobol/VMS -> X/Linux.

Arne

On 11/25/2021 4:04 PM, Bill Gunshannon wrote:
> On 11/25/21 2:20 PM, Arne Vajhøj wrote:
>>
>> Those running VMS today are mostly those without an easy way off
>> VMS.
>>
>
>
> I would really like to know what people could be running on
> VMS on an Itanic that would be so difficult to move to a
> totally different system. Any applications are almost
> guaranteed to be written in an HLL. Just what is it that
> they are doing on VMS that can not be done on another
> system?
>
> bill
>
>

I sort of don't like doing this, but, it is what it is ...

Your posts include working for the government and a university. Perhaps others,
but that is what I recall.

I feel that perhaps you've never worked in an environment where being profitable
is the first consideration. I may be wrong.

Increasingly, companies depend on computer applications, note, not computers,
but applications, to run their businesses. The cost is an expense, not
profitable, other than what such applications allow.

First, lets look at: "Any applications are almost guaranteed to be written in an
HLL." I can point to at lease one application where that is not true. I've
seen references to others also. Just because you don't have one doesn't mean
others don't.

Many applications, maybe most, at least those still being used, running on VMS
would be costly to migrate/port to another environment. I know that that is
true for Basic, and I suspect it to be true for most or all languages.

Even if there might be some migration path other than total re-write, there will
be costs, there will be mistakes, and such. This costs money. Money that takes
away from profits, if not worse.

Just about anything can be done, with enough money and effort. Where would this
money and effort come from? For those whose business is providing tha effort,
perhaps they think the money should be available. Those who would bear the cost
might think otherwise.

Would VSI have customers now, if your conjecture had any merit?

In my case, an extensive application written almost exclusively in
Basic+/BP2/VAX Basic/DEC Basic used to run multiple companies. There is no
substitute that I'm aware of that could be used to run these applications. In
all cases, there would be design work, programming work, mistakes, business
disruption, failure, and such. Nothing insignificant either, we're talking 7 or
8 digits.

If it was so easy, why would not software competitors already have come forth
with replacement applications. It's not like VMS users have been treated well
for many years by the OS vendor. Where are those supposed alternatives?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 11/25/2021 4:24 PM, Phillip Helbig (undress to reply) wrote:
> In article <j0ac3aFojqmU1@mid.individual.net>, Bill Gunshannon
> <bill.gunshannon@gmail.com> writes:
>
>> On 11/25/21 2:20 PM, Arne VajhÞj wrote:
>>>
>>> Those running VMS today are mostly those without an easy way off
>>> VMS.
>>
>> I would really like to know what people could be running on
>> VMS on an Itanic that would be so difficult to move to a
>> totally different system. Any applications are almost
>> guaranteed to be written in an HLL. Just what is it that
>> they are doing on VMS that can not be done on another
>> system?
>
> Rdb. Sure, if you use standard SQL, you could port it to another
> database without much trouble. But there is also RMU for things such as
> backups and unloads. Yes, can be done in another way. Any Turing
> machine can emulate another. :-) But those who have worked with Rdb,
> especially those who can compare it with other databases, know how good
> it is.
>
> Clustering. Real clustering.
>
> The two together. The database is open on all nodes in the cluster,
> processes running on all nodes. It works. Lose a node? Reconnect to a
> generic interface and continue.
>
> Good documentation.
>
> Built-in file versions.
>
> EDT. :-)
>

Sorry Phillip, but none of your arguments really matter. Perhaps disaster
tolerant clusters. I doubt those are the majority of current VMS users.

What matters are the current applications.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Thursday, 25 November 2021 at 15:48:37 UTC, Dave Froble wrote:

> VMS was designed and implemented for VAX, not generic computers.

As I remember it, VAX/VMS was designed by DEC to be the ideal OS then the VAX hardware was designed and built to run it not the other way around. There were probably some mistakes made, unforeseen implementation issues and some during development of the harware and software but the facilities that this combination provided, especially in comparison to the price range of other systems, was

It's not proprietary in the traditional sense but it is difficult to port to hardware that was not designed to run it. It is certainly worth tidying up the legacy flaws to make future ports easier but until somebody designs new hardware that can utilise / exploit the full functionality of OpenVMS any port will be difficult, incomplete and imperfect.

On Thursday, 25 November 2021 at 15:48:37 UTC, Dave Froble wrote:
> VMS was designed and implemented for VAX, not generic computers.

As I remember it, VAX/VMS was designed by DEC to be its best ever OS then the VAX hardware was designed and built to run it not the other way around. There were probably some mistakes made, unforeseen implementation issues and some miscommunications during parallel development of the hardware and software but the facilities that this combination provided, especially in comparison to the price range of other systems at the time, was revolutionary.

OpenVMS is not proprietary in the traditional sense but it is difficult to port to hardware that was not designed to run it. It is certainly worth tidying up the legacy flaws to make future ports easier but, until somebody designs new hardware that can utilise / exploit the full functionality of OpenVMS, any port will be difficult, incomplete and imperfect.

On 11/25/21 8:47 PM, Dave Froble wrote:
> On 11/25/2021 4:04 PM, Bill Gunshannon wrote:
>> On 11/25/21 2:20 PM, Arne Vajhøj wrote:
>>>
>>> Those running VMS today are mostly those without an easy way off
>>> VMS.
>>>
>>
>>
>> I would really like to know what people could be running on
>> VMS on an Itanic that would be so difficult to move to a
>> totally different system.  Any applications are almost
>> guaranteed to be written in an HLL.  Just what is it that
>> they are doing on VMS that can not be done on another
>> system?
>>
>> bill
>>
>>
>
> I sort of don't like doing this, but, it is what it is ...
>
> Your posts include working for the government and a university.  Perhaps
> others, but that is what I recall.
>
> I feel that perhaps you've never worked in an environment where being
> profitable is the first consideration.  I may be wrong.

You would be wrong. I have also worked for Martin Marietta (now
Lockheed Martin) and TRW (IND, not the car parts division).

>
> Increasingly, companies depend on computer applications, note, not
> computers, but applications, to run their businesses.  The cost is an
> expense, not profitable, other than what such applications allow.
>
> First, lets look at: "Any applications are almost guaranteed to be
> written in an HLL."  I can point to at lease one application where that
> is not true.  I've seen references to others also.  Just because you
> don't have one doesn't mean others don't.

Considering that, like COBOL, no one is teaching any kind of assembler
they would have to be real legacy applications.

>
> Many applications, maybe most, at least those still being used, running
> on VMS would be costly to migrate/port to another environment.  I know
> that that is true for Basic, and I suspect it to be true for most or all
> languages.
>
> Even if there might be some migration path other than total re-write,
> there will be costs, there will be mistakes, and such.  This costs
> money.  Money that takes away from profits, if not worse.

I never said it would be free. But as someone else mentioned cost is
important but so is risk.

>
> Just about anything can be done, with enough money and effort.  Where
> would this money and effort come from?  For those whose business is
> providing tha effort, perhaps they think the money should be available.
> Those who would bear the cost might think otherwise.
>
> Would VSI have customers now, if your conjecture had any merit?

But there is the rub. VSI does have customers but based on the
comments I am still seeing here the numbers may be decreasing.
And people may be getting concerned about the time scale.

>
> In my case, an extensive application written almost exclusively in
> Basic+/BP2/VAX Basic/DEC Basic used to run multiple companies.  There is
> no substitute that I'm aware of that could be used to run these
> applications.  In all cases, there would be design work, programming
> work, mistakes, business disruption, failure, and such.  Nothing
> insignificant either, we're talking 7 or 8 digits.

Yes, but what does it do that your customers can't find another
product to do. It may take major changes in the way they handle
the nuts and bolts of their business, but it happens every day.
The University I worked at had all in-house applications when I
got there. Running on Big Blue. Moved the whole thing to VMS.
And then moved the whole thing to Banner. No more VMS. It can
be done and it is being done every day. Don't get me wrong, I
don't think the model is a good idea, but then, I am not a CIO.
They do.

>
> If it was so easy, why would not software competitors already have come
> forth with replacement applications.  It's not like VMS users have been
> treated well for many years by the OS vendor.  Where are those supposed
> alternatives?
>

VMS is a religion. Just read what is said here. But there have been
desertions. The VMS constant no longer exists. I expect there are
maybe 10% of that number left. And it is a self-fulfilling prophecy.
Every defection decreases the long term existence of the product.

And, it still avoids my original question. What can you do on VMS
that can not be done on another system? The effort and cost are
not a part of this equation. Only the task to be done. Cost
and effort decrease as risk increases.

bill

On Friday, November 26, 2021 at 6:40:42 AM UTC-5, felim...@gmail.com wrote:
> On Thursday, 25 November 2021 at 15:48:37 UTC, Dave Froble wrote:
> > VMS was designed and implemented for VAX, not generic computers.
> As I remember it, VAX/VMS was designed by DEC to be its best ever OS then the VAX hardware was designed and built to run it not the other way around.. There were probably some mistakes made, unforeseen implementation issues and some miscommunications during parallel development of the hardware and software but the facilities that this combination provided, especially in comparison to the price range of other systems at the time, was revolutionary.
>
> OpenVMS is not proprietary in the traditional sense but it is difficult to port to hardware that was not designed to run it. It is certainly worth tidying up the legacy flaws to make future ports easier but, until somebody designs new hardware that can utilise / exploit the full functionality of OpenVMS, any port will be difficult, incomplete and imperfect.

Have not been here for a bit. My answer to the "how many people" question........

If you include the compiler teams who were actually separate from VMS Engineering itself in the bad old days, there was somewhere in the range of 250 people in the two organizations combined when we ported from VAX to Alpha and then Alpha to IPF. Not all of these people worked on the port all at once but they were all available to pitch in as needed even when it was not their full-time job. Both of those ports took 3 years; they were very different technically but nonetheless, the total elapsed time was eerily the same.

With the same person power, porting to x86 would have been roughly the same, I believe. No reason to think otherwise (similar issues, same parts of the system needing architecture-specific work). But that is not the case. We have way fewer people now so it is not surprising to me, at least, that it is taking way longer.

Clair

BTW: Right after we ported to IPF, I was asked how long it would take to port VMS to x86. I said, 3 years, given the same of team that just completed porting. I never heard another word about that topic.

>> On 11/25/2021 4:04 PM, Bill Gunshannon wrote:
>>>
>>> I would really like to know what people could be running on
>>> VMS on an Itanic that would be so difficult to move to a
>>> totally different system.  Any applications are almost
>>> guaranteed to be written in an HLL.  Just what is it that
>>> they are doing on VMS that can not be done on another
>>> system?
>>>
>>> bill
>>>

An "application" is not only the core routines in Cobol or
some other HLL. There are usually also a lot of routines that
are written (for VMS) in DCL that "runs" the applications.

And the whole application infrastructure can rely on VMS unique
things like logical names, mailboxes and other stuff.

I guess the majority of an porting effort is to move off the
VMS unique features.

In article <j0c73vF4nvbU1@mid.individual.net>, Bill Gunshannon
<bill.gunshannon@gmail.com> writes:

> And, it still avoids my original question. What can you do on VMS
> that can not be done on another system? The effort and cost are
> not a part of this equation. Only the task to be done.

Any Turing machine can emulate another. So the answer is "nothing".
But important to most people are the time, effort, risk, and money
involved and how much enjoyment it brings.

In article <snqqpn$72n$1@dont-email.me>,
=?UTF-8?Q?Jan-Erik_Söderholm?= <jan-erik.soderholm@telia.com>
writes:

> >>> I would really like to know what people could be running on
> >>> VMS on an Itanic that would be so difficult to move to a
> >>> totally different system. Any applications are almost
> >>> guaranteed to be written in an HLL. Just what is it that
> >>> they are doing on VMS that can not be done on another
> >>> system?
> >>>
> >>> bill
> >>>
>
> An "application" is not only the core routines in Cobol or
> some other HLL. There are usually also a lot of routines that
> are written (for VMS) in DCL that "runs" the applications.

Indeed, e.g. job schedulers written in DCL.

> And the whole application infrastructure can rely on VMS unique
> things like logical names, mailboxes and other stuff.

Especially combinations such as cluster-wide logical names visible to
only a group.

> I guess the majority of an porting effort is to move off the
> VMS unique features.

Yes.

On 11/26/2021 9:12 AM, Clair Grant wrote:
> Have not been here for a bit. My answer to the "how many people"
> question.......
>
> If you include the compiler teams who were actually separate from VMS
> Engineering itself in the bad old days, there was somewhere in the
> range of 250 people in the two organizations combined when we ported
> from VAX to Alpha and then Alpha to IPF. Not all of these people
> worked on the port all at once but they were all available to pitch
> in as needed even when it was not their full-time job. Both of those
> ports took 3 years; they were very different technically but
> nonetheless, the total elapsed time was eerily the same.
>
> With the same person power, porting to x86 would have been roughly
> the same, I believe. No reason to think otherwise (similar issues,
> same parts of the system needing architecture-specific work). But
> that is not the case. We have way fewer people now so it is not
> surprising to me, at least, that it is taking way longer.

People without experience in big software projects tend to think
that it is a few hard to solve problems that take the time. But
that is rarely the case. The time is typical spent on relative
easy problems - there are just a lot of them. I do not expect
the fact that x86-64 is 2 mode instead of 4 modes, the fact
that lot of VMS code is Macro-32 or Bliss to be what is driving
the effort required. But you have N places where there are something
ISA specific. And N is a large number. And for every one of those
somebody needs to understand the problem, make the fix, document it and
test it. It takes 1 day or 1 week or 1 month. But multiply that with
thousands of places. And then mix in the hassle of cross-developing on
a different platform, the coordination effort to ensure that all parts
are changed in a compatible way and the interruptions of 8.4 support
and requests for new features / bug fixes from customers and
the man months start going quickly.

Arne

On 2021-11-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/25/2021 1:25 PM, Simon Clubley wrote:
>>
>> I doubt many would have joined you.
>
> I think most would.
>
> Those running VMS today are mostly those without an easy way off
> VMS.
>
> Continuing with VMS is what they want.
>
> They are very interested in that VMS has a future. If not then
> migration becomes necessary at some point in time.
>
> So the confidence in VSI completing the port is very important.
> But the timeline is less important.
>

The problem Arne is that in many companies, those who want to stay
on VMS are not those who actually make the final decision about whether
to stay on VMS.

Those kinds of decisions are usually made one or two levels higher up
and those people tend not to have an emotional bond to VMS and they also
want to take what they perceive as the safer decision (both for them and
for their pension.)

Saying that a port to x86-64 would be available in about 8 years is
not the kind of thing that endears you to those types of managers. :-)

> Sure a x86-64 box is way more powerful and way cheaper than
> Itanium and old Alpha's. But the Itanium's and Alpha's can
> still do the job those VMS users need.
>
> The drop dead time is when IslandCo can no longer deliver
> Itanium's and Alpha's.
>

Alpha not so much, because full system emulation is available.

But yes, for Itanium, when replacement physical boxes are no longer
available is when the real problems start to occur.

It really is a pity that a full system emulator was never developed
for the Itanium architecture. That would have given people a few more
options.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.