General jist is that VMS is available on x86-64, but does anyone care ?

https://www.theregister.com/2022/05/10/openvms_92/

Subtext underneath the title from the article:

"One of the most battle-tested OSes out there hits commodity kit, but does
anyone still care?"

Before you all start screaming in indignation, and start acting like
a fanboi in the comments, consider that he might have a point if you
post a comment...

Also, on first read, it's actually a well-written article in the details
provided, so it was clearly written by someone who knows VMS well and
went to the effort to fill in the details.

Simon.

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

On 5/10/2022 1:36 PM, Simon Clubley wrote:
> General jist is that VMS is available on x86-64, but does anyone care ?
>
> https://www.theregister.com/2022/05/10/openvms_92/
>
> Subtext underneath the title from the article:
>
> "One of the most battle-tested OSes out there hits commodity kit, but does
> anyone still care?"
>
> Before you all start screaming in indignation, and start acting like
> a fanboi in the comments, consider that he might have a point if you
> post a comment...

Of course he has a point.

VMS still has some users that like it, but it is not like
tens of thousands of new users will show up tomorrow.

But the same point could be made for any server OS besides Linux
and maybe Windows.

VMS has more future than HP-UX and Solaris.

Arne

On 5/10/22 20:41, Arne Vajhøj wrote:
> On 5/10/2022 1:36 PM, Simon Clubley wrote:
>> General jist is that VMS is available on x86-64, but does anyone care ?
>>
>> https://www.theregister.com/2022/05/10/openvms_92/
>>
>> Subtext underneath the title from the article:
>>
>> "One of the most battle-tested OSes out there hits commodity kit, but
>> does
>> anyone still care?"
>>
>> Before you all start screaming in indignation, and start acting like
>> a fanboi in the comments, consider that he might have a point if you
>> post a comment...
>
> Of course he has a point.
>
> VMS still has some users that like it, but it is not like
> tens of thousands of new users will show up tomorrow.
>
> But the same point could be made for any server OS besides Linux
> and maybe Windows.
>
> VMS has more future than HP-UX and Solaris.
>

zOS?

OS2200?

bill

On 5/10/2022 9:41 PM, Bill Gunshannon wrote:
> On 5/10/22 20:41, Arne Vajhøj wrote:
>> On 5/10/2022 1:36 PM, Simon Clubley wrote:
>>> General jist is that VMS is available on x86-64, but does anyone care ?
>>>
>>> https://www.theregister.com/2022/05/10/openvms_92/
>>>
>>> Subtext underneath the title from the article:
>>>
>>> "One of the most battle-tested OSes out there hits commodity kit, but
>>> does
>>> anyone still care?"
>>>
>>> Before you all start screaming in indignation, and start acting like
>>> a fanboi in the comments, consider that he might have a point if you
>>> post a comment...
>>
>> Of course he has a point.
>>
>> VMS still has some users that like it, but it is not like
>> tens of thousands of new users will show up tomorrow.
>>
>> But the same point could be made for any server OS besides Linux
>> and maybe Windows.
>>
>> VMS has more future than HP-UX and Solaris.
>
> zOS?
>
> OS2200?

z/OS got a much larger customer base than VMS so they are far better
off, but it is still a platform companies want to migrate off not
migrate on.

I don't know much about OS 2200 but my feeling is that it is more
like the HP-UX state.

Arne

On 5/10/22 7:52 PM, Arne Vajhøj wrote:
> z/OS got a much larger customer base than VMS so they are far better
> off, but it is still a platform companies want to migrate off not
> migrate on.

There is also a separation of z/OS and the platform that it runs on.

Linux is also quite popular on the mainframe platform. I speculate that
there is a 10 or even 100 to one ratio between Linux on the mainframe
and z/OS on the mainframe.

There are also other traditional OSs that run on the mainframe that are
as common, if not more so (collectively) than z/OS.

--
Grant. . . .
unix || die

In article <627b16f7$0$697$14726298@news.sunsite.dk>, arne@vajhoej.dk
(Arne Vajh�j) wrote:

> I don't know much about OS 2200 but my feeling is that it is more
> like the HP-UX state.

