On 5/19/22 21:42, Arne Vajhøj wrote:
> 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.

Of course they would. But not for the reason you would think.
Too many places let their IT departments die by attrition and
now no longer have the staff to even handle maintenance on
their legacy stuff. Places that do are the ones not looking
to port in most cases. The whole idea of porting is usually
brought up by the sbake oil salesdroids.

>
> I doubt they would exist if it was so easy.

Depends on your definition of "porting". I doubt you will find
many (any?) companies offering to port COBOL on VMS to COBOL on
Unix or Windows. What you will find is companies offering to
port COBOL to some language du jour on another platform. Where
is the money? In a one week COBOL -> COBOL port or in a 6 month
or even a year COBOL -> JAVA project.

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

I am sure there are. But it seems like we read about the
failures quite regularly in the trade rags. Over time.
Over Budget. Bug ridden replacements for functional legacy
systems. I am tracking one now. A massive COBOL application
being replaced by a total re-write in some other language.
It is already behind schedule and has a lot of problems in
the first run. But it's government so they will let the
contractor drag this on and offer an almost endless trough
of money for them to belly up to.

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

Even Ada can't make that claim. There are features in Ada
that the even the standard allows to function differently
on different implementations. Implementors choice.

> Today it is quite common
> to have dev on one platform and test and production
> on another platform - it works. For many newer
> languages.

I do Arduino development. While the compiler is on a PC you
can not develop without having an Arduino hooked up to your
development system. In the old days it was quite common to
have an emulator on your development system to test your
work as you went along the development path. Not really much
different except that the targets got physically smaller, the
communications got better and we now use the real thing.

bill

On 5/20/2022 8:59 AM, Bill Gunshannon wrote:
> On 5/19/22 21:42, Arne Vajhøj wrote:
>> On 5/19/2022 9:27 PM, Bill Gunshannon wrote:
>>> On 5/19/22 21:22, Arne Vajhøj wrote:
>>>> 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.
>
> Of course they would.  But not for the reason you would think.
> Too many places let their IT departments die by attrition and
> now no longer have the staff to even handle maintenance on
> their legacy stuff.  Places that do are the ones not looking
> to port in most cases.  The whole idea of porting is usually
> brought up by the sbake oil salesdroids.
>
>> I doubt they would exist if it was so easy.
>
> Depends on your definition of "porting".  I doubt you will find
> many (any?) companies offering to port COBOL on VMS to COBOL on
> Unix or Windows.

I have not heard about companies porting Cobol/VMS to
Cobol/Linux. But there are companies doing Cobol/IBM mainframe
to Cobol/Linux and even Cobol/Unisys mainframe to Cobol/Linux.

>   What you will find is companies offering to
> port COBOL to some language du jour on another platform.  Where
> is the money?  In a one week COBOL -> COBOL port or in a 6 month
> or even a year COBOL -> JAVA project.

I don't think you will see those one week Cobol to Cobol
ports in the real world.

The benefits from changing language are:
* reduced risk of skills shortage
* faster changes
* new capabilities typical relate dto integration

>>>> 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.
>
> Even Ada can't make that claim.  There are features in Ada
> that the even the standard allows to function differently
> on different implementations.  Implementors choice.

I was not thinking about Ada - it is not really a newer language.

Languages today have well defined data types like a short is 16
bit, int is 32 bit, long is 64 bit, all two's complement, FP
are IEEE. Practically all operations have precise defined
behavior - no undefined or implementation specific behavior.

>>                            Today it is quite common
>> to have dev on one platform and test and production
>> on another platform - it works. For many newer
>> languages.
>
> I do Arduino development.  While the compiler is on a PC you
> can not develop without having an Arduino hooked up to your
> development system.  In the old days it was quite common to
> have an emulator on your development system to test your
> work as you went along the development path.  Not really much
> different except that the targets got physically smaller, the
> communications got better and we now use the real thing.

Cross compiling and testing in emulator is something
completely different from a language being so portable
that you can develop on a different platform than target.
In fact the existence of the emulator proves that the
code is not portable, because otherwise it would not
be needed.

Arne

On 5/20/22 11:39, Arne Vajhøj wrote:
> On 5/20/2022 8:59 AM, Bill Gunshannon wrote:
>> On 5/19/22 21:42, Arne Vajhøj wrote:
>>> On 5/19/2022 9:27 PM, Bill Gunshannon wrote:
>>>> On 5/19/22 21:22, Arne Vajhøj wrote:
>>>>> 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.
>>
>> Of course they would.  But not for the reason you would think.
>> Too many places let their IT departments die by attrition and
>> now no longer have the staff to even handle maintenance on
>> their legacy stuff.  Places that do are the ones not looking
>> to port in most cases.  The whole idea of porting is usually
>> brought up by the sbake oil salesdroids.
>>
>>> I doubt they would exist if it was so easy.
>>
>> Depends on your definition of "porting".  I doubt you will find
>> many (any?) companies offering to port COBOL on VMS to COBOL on
>> Unix or Windows.
>
> I have not heard about companies porting Cobol/VMS to
> Cobol/Linux. But there are companies doing Cobol/IBM mainframe
> to Cobol/Linux and even Cobol/Unisys mainframe to Cobol/Linux.

Porting COBOL from one system to another is something I have played
with. I have yet to find a case where the COBOL (not DB or CICS or
any other add on) took more than a couple hours to port. Almost
all of the commercial offerings (especially contracting projects
like for the government) mean COBOL to some other "modern" language.

>
>>                      What you will find is companies offering to
>> port COBOL to some language du jour on another platform.  Where
>> is the money?  In a one week COBOL -> COBOL port or in a 6 month
>> or even a year COBOL -> JAVA project.
>
> I don't think you will see those one week Cobol to Cobol
> ports in the real world.

Don't see why not. Unless the COBOL is not really COBOL but
a high percentage of non-COBOL add ons. Even EXEC SQL statements
translate very well between different SQL Databases. Of course,
prolonging the job just means more money.

>
> The benefits from changing language are:
> * reduced risk of skills shortage

This one is true bu there is still hope the problem can be fixed.

> * faster changes

Don't get this one. Can't see how making minor changes to the COBOL
would be slower than re-writting in Python.

> * new capabilities typical relate dto integration

But if the original legacy program didn't need them maybe they
aren't really needed at all. If they are then one should seriously
consider scrapping the original and writing a new program and not
doing a port at all.

>
>>>>> 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.
>>
>> Even Ada can't make that claim.  There are features in Ada
>> that the even the standard allows to function differently
>> on different implementations.  Implementors choice.
>
> I was not thinking about Ada - it is not really a newer language.

Well, it's newer than COBOL, Fortran, Pascal, PL/I and Algol.

>
> Languages today have well defined data types like a short is 16
> bit, int is 32 bit, long is 64 bit, all two's complement, FP
> are IEEE. Practically all operations have precise defined
> behavior - no undefined or implementation specific behavior.

Hmmm... Not sure I agree 100% with this.

>
>>>                            Today it is quite common
>>> to have dev on one platform and test and production
>>> on another platform - it works. For many newer
>>> languages.
>>
>> I do Arduino development.  While the compiler is on a PC you
>> can not develop without having an Arduino hooked up to your
>> development system.  In the old days it was quite common to
>> have an emulator on your development system to test your
>> work as you went along the development path.  Not really much
>> different except that the targets got physically smaller, the
>> communications got better and we now use the real thing.
>
> Cross compiling and testing in emulator is something
> completely different from a language being so portable
> that you can develop on a different platform than target.
> In fact the existence of the emulator proves that the
> code is not portable, because otherwise it would not
> be needed.

Well, that was an old idea. It didn't sell at the time it came
out either. Took a couple decades to catch on. UCSD-Pascal - write
once run on anything. But, like Java, portability depended on the
various systems having the same capabilities. Like Graphics.

bill

