Re: Rewriting SSA. Is This A Chance For GNU/Linux?

On 4/3/25 11:12 AM, David W. Hodgins wrote:

On Thu, 03 Apr 2025 06:11:37 -0400, c186282 <c186282@nnada.net> wrote:
<snip>

   You're seeing the True Picture - It's *not* "easy" to
   re-write at all.
>
   And if you get it wrong there's all hell to pay.
>
   Which is why bcrats are hyper-conservative in these
   regards. They have good jobs/pensions to protect.
>
   IMHO, any re-write will HAVE to involve a 'parallel system'
   for awhile ... give it the same data, the same tasks, and
   eval if it's always doing the same thing as the old stuff.
   THEN, in a few years, quietly switch.

 The problem is people come in who do not understand how many parts there are or
are willing to spend the time to learn. They look at one small part such as the code
for the main module, and think it's easy to convert.
 They rush the conversion, and only after they start using the new versions, learn that
they missed or misunderstood many of the edge cases.
 They then get wrong results, but insist their results are correct!
 There are many languages used, not just COBOL Some of the ones I worked with include
Fortran, PL/1, RPG III, Mark IV, ADF, ASM (360/370),
 Even simple looking things like MFS code for screen definitions has quirks that are not
going to be obvious to anyone who has not encountered them.
 For example, in a 3270 style terminal where an input field is restricted to numeric, uppercase
letters are still allowed.
 It's done that way to allow for signed numeric fields. In EBCDIC, the zoned decimal value for
minus one and the capital letter D both use the same hexadecimal value. Plus one is "C".
 With edge cases, the problem is that the person doing the conversion doesn't understand that
they exist, so they don't include them in test data, and don't encounter them during any parallel
testing. Later, the system fails to handle the edge cases.
 Regards, Dave Hodgins

   Aww ... just give 'em a copy of "COBOL For Total Idiots"
   and it'll all be just fine  :-)
   Anyway, I do see where all those jagged little edges
   can totally confound anybody attempting conversions
   from the original sources.
   A sort of work-around is a functional understanding of
   the original - hardly ever look at the source - and then
   reproduce the function in a 'newer and better' lang/system.
   In short, GM didn't have to reproduce a Model-T, just
   have an idea of what cars were expected to do, what
   some of the parts should look kind-of look like. Then
   their own people could build a relative work-alike.
   Dealing with decades of the old RECORDS ... there's
   a pain regardless.