←back to thread

Watsonx: IBM's code assistant for turning COBOL into Java

(www.pcmag.com)
127 points Anon84 | 1 comments | 03 Dec 23 16:31 UTC | HN request time: 0.236s | source
Show context
ufmace ◴[03 Dec 23 17:53 UTC] No.38509082[source]▶
The article title is clickbaity, but the actual point is the proposal of using LLMs to translate large amounts of legacy COBOL systems to more modern languages like Java. Doesn't seem terribly useful to me. I expect you could get a 90% solution faster, but the whole challenge with these projects is how to get that last bit of correctness, and how to be confident enough in the correctness of it to actually use it in Production.

But then all of this has been known for decades. There are plenty of well-known techniques for how to do all that. If they haven't actually done it by now, it's a management problem, and no AI tech is going to fix that.

replies(11): >>38509198 #>>38509418 #>>38509802 #>>38509995 #>>38510231 #>>38510273 #>>38510431 #>>38511157 #>>38511186 #>>38512486 #>>38512716 #
1. rodgerd ◴[04 Dec 23 01:32 UTC] No.38512716[source]▶
I once did some work looking into whether I could help move some subsystems off a zOS system with the help of an HP pitch that was a combo of auto-translation plus contractors checking. It was an attractive idea. I've also looked at CICS/COBOL environments that run on *ix systems, with a similar view.

The problem is that once you start working through your system, it's a lot harder than people making this sort of pitch would like you to believe. People writing CICS/COBOL now will likely be writing well-structured code with sensible names, taking advantage of threading and with proper interfaces between different programs. They're shipping data on and off the mainframe with maybe REST maybe SOAP maybe MQ. They're storing their data in DB2.

But people writing the parts of the codebase 20 years ago were still regularly dropping down to 390 assembler to get it to run fast enough and, guess what, that code is still there and still being extended. Maybe they were using DB2, maybe they were using VSAM files. They were using maybe MQ, maybe SNA, maybe TCP sockets with bespoke protocols to interact with the outside world. Programs might have just been talking to each other by banging on memory regions.

If they were working in the 80s and 90s, they had all that, but they were probably experimenting with 4GLs that promised to let anyone build programs. Some of those 4GLs are still around, probably not running CICS. And there was a lot of assembler. Maybe some non-CICS workloads. Passing things around via memory regions would be as often as not.

Oh, and the people who understood any of the business processes that got turned into code are long, long gone. They got laid off to justify the computerisation. The only people who know why things happen a particular way are the people who wrote the code, if they're still alive and working for you.

And so on and so forth. The reason mainframe code bases are hard to pick apart are because they're 50 years of different languages and runtimes and databases and performance tradeoffs and opinions about what good practise is. This is hard. An "AI" COBOL to Java translator isn't 80 or 90% of the job and honestly IBM should be embarrassed to be the ones suggesting that it is.