On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
> On 5/20/22 11:39, Arne Vajhøj wrote:
>> On 5/20/2022 8:59 AM, Bill Gunshannon wrote:
>>> On 5/19/22 21:42, Arne Vajhøj wrote:
>>>>                            Today it is quite common
>>>> to have dev on one platform and test and production
>>>> on another platform - it works. For many newer
>>>> languages.
>>>
>>> I do Arduino development.  While the compiler is on a PC you
>>> can not develop without having an Arduino hooked up to your
>>> development system.  In the old days it was quite common to
>>> have an emulator on your development system to test your
>>> work as you went along the development path.  Not really much
>>> different except that the targets got physically smaller, the
>>> communications got better and we now use the real thing.
>>
>> Cross compiling and testing in emulator is something
>> completely different from a language being so portable
>> that you can develop on a different platform than target.
>> In fact the existence of the emulator proves that the
>> code is not portable, because otherwise it would not
>> be needed.
>
> Well, that was an old idea.  It didn't sell at the time it came
> out either.  Took a couple decades to catch on.  UCSD-Pascal - write
> once run on anything.  But, like Java, portability depended on the
> various systems having the same capabilities.  Like Graphics.

It works today.

I would guess that 2/3 of all the worlds developers
develop and test (not via simulator) on a different
platform than their final target.

Java, PHP, Python, JavaScript etc. developers write their
code on Windows or macOS and deploy on Linux.

Arne

On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
> On 5/20/22 11:39, Arne Vajhøj wrote:
>> The benefits from changing language are:
>> * reduced risk of skills shortage
>
> This one is true bu there is still hope the problem can be fixed.
>
>> * faster changes
>
> Don't get this one.  Can't see how making minor changes to the COBOL
> would be slower than re-writting in Python.

* more powerful language (fewer lines of code per functionality)
* more powerful libraries
* better isolation making changes less risky [not sure whether
that applies to Python - consider that more a JVM / CLR
language thing]
* better tooling
* different mindset among the developers

>> * new capabilities typical relate dto integration
>
> But if the original legacy program didn't need them maybe they
> aren't really needed at all.

Most companies has a long list of things they would like to
do.

>   If they are then one should seriously
> consider scrapping the original and writing a new program and not
> doing a port at all.

The difference between porting an old program from one language
to another very different language and writing a new program in
the the other languages is pretty small.

Arne

On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
> On 5/20/22 11:39, Arne Vajhøj wrote:
>> On 5/20/2022 8:59 AM, Bill Gunshannon wrote:
>>> Depends on your definition of "porting".  I doubt you will find
>>> many (any?) companies offering to port COBOL on VMS to COBOL on
>>> Unix or Windows.
>>
>> I have not heard about companies porting Cobol/VMS to
>> Cobol/Linux. But there are companies doing Cobol/IBM mainframe
>> to Cobol/Linux and even Cobol/Unisys mainframe to Cobol/Linux.
>
> Porting COBOL from one system to another is something I have played
> with.  I have yet to find a case where the COBOL (not DB or CICS or
> any other add on) took more than a couple hours to port.  Almost
> all of the commercial offerings (especially contracting projects
> like for the government) mean COBOL to some other "modern" language.
>
>>
>>>                      What you will find is companies offering to
>>> port COBOL to some language du jour on another platform.  Where
>>> is the money?  In a one week COBOL -> COBOL port or in a 6 month
>>> or even a year COBOL -> JAVA project.
>>
>> I don't think you will see those one week Cobol to Cobol
>> ports in the real world.
>
> Don't see why not.  Unless the COBOL is not really COBOL but
> a high percentage of non-COBOL add ons.  Even EXEC SQL statements
> translate very well between different SQL Databases.  Of course,
> prolonging the job just means more money.

If system migration is just taking a Cobol program with
mostly ANSI Cobol and get it to build and run on a new platform
then it is not a big thing.

But that is not how a system migration look like in
real life.

You have N Cobol pieces, X relational databases,
Y ISAM files, Z integration with other things
(transaction monitors, message queues, external
data dictionaries etc.), W cases of platform specific
Cobol extensions and M pieces in assembler
or some system dependent language.

The relational database will typical change. So
X database definition need to be created for the new
database.

Then X tools to migrate database data has to be written (can likely
be done in something more high level than Cobol).

Then embedded SQL in NX pieces of Cobol need to be checked and
possible modified.

The Y ISAM file definitions need to be tested for
portability to target platform.

Y tools to migrate ISAM file data has to be written (most
likely written in Cobol).

The ISAM file access in NY pieces of Cobol need to
be checked andpossible modified.

The other integration stuff need to be rewritten in
NZ pieces of Cobol.

The platform specific extension need to be rewritten in NW
pieces of Cobol.

The M pieces of whatever need to be rewritten to most
likely C on the target platform.

And all the N pieces of Cobol need to be ported.

That gives:
* Simple move N pieces of Cobol (and N is often in the thousands
or tens of thousands)
* Verify and possible modify data access in NX+NY pieces of Cobol
* Rewrite other integrations and extensions in NZ+NW pieces of Cobol
* Write M new pieces of C
* Create X database definitions
* Write X database migration tools in something high level
* Write Y ISAM file migration tools in Cobol

And everything need to be tested:
* data conversion
* functionality
* performance
* security
* high availability

Operations need to create totally new procedures and
scripts for operating the new system.

And project management of it all.

It will take months just to create the project plan for this.

Arne

On 5/20/2022 8:11 PM, Arne Vajhøj wrote:
> On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
>> On 5/20/22 11:39, Arne Vajhøj wrote:
>>> The benefits from changing language are:
>>> * reduced risk of skills shortage
>>
>> This one is true bu there is still hope the problem can be fixed.
>>
>>> * faster changes
>>
>> Don't get this one. Can't see how making minor changes to the COBOL
>> would be slower than re-writting in Python.
>
> * more powerful language (fewer lines of code per functionality)
> * more powerful libraries
> * better isolation making changes less risky [not sure whether
> that applies to Python - consider that more a JVM / CLR
> language thing]
> * better tooling
> * different mindset among the developers
>
>>> * new capabilities typical relate dto integration
>>
>> But if the original legacy program didn't need them maybe they
>> aren't really needed at all.
>
> Most companies has a long list of things they would like to
> do.
>
>> If they are then one should seriously
>> consider scrapping the original and writing a new program and not
>> doing a port at all.
>
> The difference between porting an old program from one language
> to another very different language and writing a new program in
> the the other languages is pretty small.

Only if very good specifications exist. Trying to figure out what code is
doing, and it's worse if you aren't very good in the old code, rarely ends well.

You may claim different. Doesn't make you right. I've seen it. I've
experienced it. I'll go with my experiences rather than your claims.

