Re: Bootcamp

On 7/12/2025 10:41 AM, Arne Vajhøj wrote:

On 7/12/2025 9:35 AM, bill wrote:

On 7/11/2025 8:16 PM, Arne Vajhøj wrote:

The idea of a 1:1 port is usually bad. Yes - you can implement the
exact same flow of your Cobol application in Java/C++/Go/C#,
but that only solves a language problem not an architecture problem.

>
The biggest problem with this the idea of going from a domain specific
language to a general purpose language.  While you can write an IS in
pretty much any language (imagine rewriting the entire government
payroll currently in COBOL in BASIC!!) there were real advantages to
having domain specific languages.  But then, no one today seems to even
consider things like efficiency.  Just throw more hardware at the
problem.

 That argument made sense 40 years ago, but I don't think there
is much point today - the modern languages have the features
the need like easy database access and decimal data type and
the missing features like terminal screen and reporting are no
longer needed.

Jack of all trades, master of none.

 

You need to re-architect the solution: from ISAM to RDBMS,

>
This is the only one I totally agree with but the original problem
had nothing to do with the language.  It had to do with the fact that
RDBMS wasn't around when COBOL was written.  I have been doing COBOL
and RDBMS since 1980 and it was old code when I got there.

 True.
 But it is still a relevant example of where 1:1 will go wrong.

No one thinks 1:1 is a good idea.  Many of us think converting to
a different language, any different language, is not a good idea
and carries with it risk that need not be taken.  Using the logic
that conversion is always a good think, why is anyone still on VMS?
Why do people stay on VMS?  Because in many cases it is the right
tool for the job.  The same can be said about "legacy" languages.

                                                               If
you have a Cobol system using ISAM files, then do not want to convert
it to a Java/C++/Go/C# system using ISAM files.

If you have a COBOL program using ISAM today it should have been
converted to DBMS years ago.  That does not imply that it should be
converted to JAVA/C++/Go/C#.  Unless we are talking about trivial
programs, like balancing your checkbook, there are many potential
problems in moving a well functioning "legacy" program to a new
language.  And to be totally honest, no apparent value.

 

from vertical app scaling to horizontal app scaling,

>
Not really sure what this means.  :-)

 You can call it cluster support.
 If you run out of CPU power, then instead of upgrading from a
big expensive box to a very big very expensive box then you just
add a cluster node more.

OK.  But I don't see what that has to do with it being written in COBOL.
Or are you saying that IBM Systems don't scale?

 

                                                      from 5x16 to
7x24 operations etc..

>
Certainly don't get this.  Every place I ever saw COBOL was 24/7 and
that is going back to at least 1972.

 I would be surprised if you have never experienced a financial
institution operating with a "transaction will be completed
next day" model.

I get that now.  That has nothing to do with IT and everything to do
with people and their being more "legacy" than the IS.  I am finally
starting to see change. My last automatic payment from DFAS wasn't
really due until a Monday, but the funds showed up on a Saturday.
Even things that once ran only nightly as "batch" are now processed
almost immediately.  But the people still only work 8 hours a day 5
days a week and it is them that cause the apparent lag in most IT
processing.  Used to be systems went offline for 6-8 hours for backups.
Today if they go offline at all it is for seconds to minutes.  But, none
of this was ever related to the language an IS was written in and
rewriting it in JAVA/C++/Go/C# is not going to improve anything.
bill