Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AI migrated legacy COBOL programs to Java, bugs included

arxiv.org

Post reply on HN
Print view View original

31–40 of 108 posts

Re: AI migrated legacy COBOL programs to Java, bugs included

#31

Post by maoberlehner »

selcuka wrote: post #23
toplinesoftsys wrote: post #12

The biggest problem is not that bugs are migrated with COBOL, but that lots of new bugs are going to be introduced. AI is not deterministic, it will be making tons of mistakes. The only realistic low-error approach is incremental step-by-step migration using Cursor or similar tools. However, it requires much more time as each step must be prompted, tested and committed manually. Any hope that one-shot migraton of a l…

> AI is not deterministic, it will be making tons of mistakes. From the paper: > The COBOL source is passed through an internal deterministic Migrator to produce a generated Java target. Also, humans are not deterministic either. Give the same COBOL -> Java translation to multiple developers and each will come up with a different solution. Heck, even the same developer will produce a different output for the same tas…

> Also, humans are not deterministic either.

Indeed, and that's why so few dare to migrate them, and so many who do fail or blow the budget many times over.

I think that was the implicit point of the comment: don't expect that with AI, suddenly we can convert all those COBOL apps with a single prompt.

Re: AI migrated legacy COBOL programs to Java, bugs included

#32

Post by p_l »

Surac wrote: post #20

How does ai implement all the not Cobol parts a Cobol program rely on? Job Contol, CICS, sort processors? Cobol and mainframe technologies are non existant in java on any modern machine

Batch job control is handled by alternative systems (already often triggering the work on mainframes anyway) like Control-M

CICS is the big issue but AFAIK there were attempts. Everything else, including sort and VSAM, has various options provided usually by COBOL compiler vendors.

Re: AI migrated legacy COBOL programs to Java, bugs included

#33

Post by kukkeliskuu »

While not everything can be easily converted (IMS, CICS, reports, batch processing etc.), there are many situations where automated tooling can be helpful in migrations.

Related to this, I created a tool for situations where you want to compare COBOL code with Java code. It includes a preprocessing step where IMS etc. calls are converted to mocks that return JSON (from file), and also use JSON for input/output, and GnuCOBOL to run the program. More a proof-of-concept than production, but here is a link if somebody finds it helpful.

https://github.com/mikko-ahonen/coboltwin

Re: AI migrated legacy COBOL programs to Java, bugs included

#36

Post by dwroberts »

selcuka wrote: post #23
toplinesoftsys wrote: post #12

The biggest problem is not that bugs are migrated with COBOL, but that lots of new bugs are going to be introduced. AI is not deterministic, it will be making tons of mistakes. The only realistic low-error approach is incremental step-by-step migration using Cursor or similar tools. However, it requires much more time as each step must be prompted, tested and committed manually. Any hope that one-shot migraton of a l…

> AI is not deterministic, it will be making tons of mistakes. From the paper: > The COBOL source is passed through an internal deterministic Migrator to produce a generated Java target. Also, humans are not deterministic either. Give the same COBOL -> Java translation to multiple developers and each will come up with a different solution. Heck, even the same developer will produce a different output for the same tas…

But it says that the agentic authoring step patches the migrator when things get stuck. So while the execution of this stuff is deterministic, its actual content is not.

Re: AI migrated legacy COBOL programs to Java, bugs included

#38

Post by win311fwg »

dragonwriter wrote: post #29
toplinesoftsys wrote: post #12

The biggest problem is not that bugs are migrated with COBOL, but that lots of new bugs are going to be introduced. AI is not deterministic, it will be making tons of mistakes. The only realistic low-error approach is incremental step-by-step migration using Cursor or similar tools. However, it requires much more time as each step must be prompted, tested and committed manually. Any hope that one-shot migraton of a l…

> The only realistic low-error approach is incremental step-by-step migration using Cursor or similar tools. Correction: AI is not deterministic, the only realistic low-error solution is not a more complex use of non-deterministic AI, but deterministic transpilation. The problem is that this results in COBOL-in-Java which runs correctly but it is a nightmare to maintain.

AI (LLMs) is typically not run deterministically for performance reasons, but can be turned deterministic if you want it to be. The output will still be probabilistic, however, so you will be no further ahead. Determinism isn't helpful.

Re: AI migrated legacy COBOL programs to Java, bugs included

#39

Post by TimByte »

Surac wrote: post #20

How does ai implement all the not Cobol parts a Cobol program rely on? Job Contol, CICS, sort processors? Cobol and mainframe technologies are non existant in java on any modern machine

For the article they just mocked it out for unit tests. But in reality you really can't - that’s a massive pain in the ass. Rewriting pure math is easy, but mocking CICS transaction isolation in java means spinning up these monstrous adapter frameworks that just tank performance

Re: AI migrated legacy COBOL programs to Java, bugs included

#40

Post by TimByte »

fock wrote: post #13

300 to 4000 lines of "production like" (whatever that is) cobol code which is easily ported to a non-mainframe env. Our's sometimes uses assembler in its innards, so good luck with real legacy code spanning a dozen files and 50k loc... I recently threw in (want to check those intelligence metrics!) some real production code into a non-agentic system (just to get a feel how things perform without a custom harness) and…

Yeah that’s why they delegated code gen to deterministic tooling and saved the model for input fuzzing - let it fight the data instead of legacy syntax
Post reply on HN