--
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/20/2022 8:37 PM, Arne Vajhøj wrote:
> On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
>> On 5/20/22 11:39, Arne Vajhøj wrote:
>>> On 5/20/2022 8:59 AM, Bill Gunshannon wrote:
>>>> Depends on your definition of "porting". I doubt you will find
>>>> many (any?) companies offering to port COBOL on VMS to COBOL on
>>>> Unix or Windows.
>>>
>>> I have not heard about companies porting Cobol/VMS to
>>> Cobol/Linux. But there are companies doing Cobol/IBM mainframe
>>> to Cobol/Linux and even Cobol/Unisys mainframe to Cobol/Linux.
>>
>> Porting COBOL from one system to another is something I have played
>> with. I have yet to find a case where the COBOL (not DB or CICS or
>> any other add on) took more than a couple hours to port. Almost
>> all of the commercial offerings (especially contracting projects
>> like for the government) mean COBOL to some other "modern" language.
>>
>>>
>>>> What you will find is companies offering to
>>>> port COBOL to some language du jour on another platform. Where
>>>> is the money? In a one week COBOL -> COBOL port or in a 6 month
>>>> or even a year COBOL -> JAVA project.
>>>
>>> I don't think you will see those one week Cobol to Cobol
>>> ports in the real world.
>>
>> Don't see why not. Unless the COBOL is not really COBOL but
>> a high percentage of non-COBOL add ons. Even EXEC SQL statements
>> translate very well between different SQL Databases. Of course,
>> prolonging the job just means more money.
>
> If system migration is just taking a Cobol program with
> mostly ANSI Cobol and get it to build and run on a new platform
> then it is not a big thing.
>
> But that is not how a system migration look like in
> real life.
>
> You have N Cobol pieces, X relational databases,
> Y ISAM files, Z integration with other things
> (transaction monitors, message queues, external
> data dictionaries etc.), W cases of platform specific
> Cobol extensions and M pieces in assembler
> or some system dependent language.
>
> The relational database will typical change. So
> X database definition need to be created for the new
> database.
>
> Then X tools to migrate database data has to be written (can likely
> be done in something more high level than Cobol).
>
> Then embedded SQL in NX pieces of Cobol need to be checked and
> possible modified.
>
> The Y ISAM file definitions need to be tested for
> portability to target platform.
>
> Y tools to migrate ISAM file data has to be written (most
> likely written in Cobol).
>
> The ISAM file access in NY pieces of Cobol need to
> be checked andpossible modified.
>
> The other integration stuff need to be rewritten in
> NZ pieces of Cobol.
>
> The platform specific extension need to be rewritten in NW
> pieces of Cobol.
>
> The M pieces of whatever need to be rewritten to most
> likely C on the target platform.
>
> And all the N pieces of Cobol need to be ported.
>
> That gives:
> * Simple move N pieces of Cobol (and N is often in the thousands
> or tens of thousands)
> * Verify and possible modify data access in NX+NY pieces of Cobol
> * Rewrite other integrations and extensions in NZ+NW pieces of Cobol
> * Write M new pieces of C
> * Create X database definitions
> * Write X database migration tools in something high level
> * Write Y ISAM file migration tools in Cobol
>
> And everything need to be tested:
> * data conversion
> * functionality
> * performance
> * security
> * high availability
>
> Operations need to create totally new procedures and
> scripts for operating the new system.
>
> And project management of it all.
>
> It will take months just to create the project plan for this.
>
> Arne

Uh, didn't you just describe why changing to another language is such a bad,
expensive, and dangerous thing to do?

--
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/20/22 19:39, Arne Vajhøj wrote:
> On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
>> On 5/20/22 11:39, Arne Vajhøj wrote:
>>> On 5/20/2022 8:59 AM, Bill Gunshannon wrote:
>>>> On 5/19/22 21:42, Arne Vajhøj wrote:
>>>>>                            Today it is quite common
>>>>> to have dev on one platform and test and production
>>>>> on another platform - it works. For many newer
>>>>> languages.
>>>>
>>>> I do Arduino development.  While the compiler is on a PC you
>>>> can not develop without having an Arduino hooked up to your
>>>> development system.  In the old days it was quite common to
>>>> have an emulator on your development system to test your
>>>> work as you went along the development path.  Not really much
>>>> different except that the targets got physically smaller, the
>>>> communications got better and we now use the real thing.
>>>
>>> Cross compiling and testing in emulator is something
>>> completely different from a language being so portable
>>> that you can develop on a different platform than target.
>>> In fact the existence of the emulator proves that the
>>> code is not portable, because otherwise it would not
>>> be needed.
>>
>> Well, that was an old idea.  It didn't sell at the time it came
>> out either.  Took a couple decades to catch on.  UCSD-Pascal - write
>> once run on anything.  But, like Java, portability depended on the
>> various systems having the same capabilities.  Like Graphics.
>
> It works today.

Another example of being ahead of their time. like STVOS/POSIX.

>
> I would guess that 2/3 of all the worlds developers
> develop and test (not via simulator) on a different
> platform than their final target.
>
> Java, PHP, Python, JavaScript etc. developers write their
> code on Windows or macOS and deploy on Linux.

Java fits this category. But not the others. If you are going to
include interpreted languages then BASIC wins hands down.

bill

On 5/20/22 20:11, Arne Vajhøj wrote:
> On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
>> On 5/20/22 11:39, Arne Vajhøj wrote:
>>> The benefits from changing language are:
>>> * reduced risk of skills shortage
>>
>> This one is true bu there is still hope the problem can be fixed.
>>
>>> * faster changes
>>
>> Don't get this one.  Can't see how making minor changes to the COBOL
>> would be slower than re-writting in Python.
>
> * more powerful language (fewer lines of code per functionality)

That only mattered when resources like memory and disk space were at
a premium. And, don't throw out the red herring about how much longer
it takes to type the program in. With modern IDE's (well, not very
modern as we had them on the VAX) most of the boiler plate is added
automatically. And lines of source has little if anything to do with
the amount of functionality you get in the end.

> * more powerful libraries

Only important if your trying to use the wrong language for the job.
COBOL does what COBOL does. Linking in foreign languages is mostly
limited to things like SQL and CICS.

> * better isolation making changes less risky [not sure whether
>   that applies to Python - consider that more a JVM / CLR
>   language thing]

Once again, don't understand this. I think it is probably something
totally unrelated to what COBOL is for. Pick the right tool for the
job.

> * better tooling

If you mean IDE's COBOL has them, too. And, has had them for a long
time. LSE on VAX/VMS was great for developing COBOL. And I used the
same techniques back then that I do now. At least two windows. One
for editing and another for compiling/running.

> * different mindset among the developers

Not really a plus. COBOL programmers tend to have a mindset targeted
at the business they are doing. Electrical Engineers make lousy
business programmers.

>
>>> * new capabilities typical relate dto integration
>>
>> But if the original legacy program didn't need them maybe they
>> aren't really needed at all.
>
> Most companies has a long list of things they would like to
> do.

Sorry, but I don't think that is as true as you think. I have
mentioned two of the places where I did COBOL. One was 40 years
ago and one was 10 years ago. The older one hasn't changed in
any significant way in all of those 40 years. The items that
are subject to change are parameterized, as they should be.
The other, the only changes I was asked to make to any of the
programs (except for fixing mistakes made by the contractors who
did the original work) were trivial changes to report formats.
What the program do doesn't change, why would you change the program.

>
>>                              If they are then one should seriously
>> consider scrapping the original and writing a new program and not
>> doing a port at all.
>
> The difference between porting an old program from one language
> to another very different language and writing a new program in
> the the other languages is pretty small.

You are definitely right about that. If your porting from one
language to another the old program is really little more than
documentation.

bill

