On 5/11/22 16:02, Dave Froble 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.
>>>
>>> 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.

Given a reason to do so I could point out piles of reasons to move.
That;s why I said it would be valuable to know just what makes them
stay.

In one case, I know the reason. But there are a number of others
where the reason is very unclear,

>
> 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.
>

I don't think the hardware had all that much to do with it. I
think VMS just lost it's visibility and how much people liked
it. Comes back to what I said. With IBM the answer is simple.
Customers like IBM. But with Unisys and OS2200, the question
remains what is it that customers like so much that they don't
consider moving to something more modern?

bill

On 5/11/22 2:56 PM, Stephen Hoffman wrote:
> What's comparatively unusual with OpenVMS software RAID-1 (confusingly
> known as HBVS) is software shared-write multi-host RAID-1.

The multi-host aspect is the key point that I'm referencing.

I'm not aware of any other software RAID (especially at the block level)
that is multi-host aware.

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

DRBD /might/ approach this. However I'm not aware of any DRBD
implementations that are integrated to the point that they are part of
the OS that's enabled / configured. Everything that I've looked at is
decidedly on top of the base system and decidedly atypical if not
actually custom.

> Where smaller sites can fail-over NAS or fail-over FC SAN controllers,
> too.

You start to get into the nuance of what is fail-over NAS / SAN.

Things like the EMC CLARiiON CX line tend to be dual controllers in a
single NAS / SAN. As such I tend to view them as a single shared
storage system.

Things are a little different when you start replicating between them.
But that's additional complexity.

> 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.

Replicating servers vs disks seems to end up approaching a SPOF for the
data on the disks to me.

> 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.

My concern is that the CPU would likely be involved in copying data
between the I/O controller and the GPU thus rendering the performance
gain smaller than hoped for.

> This if you can't keep it all out on the storage controller.

I don't see how a storage controller itself will be able to do anything
like the multi-host RAID 1 that volume shadows can do (as I understand
them).

--
Grant. . . .
unix || die

On 5/11/2022 11:53 AM, Grant Taylor wrote:
> 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.

Given that companies are spending two digit and three digit
millions of dollars on projects to migrate off mainframe, then
I assume that the numbers are not in favor of the mainframe.

>> 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.

A z16 has max 200 core and max 40 TB.

20 mid size servers with 2s48c and 2 TB would have 960 cores
and 40 TB. And would probably be a typical size used for a
large number of VM's.

You can buy a HPE SuperDome Flex with 32s896c and 48 TB, but I
suspect that it will be a lot more expensive than the 20
mid size servers.

Arne

On 5/11/2022 5:10 PM, Bill Gunshannon wrote:
> 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.

There is the question, what is the advantage.

My experience is that using SQL means significant changes in the basic design of
programs that do a lot of data access. The question is, why do so, if the
current application is working well.

--
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 5:19 PM, Bill Gunshannon wrote:
> On 5/11/22 16:02, Dave Froble 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.
>>>>
>>>> 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.
>
> Given a reason to do so I could point out piles of reasons to move.
> That;s why I said it would be valuable to know just what makes them
> stay.
>
> In one case, I know the reason. But there are a number of others
> where the reason is very unclear,
>
>>
>> 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.
>>
>
> I don't think the hardware had all that much to do with it. I
> think VMS just lost it's visibility and how much people liked
> it. Comes back to what I said. With IBM the answer is simple.
> Customers like IBM. But with Unisys and OS2200, the question
> remains what is it that customers like so much that they don't
> consider moving to something more modern?

Money?

Risk?

If all that is desired is to move from X to Y, there can be significant cost and
risk. For basically a sideways move, and most likely the loss of some
capabilities. If the application(s) are working just fine, then why spend money
and take such a risk. The risk has been real and killed some companies.