The manufacturer (Unisys) wants to keep OS 2200 alive, unlike HPE with
HP-UX. Since CPU performance was never very high, this is practical via
emulation on commodity processors, and that's how it's been done since
2015.

<https://www.unisys.com/news-release/unisys-debuts-most-powerful-clearpath
-dorado-systems-ever/>

John

On 5/11/2022 3:33 AM, John Dallman wrote:
> In article <627b16f7$0$697$14726298@news.sunsite.dk>, arne@vajhoej.dk
> (Arne Vajhøj) wrote:
>> I don't know much about OS 2200 but my feeling is that it is more
>> like the HP-UX state.
>
> The manufacturer (Unisys) wants to keep OS 2200 alive, unlike HPE with
> HP-UX. Since CPU performance was never very high, this is practical via
> emulation on commodity processors, and that's how it's been done since
> 2015.
>
> <https://www.unisys.com/news-release/unisys-debuts-most-powerful-clearpath-dorado-systems-ever/>

I got the impression that Unisys was mostly services around
industry standard servers today. But then I am not close to
the Unisys world, so they may have firm support for OS 2200.
So maybe more like HPE NonStop than HPE HP-UX.

Arne

On 5/11/22 08:21, Arne Vajhøj wrote:
> On 5/11/2022 3:33 AM, John Dallman wrote:
>> In article <627b16f7$0$697$14726298@news.sunsite.dk>, arne@vajhoej.dk
>> (Arne Vajhøj) wrote:
>>> I don't know much about OS 2200 but my feeling is that it is more
>>> like the HP-UX state.
>>
>> The manufacturer (Unisys) wants to keep OS 2200 alive, unlike HPE with
>> HP-UX. Since CPU performance was never very high, this is practical via
>> emulation on commodity processors, and that's how it's been done since
>> 2015.
>>
>> <https://www.unisys.com/news-release/unisys-debuts-most-powerful-clearpath-dorado-systems-ever/>
>>
>
> I got the impression that Unisys was mostly services around
> industry standard servers today. But then I am not close to
> the Unisys world, so they may have firm support for OS 2200.
> So maybe more like HPE NonStop than HPE HP-UX.
>

OS2200 is alive and well. Like zOS backwards compatibility has been
maintained at least as far back as Univac 1100 EXEC8. They also have
a program that let's you run it on a PC kinda like what VSI does with
the education program. There are some very large (and not going away)
ISes running on OS2200.

If nothing else, it proves that Legacy Systems can continue to be
of value. Too bad the post DEC owners of VMS couldn't see this as
we might now be in a much better position.

bill

bill

On 5/11/2022 12:37 AM, Grant Taylor wrote:
> On 5/10/22 7:52 PM, Arne Vajhøj wrote:
>> z/OS got a much larger customer base than VMS so they are far better
>> off, but it is still a platform companies want to migrate off not
>> migrate on.
>
> There is also a separation of z/OS and the platform that it runs on.
>
> Linux is also quite popular on the mainframe platform.  I speculate that
> there is a 10 or even 100 to one ratio between Linux on the mainframe
> and z/OS on the mainframe.

True.

But I suspect that z/OS is the reason the mainframe is there and
the Linux instances got added to provide supporting services. I expect
very few to buy a mainframe to only run Linux - does not make sense
financially.

> There are also other traditional OSs that run on the mainframe that are
> as common, if not more so (collectively) than z/OS.

z/VSE?

I thought most VSE users had migrated either up to MVS or down to
something non-mainframe.

Arne

On 5/11/22 6:40 AM, Arne Vajhøj wrote:
> But I suspect that z/OS is the reason the mainframe is there and the
> Linux instances got added to provide supporting services. I expect
> very few to buy a mainframe to only run Linux - does not make sense
> financially.

Traditional mainframe OSs are almost certainly why the original
mainframe was originally installed at an institution. But that is
historic and does not account for why the mainframe has been refreshed
over the years.

When I was around some IBM mainframe support people, they told me that
they supported multiple systems that were running double digit instances
of VM, each with double digit secondary instances of VM there in, each
with double or triple digit tertiary instances of Linux therein. So a
single system hosted anywhere between 10 * 10 * 100 = 10,000 and 100,000
instances of Linux on a single system. When you're talking about that
many instances of Linux, the economies of scale really start to shine
for physically large systems. Scale that the most economical x86
architecture has a lot of trouble keeping up with.