On 5/20/22 20:37, Arne Vajhøj wrote:
> On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
>> On 5/20/22 11:39, Arne Vajhøj wrote:
>>> On 5/20/2022 8:59 AM, Bill Gunshannon wrote:
>>>> Depends on your definition of "porting".  I doubt you will find
>>>> many (any?) companies offering to port COBOL on VMS to COBOL on
>>>> Unix or Windows.
>>>
>>> I have not heard about companies porting Cobol/VMS to
>>> Cobol/Linux. But there are companies doing Cobol/IBM mainframe
>>> to Cobol/Linux and even Cobol/Unisys mainframe to Cobol/Linux.
>>
>> Porting COBOL from one system to another is something I have played
>> with.  I have yet to find a case where the COBOL (not DB or CICS or
>> any other add on) took more than a couple hours to port.  Almost
>> all of the commercial offerings (especially contracting projects
>> like for the government) mean COBOL to some other "modern" language.
>>
>>>
>>>>                      What you will find is companies offering to
>>>> port COBOL to some language du jour on another platform.  Where
>>>> is the money?  In a one week COBOL -> COBOL port or in a 6 month
>>>> or even a year COBOL -> JAVA project.
>>>
>>> I don't think you will see those one week Cobol to Cobol
>>> ports in the real world.
>>
>> Don't see why not.  Unless the COBOL is not really COBOL but
>> a high percentage of non-COBOL add ons.  Even EXEC SQL statements
>> translate very well between different SQL Databases.  Of course,
>> prolonging the job just means more money.
>
> If system migration is just taking a Cobol program with
> mostly ANSI Cobol and get it to build and run on a new platform
> then it is not a big thing.
>
> But that is not how a system migration look like in
> real life.
>
> You have N Cobol pieces, X relational databases,
> Y ISAM files, Z integration with other things
> (transaction monitors, message queues, external
> data dictionaries etc.), W cases of platform specific
> Cobol extensions and M pieces in assembler
> or some system dependent language.
>
> The relational database will typical change. So
> X database definition need to be created for the new
> database.
>
> Then X tools to migrate database data has to be written (can likely
> be done in something more high level than Cobol).
>
> Then embedded SQL in NX pieces of Cobol need to be checked and
> possible modified.
>
> The Y ISAM file definitions need to be tested for
> portability to target platform.
>
> Y tools to migrate ISAM file data has to be written (most
> likely written in Cobol).
>
> The ISAM file access in NY pieces of Cobol need to
> be checked andpossible  modified.
>
> The other integration stuff need to be rewritten in
> NZ pieces of Cobol.
>
> The platform specific extension need to be rewritten in NW
> pieces of Cobol.
>
> The M pieces of whatever need to be rewritten to most
> likely C on the target platform.
>
> And all the N pieces of Cobol need to be ported.
>
> That gives:
> * Simple move N pieces of Cobol (and N is often in the thousands
>   or tens of thousands)
> * Verify and possible modify data access in NX+NY pieces of Cobol
> * Rewrite other integrations and extensions in NZ+NW pieces of Cobol
> * Write M new pieces of C
> * Create X database definitions
> * Write X database migration tools in something high level
> * Write Y ISAM file migration tools in Cobol
>
> And everything need to be tested:
> * data conversion
> * functionality
> * performance
> * security
> * high availability
>
> Operations need to create totally new procedures and
> scripts for operating the new system.
>
> And project management of it all.
>
> It will take months just to create the project plan for this.
>

All true. But none of it has anything to do with the COBOL. And
a lot of it would be more work when moving to a new language.
Moving the COBOL would be fairly trivial and all the rest will
be the same or worse if you are changing languages as well as
systems.

I was going to address your laundry list item by item as I have
actually played with a lot of it but it really adds little value
to the discussion.

bill

On Saturday, May 21, 2022 at 10:37:16 AM UTC+10, Arne Vajhøj wrote:
> On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
> > On 5/20/22 11:39, Arne Vajhøj wrote:
> >> On 5/20/2022 8:59 AM, Bill Gunshannon wrote:
> >>> Depends on your definition of "porting". I doubt you will find
> >>> many (any?) companies offering to port COBOL on VMS to COBOL on
> >>> Unix or Windows.
> >>
> >> I have not heard about companies porting Cobol/VMS to
> >> Cobol/Linux. But there are companies doing Cobol/IBM mainframe
> >> to Cobol/Linux and even Cobol/Unisys mainframe to Cobol/Linux.
> >
> > Porting COBOL from one system to another is something I have played
> > with. I have yet to find a case where the COBOL (not DB or CICS or
> > any other add on) took more than a couple hours to port. Almost
> > all of the commercial offerings (especially contracting projects
> > like for the government) mean COBOL to some other "modern" language.
> >
> >>
> >>> What you will find is companies offering to
> >>> port COBOL to some language du jour on another platform. Where
> >>> is the money? In a one week COBOL -> COBOL port or in a 6 month
> >>> or even a year COBOL -> JAVA project.
> >>
> >> I don't think you will see those one week Cobol to Cobol
> >> ports in the real world.
> >
> > Don't see why not. Unless the COBOL is not really COBOL but
> > a high percentage of non-COBOL add ons. Even EXEC SQL statements
> > translate very well between different SQL Databases. Of course,
> > prolonging the job just means more money.
> If system migration is just taking a Cobol program with
> mostly ANSI Cobol and get it to build and run on a new platform
> then it is not a big thing.
>
> But that is not how a system migration look like in
> real life.
>
> You have N Cobol pieces, X relational databases,
> Y ISAM files, Z integration with other things
> (transaction monitors, message queues, external
> data dictionaries etc.), W cases of platform specific
> Cobol extensions and M pieces in assembler
> or some system dependent language.
>
> The relational database will typical change. So
> X database definition need to be created for the new
> database.
>
> Then X tools to migrate database data has to be written (can likely
> be done in something more high level than Cobol).
>
> Then embedded SQL in NX pieces of Cobol need to be checked and
> possible modified.
>
> The Y ISAM file definitions need to be tested for
> portability to target platform.
>
> Y tools to migrate ISAM file data has to be written (most
> likely written in Cobol).
>
> The ISAM file access in NY pieces of Cobol need to
> be checked andpossible modified.
>
> The other integration stuff need to be rewritten in
> NZ pieces of Cobol.
>
> The platform specific extension need to be rewritten in NW
> pieces of Cobol.
>
> The M pieces of whatever need to be rewritten to most
> likely C on the target platform.
>
> And all the N pieces of Cobol need to be ported.
>
> That gives:
> * Simple move N pieces of Cobol (and N is often in the thousands
> or tens of thousands)
> * Verify and possible modify data access in NX+NY pieces of Cobol
> * Rewrite other integrations and extensions in NZ+NW pieces of Cobol
> * Write M new pieces of C
> * Create X database definitions
> * Write X database migration tools in something high level
> * Write Y ISAM file migration tools in Cobol
>
> And everything need to be tested:
> * data conversion
> * functionality
> * performance
> * security
> * high availability
>
> Operations need to create totally new procedures and
> scripts for operating the new system.
>
> And project management of it all.
>
> It will take months just to create the project plan for this.
>
> Arne

Yep, pretty much what ETL (or the more funky modern incarnation, pipeline) conceptualizes.

On a project currently that will literally take about 18-24 months just to clarify a formal technical design after data/analysis emerges from a poc model designed to tease out the many gotchas from an application that's been in place since the early 70's.

We are not even rewriting the app, 'just' swapping out the underlining DB via a call change (the existing non relational DBMS was in-house written) to something vendor supported.

It's on a mainframe which isn't going away, in fact, significant investment is being put into the mainframe to move other business critical functions to it because of it's ability to centralize licencing costs, reduce the sprawling VM landscape (VMware/Nutanix) and business/regulatory requirements. The mainframe is gaining favor for anything left behind in the headlong rush to the cloud.
Tolerance for failure is zero, not a chance in hell of changing platforms or coding languages as deemed easy by some, as this thing churns through hundreds of Billions a day - even the hint of acceptable failure and you need to start packing your bags immediately