--
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 8:10 PM, Dave Froble wrote:
> On 5/11/2022 5:19 PM, Bill Gunshannon wrote:
>> I don't think the hardware had all that much to do with it.  I
>> think VMS just lost it's visibility and how much people liked
>> it.  Comes back to what I said.  With IBM the answer is simple.
>> Customers like IBM.  But with Unisys and OS2200, the question
>> remains what is it that customers like so much that they don't
>> consider moving to something more modern?
>
> Money?
>
> Risk?
>
> If all that is desired is to move from X to Y, there can be significant
> cost and risk.  For basically a sideways move, and most likely the loss
> of some capabilities.

The migration effort itself (ensure that the functionality is
documented, actual development work, test, project management) cost
money.

It is almost a given that the new system will have way more bugs the
first few years than the old system - and that may create business
problems. Risk.

And there is the alternate cost. The revenue loss from the system
enhancements not done during the migration. That can be significant
money.

>   If the application(s) are working just fine, then
> why spend money and take such a risk.  The risk has been real and killed
> some companies.

There are also cost and risk by not migrating.

Slower rollout of changes and high cost may impact the
companies competitiveness negatively.

If hardware/software goes EOL it could turn into
a disaster.

Arne

On 5/11/22 20:05, Dave Froble wrote:
> On 5/11/2022 5:10 PM, Bill Gunshannon wrote:
>> 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.
>
> There is the question, what is the advantage.

The advantage to what staying or moving? The advantage to moving
in some cases is reduction of cost.

>
> My experience is that using SQL means significant changes in the basic
> design of programs that do a lot of data access.  The question is, why
> do so, if the current application is working well.

Well, using the example of the programs I worked on, the access to
the data was done with embedded SELECT statements. Not a lot of
difference there. Most of the difference is in the connection and
setup for DB access. Still trivial for the programs I worked on.

Why change if the application is working well. Cost of the
hardware needed to run it is one. The program was written for
a UNIVAC 1100. My wristwatch is more powerful. And a fraction
of the cost. Pretty much any server class PC box would run
circles around it. What do you think the difference in price
is between a Server Class PC and the smallest mainframe they
offer? And then there is the difference that can apply to
VMS as well. How many experienced/trained/competent UNISYS
2200 programmers, DBAs and sys admins do you think are running
around out there today? Back in the (very) early 80's when I
was still doing Univac DBAs were rare and highly valued. We
lost ours to the IRS. The IRS Univac DBA was the highest paid
IT position in the government at the time. Finding a PostGres
or MySQL DBA would be a lot easier and cheaper.

So, we still come back to the big question. Why do customers stay
with UNISYS? Don't know how to answer that one.

bill

On 5/11/22 20:10, Dave Froble wrote:
> On 5/11/2022 5:19 PM, Bill Gunshannon wrote:
>> On 5/11/22 16:02, Dave Froble 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.
>>>>>
>>>>> 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.
>>
>> Given a reason to do so I could point out piles of reasons to move.
>> That;s why I said it would be valuable to know just what makes them
>> stay.
>>
>> In one case, I know the reason.  But there are a number of others
>> where the reason is very unclear,
>>
>>>
>>> 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.
>>>
>>
>> I don't think the hardware had all that much to do with it.  I
>> think VMS just lost it's visibility and how much people liked
>> it.  Comes back to what I said.  With IBM the answer is simple.
>> Customers like IBM.  But with Unisys and OS2200, the question
>> remains what is it that customers like so much that they don't
>> consider moving to something more modern?
>
> Money?

The hardware alone would cost a fraction of the current amount.
The salaries of people working with common systems tend to run
a lot lower than the salaries of people with skillsets that are
rare.

>
> Risk?

Again, I am talking here about a system I, personally, know rather
intimately. The program is not difficult to understand. Doesn't
do anything with smoke and mirrors. Is very well documented. The
risk of moving it would be minimal and could even be done in parallel
until one was sure the new version was ready.

>
> If all that is desired is to move from X to Y, there can be significant
> cost and risk.  For basically a sideways move, and most likely the loss
> of some capabilities.

Loss of capabilities? We are talking about moving from 1980 to 2022.
What possible capability could they have had then that they would not
have now.

> If the application(s) are working just fine, then
> why spend money and take such a risk.