> z/VSE?

TPF is supposedly quite common in the airline and similar reservation
and CC industries.

There's obviously z/VM.

There are others that are still maintained that aren't coming to mind at
the moment.

> I thought most VSE users had migrated either up to MVS or down to
> something non-mainframe.

z/VSE is a contemporary product so there are enough people using it for
IBM to continue supporting and developing it.

--
Grant. . . .
unix || die

On 5/11/2022 11:01 AM, Grant Taylor wrote:

>> I thought most VSE users had migrated either up to MVS or down to something non-mainframe.
>
> z/VSE is a contemporary product so there are enough people using it for IBM to continue supporting and developing it.

Similar to how Teracloud/VSI acquired the development rights to VMS from HP,
Teracloud/21st Century Software acquired the development rights to VSE from IBM

https://www.21stcenturysoftware.com/21st-century-software-announces-vsen-v6-3/

--

-- Rob

On 5/11/2022 11:01 AM, Grant Taylor wrote:
> On 5/11/22 6:40 AM, Arne Vajhøj wrote:
>> But I suspect that z/OS is the reason the mainframe is there and the
>> Linux instances got added to provide supporting services. I expect
>> very few to buy a mainframe to only run Linux - does not make sense
>> financially.
>
> Traditional mainframe OSs are almost certainly why the original
> mainframe was originally installed at an institution.  But that is
> historic and does not account for why the mainframe has been refreshed
> over the years.

If they only need Linux then they could save money by switching
to x86-64.

> When I was around some IBM mainframe support people, they told me that
> they supported multiple systems that were running double digit instances
> of VM, each with double digit secondary instances of VM there in, each
> with double or triple digit tertiary instances of Linux therein.  So a
> single system hosted anywhere between 10 * 10 * 100 = 10,000 and 100,000
> instances of Linux on a single system.  When you're talking about that
> many instances of Linux, the economies of scale really start to shine
> for physically large systems.  Scale that the most economical x86
> architecture has a lot of trouble keeping up with.

You could not run that on a single x86-64 system, but you could
on multiple x86-64 systems, which would be a lot cheaper than that
mainframe.

>> z/VSE?
>
> TPF is supposedly quite common in the airline and similar reservation
> and CC industries.

z/TPF for those that need it.

> There's obviously z/VM.

I am not a mainframe person, but I thought z/VM was the hypervisor
running z/OS, z/VSE, z/TPF, z Linux etc. and not an end OS - aka
more like VMWare ESXi (obviously somewhat different).

>> I thought most VSE users had migrated either up to MVS or down to
>> something non-mainframe.
>
> z/VSE is a contemporary product so there are enough people using it for
> IBM to continue supporting and developing it.

Obviously.

But I still think it is a pretty small market compared to z/OS.

Arne

In article <je1opmFavjuU1@mid.individual.net>, bill.gunshannon@gmail.com
(Bill Gunshannon) wrote:

> If nothing else, it proves that Legacy Systems can continue to be
> of value. Too bad the post DEC owners of VMS couldn't see this as
> we might now be in a much better position.

VMS may not have been different enough from newer platforms to make
transitions painful for lots of companies.

Alpha, while excellent, wasn't all that different from other RISC
architectures once they were extended to 64-bit. VMS terminology isn't as
different from UNIX as z/OS is.

John

On 5/11/22 9:21 AM, Arne Vajhøj wrote:
> If they only need Linux then they could save money by switching
> to x86-64.

They could switch to Raspberry Pis too.

But it turns into a numbers game. Cost of system(s) / cost of
operations / installation space / power / cooling / etc.

> You could not run that on a single x86-64 system, but you could
> on multiple x86-64 systems, which would be a lot cheaper than that
> mainframe.

I don't know how many high end x86 systems you'll need to run 100k Linux
VMs. But I suspect it's more than a few.

Networking also gets more complex as the number of physical systems grows.

> z/TPF for those that need it.

;-)