This return to a centralization focus under a mainframe model gives the risk and security folk plenty of reasons to salivate and risk drives everything at the moment

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of IanD via Info-
> vax
> Sent: May-21-22 6:39 PM
> To: info-vax@rbnsn.com
> Cc: IanD <iloveopenvms@gmail.com>
> Subject: Re: [Info-vax] VMS article in The Register
>
> On Saturday, May 21, 2022 at 10:37:16 AM UTC+10, Arne Vajhøj wrote:
> > On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
> > > On 5/20/22 11:39, Arne Vajhøj wrote:
> > >> On 5/20/2022 8:59 AM, Bill Gunshannon wrote:
> > >>> Depends on your definition of "porting". I doubt you will find
> > >>> many (any?) companies offering to port COBOL on VMS to COBOL on
> > >>> Unix or Windows.
> > >>
> > >> I have not heard about companies porting Cobol/VMS to Cobol/Linux.
> > >> But there are companies doing Cobol/IBM mainframe to Cobol/Linux
> > >> and even Cobol/Unisys mainframe to Cobol/Linux.
> > >
> > > Porting COBOL from one system to another is something I have played
> > > with. I have yet to find a case where the COBOL (not DB or CICS or
> > > any other add on) took more than a couple hours to port. Almost all
> > > of the commercial offerings (especially contracting projects like
> > > for the government) mean COBOL to some other "modern" language.
> > >
> > >>
> > >>> What you will find is companies offering to
> > >>> port COBOL to some language du jour on another platform. Where is
> > >>> the money? In a one week COBOL -> COBOL port or in a 6 month or
> > >>> even a year COBOL -> JAVA project.
> > >>
> > >> I don't think you will see those one week Cobol to Cobol ports in
> > >> the real world.
> > >
> > > Don't see why not. Unless the COBOL is not really COBOL but a high
> > > percentage of non-COBOL add ons. Even EXEC SQL statements translate
> > > very well between different SQL Databases. Of course, prolonging
> > > the job just means more money.
> > If system migration is just taking a Cobol program with mostly ANSI
> > Cobol and get it to build and run on a new platform then it is not a
> > big thing.
> >
> > But that is not how a system migration look like in real life.
> >
> > You have N Cobol pieces, X relational databases, Y ISAM files, Z
> > integration with other things (transaction monitors, message queues,
> > external data dictionaries etc.), W cases of platform specific Cobol
> > extensions and M pieces in assembler or some system dependent
> > language.
> >
> > The relational database will typical change. So X database definition
> > need to be created for the new database.
> >
> > Then X tools to migrate database data has to be written (can likely be
> > done in something more high level than Cobol).
> >
> > Then embedded SQL in NX pieces of Cobol need to be checked and
> > possible modified.
> >
> > The Y ISAM file definitions need to be tested for portability to
> > target platform.
> >
> > Y tools to migrate ISAM file data has to be written (most likely
> > written in Cobol).
> >
> > The ISAM file access in NY pieces of Cobol need to be checked
> > andpossible modified.
> >
> > The other integration stuff need to be rewritten in NZ pieces of
> > Cobol.
> >
> > The platform specific extension need to be rewritten in NW pieces of
> > Cobol.
> >
> > The M pieces of whatever need to be rewritten to most likely C on the
> > target platform.
> >
> > And all the N pieces of Cobol need to be ported.
> >
> > That gives:
> > * Simple move N pieces of Cobol (and N is often in the thousands or
> > tens of thousands)
> > * Verify and possible modify data access in NX+NY pieces of Cobol
> > * Rewrite other integrations and extensions in NZ+NW pieces of Cobol
> > * Write M new pieces of C
> > * Create X database definitions
> > * Write X database migration tools in something high level
> > * Write Y ISAM file migration tools in Cobol
> >
> > And everything need to be tested:
> > * data conversion
> > * functionality
> > * performance
> > * security
> > * high availability
> >
> > Operations need to create totally new procedures and scripts for
> > operating the new system.
> >
> > And project management of it all.
> >
> > It will take months just to create the project plan for this.
> >
> > Arne
>
> Yep, pretty much what ETL (or the more funky modern incarnation, pipeline)
> conceptualizes.
>
> On a project currently that will literally take about 18-24 months just to clarify
> a formal technical design after data/analysis emerges from a poc model
> designed to tease out the many gotchas from an application that's been in
> place since the early 70's.
>
> We are not even rewriting the app, 'just' swapping out the underlining DB via
> a call change (the existing non relational DBMS was in-house written) to
> something vendor supported.
>
> It's on a mainframe which isn't going away, in fact, significant investment is
> being put into the mainframe to move other business critical functions to it
> because of it's ability to centralize licencing costs, reduce the sprawling VM
> landscape (VMware/Nutanix) and business/regulatory requirements. The
> mainframe is gaining favor for anything left behind in the headlong rush to
> the cloud.
> Tolerance for failure is zero, not a chance in hell of changing platforms or
> coding languages as deemed easy by some, as this thing churns through
> hundreds of Billions a day - even the hint of acceptable failure and you need
> to start packing your bags immediately
>
> This return to a centralization focus under a mainframe model gives the risk
> and security folk plenty of reasons to salivate and risk drives everything at
> the moment _______________________________________________

As others have stated in this thread, there are pro's and con's with every compute strategy. The distributed vs. centralized architecture wars have been going on for 40+ years.

However, do not under estimate the allure of centralized, highly secure environments such as the Mainframe.

Remember that mainframes can be clustered across different sites for mission critical multi-site solutions that run on very high IO, highly secure hardware.

Remember that IBM now owns Red Hat and hence has, and will continue to in the future, optimize huge numbers of Linux VM's on mainframes.

In terms of new Mainframe Customers and benefits of new mainframes like the z16, check out:
<https://thestack.technology/ibm-mainframe-z16/>
Extract " Yet for speed, raw data processing power and uptime mainframes remain a compelling proposition. Innovations in recent years by IBM and Red Hat mean users can deploy cloud native applications on Kubernetes and Red Hat OpenShift on IBM Z and LinuxONE using what it calls “Cloud Paks” — while its new “Wazi aaS” (don’t laugh) offering lets users provision z/OS virtual server instances on IBM Z in IBM Cloud; something that Big Blue thinks has cut z/OS development and test environments from days or weeks down to six minutes or fewer."

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG.
https://www.avg.com

On Sunday, May 22, 2022 at 7:45:05 AM UTC-7, Kerry Main wrote:
>
> As others have stated in this thread, there are pro's and con's with every compute strategy. The distributed vs. centralized architecture wars have been going on for 40+ years.
>
> However, do not under estimate the allure of centralized, highly secure environments such as the Mainframe.
>
> Remember that mainframes can be clustered across different sites for mission critical multi-site solutions that run on very high IO, highly secure hardware.
>
> Remember that IBM now owns Red Hat and hence has, and will continue to in the future, optimize huge numbers of Linux VM's on mainframes.
>
> In terms of new Mainframe Customers and benefits of new mainframes like the z16, check out:
> <https://thestack.technology/ibm-mainframe-z16/>

IBM has some very impressive achievements as far as uptime (7 nines), backwards compatibility, and hardware acceleration for everything from COBOL (SIMD decimal, hexadecimal, and IEEE floating point and fast numeric format conversions) to sorting (z15 added an in-memory sort instruction, implemented in millicode with hardware acceleration) to hardware gzip compression and encryption (the latest algorithms). Many of those new features are equally relevant to Linux, since they're user-mode instructions (hardware-accelerated Java BigDecimal, libz, encryption libraries, etc.), but mainframes are primarily optimized for z/OS, COBOL, and IBM's other proprietary OS's, languages (PL/I), and middleware (CICS, IMS, Db2). The z16 adds an innovative cache design and an AI model accelerator that runs on-chip to be able to run fraud detection models on every transaction without adding latency.

Historically, VMS and OS/360 often targeted the same use cases. But conceptually, mainframes are even more alien to UNIX than VMS is. z/OS uses EBCDIC, JCL, 80-column records derived from punch cards, FICON storage arrays emulating ECKD disk blocks and track sizes based on the geometry of IBM 3390 hard disks from 1991, and a lot of other quirks that make VMS feel futuristic and future-ready in comparison. Just look at the definition for "IEFBR14" to get an idea of the utterly bizarre naming conventions of the standard system programs that you can run from JCL: https://en.wikipedia.org/wiki/IEFBR14

z/OS makes DEC's "SYS$" verbose naming feel extremely user-friendly in comparison. And yet IBM recognizes the uphill battle they're in, and has spent a lot of money on training programs and outreach to universities in order to indoctrinate a new generation into not running away screaming at the sight of JCL and COBOL. VSI can definitely learn from their success at this. They've both figured out that VS Code extensions are a good way to help programmers acclimate to the environment.

The one commonality I've noticed between VMS and z/OS that sets them both apart from UNIX, Windows, macOS, etc. is the insistence that files are more than just "bags of bytes", and that the OS can and should provide valuable services, particularly to programs written in COBOL (or FORTRAN) in terms of organizing those files into records and efficiently querying and updating them.