Because the risk is less than minimal and the savings huge.

> The risk has been real and killed
> some companies.

Yes, and usually it didn't involve a simple move it involved a
complete redesign of a badly documented system done by people
who didn't have a clue. Often sold to management by a snakeoil
salesman.

bill

On 5/11/22 20:17, Arne Vajhøj wrote:
> On 5/11/2022 8:10 PM, Dave Froble wrote:
>> On 5/11/2022 5:19 PM, Bill Gunshannon wrote:
>>> I don't think the hardware had all that much to do with it.  I
>>> think VMS just lost it's visibility and how much people liked
>>> it.  Comes back to what I said.  With IBM the answer is simple.
>>> Customers like IBM.  But with Unisys and OS2200, the question
>>> remains what is it that customers like so much that they don't
>>> consider moving to something more modern?
>>
>> Money?
>>
>> Risk?
>>
>> If all that is desired is to move from X to Y, there can be
>> significant cost and risk.  For basically a sideways move, and most
>> likely the loss of some capabilities.
>
> The migration effort itself (ensure that the functionality is
> documented, actual development work, test, project management) cost
> money.

Mainframes cost money. People with scarce talents cost money.
Everything costs money. One has to look at which costs more money.

>
> It is almost a given that the new system will have way more bugs the
> first few years than the old system - and that may create business
> problems. Risk.

If the major part of the move involves little more than recompiling
a COBOL program where are all these new bugs going to come from?

>
> And there is the alternate cost. The revenue loss from the system
> enhancements not done during the migration. That can be significant
> money.

What makes you think there are "system enhancements" being done?
Everybody keeps saying "If it ain't broke don't fix it." In the
example I have been talking about the actual task to be done hasn't
changed in decades. The only changes one might see is a change
in the score desired for selection of candidates. Nothing changes
in the logic.

In another example from my personal experience after I left they
were unable to hire anyone with COBOL experience to take over the
position. They stopped trying. And that also meant they stopped
accepting System Change Requests for any of the COBOL programs. :-)
The programs continue to run today as I left them.

>
>>                       If the application(s) are working just fine,
>> then why spend money and take such a risk.  The risk has been real and
>> killed some companies.
>
> There are also cost and risk by not migrating.

Yes, as I stated above. and in other messages.

>
> Slower rollout of changes and high cost may impact the
> companies competitiveness negatively.

Luckily, in my two examples that does not apply. Neither of them
have competitors. :-)

>
> If hardware/software goes EOL it could turn into
> a disaster.

So now I am confused. You have come down on both sides of the argument.
Not sure where you actually stand.

bill

On 5/11/2022 8:46 PM, Bill Gunshannon wrote:
> On 5/11/22 20:17, Arne Vajhøj wrote:
>> It is almost a given that the new system will have way more bugs the
>> first few years than the old system - and that may create business
>> problems. Risk.
>
> If the major part of the move involves little more than recompiling
> a COBOL program where are all these new bugs going to come from?

Just recompiling is probably not the case for most.

Otherwise they probably would have migrated.

>> And there is the alternate cost. The revenue loss from the system
>> enhancements not done during the migration. That can be significant
>> money.
>
> What makes you think there are "system enhancements" being done?
> Everybody keeps saying "If it ain't broke don't fix it."  In the
> example I have been talking about the actual task to be done hasn't
> changed in decades.  The only changes one might see is a change
> in the score desired for selection of candidates.  Nothing changes
> in the logic.
>
> In another example from my personal experience after I left they
> were unable to hire anyone with COBOL experience to take over the
> position.  They stopped trying.  And that also meant they stopped
> accepting System Change Requests for any of the COBOL programs. :-)
> The programs continue to run today as I left them.

Wanting to update the system to stay competitive is quite common
for private businesses.

Government systems do not need to worry about that. But they need
to worry about an endless stream of changes to rules being
made by the politicians.

>> If hardware/software goes EOL it could turn into
>> a disaster.
>
> So now I am confused.  You have come down on both sides of the argument.
> Not sure where you actually stand.