> I am not a mainframe person, but I thought z/VM was the hypervisor
> running z/OS, z/VSE, z/TPF, z Linux etc. and not an end OS - aka more
> like VMWare ESXi (obviously somewhat different).

z/VM is one of a hand full of hypervisors that can be used on the mainframe.

The hypervisor that's built into the hardware is PR/SM and pronounced
"prism". It operates at the firmware level and logically divides the
system into LPARs. LPARs then run mainframe OSs.

I believe there are people that still use z/VM as an end OS for some
things. Though I don't think it's as common as it once was.

> Obviously.

;-)

> But I still think it is a pretty small market compared to z/OS.

That's probably true. But the non-dominant market doesn't mean that
it's not a market.

--
Grant. . . .
unix || die

On 5/11/22 11:47, John Dallman wrote:
> In article <je1opmFavjuU1@mid.individual.net>, bill.gunshannon@gmail.com
> (Bill Gunshannon) wrote:
>
>> If nothing else, it proves that Legacy Systems can continue to be
>> of value. Too bad the post DEC owners of VMS couldn't see this as
>> we might now be in a much better position.
>
> VMS may not have been different enough from newer platforms to make
> transitions painful for lots of companies.

If that were the case OS2200 never would have come about. Most
of what they run is HLL. COBOL (still a lot of 68) and Fortran.
Any of which could be easily ported to Linux or even Windows.
There has to be a reason so many people people stay with that
architecture and vendor.

>
> Alpha, while excellent, wasn't all that different from other RISC
> architectures once they were extended to 64-bit. VMS terminology isn't as
> different from UNIX as z/OS is.

VMS terminolgy compared to Unix is like English and Swahili.
Except for the Unix terminology that has crept in to VMS,
usually unsuccessfully, like fork(). :-)

bill

On 5/11/22 12:27 PM, Bill Gunshannon wrote:
> Any of which could be easily ported to Linux or even Windows.

I don't buy that statement nearly as much as I once did.

Yes, languages exist on many, if not most, platforms. However there is
more to programs than just the languages themselves. There are other
things that the platform provides which are inherently platform specific.

Mainframes have coupling facility at the hardware level for a very high
degree of clustering which is managed outside of / below the program.
I'm not aware of anything like VMS's disk shadowing outside of VMS. --
These are just two -- hopefully -- poignantly obvious things that are
fairly unique and salient to the respective platforms that come to mind.
I'm sure there are many more.

The point being that the platform provides non-portable things that
programs written in otherwise portable language use. So simply taking
the source code written in a portable language and compiling on another
platform is ... difficult at best.

--
Grant. . . .
unix || die

On 5/11/22 1:00 PM, Grant Taylor wrote:
> Mainframes have coupling facility at the hardware level for a very high
> degree of clustering which is managed outside of / below the program.
> I'm not aware of anything like VMS's disk shadowing outside of VMS.  --
> These are just two -- hopefully -- poignantly obvious things that are
> fairly unique and salient to the respective platforms that come to mind.
>  I'm sure there are many more.

It seems as if many of these platform specific advantage are largely
unknown outside of the platform. As such, application designers have
often found different ways to achieve the desired effect using
completely different functionality.

OS level clustering is now not nearly as much of a thing as it once was.
Now things sit on top of a generic OS and provide pseudo clustering
like effect to applications. Never mind the fact that the applications
now need to be aware of and manage more of this clustering capability
themselves.

Does the mainframe's parallel coupling facility mean anything to the top
web scale companies? Nope. Their software stack isn't designed for it.
Nor could the largest PCF scale to the workload that the aggregate
distributed fleet sustains on a daily basis.

Yet there are some tasks that the mainframe and VMS are more uniquely
suited to provide. Extremely fast transnational processing comes to
mind, a la. z/TPF.

--
Grant. . . .
unix || die

On 5/11/2022 2:27 PM, Bill Gunshannon wrote:
> On 5/11/22 11:47, John Dallman wrote:
>> In article <je1opmFavjuU1@mid.individual.net>, bill.gunshannon@gmail.com
>> (Bill Gunshannon) wrote:
>>> If nothing else, it proves that Legacy Systems can continue to be
>>> of value.  Too bad the post DEC owners of VMS couldn't see this as
>>> we might now be in a much better position.
>>
>> VMS may not have been different enough from newer platforms to make
>> transitions painful for lots of companies.
>
> If that were the case OS2200 never would have come about.  Most
> of what they run is HLL.  COBOL (still a lot of 68) and Fortran.
> Any of which could be easily ported to Linux or even Windows.