There's standard COBOL, and then there's COBOL that only runs in the context of CICS on an IBM mainframe, or reading/writing IBM VSAM data sets in batch jobs. VSI COBOL only supports a single code page of EBCDIC (there are hundreds). In terms of porting programs written originally for VMS, I'd expect that you'd run into similar difficulties to the extent that the program is dependent on calling VMS library routines or uses RMS features extensively.

Jake

On 5/20/2022 11:10 PM, Dave Froble wrote:
> On 5/20/2022 8:11 PM, Arne Vajhøj wrote:
>> On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
>>>                              If they are then one should seriously
>>> consider scrapping the original and writing a new program and not
>>> doing a port at all.
>>
>> The difference between porting an old program from one language
>> to another very different language and writing a new program in
>> the the other languages is pretty small.
>
> Only if very good specifications exist.  Trying to figure out what code
> is doing, and it's worse if you aren't very good in the old code, rarely
> ends well.

It is not clear to me in what case you think the difference is big.

Arne

On 5/22/2022 10:41 AM, Kerry Main wrote:
> Extract " Yet for speed, raw data processing power and uptime
> mainframes remain a compelling proposition. Innovations in recent
> years by IBM and Red Hat mean users can deploy cloud native
> applications on Kubernetes and Red Hat OpenShift on IBM Z and
> LinuxONE using what it calls “Cloud Paks” — while its new “Wazi aaS”
> (don’t laugh) offering lets users provision z/OS virtual server
> instances on IBM Z in IBM Cloud; something that Big Blue thinks has
> cut z/OS development and test environments from days or weeks down to
> six minutes or fewer."
As a general rule if the best argument for buying X is that
it is able to do the same as Y, then most will prefer Y over X.

Arne

On 5/21/2022 9:32 AM, Bill Gunshannon wrote:
> On 5/20/22 20:11, Arne Vajhøj wrote:
>> On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
>>> On 5/20/22 11:39, Arne Vajhøj wrote:
>>>> The benefits from changing language are:
>>>> * reduced risk of skills shortage
>>>
>>> This one is true bu there is still hope the problem can be fixed.
>>>
>>>> * faster changes
>>>
>>> Don't get this one.  Can't see how making minor changes to the COBOL
>>> would be slower than re-writting in Python.
>>
>> * more powerful language (fewer lines of code per functionality)
>
> That only mattered when resources like memory and disk space were at
> a premium.  And, don't throw out the red herring about how much longer
> it takes to type the program in.  With modern IDE's (well, not very
> modern as we had them on the VAX) most of the boiler plate is added
> automatically.  And lines of source has little if anything to do with
> the amount of functionality you get in the end.

Lines of code does matter cost wise.

It is not the time to type it in, but the time to read
it that matters.

>
>> * more powerful libraries
>
> Only important if your trying to use the wrong language for the job.
> COBOL does what COBOL does.  Linking in foreign languages is mostly
> limited to things like SQL and CICS.

The world evolve and requirements for systems evolve. The
size of required library code for a current application
for a given domain has exploded.

That isolated application doing what it did 50 years ago
is becoming a rarity.

>> * better isolation making changes less risky [not sure whether
>>    that applies to Python - consider that more a JVM / CLR
>>    language thing]
>
> Once again, don't understand this.  I think it is probably something
> totally unrelated to what COBOL is for.  Pick the right tool for the
> job.

When needing to modify large systems without worrying about
breaking something somewhere else, then programming languages
has evolved a lot since Cobol was designed.

Coding to interfaces not implementations, immutable
data objects etc..

>> * better tooling
>
> If you mean IDE's COBOL has them, too.  And, has had them for a long
> time.  LSE on VAX/VMS was great for developing COBOL.  And I used the
> same techniques back then that I do now.  At least two windows.  One
> for editing and another for compiling/running.

LSE is 30-40 years behind when it comes to IDE's.

But tooling is more than just IDE's.

>> * different mindset among the developers
>
> Not really a plus.  COBOL programmers tend to have a mindset targeted
> at the business they are doing. Electrical Engineers make lousy
> business programmers.

It is not their educational background.

But their focus on and experience with CI/CD, devops etc..

>>>> * new capabilities typical relate dto integration
>>>
>>> But if the original legacy program didn't need them maybe they
>>> aren't really needed at all.
>>
>> Most companies has a long list of things they would like to
>> do.
>
> Sorry, but I don't think that is as true as you think.  I have
> mentioned two of the places where I did COBOL.  One was 40 years
> ago and one was 10 years ago.  The older one hasn't changed in
> any significant way in all of those 40 years.  The items that
> are subject to change are parameterized, as they should be.
> The other, the only changes I was asked to make to any of the
> programs (except for fixing mistakes made by the contractors who
> did the original work) were trivial changes to report formats.
> What the program do doesn't change, why would you change the program.

Businesses change.

Cobol is big in the financial sector. They have changed a lot in
the last two decades and they will be changing even more in the
next. Otherwise the new fintech's will eat their lunch.

Arne

On 5/21/2022 11:25 AM, Bill Gunshannon wrote:
> On 5/20/22 20:37, Arne Vajhøj wrote:
>> On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
>>> On 5/20/22 11:39, Arne Vajhøj wrote:
>>>> On 5/20/2022 8:59 AM, Bill Gunshannon wrote:
>>>>>                      What you will find is companies offering to
>>>>> port COBOL to some language du jour on another platform.  Where
>>>>> is the money?  In a one week COBOL -> COBOL port or in a 6 month
>>>>> or even a year COBOL -> JAVA project.
>>>>
>>>> I don't think you will see those one week Cobol to Cobol
>>>> ports in the real world.
>>>
>>> Don't see why not.  Unless the COBOL is not really COBOL but
>>> a high percentage of non-COBOL add ons.  Even EXEC SQL statements
>>> translate very well between different SQL Databases.  Of course,
>>> prolonging the job just means more money.
>>
>> If system migration is just taking a Cobol program with
>> mostly ANSI Cobol and get it to build and run on a new platform
>> then it is not a big thing.
>>
>> But that is not how a system migration look like in
>> real life.
>>
>> You have N Cobol pieces, X relational databases,
>> Y ISAM files, Z integration with other things
>> (transaction monitors, message queues, external
>> data dictionaries etc.), W cases of platform specific
>> Cobol extensions and M pieces in assembler
>> or some system dependent language.
>>
>> The relational database will typical change. So
>> X database definition need to be created for the new
>> database.
>>
>> Then X tools to migrate database data has to be written (can likely
>> be done in something more high level than Cobol).
>>
>> Then embedded SQL in NX pieces of Cobol need to be checked and
>> possible modified.
>>
>> The Y ISAM file definitions need to be tested for
>> portability to target platform.
>>
>> Y tools to migrate ISAM file data has to be written (most
>> likely written in Cobol).
>>
>> The ISAM file access in NY pieces of Cobol need to
>> be checked andpossible  modified.
>>
>> The other integration stuff need to be rewritten in
>> NZ pieces of Cobol.
>>
>> The platform specific extension need to be rewritten in NW
>> pieces of Cobol.
>>
>> The M pieces of whatever need to be rewritten to most
>> likely C on the target platform.
>>
>> And all the N pieces of Cobol need to be ported.
>>
>> That gives:
>> * Simple move N pieces of Cobol (and N is often in the thousands
>>    or tens of thousands)
>> * Verify and possible modify data access in NX+NY pieces of Cobol
>> * Rewrite other integrations and extensions in NZ+NW pieces of Cobol
>> * Write M new pieces of C
>> * Create X database definitions
>> * Write X database migration tools in something high level
>> * Write Y ISAM file migration tools in Cobol
>>
>> And everything need to be tested:
>> * data conversion
>> * functionality
>> * performance
>> * security
>> * high availability
>>
>> Operations need to create totally new procedures and
>> scripts for operating the new system.
>>
>> And project management of it all.
>>
>> It will take months just to create the project plan for this.
>
> All true. But none of it has anything to do with the COBOL.  And
> a lot of it would be more work when moving to a new language.
> Moving the COBOL would be fairly trivial and all the rest will
> be the same or worse if you are changing languages as well as
> systems.

