I believe that practically the whole barrier to getting rid of legacy COBOL systems is testing the replacement system. Of course it's possible but it's very very expensive ... I don't have numbers for how expensive, but I've worked on financial software in COBOL on a mainframe, and nothing was the least bit abstruse or scary or difficult about it except the worry that our test suite might not be comprehensive, no matter how much we worked on it (and we worked on the test suite about the same amount as we worked on all the rest of the code put together). But at least our test suite appeared to cover all the cases that eventuated when we ran our COBOL code. How confident would be be that it would cover all the cases that eventuated when we ran translated code? THAT is the problem (or at least was for us). Nothing at all to do with whether translating COBOL can be made easier.
Watsonx: IBM's code assistant for turning COBOL into Java
101–110 of 186 posts
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#102Earlier quoted context omitted.
How hard is it to actually learn COBOL? It seems like a fairly simple language to pick up, but maybe the idiomatic COBOL used in these legacy systems is particularly nasty for some reason.
Not hard. It's a bit old-fashioned and sort of verbose but it's nothing difficult especially if you already know any other imperative languages. My first job out of school in the early 1990s was with one of the "big" consulting firms. We learned COBOL in a four-week boot camp and were then dispatched to a client site to write code.
Haha that explains a lot :-)
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#103Another marketing piece by IBM aimed at impressing inexperienced managers and developers. If they wanted to come up with a tool to rewrite Cobol they’d have come up with a standard transpiler.
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#104Earlier quoted context omitted.
Heirloom computing where I am cto does this using transpilers with 100% automated transpilation. Using LLMs for an entirely deterministic domain borders on the insane. This is just marketing bs but we get asked about it and what our plan is to counter it all the time. Explaining that using Gen-ai and LLMs for what is a well understood compiler/transpiler problem that is already solved just seems to be too difficult f…
In fairness I imagine an LLM could maybe transpile to more idiomatic code. For example when you transpile FORTRAN to C you get a load of +1s and -1s everywhere to deal with FORTRAN's 1-based indexing. An LLM could avoid that. But I agree, it doesn't make sense to risk bugs just for that.
You could do it with a trivial C macro instead.
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#105The implicit assumption here is that developers will charge less to maintain code that was machine translated from cobol to java than they will to maintain the original code.
I’d certainly want to be paid more to deal with the LLM output than the original source code.
I don’t know cobol and I do know java, but that doesn’t enter into it from my perspective.
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#106The implicit assumption here is that developers will charge less to maintain code that was machine translated from cobol to java than they will to maintain the original code. I’d certainly want to be paid more to deal with the LLM output than the original source code. I don’t know cobol and I do know java, but that doesn’t enter into it from my perspective.
> I don’t know cobol and I do know java, but that doesn’t enter into it from my perspective.
Shouldn't it though? Maybe you (as an individual) would charge (or expect to be paid) more to maintain LLM code than bespoke code, banks know they won't have to pay as much to you (as a member of the collective of java engineers) than they would to a cobol dev.
Really the implicit assumption is that cobol devs are fewer and more expensive than java devs.
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#107Having 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…
>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,…
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.
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#108Earlier quoted context omitted.
Learning COBOL is the easy part. My understanding is the hard part is becoming familiar with insanely expensive, proprietary mainframe platform that’s you’ll find in most COBOL work. I know IBM has some sort of self training material, but I’m not sure if it’s enough to go from zero to qualified. Most work I see in the area seems to want established domain experts, not hackers who learn just enough to be dangerous.
It’s not that the mainframe is hard to learn. In fact, the environment is pretty easy to understand once you get past the archaic naming (but let’s not kid ourselves: on the POSIX side we’re still running t[ape]ar[chive] and other archaic tools too). In a way, the ease IS the problem: the runtime environment for COBOL (and other stuff on the mainframe) assumes that the underlying platform and OS deal with the really…
Well said! This echos my, admittedly somewhat limited, experiences as well.
I remember one mainframe I supported, there was an explosion on the same block which took out most of the buildings in the area. It was bad enough that the building which housed the mainframe was derelict. But that mainframe chugged along like nothing happened. I can't remember what hardware nor TSS it was running but I woul guarantee that none of the platforms I've supported since would have faired nearly as well (though I did have some SPARC boxes in one company that survived more than 10 years continual use and zero downtime -- they were pretty special machines too).
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#109Earlier quoted context omitted.
> that rewriting them is an absolute no-go Rewriting and expecting 100% feature-parity (and bug-parity, since any bugs/inconsistencies are most likely relied upon by now) is realistically impossible. However, new banking/insurance startups proved you can build this stuff from scratch using modern tooling, so the migration path would be to create your own "competitor" and then move your customers onto it. The problem…
That happens, but what also happens is that everybody is painfully aware of the situation and they do the best they can. Just like you or I would. And of course, if you start a bank today you'd do the whole cycle all over again, shiny new tech, that in a decade or two is legacy that nobody dares to touch. Because stuff like this is usually industry wide: risk adversity translates into tech debt in the long term. I su…
Why would software technology ever stop moving? To a first approximation it is unconstrained by physical reality (unlike other engineering disciplines) so I expect it will keep moving at roughly the same rate. Maybe even accelerate in some areas.
Individual organizations can consciously choose to slow down. Which works for a while in terms of boosting quality and productivity. But over the long run they inevitably fall behind and an upstart competitor with a new business model enabled by new software technology eventually eats their lunch.
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#110There seems to be plenty of cobol transpilers - anybody know why they can’t use those. Immediate thought was it’s just beating on the dead Watson horse.
Well, I mean, if they were to do that, they wouldn’t be able to issue a press release containing the word ‘AI’, now, would they? Like, that is what this is about.