It is not like it is never good to migrate or it is always good
to migrate.

It is an evaluation for the specific application, the specific
migration target and the specific point in time. One evaluate
the risks and costs of migrating and the risks and costs of
not migrating and make a decision. In a few years the evaluation
need to be done again, because the world constantly change.

There are actually people that get paid to do such analysis.

As a rule of thumb then the arguments for migrating get stronger
over time and the arguments for not migrating get weaker over time.
At some point in time the migration becomes a good idea.

If you are good at doing that analysis and pick the right
time to migrate, then you will have a great career as CIO
ahead of you. It is not easy.

Arne

On 11/05/2022 13:40, Arne Vajhøj wrote:
> 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.

IBM of course have the answer to that. Just as in the days of the NT
only Alpha boxes, IBM have differential pricing for CPUs for running
Z/OS and CPUs running Linux. They are known as "Integrated Facility for
Linux" or IFL CPUs. They are exactly the same as "normal" CPU except
they won't run zOS and they are a lot cheaper.

https://www.ibm.com/products/integrated-facility-for-linux

IBM actually now offer several other specialist CPUs and in 2009 Neon
announced products to allow Z work to run on these..

https://www.theregister.com/Print/2009/07/08/neon_zprime_mainframe/

NEON is no more...

>
>> 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
>

I believe that UK Air Traffic Control still uses a Z box under the
covers for which there is a special OS....

Dave

On 5/11/2022 1:51 PM, Arne Vajhøj wrote:
> <snip>
>
> 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.
>
>

It's been many years since I've done anything with DMSII, but as I
recall, it was possible to use it to implement a relational database
with decent performance. It was also possible to create hierarchical
databases (and maybe even network databases) and of course it was easy
to do all sorts of things that would have terrible performance. (I was a
Burroughs technical rep in 1975 and I could tell you stories.)

How hard would it be to switch from using DMSII to an RDBMS used today?
The answer would depend on what the DMSII database looked like and how
it was being used. I haven't seen any SQL documentation that isn't
reminiscent of a relational model built using DMSII, but as always, the
devil is in the details.

Louis

On 5/11/22 21:41, Arne Vajhøj wrote:
> On 5/11/2022 8:46 PM, Bill Gunshannon wrote:
>> On 5/11/22 20:17, Arne Vajhøj wrote:
>>> It is almost a given that the new system will have way more bugs the
>>> first few years than the old system - and that may create business
>>> problems. Risk.
>>
>> If the major part of the move involves little more than recompiling
>> a COBOL program where are all these new bugs going to come from?
>
> Just recompiling is probably not the case for most.

At least in the case of COBOL, with only minor changes to allow
for file naming conventions, it actually is. And with Fortran
even more so.

>
> Otherwise they probably would have migrated.

Which brings us back to the question why are so many Univac customers
still with Unisys? Just what do they offer that makes it worthwhile
to remain? Something that could be of value to the future of VMS.

>
>>> And there is the alternate cost. The revenue loss from the system
>>> enhancements not done during the migration. That can be significant
>>> money.
>>
>> What makes you think there are "system enhancements" being done?
>> Everybody keeps saying "If it ain't broke don't fix it."  In the
>> example I have been talking about the actual task to be done hasn't
>> changed in decades.  The only changes one might see is a change
>> in the score desired for selection of candidates.  Nothing changes
>> in the logic.
>>
>> In another example from my personal experience after I left they
>> were unable to hire anyone with COBOL experience to take over the
>> position.  They stopped trying.  And that also meant they stopped
>> accepting System Change Requests for any of the COBOL programs. :-)
>> The programs continue to run today as I left them.
>
> Wanting to update the system to stay competitive is quite common
> for private businesses.
>
> Government systems do not need to worry about that. But they need
> to worry about an endless stream of changes to rules being > made by the politicians.

Depends on what the program actually does. Some things never change.
The two examples I was personally involved in that I have mentioned
here are just two examples of that. The latter one having run with
no one to make modifications for at least 10 years now.