Not necessarily.

There can be a lot of small devils in the details:
* use of platform specific extensions to the language
* pieces of assembler.
* assumptions about file system.
* assumptions about endianess
* assumptions about bit size of various data types

Arne

On 5/11/22 15:00, Grant Taylor wrote:
> On 5/11/22 12:27 PM, Bill Gunshannon wrote:
>> Any of which could be easily ported to Linux or even Windows.
>
> I don't buy that statement nearly as much as I once did.
>
> Yes, languages exist on many, if not most, platforms.  However there is
> more to programs than just the languages themselves.  There are other
> things that the platform provides which are inherently platform specific.

Once again you are tying to apply VMS logic to someone else. I am
personally aware of two very large ISes that run on OS2200. Both
of them are over 40 years old and run pretty much as they have from
the beginning. One I know is written in COBOL68 (because some of the
code was written by me) and the other is very likely still COBOL68
as there would be no real reason to re-write it in the newer COBOL.
They use DMS11 for their database. A mere child when compared to
today's databases. Even MySQl could be used to replace it.
>
> Mainframes have coupling facility at the hardware level for a very high
> degree of clustering which is managed outside of / below the program.
> I'm not aware of anything like VMS's disk shadowing outside of VMS.  --
> These are just two -- hopefully -- poignantly obvious things that are
> fairly unique and salient to the respective platforms that come to mind.
>  I'm sure there are many more.

There probably are, but we are talking legacy programs here. If they
wanted to modify them to make use of these more modern facilities why
would they even stay where they are?

>
> The point being that the platform provides non-portable things that
> programs written in otherwise portable language use.  So simply taking
> the source code written in a portable language and compiling on another
> platform is ... difficult at best.

As I said, in at least one of the ISes I worked on it for a number
of years. I know what the source looks like. I could easily port
it to GnuCOBOL and PostGres running on BSD, Linux or even Windows.
And yet, these people stay with Unisys (Univac) and OS2200. There
must be a reason. Knowledge of this reason could likely be used
to try and stem the bleeding off of VMS users.

bill

On 5/11/2022 3:35 PM, Bill Gunshannon wrote:
> On 5/11/22 15:00, Grant Taylor wrote:
>> On 5/11/22 12:27 PM, Bill Gunshannon wrote:
>>> Any of which could be easily ported to Linux or even Windows.
>>
>> I don't buy that statement nearly as much as I once did.
>>
>> Yes, languages exist on many, if not most, platforms.  However there
>> is more to programs than just the languages themselves.  There are
>> other things that the platform provides which are inherently platform
>> specific.
>
> Once again you are tying to apply VMS logic to someone else.  I am
> personally aware of two very large ISes that run on OS2200.  Both
> of them are over 40 years old and run pretty much as they have from
> the beginning.  One I know is written in COBOL68 (because some of the
> code was written by me) and the other is very likely still COBOL68
> as there would be no real reason to re-write it in the newer COBOL.
> They use DMS11 for their database.  A mere child when compared to
> today's databases.  Even MySQl could be used to replace it.

MySQL could probably handle the data size. Facebook use MySQL
to handle double digit PB of data.

But it will require changes to application. From what
I can read from https://en.wikipedia.org/wiki/Unisys_DMSII
then it is not in nay way compatible with a RDBMS.

Arne

On 5/11/2022 2:27 PM, Bill Gunshannon wrote:
> On 5/11/22 11:47, John Dallman wrote:
>> In article <je1opmFavjuU1@mid.individual.net>, bill.gunshannon@gmail.com
>> (Bill Gunshannon) wrote:
>>
>>> If nothing else, it proves that Legacy Systems can continue to be
>>> of value. Too bad the post DEC owners of VMS couldn't see this as
>>> we might now be in a much better position.
>>
>> VMS may not have been different enough from newer platforms to make
>> transitions painful for lots of companies.
>
> If that were the case OS2200 never would have come about. Most
> of what they run is HLL. COBOL (still a lot of 68) and Fortran.
> Any of which could be easily ported to Linux or even Windows.
> There has to be a reason so many people people stay with that
> architecture and vendor.
>