True.

But you seem to be missing the point.

It is not like Cobol->Cobol is a 1 week project and Cobol->X
is a 6-12 month project like you described.

Both are 18-24 months projects. And due to all the common work
Cobol->Cobol may be 30 M$ and Cobol->X may be 35 M$.

And then in many cases the decision is that when starting
such a gigantic project then just as well pay that slice
extra and actually get to where they want to be instead
of having a new conversion project already lining up in
the horizon.

Arne

On 5/21/2022 9:18 AM, Bill Gunshannon wrote:
> On 5/20/22 19:39, Arne Vajhøj wrote:
>> I would guess that 2/3 of all the worlds developers
>> develop and test (not via simulator) on a different
>> platform than their final target.
>>
>> Java, PHP, Python, JavaScript etc. developers write their
>> code on Windows or macOS and deploy on Linux.
>
> Java fits this category. But not the others.  If you are going to
> include interpreted languages then BASIC wins hands down.

It is obviously easier for interpreted languages, but that
just gives these languages an advantage. It does not change
the industry expectation.

Arne

PS: Basic is mostly compiled today. VB.NET, VB6 and VMS Basic are
all compiled. VBS is not though.

On 5/20/2022 11:13 PM, Dave Froble wrote:
> On 5/20/2022 8:37 PM, Arne Vajhøj wrote:
>> On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
>>> On 5/20/22 11:39, Arne Vajhøj wrote:
>>>> On 5/20/2022 8:59 AM, Bill Gunshannon wrote:
>>>>>                      What you will find is companies offering to
>>>>> port COBOL to some language du jour on another platform.  Where
>>>>> is the money?  In a one week COBOL -> COBOL port or in a 6 month
>>>>> or even a year COBOL -> JAVA project.
>>>>
>>>> I don't think you will see those one week Cobol to Cobol
>>>> ports in the real world.
>>>
>>> Don't see why not.  Unless the COBOL is not really COBOL but
>>> a high percentage of non-COBOL add ons.  Even EXEC SQL statements
>>> translate very well between different SQL Databases.  Of course,
>>> prolonging the job just means more money.
>>
>> If system migration is just taking a Cobol program with
>> mostly ANSI Cobol and get it to build and run on a new platform
>> then it is not a big thing.
>>
>> But that is not how a system migration look like in
>> real life.
>>
>> You have N Cobol pieces, X relational databases,
>> Y ISAM files, Z integration with other things
>> (transaction monitors, message queues, external
>> data dictionaries etc.), W cases of platform specific
>> Cobol extensions and M pieces in assembler
>> or some system dependent language.
>>
>> The relational database will typical change. So
>> X database definition need to be created for the new
>> database.
>>
>> Then X tools to migrate database data has to be written (can likely
>> be done in something more high level than Cobol).
>>
>> Then embedded SQL in NX pieces of Cobol need to be checked and
>> possible modified.
>>
>> The Y ISAM file definitions need to be tested for
>> portability to target platform.
>>
>> Y tools to migrate ISAM file data has to be written (most
>> likely written in Cobol).
>>
>> The ISAM file access in NY pieces of Cobol need to
>> be checked andpossible  modified.
>>
>> The other integration stuff need to be rewritten in
>> NZ pieces of Cobol.
>>
>> The platform specific extension need to be rewritten in NW
>> pieces of Cobol.
>>
>> The M pieces of whatever need to be rewritten to most
>> likely C on the target platform.
>>
>> And all the N pieces of Cobol need to be ported.
>>
>> That gives:
>> * Simple move N pieces of Cobol (and N is often in the thousands
>>   or tens of thousands)
>> * Verify and possible modify data access in NX+NY pieces of Cobol
>> * Rewrite other integrations and extensions in NZ+NW pieces of Cobol
>> * Write M new pieces of C
>> * Create X database definitions
>> * Write X database migration tools in something high level
>> * Write Y ISAM file migration tools in Cobol
>>
>> And everything need to be tested:
>> * data conversion
>> * functionality
>> * performance
>> * security
>> * high availability
>>
>> Operations need to create totally new procedures and
>> scripts for operating the new system.
>>
>> And project management of it all.
>>
>> It will take months just to create the project plan for this.
>
> Uh, didn't you just describe why changing to another language is such a
> bad, expensive, and dangerous thing to do?

The difference between Cobol/mainframe -> Cobol/newer and
Cobol/mainframe -> newer/newer is not that big.

So it describes why not migrating at all is pretty attractive.

The cost and risk of big conversion projects is big. Most
CEO/CFO/CIO tend to prefer the "next guy" to have that
problem.

So decisions is like:
- some (think 5% magnitude) decide to stay at Cobol but change platform
- some (think 5% magnitude) decide to change language and platform
- most (think 90% magnitude) decide to not change language or platform
for now

So only 10% leave, but when the question come up again a few year later,
then 10% leave again and so on.

Arne

On 5/22/2022 8:39 PM, Arne Vajhøj wrote:
> On 5/22/2022 10:41 AM, Kerry Main wrote:
>> Extract " Yet for speed, raw data processing power and uptime
>> mainframes remain a compelling proposition. Innovations in recent
>> years by IBM and Red Hat mean users can deploy cloud native
>> applications on Kubernetes and Red Hat OpenShift on IBM Z and
>> LinuxONE using what it calls “Cloud Paks” — while its new “Wazi aaS”
>> (don’t laugh) offering lets users provision z/OS virtual server
>> instances on IBM Z in IBM Cloud; something that Big Blue thinks has
>> cut z/OS development and test environments from days or weeks down to
>> six minutes or fewer."
> As a general rule if the best argument for buying X is that
> it is able to do the same as Y, then most will prefer Y over X.
>
> Arne

Goes both directions Arne ....