>
>>> If hardware/software goes EOL it could turn into
>>> a disaster.
>>
>> So now I am confused.  You have come down on both sides of the argument.
>> Not sure where you actually stand.
>
> It is not like it is never good to migrate or it is always good
> to migrate.
>
> It is an evaluation for the specific application, the specific
> migration target and the specific point in time. One evaluate
> the risks and costs of migrating and the risks and costs of
> not migrating and make a decision. In a few years the evaluation
> need to be done again, because the world constantly change.
>
> There are actually people that get paid to do such analysis.
>
> As a rule of thumb then the arguments for migrating get stronger
> over time and the arguments for not migrating get weaker over time.
> At some point in time the migration becomes a good idea.
>
> If you are good at doing that analysis and pick the right
> time to migrate, then you will have a great career as CIO
> ahead of you. It is not easy.

And we are back once again. The cost of running a Unisys Mainframe
have risen and continue to rise. The cost of alternatives (VMS could
actually be one of those alternatives!) continues to drop. The cost
of people with the skills to work those Unisys Mainframes continues
to rise as the pool of qualified people continues to drop. the cost
of people qualified to work with the alternatives continues to drop.

So, what is it that Unisys offers that keeps those customers coming
back?

bill

On 2022-05-11, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> 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.
>

The reason could be something as simple as the reason why (for example)
train companies continue to run decades-old rolling stock alongside
more modern rolling stock.

Ie: it works, it's reliable, it's a known quantity and it's in no
danger of suddenly not working one day.

VMS has the first three qualities, but not the 4th one (for multiple
reasons, ranging from new security threats to VSI licence policies).

Simon.

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

On 2022-05-11, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>
> 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.
>

Do graphics cards in general have ECC memory ?

Some appear to do so, but I can't tell if the majority of them do.

Simon.

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

On 5/12/22 08:55, Simon Clubley wrote:
> On 2022-05-11, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>
>> 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.
>>
>
> The reason could be something as simple as the reason why (for example)
> train companies continue to run decades-old rolling stock alongside
> more modern rolling stock.

Sorry, makes no sense. Old rolling stock costs nothing. Running any
mainframe costs a lot.

>
> Ie: it works, it's reliable, it's a known quantity and it's in no
> danger of suddenly not working one day.
>
> VMS has the first three qualities, but not the 4th one (for multiple
> reasons, ranging from new security threats to VSI licence policies).
>

1,2 and 3 can apply. #4 is just as much a threat for OS2200 as it
is for VMS and any other legacy system. (Well, except probably for
IBM. :-))

bill

On 2022-05-12 12:58:22 +0000, Simon Clubley said:

> On 2022-05-11, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>
>> 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.
>>
>
> Do graphics cards in general have ECC memory ?

Graphics controllers in general? No. ECC is omitted in most (all?)
low-end and embedded graphics, same as ECC is largely omitted by Intel
below Xeon. CUDA and related hardware aimed at HPC do offer ECC. And
whether the offloading goes to the network controller, or storage
controller, or elsewhere? VSI isn't going to implement their own
hardware to provide that, but whether—some years from now, shortly
ahead of the OpenVMS port to AArch64—they add software support for
then-available hardware accelerators?

The offloading that's happening now for running ML and for offloading
other specific tasks—mixed-speed cores, and heterogeneous processors,
and embedded GPUs—all involve using hardware features simply not found
on older OpenVMS hardware.

Ancient ECC history: "Parity is for farmers" and "Apparently a lot of
farmers buy computers". Why mention that era? If you're fast enough,
maybe run it again. And in this case, you're probably already dealing
with ECC memory (Xeon, etc), and (again, in this case) a transient data
comparison error in a GPGPU or other offload means you copy an extra
sector, which is hardly a serious issue—absent lots of errors...

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-05-12, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 5/12/22 08:55, Simon Clubley wrote:
>> On 2022-05-11, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>>
>>> 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.
>>>
>>
>> The reason could be something as simple as the reason why (for example)
>> train companies continue to run decades-old rolling stock alongside
>> more modern rolling stock.
>
> Sorry, makes no sense. Old rolling stock costs nothing. Running any
> mainframe costs a lot.
>