One might claim inertia, but then, that would also imply that x86 is better. I
don't think x86 should get that much of assumed advantage. But perhaps that's
just me.

>> Alpha, while excellent, wasn't all that different from other RISC
>> architectures once they were extended to 64-bit. VMS terminology isn't as
>> different from UNIX as z/OS is.
>
> VMS terminolgy compared to Unix is like English and Swahili.
> Except for the Unix terminology that has crept in to VMS,
> usually unsuccessfully, like fork(). :-)

In many ways they are very unalike. More than just the terminology. Myself, I
cannot understand why anyone would like to use Unix/Linux, but perhaps I'm
prejudiced.

--
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 5/11/2022 3:35 PM, Bill Gunshannon wrote:
> On 5/11/22 15:00, Grant Taylor wrote:
>> On 5/11/22 12:27 PM, Bill Gunshannon wrote:
>>> Any of which could be easily ported to Linux or even Windows.
>>
>> I don't buy that statement nearly as much as I once did.
>>
>> Yes, languages exist on many, if not most, platforms. However there is more
>> to programs than just the languages themselves. There are other things that
>> the platform provides which are inherently platform specific.
>
> Once again you are tying to apply VMS logic to someone else. I am
> personally aware of two very large ISes that run on OS2200. Both
> of them are over 40 years old and run pretty much as they have from
> the beginning. One I know is written in COBOL68 (because some of the
> code was written by me) and the other is very likely still COBOL68
> as there would be no real reason to re-write it in the newer COBOL.
> They use DMS11 for their database. A mere child when compared to
> today's databases. Even MySQl could be used to replace it.
>>
>> Mainframes have coupling facility at the hardware level for a very high degree
>> of clustering which is managed outside of / below the program. I'm not aware
>> of anything like VMS's disk shadowing outside of VMS. -- These are just two
>> -- hopefully -- poignantly obvious things that are fairly unique and salient
>> to the respective platforms that come to mind. I'm sure there are many more.
>
> There probably are, but we are talking legacy programs here. If they
> wanted to modify them to make use of these more modern facilities why
> would they even stay where they are?
>
>>
>> The point being that the platform provides non-portable things that programs
>> written in otherwise portable language use. So simply taking the source code
>> written in a portable language and compiling on another platform is ...
>> difficult at best.
>
> As I said, in at least one of the ISes I worked on it for a number
> of years. I know what the source looks like. I could easily port
> it to GnuCOBOL and PostGres running on BSD, Linux or even Windows.
> And yet, these people stay with Unisys (Univac) and OS2200. There
> must be a reason. Knowledge of this reason could likely be used
> to try and stem the bleeding off of VMS users.
>
> bill
>
>

Perhaps they do not see any advantages worth making any such moves.

If VMS had not lost it's "native hardware", perhaps it would also be treated
similar. Losing first VAX, then Alpha, and even itanic could be a turn off for
some people. They might think "what's next". VAX emulators seem to be useful,
so some for whatever reasons still prefer VAX.

--
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 5/11/2022 3:54 PM, Dave Froble wrote:
> On 5/11/2022 2:27 PM, Bill Gunshannon wrote:
>> There has to be a reason so many people people stay with that
>> architecture and vendor.
>
> One might claim inertia, but then, that would also imply that x86 is
> better.  I don't think x86 should get that much of assumed advantage.
> But perhaps that's just me.

I think very few people claim that x86-64 is a great CPU architecture.

But for various reasons it got the volume. And with the cost structure
in the CPU market then the high volume CPU wins.

>> VMS terminolgy compared to Unix is like English and Swahili.
>> Except for the Unix terminology that has crept in to VMS,
>> usually unsuccessfully, like fork().  :-)
>
> In many ways they are very unalike.  More than just the terminology.
> Myself, I cannot understand why anyone would like to use Unix/Linux, but
> perhaps I'm prejudiced.

The main advantage of Linux is that for the server market then
almost everybody supports it - whatever software you want to use
then it is available.