--
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/22/2022 9:38 PM, Arne Vajhøj wrote:
> On 5/20/2022 11:13 PM, Dave Froble wrote:
>> On 5/20/2022 8:37 PM, Arne Vajhøj wrote:
>>> On 5/20/2022 12:18 PM, Bill Gunshannon wrote:
>>>> On 5/20/22 11:39, Arne Vajhøj wrote:
>>>>> On 5/20/2022 8:59 AM, Bill Gunshannon wrote:
>>>>>> What you will find is companies offering to
>>>>>> port COBOL to some language du jour on another platform. Where
>>>>>> is the money? In a one week COBOL -> COBOL port or in a 6 month
>>>>>> or even a year COBOL -> JAVA project.
>>>>>
>>>>> I don't think you will see those one week Cobol to Cobol
>>>>> ports in the real world.
>>>>
>>>> Don't see why not. Unless the COBOL is not really COBOL but
>>>> a high percentage of non-COBOL add ons. Even EXEC SQL statements
>>>> translate very well between different SQL Databases. Of course,
>>>> prolonging the job just means more money.
>>>
>>> If system migration is just taking a Cobol program with
>>> mostly ANSI Cobol and get it to build and run on a new platform
>>> then it is not a big thing.
>>>
>>> But that is not how a system migration look like in
>>> real life.
>>>
>>> You have N Cobol pieces, X relational databases,
>>> Y ISAM files, Z integration with other things
>>> (transaction monitors, message queues, external
>>> data dictionaries etc.), W cases of platform specific
>>> Cobol extensions and M pieces in assembler
>>> or some system dependent language.
>>>
>>> The relational database will typical change. So
>>> X database definition need to be created for the new
>>> database.
>>>
>>> Then X tools to migrate database data has to be written (can likely
>>> be done in something more high level than Cobol).
>>>
>>> Then embedded SQL in NX pieces of Cobol need to be checked and
>>> possible modified.
>>>
>>> The Y ISAM file definitions need to be tested for
>>> portability to target platform.
>>>
>>> Y tools to migrate ISAM file data has to be written (most
>>> likely written in Cobol).
>>>
>>> The ISAM file access in NY pieces of Cobol need to
>>> be checked andpossible modified.
>>>
>>> The other integration stuff need to be rewritten in
>>> NZ pieces of Cobol.
>>>
>>> The platform specific extension need to be rewritten in NW
>>> pieces of Cobol.
>>>
>>> The M pieces of whatever need to be rewritten to most
>>> likely C on the target platform.
>>>
>>> And all the N pieces of Cobol need to be ported.
>>>
>>> That gives:
>>> * Simple move N pieces of Cobol (and N is often in the thousands
>>> or tens of thousands)
>>> * Verify and possible modify data access in NX+NY pieces of Cobol
>>> * Rewrite other integrations and extensions in NZ+NW pieces of Cobol
>>> * Write M new pieces of C
>>> * Create X database definitions
>>> * Write X database migration tools in something high level
>>> * Write Y ISAM file migration tools in Cobol
>>>
>>> And everything need to be tested:
>>> * data conversion
>>> * functionality
>>> * performance
>>> * security
>>> * high availability
>>>
>>> Operations need to create totally new procedures and
>>> scripts for operating the new system.
>>>
>>> And project management of it all.
>>>
>>> It will take months just to create the project plan for this.
>>
>> Uh, didn't you just describe why changing to another language is such a bad,
>> expensive, and dangerous thing to do?
>
> The difference between Cobol/mainframe -> Cobol/newer and
> Cobol/mainframe -> newer/newer is not that big.
>
> So it describes why not migrating at all is pretty attractive.
>
> The cost and risk of big conversion projects is big. Most
> CEO/CFO/CIO tend to prefer the "next guy" to have that
> problem.
>
> So decisions is like:
> - some (think 5% magnitude) decide to stay at Cobol but change platform
> - some (think 5% magnitude) decide to change language and platform
> - most (think 90% magnitude) decide to not change language or platform for now
>
> So only 10% leave, but when the question come up again a few year later,
> then 10% leave again and so on.

Where can I find a hat like that one you pull all those numbers and such from?

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

Den 2022-05-23 kl. 00:59, skrev Jake Hamby:

Just look at the definition for "IEFBR14" to get an idea of the utterly
bizarre naming conventions of the standard system programs that you can run
from JCL: https://en.wikipedia.org/wiki/IEFBR14

I have written quite some JCL that used IEFBR14.
Another common one is IEBGENER. Compare that with a simple "$ COPY...".
https://www.ibm.com/docs/en/zos-basic-skills?topic=utilities-iebgener-utility-generate-copy-sequential-data-set

That was fun times...

Jan-Erik.

>
> Jake

On 5/23/22 02:21, Jan-Erik Söderholm wrote:
> Den 2022-05-23 kl. 00:59, skrev Jake Hamby:
>
>
> Just look at the definition for "IEFBR14" to get an idea of the utterly
> bizarre naming conventions of the standard system programs that you can
> run from JCL: https://en.wikipedia.org/wiki/IEFBR14
>
> I have written quite some JCL that used IEFBR14.
> Another common one is IEBGENER. Compare that with a simple "$ COPY...".
> https://www.ibm.com/docs/en/zos-basic-skills?topic=utilities-iebgener-utility-generate-copy-sequential-data-set
>
>
> That was fun times...
>

40 years ago those names had meaning (in the IBM world). They
remain the same today out of momentum. Unix 's curt naming dates
to a time of 110 Baud communications. Today "cp" could easily be
"copy", "ld" could be "load" and "ls" could be "list". But why
fix what isn't broken.

bill

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Jake Hamby
> via Info-vax
> Sent: May-22-22 7:59 PM
> To: info-vax@rbnsn.com
> Cc: Jake Hamby <jake.hamby@gmail.com>
> Subject: Re: [Info-vax] VMS article in The Register
>
> On Sunday, May 22, 2022 at 7:45:05 AM UTC-7, Kerry Main wrote:
> >
> > As others have stated in this thread, there are pro's and con's with every
> compute strategy. The distributed vs. centralized architecture wars have
> been going on for 40+ years.
> >
> > However, do not under estimate the allure of centralized, highly secure
> environments such as the Mainframe.
> >
> > Remember that mainframes can be clustered across different sites for
> mission critical multi-site solutions that run on very high IO, highly secure
> hardware.
> >
> > Remember that IBM now owns Red Hat and hence has, and will continue to
> in the future, optimize huge numbers of Linux VM's on mainframes.
> >
> > In terms of new Mainframe Customers and benefits of new mainframes
> like the z16, check out:
> > <https://thestack.technology/ibm-mainframe-z16/>
>
> IBM has some very impressive achievements as far as uptime (7 nines),
> backwards compatibility, and hardware acceleration for everything from
> COBOL (SIMD decimal, hexadecimal, and IEEE floating point and fast numeric
> format conversions) to sorting (z15 added an in-memory sort instruction,
> implemented in millicode with hardware acceleration) to hardware gzip
> compression and encryption (the latest algorithms). Many of those new
> features are equally relevant to Linux, since they're user-mode instructions
> (hardware-accelerated Java BigDecimal, libz, encryption libraries, etc.), but
> mainframes are primarily optimized for z/OS, COBOL, and IBM's other
> proprietary OS's, languages (PL/I), and middleware (CICS, IMS, Db2). The z16
> adds an innovative cache design and an AI model accelerator that runs on-
> chip to be able to run fraud detection models on every transaction without
> adding latency.
>
> Historically, VMS and OS/360 often targeted the same use cases. But
> conceptually, mainframes are even more alien to UNIX than VMS is. z/OS
> uses EBCDIC, JCL, 80-column records derived from punch cards, FICON
> storage arrays emulating ECKD disk blocks and track sizes based on the
> geometry of IBM 3390 hard disks from 1991, and a lot of other quirks that
> make VMS feel futuristic and future-ready in comparison. Just look at the
> definition for "IEFBR14" to get an idea of the utterly bizarre naming
> conventions of the standard system programs that you can run from JCL:
> https://en.wikipedia.org/wiki/IEFBR14
>
> z/OS makes DEC's "SYS$" verbose naming feel extremely user-friendly in
> comparison. And yet IBM recognizes the uphill battle they're in, and has
> spent a lot of money on training programs and outreach to universities in
> order to indoctrinate a new generation into not running away screaming at
> the sight of JCL and COBOL. VSI can definitely learn from their success at this.
> They've both figured out that VS Code extensions are a good way to help
> programmers acclimate to the environment.
>
> The one commonality I've noticed between VMS and z/OS that sets them
> both apart from UNIX, Windows, macOS, etc. is the insistence that files are
> more than just "bags of bytes", and that the OS can and should provide
> valuable services, particularly to programs written in COBOL (or FORTRAN) in
> terms of organizing those files into records and efficiently querying and
> updating them.
>
> There's standard COBOL, and then there's COBOL that only runs in the
> context of CICS on an IBM mainframe, or reading/writing IBM VSAM data
> sets in batch jobs. VSI COBOL only supports a single code page of EBCDIC
> (there are hundreds). In terms of porting programs written originally for
> VMS, I'd expect that you'd run into similar difficulties to the extent that the
> program is dependent on calling VMS library routines or uses RMS features
> extensively.
>
> Jake
> _______________________________________________

Another similarity is that OpenVMS and z/OS is are both active-active, shared disk file systems.

Walk down memory lane - "the best clusters on the planet have the same 3 letters" .. VMS and MVS (aka z/OS).

😊

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG.
https://www.avg.com