Oh, but that is most certainly _not_ the case. :-)

Old rolling stock has ongoing maintenance and safety inspection costs.

You also have additional costs to consider as external factors cause
a change in the operating conditions of the old rolling stock.

For example, what do you do when automated signalling is introduced
on the lines the old rolling stock is running on ? Do you move them
onto other lines or invest in upgrading them ?

The example I gave is a lot closer to maintaining old systems than
it would appear at first glance... :-)

Simon.

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

On 5/12/2022 7:36 AM, Bill Gunshannon wrote:
> On 5/11/22 21:41, Arne Vajhøj wrote:
>> On 5/11/2022 8:46 PM, Bill Gunshannon wrote:
>>> On 5/11/22 20:17, Arne Vajhøj wrote:
>>>> It is almost a given that the new system will have way more bugs the
>>>> first few years than the old system - and that may create business
>>>> problems. Risk.
>>>
>>> If the major part of the move involves little more than recompiling
>>> a COBOL program where are all these new bugs going to come from?
>>
>> Just recompiling is probably not the case for most.
>
> At least in the case of COBOL, with only minor changes to allow
> for file naming conventions, it actually is.  And with Fortran
> even more so.

I don't believe that.

Why do you think there is an entire industry around
moving Cobol programs from mainframe to newer platforms?
Because companies can't change file names and recompile??

Arne

On 13/05/2022 2:01 am, Simon Clubley wrote:
> On 2022-05-12, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 5/12/22 08:55, Simon Clubley wrote:
>>> On 2022-05-11, Bill Gunshannon <bill.gunshannon@gmail.com>
>>> wrote:
>>>>
>>>> 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.
>>>>
>>>
>>> The reason could be something as simple as the reason why (for
>>> example) train companies continue to run decades-old rolling
>>> stock alongside more modern rolling stock.
>>
>> Sorry, makes no sense. Old rolling stock costs nothing. Running
>> any mainframe costs a lot.
>>
>
> Oh, but that is most certainly _not_ the case. :-)
>
> Old rolling stock has ongoing maintenance and safety inspection
> costs.
>
> You also have additional costs to consider as external factors cause
> a change in the operating conditions of the old rolling stock.
>
> For example, what do you do when automated signalling is introduced
> on the lines the old rolling stock is running on ? Do you move them
> onto other lines or invest in upgrading them ?
>
> The example I gave is a lot closer to maintaining old systems than it
> would appear at first glance... :-)
>
> Simon.
>

Just be in the UK when the govt privatize the railways and needs someone
to give the rolling stock to. You and your mates set up a company with
just GBP15K each and then all the new companies have to lease it off you
at a huge profit.

The same/successive govts that you keep unsafe slam-door rolling stock
going into the 21st century. Maintenance my arse.

On 5/12/22 14:01, Simon Clubley wrote:
> On 2022-05-12, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 5/12/22 08:55, Simon Clubley wrote:
>>> On 2022-05-11, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>>>
>>>> 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.
>>>>
>>>
>>> The reason could be something as simple as the reason why (for example)
>>> train companies continue to run decades-old rolling stock alongside
>>> more modern rolling stock.
>>
>> Sorry, makes no sense. Old rolling stock costs nothing. Running any
>> mainframe costs a lot.
>>
>
> Oh, but that is most certainly _not_ the case. :-)
>
> Old rolling stock has ongoing maintenance and safety inspection costs.

Sorry, I should have said that old rolling stock has less costs.
New rolling stock has maintenance costs, too, but also has the
cost of purchase over the already paid for (and costs recovered
thru depreciation) old rolling stock.

>
> You also have additional costs to consider as external factors cause
> a change in the operating conditions of the old rolling stock.
>
> For example, what do you do when automated signalling is introduced
> on the lines the old rolling stock is running on ? Do you move them
> onto other lines or invest in upgrading them ?
>
> The example I gave is a lot closer to maintaining old systems than
> it would appear at first glance... :-)