Arne

On 2022-05-11 19:00:53 +0000, Grant Taylor said:

> Mainframes have coupling facility at the hardware level for a very high
> degree of clustering which is managed outside of / below the program.

Unfamiliar with mainframes' features here, but more than a few vendors
have tried hardware clustering. And failed. StorageTech IIRC tried that
on then VAX/VMS back in the 1980s, and failed hard. The OS has the
necessary context, and needs to be involved (somehow).

> I'm not aware of anything like VMS's disk shadowing outside of VMS.

macOS has software RAID-1 built in, and the SoftRAID package is
available for Windows and macOS. ZFS, too. Lots of options. What's
comparatively unusual with OpenVMS software RAID-1 (confusingly known
as HBVS) is software shared-write multi-host RAID-1.

Of what else is available analogous to OpenVMS software RAID-1, Linux
(2.6.33 and later) DRDB is probably the closest.

The OpenVMS folks that need distributed software RAID-1 tend to be tied
to the OpenVMS view of clustering, rather than other sorts of
clustering where the data is mirrored, and not the storage volumes.
Where smaller sites can fail-over NAS or fail-over FC SAN controllers,
too.

The market for folks that need multiple hosts exists between those
fitting onto single hosts (with failover), and those that won't fit on
the he 96 (to ~150) hosts supported by OpenVMS due to geographic
requirements or scale.

And for distributed multi-host RAID, while the interconnect performance
is available. Minicopy and minimerge optimizations aside, a full copy
takes a while on many networks. Probably better to copy just the data,
and not the raw storage. Possibly entirely in memory, and not hitting
storage; replicated servers, rather than replicated disks.

The various owners of OpenVMS have long sought to profit from this
fairly unique capability—and that a decision which is entirely at their
discretion—but this profit does come at the cost of the folks not
getting tied into these features; of making many OpenVMS apps less
sticky.

Old:
https://dsf.berkeley.edu/papers/ERL-M89-56.pdf
https://people.vcu.edu/~xhe2/publications/Conferences/iRAID-SNAPI-cr.pdf

ps: kinda wonder if some of the software RAID-1 processing support
could potentially (eventually) be offloaded to a GPU/GPGPU via OpenCL
or CUDA or ilk. For the busier parts, it's slinging sectors and
comparing two streams of data. This if you can't keep it all out on the
storage controller.

--
Pure Personal Opinion | HoffmanLabs LLC

On 5/11/22 15:51, Arne Vajhøj wrote:
> On 5/11/2022 3:35 PM, Bill Gunshannon wrote:
>> On 5/11/22 15:00, Grant Taylor wrote:
>>> On 5/11/22 12:27 PM, Bill Gunshannon wrote:
>>>> Any of which could be easily ported to Linux or even Windows.
>>>
>>> I don't buy that statement nearly as much as I once did.
>>>
>>> Yes, languages exist on many, if not most, platforms.  However there
>>> is more to programs than just the languages themselves.  There are
>>> other things that the platform provides which are inherently platform
>>> specific.
>>
>> Once again you are tying to apply VMS logic to someone else.  I am
>> personally aware of two very large ISes that run on OS2200.  Both
>> of them are over 40 years old and run pretty much as they have from
>> the beginning.  One I know is written in COBOL68 (because some of the
>> code was written by me) and the other is very likely still COBOL68
>> as there would be no real reason to re-write it in the newer COBOL.
>> They use DMS11 for their database.  A mere child when compared to
>> today's databases.  Even MySQl could be used to replace it.
>
> MySQL could probably handle the data size. Facebook use MySQL
> to handle double digit PB of data.
>
> But it will require changes to application. From what
> I can read from https://en.wikipedia.org/wiki/Unisys_DMSII
> then it is not in nay way compatible with a RDBMS.

Depends on what you mean by compatible. DMS11 predates the
plethora of SQL based databases so the syntax is a little
different. But there is nothing that DMS11 does that modern
DBs can't do. Yes, some modification of the source for that
would be required but mostly trivial. What percentage of
any COBOL/Database program do you think is EXEC SQL statements?
I have seen programs with over 10,000 lines of COBOL that had
as little as 20 EXEC SQL statements.

bill