From: bill.gunshannon@gmail.com   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)