Re: Bootcamp

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

On 7/11/2025 5:58 PM, Stephen Hoffman wrote:

On 2025-07-06 12:52:22 +0000, Waldek Hebisch said:

There are no indicatianos of substantial reimplementation.  Official info says that new or substantially reworked code is in C.  But w also have information that amount of Macro32 and Bliss did not substantially decrease.  So, (almost all) old code is still in use.
It could be that small changes to old code took a lot of time. It could be that some new pieces were particularly tricky. However, you should understand that porting really means replicating exisiting behaviour on new hardware.  Replicating behaviour gets more tricky if you change more parts and especially if you want to target a high level interface.

>
You're correct. Reworking existing working code is quite often an immense mistake.
>
It usually fails. If not always fails.
>
And bringing a source-to-source translation tooling or an LLM can be helpful, and can also introduce new issues and new bugs.
>
About the only way a global rewrite can succeed — absent a stratospheric-scale budget for the rewrite, and maybe not even then — is an incremental rewrite, as the specific modules need more than trivial modifications.

 Large applications get rewritten all the time.
 The failure rate is pretty high, but there are also lots of successes.
 Two key factors for success are:
- realistic approach: realistic scope, realistic time frame and
   realistic budget
- good team - latest and greatest development methodology can not
   make a bad team succeed - people with skills and experience are
   needed for big projects
 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.  The DOD EMR.  Used to be written in COBOL maintained by
General Dynamics out of Maryland.  Only major problem was inability
to share info with the VA system which was written in MUMPS.  So they
changed both of them to basically the same system.  It now takes
20-30 minutes to just get logged on to the DOD system (VA is doing
much better) and they still can't do something as simple as exchange
prescriptions.

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.
The only bad example I know of this had nothing to do with the language
but was totally on the shoulders of the one who hired government
contractors to convert from file access to DBMS.  A number of the
programs I had to deal with involved the programmer reading from the
DBMS into a file and then continuing to use the COBOL program to do
the processing.  Hardly the fault of COBOL.

from vertical app scaling to horizontal app scaling,

Not really sure what this means.  :-)

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