Cute conversation but it just points out how badly this example
compares to discussing mainframes. :-)

bill

On 5/12/22 20:52, Arne Vajhøj wrote:
> On 5/12/2022 7:36 AM, Bill Gunshannon wrote:
>> On 5/11/22 21:41, Arne Vajhøj wrote:
>>> On 5/11/2022 8:46 PM, Bill Gunshannon wrote:
>>>> On 5/11/22 20:17, Arne Vajhøj wrote:
>>>>> It is almost a given that the new system will have way more bugs the
>>>>> first few years than the old system - and that may create business
>>>>> problems. Risk.
>>>>
>>>> If the major part of the move involves little more than recompiling
>>>> a COBOL program where are all these new bugs going to come from?
>>>
>>> Just recompiling is probably not the case for most.
>>
>> At least in the case of COBOL, with only minor changes to allow
>> for file naming conventions, it actually is.  And with Fortran
>> even more so.
>
> I don't believe that.
>
> Why do you think there is an entire industry around
> moving Cobol programs from mainframe to newer platforms?

Because it's an easy target. Managers today have all heard of
Java and Python. Most have probably never heard of COBOL or
seen so much as on example. There is more money to be made in
getting people to move, whether it is a good idea or not, than
letting them stay with their perfectly functioning "Legacy"
systems. Haven't all VMS people learned that lesson yet.

> Because companies can't change file names and recompile??

It was probably an over simplification, but I have done a lot
of COBOL System moves in my private research and it is a damn
sight easier to move a Primos COBOL Program (or a VMS COBOL
program) to a new system like GnuCOBOL on Windows, BSD or Linux
than it is to re-write the entire thing into a newer language
like Java or Python.

bill

On 5/19/2022 10:40 AM, Bill Gunshannon wrote:
> On 5/12/22 20:52, Arne Vajhøj wrote:
>> On 5/12/2022 7:36 AM, Bill Gunshannon wrote:
>>> On 5/11/22 21:41, Arne Vajhøj wrote:
>>>> On 5/11/2022 8:46 PM, Bill Gunshannon wrote:
>>>>> On 5/11/22 20:17, Arne Vajhøj wrote:
>>>>>> It is almost a given that the new system will have way more bugs the
>>>>>> first few years than the old system - and that may create business
>>>>>> problems. Risk.
>>>>>
>>>>> If the major part of the move involves little more than recompiling
>>>>> a COBOL program where are all these new bugs going to come from?
>>>>
>>>> Just recompiling is probably not the case for most.
>>>
>>> At least in the case of COBOL, with only minor changes to allow
>>> for file naming conventions, it actually is.  And with Fortran
>>> even more so.
>>
>> I don't believe that.
>>
>> Why do you think there is an entire industry around
>> moving Cobol programs from mainframe to newer platforms?
>
> Because it's an easy target.  Managers today have all heard of
> Java and Python.  Most have probably never heard of COBOL or
> seen so much as on example.  There is more money to be made in
> getting people to move, whether it is a good idea or not, than
> letting them stay with their perfectly functioning "Legacy"
> systems.

I was talking about migrating from Cobol/mainframe to
Cobol/non-mainframe above.

Which is what is relevant for the "just recompile"
discussion.

There are also those that migrate from Cobol/mainframe
to newer language/non-mainframe.

But that does not really say anything about Cobol
code portability.

Arne

