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

On 4/1/25 10:40, Robert Heller wrote:

It should be noted that GnuCOBOL actually translates COBOL to C, and then
compiles the C code with GnuC.  In *theory* one could just run the whole code
base through GnuCOBOL and create a C code base, but good luck making much
sense of the generated C code...

I had to listen to a PMP rant all weekend about how profoundly stupid of a plan this is from DOGE, especially the "in 5 months" claim.  Overall, it sounds like another example of a "contract out to Elon" attempt, where they'll of course fail to meet any milestones, plus they'll skip any high quality testing, and dump whatever human overrides onto the already slashed staff to try to deal with while they claim "Victory!".
Total bullshit.
But in putting on a technologist's cap to contemplate what could be done, something like what you're referring to ... and/or other AI's being applied to comb & document what the code is doing ... should in theory be able to deliver an 80% solution (or better).
The challenge then becomes in building the test deck to verify that the functions were transcribed correctly, and that's going to have to be extensive to get into all of the currently-solved corner cases, so testing alone will take the better part of a year just to verify its definitions.
And that's before any performance specifications or regulations are applied for V&V.  For example, if the software safety standards of MIL-STD-882 are applied, its a "Level 5" (highest) system, so there's huge time/cost implications for passing the Levels 1-5 requirements. The irony of this is that with DOGE claiming that they want to eliminate all waste/fraud, Level 5's criteria is no more than $1M, not a 'reduce it to zero' propaganda goalpost.
-hh
  > At Tue, 1 Apr 2025 10:16:55 -0400 -hh <recscuba_google@huntzinger.com> wrote:

 

>
On 3/31/25 08:11, chrisv wrote:

c186282 wrote:
>

    Oh, I agree ... trying to "rapidly rebuild" the "Just Works"
    code-base is VERY risky. As said, most of those old COBOL
    apps on those old computers were basically PERFECT - and
    the fallout from being IMperfect is SEVERE - both politically
    and per-individual affected. Extreme caution is advised.

>
Sorry for my below naive/stupid questions...
>
How hard could SS be?

>
In a word, "very".
>

Are the rules so complex?

>
In snapshot form, not too terribly bad.  Problem is that there's been
50+ years worth of revisions, and the documentation of every change is
never 100.0000% perfect in every last detail.
>
As such, its become a "black box" that no one really knows what all it
is doing, so its a nightmare to try to document all the processes to try
to reproduce it.
>
This is why multiple Fortune 500 corporations has had projects over the
years to try to replace COBOL, but which have repeatedly failed.  For
example, one that I was aware of was looking to use Smalltalk; I never
paid attention enough to know if that was a good choice or not.
>
>

I know it's hundreds
of millions of people, but that doesn't seen a huge challenge for
modern systems.  I don't know why it would be any harder than any
"significant" piece of software, like spreadsheet or database
software.

>
It is "big iron" mainframe stuff.  Think of a single data center having
literally *rows* of IBM 360's/370's.
>
Granted, there's been huge growth for web-based centers that are running
thousands of webservers/etc, but that's largely independent parallel
capacity, not a single database, so that drives solution approaches too.
>

I'm also wondering how large the code base could be, if it was written
fifty years ago when a megabyte was a huge amount of memory.

>
Yup.  A system my wife worked on back in the 1990s for Y2K had literally
a couple of **Pentabytes** of data storage being managed by their COBOL
system.  I doubt it has grown by all that much .. my guess is that
they're probably still under ~50 Pentabytes today.
>
>
-hh
                                                                         >