←back to thread

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

(www.pcmag.com)
127 points Anon84 | 3 comments | 03 Dec 23 16:31 UTC | HN request time: 0.471s | source
Show context
alexwasserman ◴[03 Dec 23 21:04 UTC] No.38510747[source]▶
Having had to support and migrate COBOL in a big financial the problems weren’t really related to the COBOL, but instead were:

1. The mainframe costs and support. These can be mitigated with migration to a platform like Microfocus to emulate it, but be careful you don’t replace your ultra reliable mainframe with some flakey Windows servers.

2. The embedded business logic. Within the 50-60 years of code there’s a ton a specific edge cases encoded for long forgotten business reasons. These make rewrites really hard as bugs and edge cases have long since become features or behaviors dependent apps are coded to rely on. It takes a ton of extra analysis work to understand what to keep and what to trash.

3. The cobol apps run in a challenging environment that’s also not well understood today. All the jobs in JCL, ISPF to manage things, and a system like CICS for input/output. It’s a huge change beyond just writing code in a regular IDE.

replies(2): >>38511269 #>>38520216 #
1. DebtDeflation ◴[03 Dec 23 22:15 UTC] No.38511269[source]▶
>The embedded business logic. Within the 50-60 years of code there’s a ton a specific edge cases encoded for long forgotten business reasons.

Honestly, this should be the top comment in the thread.

The issue isn't COBOL being a hard language to learn or to translate to Java or not enough programmers or companies not being willing to pay people enough to work with it.

The issue is the 50 years worth of business logic, added incrementally, over the years, with no documentation, blended into the original source, for reasons no one still working there remembers, as you stated. It's IF-ELSE statements all the way down and no one wants to touch a single one of them for fear of breaking something whose conditions might not even manifest themselves for months or years with no real way of even regression testing it.

replies(2): >>38511831 #>>38512035 #
2. Closi ◴[03 Dec 23 23:21 UTC] No.38511831[source]▶
But there is one way it can be done - lots of painstaking analysis of the Cobol source code to attempt to extract the business logic (which is incredibly slow).

At least this is how we did it at my old work where we were replacing a mainframe system.

In principle though, this is stuff that an LLM could do - assist with extracting some of this business logic and speed this process up (while porting it to a language that is easier to work with). While the LLM doesn't necessarily understand the business context, it can do basic analysis which will speed it up massively. It can also generate test cases across the whole codebase.

3. wredue ◴[03 Dec 23 23:50 UTC] No.38512035[source]▶
>it’s if-else statements all the way down

My experience with cobol at a few companies is that you’ve forgotten the mighty GOTO.