On 5/19/22 21:22, Arne Vajhøj wrote:
> On 5/19/2022 10:40 AM, Bill Gunshannon wrote:
>> On 5/12/22 20:52, Arne Vajhøj wrote:
>>> On 5/12/2022 7:36 AM, Bill Gunshannon wrote:
>>>> On 5/11/22 21:41, Arne Vajhøj wrote:
>>>>> On 5/11/2022 8:46 PM, Bill Gunshannon wrote:
>>>>>> On 5/11/22 20:17, Arne Vajhøj wrote:
>>>>>>> It is almost a given that the new system will have way more bugs the
>>>>>>> first few years than the old system - and that may create business
>>>>>>> problems. Risk.
>>>>>>
>>>>>> If the major part of the move involves little more than recompiling
>>>>>> a COBOL program where are all these new bugs going to come from?
>>>>>
>>>>> Just recompiling is probably not the case for most.
>>>>
>>>> At least in the case of COBOL, with only minor changes to allow
>>>> for file naming conventions, it actually is.  And with Fortran
>>>> even more so.
>>>
>>> I don't believe that.
>>>
>>> Why do you think there is an entire industry around
>>> moving Cobol programs from mainframe to newer platforms?
>>
>> Because it's an easy target.  Managers today have all heard of
>> Java and Python.  Most have probably never heard of COBOL or
>> seen so much as on example.  There is more money to be made in
>> getting people to move, whether it is a good idea or not, than
>> letting them stay with their perfectly functioning "Legacy"
>> systems.
>
> I was talking about migrating from Cobol/mainframe to
> Cobol/non-mainframe above.

In many of the cases I have played with that is more trivial than
you imagine. I have done a few (mostly trivial example programs
as no one is likely to give me production code to play with) in
my research.

>
> Which is what is relevant for the "just recompile"
> discussion.
>
> There are also those that migrate from Cobol/mainframe
> to newer language/non-mainframe.

That's a potential disaster no matter what.

>
> But that does not really say anything about Cobol
> code portability.

Probably one of the most portable languages ever devised.

bill

On 5/19/2022 9:27 PM, Bill Gunshannon wrote:
> On 5/19/22 21:22, Arne Vajhøj wrote:
>> On 5/19/2022 10:40 AM, Bill Gunshannon wrote:
>>> On 5/12/22 20:52, Arne Vajhøj wrote:
>>>> On 5/12/2022 7:36 AM, Bill Gunshannon wrote:
>>>>> On 5/11/22 21:41, Arne Vajhøj wrote:
>>>>>> On 5/11/2022 8:46 PM, Bill Gunshannon wrote:
>>>>>>> On 5/11/22 20:17, Arne Vajhøj wrote:
>>>>>>>> It is almost a given that the new system will have way more bugs
>>>>>>>> the
>>>>>>>> first few years than the old system - and that may create business
>>>>>>>> problems. Risk.
>>>>>>>
>>>>>>> If the major part of the move involves little more than recompiling
>>>>>>> a COBOL program where are all these new bugs going to come from?
>>>>>>
>>>>>> Just recompiling is probably not the case for most.
>>>>>
>>>>> At least in the case of COBOL, with only minor changes to allow
>>>>> for file naming conventions, it actually is.  And with Fortran
>>>>> even more so.
>>>>
>>>> I don't believe that.
>>>>
>>>> Why do you think there is an entire industry around
>>>> moving Cobol programs from mainframe to newer platforms?
>>>
>>> Because it's an easy target.  Managers today have all heard of
>>> Java and Python.  Most have probably never heard of COBOL or
>>> seen so much as on example.  There is more money to be made in
>>> getting people to move, whether it is a good idea or not, than
>>> letting them stay with their perfectly functioning "Legacy"
>>> systems.
>>
>> I was talking about migrating from Cobol/mainframe to
>> Cobol/non-mainframe above.
>
> In many of the cases I have played with that is more trivial than
> you imagine.  I have done a few (mostly trivial example programs
> as no one is likely to give me production code to play with) in
> my research.

Sure.

But there are companies out there that do it for living.
Porting real applications for real companies.

I doubt they would exist if it was so easy.

>> Which is what is relevant for the "just recompile"
>> discussion.
>>
>> There are also those that migrate from Cobol/mainframe
>> to newer language/non-mainframe.
>
> That's a potential disaster no matter what.

There are success stories doing that.

>> But that does not really say anything about Cobol
>> code portability.
>
> Probably one of the most portable languages ever devised.

Maybe one of the most portable languages invented before
1990.

Many newer languages are way more standardized and
well defined in semantics. Today it is quite common
to have dev on one platform and test and production
on another platform - it works. For many newer
languages.

Arne