IBM stock dives after Anthropic points out AI can rewrite COBOL fast

IBM’s share price slumped by 13 percent on Monday, seemingly caused by investors reacting to an Anthropic blog post that points out its Claude Code tools can accelerate refactoring of apps written in the ancient COBOL language. Anthropic’s post points out that COBOL applications remain prevalent and often handle critical …

[Anonymous Coward]

AI Saved Humans from COBOL?

Please award it the Nobel Peace Prize.

[Tron]

Re: AI Saved Humans from COBOL?

Would you settle for the FIFA Peace prize?

[cschneid]

COBOL is easy...

...JCL isn't. CICS isn't that hard, it's got an API that is well documented and pseudo-conversational programming style isn't that far off from server-side web applications. DB2 is just another RDBMS if you're an applications developer. ISPF contains concepts foreign to most people under 50, but ZOWE exists. IMS is so far out there it isn't even visible from here.

People have begun pointing out that it isn't COBOL that's the roadblock, it's all that other mainframe *stuff* that doesn't have a Linux or Windows analogue. A file system without directories, required disk space allocation, dataset types.

That's just the applications side of things, the systems (admin) side is *completely* different.

Rewriting COBOL as some other language? I mean, if you want to, I guess, go ahead; I don't see the ROI. If the goal is to be free of the mainframe because of cost, be sure your cloud (because of course that's the target environment) costs are cheap enough to make it worth your while.

[Anonymous Coward]

Re: COBOL is easy...

Just use the AI to fix the COBOL issues and avoid the disruption of rip and replace.

As COBOL has changed little….. AI might actually get that right.

[vtcodger]

Re: COBOL is easy...

"AI might actually get that right."

Maybe. I suppose all things are possible. But my impression is that COBOL is used mainly in things like banking applications, and AI is notoriously bad at arithmetic.

[Anonymous Coward]

Re: COBOL is easy...

Still feels better than replacing working legacy with Oracle anything, or some Vibe wanker generating Agile Rust Code to replace millions of lines of working code.

[Peter Gathercole]

Re: COBOL is easy...

Whenever I consider discussions like this, I ask myself the following question.

If you use AI to re-write the code, do you then ditch the Cobol, and continue supporting the AI generated code? Or do you keep the Cobol around, and everytime you need to change the code, make the changes in Cobol and then re-translate?

Answers to this dilemma depend very clearly on two things. Firstly, is the generated code maintainable? and secondly, does the generated code adequately cover all of the system requirements and all of the changes to them that have happened over time?

My worry is that if a business decides to ditch the Cobol, and forward fix the AI generated code, who understands the original requirements, and are those requirements sufficiently clear in the resultant code to not introduce a whole raft of corner cases going forward?

I can see a scenario where if the code base switches to the new language, a problem, or even a modification becomes impossible to work into the code, because nobody really understands the generated code to make further changes, and the rerquired changes may be too subtle to allow an AI loose to rework it.

Many of the businesses that still buy mainframes do so because they don't want to answer the above questions, because if they get the answers wrong, the cost and reputational risk is more than the cost of keeping the applications running on mainframes.

[retiredFool]

Re: COBOL is easy...

Agree, banks unlike crypto are loathe to make FU's like the one in SK where the crytpo "bank" gave away a few billion I think it was by accident. In my lifetime (which is getting long) I've seen one bank error, they screwed up and bounced a check payment for my NatGas co. They were deeply apologetic and paid the interest/penalty from the gas co. One. And this was 30 years ago. My brokerage has never screwed up. Less years, more transactions.

[Elongated Muskrat]

Re: COBOL is easy...

I think maybe the "correct" way of doing this (and it doesn't apply only to COBOL) is to use the "AI" to reverse-engineer the code into documentation, and requirements, and then have a human, or team of humans, verify that these are complete, correct, and don't include hallucinations. Then you can use these to write new specifications for the reimplementation, and have humans write that, because "AI" is terrible at actually writing code.

tl;dr; statistical models are good at analysis, and terrible at synthesis.

[Anonymous Coward]

Re: COBOL is easy...

I'm currently working in this particular trench, and you've got it. LLM coding assistants are genuinely helpful with explanations, like "what is the code in this huge file I've never looked at doing" or "where the hell is this value ultimately coming from", but for actual coding (because there's huge pressure from upper management to at least try it) I've found that the amount of time it takes iterating on prompts to make it output useful, high-quality code is more than amount of time it would take to just write it myself.

[Elongated Muskrat]

Re: COBOL is easy...

My experience of it is exactly this as well. A recent example of evaluating Claude, for example, to help fix a bug in some very sloppy code we had a contractor produce (that's a whole different story), shows us that it's actually pretty good at identifying the cause of the problem, but that it isn't so great at suggesting a correct fix (it suggested things that were close, but no cigar).

[abend0c4]

Re: COBOL is easy...

My first job involved teaching people JCL - which required me to learn it first. It's not that hard and once written is rarely altered. The biggest problem about legacy systems is usually that no-one is exactly sure what they do which parts of their function are still required and which are obsolete - and that is often reflected in a lack of comprehensive test coverage. That makes rip-and-replace a significant risk.

There are other ways to run COBOL (and CICS) code that don't involve traditional mainframes, but, as you say, consider the ROI. As for the risk, automatically translating code whose function you don't understand into another language won't make it any more maintainable and will probably introduce bugs you have no means of detecting until something randomly fails in production.

[vtcodger]

Re: COBOL is easy...

I remember encountering a friend I hadn't seen for a while back in the 1960s. He was trying to get something or other working on something using an early release of OS/360. His description of JCL? "The world's first syntax free language"

[CrazyOldCatMan]

Re: COBOL is easy...

The biggest problem about legacy systems is usually that no-one is exactly sure what they do which parts of their function are still required and which are obsolete

One place I orked we found a Novell server humming away in a cvupboard with a "do not turn off" faded sticker on it. No-one who worked there had any idea what it was doing. Attaching a keyboard and display didn't get us any useful info other than Novell was way out of date.

So, after gaining permission from The Powers Above, we turned it off.

That month, the billing cycle failed. The calculations ran happily on the mainframe but the server that generated the billing never got anything. Opps.

Turned out that the Novell box had just one job - on the last day of the month, grab the mainframe data and save it onto the server (which was on an entirely separate LAN to the mainframe).

Fortunately, turning it back on and tweaking it to run the job there and then produced that months bills only a day late.

It then got relocated into the server room and labelled properly with "Monthly billing transfer server, do not power off" and the contact details of the system owner for the billing system (who hadn't known about its existence before..)

[spold]

Re: COBOL is easy...

Can it re-punch my paper tapes? Just askin' for a friend....

[Stuart Castle]

Re: COBOL is easy...

The rewriting of the Cobol isn't the hard part. The hard part is the testing, and fixing any errors that come up (and there will be errors). If it was as easy as rewriting the COBOL, everyone would have done it. After all, during the millenium, it would surely have been cheaper to port all of the old systems in uses to modern servers and ditch the mainframes if it was as easy as just rewriting the COBOL..

The fact is it isn't that easy. There is often more than just COBOL at the heart of these system, and any changes would need testing anyway. Certainly if you are planning to run your business on it.

This might seem like I am anti AI. I am not. It is a tool with a lot of uses, but I think we need to be careful to avoid the hype. AI companies need a lot of money, and they will only get it if they can get people think they are making regular and impressive breakthroughs that are going to disrupt industries.

[hittitezombie]

Re: COBOL is easy...

Oh simples, get the LLM write your test cases as well, and ensure the instructions say 'this test must pass', and it will fabricate convincing test results just to keep you happy!

[Elongated Muskrat]

Re: COBOL is easy...

Exactly this; the main issues with any legacy code are knowing what it is actually used for, which bits are unused, which bits never worked, which bits have as-yet-undiscovered bugs in them, what people want it to do, but it doesn't, so they have workarounds, and hardware and environmental issues such as timing, and the expected shape, size, and performance of storage media and networking. Amongst others.

[Elongated Muskrat]

Re: COBOL is easy...

Oh, and let's hope it's not self-modifying code that depends on things like assumptions about disk geometry to work correctly.

[CrazyOldCatMan]

Re: COBOL is easy...

The rewriting of the Cobol isn't the hard part. The hard part is the testing, and fixing any errors that come up (and there will be errors)

Someone I know used to work with a banking mainframe running ancient Cobol stuff. His description was "some fairly simple Cobol with 10 million exception cases where the rules don't strictly apply"

[bombastic bob]

Re: COBOL is easy...

I did a quick search, found THIS - anyone try it?

I learned COBOL in the early 1990's on the fly because I suddenly needed to maintain a sales tax calculation system that was written in COBOL. Did not take long [and I discovered the previous programmer had LOST the most recent FORTRAN "glue" source and I ended up re-writing it - stupid regression bug] but there is a difference in maintaining COBOL and writing COBOL from scratch. I think I could have come up with a way to port it to another language like C (or Pascal or FORTRAN or even Clipper) at the time, maybe with simple text conversion. HP3000 systems used a Pascal-like lingo that I cannot remember the name of. And the accounting and manufacturing MRP software were both written in FORTRAN. So converting COBOL to FORTRAN would have been a reasonable task, if the hook were not there.

[Slant Four]

this is crazy talk

So yet again (like the SAAS vendors losing share price recently) something that AI might be able to do (in this case cobol conversions) but which it doesn't have a track record in causes investors to panic.

What COBOL code that is running is because it is mission critical, is running on mainframes, has hooks into mainframe sub-systems like CICS and JCL and if it was able to be moved it would have happened already (I have done several POC's back in the day for this and my conclusions were always the risks are too high).

Thus (given the workloads COBOL supports) it would be even more critical for AI to be 110% perfect in the conversion process (typically to Java!!!!).

There is nothing new under the sun with COBOL conversions, the toolkits have been around for decades but it's the other mainframe ecosystem stuff around it that makes it hard (outside of CICS and JCL)... like assembler modules that are called (who's gonna convert that and what do you convert it to)... operational workflows/interconnections to other systems etc.

I know the share market is forward looking but this panic like behaviour is illogical.

It seems to be a pre-cursor to how they will react when it is found (at least by investors) that AI (in it's current form) is a dead end.

Bluck

PS. look like I as ninja'ed by another poster on this..great minds think alike

[Fido]

Re: this is crazy talk

Since COBOL compiles to native code while Java doesn't (and further spends time boxing and unboxing the strangest things), I naively don't see how converting COBOL to Java would accomplish anything but performance problems.

While the article lacks a level of detail and facts, IBM stock did go down by more than 10 percent after the Anthropic announcement and publishing needs to be quick before the stock bounces back up.

As already mentioned, AI assistants that make maintenance of COBOL code easier and more cost effective is what IBM themselves have been focusing on for some time. As soon as the investors realise this is a good thing for IBM, the stock valuation will go back up.

[PhilDin]

Re: this is crazy talk

I know nothing about COBOL but modern JVMs are very smart at optimization and every release gets a bit better. My guess would be that standard "by the book" COBOL can probably be translated into efficient Java code. If the COBOL programmer was using some arcane hacks to optimize performance then maybe that could be missed but for the average case I wouldn't be surprised to see performance gains (all said as a non-COBOL person)

[that one in the corner]

Re: this is crazy talk

> . If the COBOL programmer was using some arcane hacks to optimize performance

There is nothing arcane in COBOL, the ALTER statement is right there near the beginning of the index, it isn't obscure or unknown, nothing hidden away, it is easily grepped for...

[bombastic bob]

Re: this is crazy talk

Java has portability as its number one benefit, and if you look at performance of legacy systems the inefficiency of Java is NOTHING compared to the klunkiness of old big-iron hardware the native code runs on.

GROK analysis

[doublelayer]

Re: this is crazy talk

The point is that it would make some structures more portable, either to different types of computers or different types of processing. Cobol that can be compiled without any dependency on other old software or hardware is less affected, but even then, more work has been done on optimizing compilation to JVM bytecode and of the JVM itself on modern hardware than you suggest.

Both of those can bring substantial performance benefits, but to get them, you have to reimplement the same behavior again, not just directly porting it. Rule-based automatic translation will produce the performance decreases you expect, which is one reason though not the biggest why previous attempts have failed, the biggest being dependency on other old systems which won't get out of the way just because calling code is in another language.

[BartyFartsLast]

Re: this is crazy talk

This panic like behaviour is a result of jittery investors who are grasping at any straw in their desperation to find something, anything that justifies the insane amounts of money being wasted by AI.

The money has to come from somewhere and the whole tech market wobbles because it's in a state where AI not turning a profit is now life and death

[steviesteveo]

Re: this is crazy talk

AI cobol migration is a feature IBM is selling on their z17s and it has the exact same issue - if that sort of risk appetite was there it already wouldn't be cobol

[CrazyOldCatMan]

Re: this is crazy talk

like assembler modules that are called (who's gonna convert that and what do you convert it to)

My first proper job was as a TPF assembler programmer on IBM 3090J S/370 lumps.

Then I realised that a) programming was boring, b) It wasn't my core skill [1] and c) Support had way cooler tools.

[1] AKA "I wasn't very good at the nitty-gritty details. Which, for an assembler programmer is 'pretty much everything'"

[Tron]

Re: this is crazy talk

People make money when stocks rise or fall.

You short stocks.

AI can do gubbins cheaper and faster...possibly.

You bank cash as stocks fall.

You buy stocks cheaply.

Turns out it can't.

You bank cash as stocks rise.

It works like a joystick.

[bombastic bob]

Re: this is crazy talk

assembler modules that are called (who's gonna convert that and what do you convert it to)... operational workflows/interconnections to other systems etc.

un-portable code is the worst, yeah. Outside of simvh how can we fix this problem before the hardware ro run it on no longer exists?

/me points out that an RPi running simvh could VERY LIKELY outperform a typical mini or mainframe from the early 90's. But I'd rather have something with SQL and REST-like protocol than rely on cryptic and/or legacy protocols.

[Denarius]

Well analysed. Migration off a mainframe is an ecological move. Difficult to get tropical fish to thrive in arctic lakes

[Bebu sa Ware]

Difficult to get tropical fish to thrive in arctic lakes

Although the AI build out is working diligently to change that by degrees. :)

Just recently a shark was observed in antarctic waters for the first time ever.

[Anonymous Coward]

Re: Difficult to get tropical fish to thrive in arctic lakes

He doesn't have a town house in Manhattan where he could stay with friends any more.

[Roland6]

“Could” - if only someone ipays us …

Reading the linked article, nowhere does it say Claude has actually been used or has the functionality today to do a COBOL migration, it just says AI “could” and then gives a load of generic stuff about what an AI tool like Claude could do.

So this is just another AI puff piece from those who believe the emperor is wearing new clothes, so fine only the initiated can see.

[Dan 55]

Re: “Could” - if only someone ipays us …

"The developers who built these systems retired years ago, and the institutional knowledge they carried left with them."

So let's put the code through a bingo machine, nobody will be able to tell if it's right or wrong.

[CrazyOldCatMan]

Re: “Could” - if only someone ipays us …

So let's put the code through a bingo machine, nobody will be able to tell if it's right or wrong.

"Bank error in your favour. Collect umpteen squillion pounds"

"SIRI, please tell me the easiest way to launder umpteen squillion pounds"

[Anonymous Coward]

Re: “Could” - if only someone ipays us …

My experience is that "AI" really struggles both with anything that isn't massively popular and also with anything that has different versions.

I'm seeing it now with a program that has changed significantly with the latest version, ask "AI" and it'll give you something that worked 3 versions back but won't now. I get team members suggesting things and I'll just shut them down if they say it came from "AI", unless they can link to the docs where it says to do this then it's a hard no. I've experimented following it down the rabbit hole and you just end up with utterly broken systems.

Relatedly, many moons ago I was part of a team migrating a COBOL system from UNIX to Linux (on the Linux side rather than the COBOL side), despite being from the same vendor there were significant differences that required significant rework by the COBOL devs. I could just see how assumptions based off older versions would cause all sorts of issues.

More recently I've been playing with Verilog, "AI" just can't manage to cope with it. I've tried getting it to write even simple blocks and it just fails to understand how the language *works* (in fairness it does take some getting your head around it).

So can it be helpful? Yeah, in a "what does this bit do" way but I can't see it replacing the skilled COBOL devs any time soon.

[Pascal Monett]

“AI can assess"

No it can't.

It can just spit out some variation of what it has been given to ingest.

I would go on a rant about how we should stop talking about "AI", but I might as well try going through a brick wall using my head.

[Tim 11]

Re: “AI can assess"

"spit out some variation of what it has been given to ingest" - that sounds very like a description of porting to a new environment

I'm no AI fanboy by any means, but COBOL is a pretty dumb and verbose language. Today's AIs should be pretty competent to port the code, including generating automated tests and verifying the new code passes.

[sabroni]

Re: I'm no AI fanboy by any means

Really? Then why are you suggesting we use AI for a task that can be handled more quickly, more accurately and more reliably by a regular transpiler?

[steviesteveo]

Re: “AI can assess"

It's beside the point, though. This stuff hasn't been carefully maintained through the decades because you were happy to mess with it. It's exec bait because everyone hates their ancient cobol that keeps the lights on but it'll never happen for the same reason it never happened before

[Roland6]

Re: “AI can assess"

>” COBOL is a pretty dumb and verbose language.”

COBOL does what it was intended to do, yes it’s verbose, but it largely self documents (although that doesn’t mean it’s not possible to write “write only code” in COBOL).

>” Today's AIs should be pretty competent to port the code”

To port software requires a Rosetta Stone or Babel fish for programming languages and job control environments.

Given previous attempts to convert COBOL to C, and current attempts to use AI to convert C to Rust - for target environment's other than Linux, I suggest code(*) porting is beyond today’s LLM style AI assistants. This is demonstrated by the lack of the backers of Claude providing any examples of COBOL code porting…

(*) By code I mean a complete enterprise S/390 or later COBOL application, not some noddy lab demo.

[NickTheGeek]

Re: “AI can assess"

<cite>

COBOL is a pretty dumb and verbose language

</cite>

<sarcasm>

It was designed by a women, after all...

</sarcasm>

<serious>

...but if you can put up with the verbosity, she ... correction, I wanted to say: "it" ..., can get the job done, and accomplish truly remarkable things. ;-)

</serious>

[Elongated Muskrat]

Re: “AI can assess"

It's fine to call it "AI" just as long as you acknowledge that the "AI" stands for "Actual Idiocy".

[Tim 11]

I'm not too sceptical that AI would be a viable tool for migrating away from COBOL, but does that 13% figure really represent the proportion of IBMs business that is COBOL related?

[MrBanana]

The 13% fall has been generated by stock holders who know less about COBOL than my cat. They are a nervous bunch and easy to get the jitters. Especially when one of them sees "something, something, AI, something" and thinks it might be bad, so prods the rest of them to react.

[johnB]

Ummm...

Wouldn't it be cheaper & more effective to train actual humans in COBOL?

You know, an actual training programme for staff rather than buying the latest vendor shiny shiny?

[andy the pessimist]

Re: Ummm...

<sarcasm>Training employees. That's crazy talk. </sarcasm>

[Anonymous Coward]

Re: Ummm...

They mention this in the article, as they've tried it, but I guess nobody under 50 wants to learn a dying/dead language.

[dippy1]

Re: Ummm...

How about training people over 50?

You will still get a good number of years out of them.

OK I know you wont find anyone over 50 at IBM below the C-suite.

[SamanthaFA]

Re: Ummm...

I'm 58, and we did learn COBOL as part of my computer studies course back in 89-92.

haven't done any since then but I'm sure I could pick it up again ;)

[CrazyOldCatMan]

Re: Ummm...

I'm 58, and we did learn COBOL as part of my computer studies course back in 89-92

Yoof! I am, as of yesterday, 61.

And, when I was looking for my first proper job back in (counts fingers) 1988, I did do a 2-week cobol course. I can just about read a Cobol listing and work out what it's doing but anything beyond that..

Nah.

[ExampleOne]

Re: Ummm...

You mean no one wants to pay enough...

If the money is there and good enough, there will always be people who would be interested.

[Anonymous Coward]

Re: Ummm...

They will if you pay them a fair remuneration. Esp. The new Grad’s who can’t get a job.

[Roland6]

Re: Ummm...

>” nobody under 50 wants to learn a dying/dead language.”

But the amount of COBOL in use and the job market, would suggest it isn’t a dying through lack of use.

I suggest the reason why it, and many other languages are “dying” is because you typical computing student only wants to learn about the new fad, hence why in the 1980’s uni’s switched to Unix and C, in more recent times we’ve seen people proclaiming Rust is the new silver bullet language, and even more recently Vibe is hip way to develop “code”.

I expect if you targeted what in previous times were HND business studies and computing students, you would get a lot of good COBOL programmers…

[that one in the corner]

Re: Ummm...

> I guess nobody under 50 wants to learn a dying/dead language.

Calling COBOL dead or dying is pretty weird, *especially* if you were being offered training to learn it and get a decently paid job (if you are the only COBOL programmer in the village you can hawk your talents around).

Dead? If there weren't lots of COBOL stil active this conversation wouldn't even be happening.

Dying? The latest COBOL spec is dated 2023, not 1963, and covers object oriented programming and even JSON (sobs quietly). Not a single antimacassar in sight.

And if those kids took the jobs - and learnt to call themselves "specialists" with a straight face - then they'd be the ones proudly keeping it alive and able to afford nice skiing holidays doing so.

"But it should be left to die!" - Why? It is doing a useful job. Otherwise this conversation...

Oh, they mean it isn't *fashionable*! They can't boast about working with it because the rest of the playground will laugh at them. They think it means they will lose out because they can't leap into the next billion dollar startup (because, of course, 99% of all us programmers are multi-millionaires after striking it lucky with our website).

It isn't *exciting*? Keeping the economy going isn't exciting? Ok, so if you screw up the COBOL and the banks collapse it isn't as glamorous as the sub-prime lenders frothing at the mouths on TV news that they deserve to be bailed out, but you'll get the adrenaline going during the code review.

You can't make your mark on the world? Come of it, when you're a senior dev pretty much the "entire* COBOL community is going to be in the auditorium for your presentation on the new keyword you've worked out: all the grunts who'll demand your autograph, as well as the luminaries you know from social media posts.

[chozorho]

Re: Ummm...

Actually, I am a software engineer under the age of 30, and I would happily learn COBOL. The problem, last I checked, is that they do not offer entry-level or training positions in COBOL. Back in 2022. the vast majority of jobs demanded at _least_ seven years of experience with "COBOL, CICS, JCL/PROC, VSAM, DB2, Easytrieve." Some of them demanded 10, 12, or even 20 years of experience! If you can tell me where these "training opportunities" were, I would greatly appreciate it. This is the one part of the article that I found very dubious.

[J.G.Harston]

Re: Ummm...

Agree. I last did COBOL programming at university (mumble) decades ago, but rereading my assignments and getting a compiler have found I can quite easily pick it back up again, but all the vacancies demand that you've been doing the job for the last 30 years right up to teatime yesterday.

Government: "Had a career break? Retrain and do something else!"

Employers: "**** off".

[ecofeco]

Re: Ummm...

Exactly.

[seven of five]

Re: Ummm...

Apply anyway. If they really need someone and you can demonstrate to be eager, quite a few companies would take you in. A COBOL (motivated, and trained in-house, on their own environment) Programmer unter 30? Worth its weight in Tritium.

[doublelayer]

Re: Ummm...

How would you do that? Whenever I've interviewed someone for a job where experience was required, the interview made them prove the experience. Someone showing up saying they don't know the things I need them to know didn't make it any further. That was also true if I thought they were smart and could learn that; I might want to hire a trainee, but the company didn't. Companies having a tall, rickety pile of Cobol to maintain aren't trying to train people in it because, if they had the people to do that, they would just make those experienced people fix their system. It would make sense for several such companies to form a training consortium to produce knowledgeable new Cobol programmers. It would have made sense to eventually bite the bullet and figure out what all of that code does and reimplement it in something that would last better. The companies still doing it haven't done the latter and aren't doing the former for the same reason.

Perhaps someone eager could just apply to all the Cobol positions on the theory that eventually, one would be desperate enough and take and train them. It might work; I can't know how all those companies hire. They should only try it if they're willing to play the lottery and lose several times, attending interviews where they'll be angrily dismissed after stating that they don't have the first five requirements on the list.

[seven of five]

Re: Ummm...

You certainly have to be up front with your (current) lack of ability. And then see what happens, some might take the risk of several years of training in order to have someone for the next twenty years.

When I have an apprentice who demonstrates interest and basic ability, I go out of my (usually very grumpy, think "25 years Unix") way and try to teach him. Worked once.

[doublelayer]

Re: Ummm...

It's less that nobody wants to learn and more that nobody wants to hire that. The people with the systems they want maintained are sitting behind a bunch of old code they don't fully understand, and they don't want to gamble on someone who learned Cobol but not some important component that their system uses. They want someone who worked on that kind of system at the time and ideally one who has continued to do so all the way through. That's not easy to train, and if they had available resources to do the training themselves, they wouldn't need to hire anyone else. Neither can a motivated student just go take a training course because available materials will cover ideal coding style in Cobol, not all the annoying little things that were made obsolete in 1995 but this code was originally written in 1982 and so it's still in there.

A modern trainee might be able to get one of those positions by learning the language and the systems themselves, manually, with a lot of grinding study for no reward, in the hope that, after they've successfully maintained some old system whose code got published, someone will hire them at a higher salary. Most new programmers don't choose to gamble on that when they could learn languages that lots of places want to hire for today and where their learning can take the form of building something useful.

[Anonymous Coward]

Re: but I guess nobody under 50 wants to learn a dying/dead language.

but I guess nobody wants to learn a dying/dead language. - perfectly sensible sentiment

but I guess nobody under 50 wants to learn a dying/dead language. - perfectly ageist stupidity, implying what? That people over 50 could learn it but they're too old to do anything useful?

[Chloe Cresswell]

IBM said this years ago?

So an "AI" company is repeating something another source already said?

How apt.

[Lon24]

apt purge ai ?

[Dunstan Vavasour]

When you've got them by the balls

IBM, like Oracle, has for a long time used the sales tactic "We've got them by the balls, so we can squeeze as hard as we like".

So while the Claude Code story is the usual self promoting bollocks, the market reaction might just be "your days of abusing your customers like this may be numbered".

[srirzosh]

None of this is new, Microfocus and BluAge (now AWS Transform) have been doing conversions of mainframe workloads to modern frameworks for years.

As always, the challenge is not converting COBOL to a modern language. It's rarely the performance of a modern language on commodity hardware vs COBOL on a mainframe. The problem is testing functional equivilence between the old and new - this is HARD and takes considerable effort usually.

[MrBanana]

Language translation is (nearly) the worst option

Another problem with any computer language conversion is that it is a one way process. If you do a COBOL -> Java (for example) translation then you end up with code that can be compiled, but is a nightmare of unintelligible gibberish (I know, I know, just more so than usual Java code). If you need to make a functional change then you have to either make the change in in the Java code (and break the link to the reference implementation), or make the change to the source COBOL, and re-convert, and re-test everything. Neither option is desirable, and I would imagine that the other path of throwing everything away, and starting from scratch in a totally different but supported system, will be even more trouble. And you will have to fight off all the hungry consultant firms with your big, shitty stick, or be in their thrall for years to come. Did someone mention IBM?

[CrazyOldCatMan]

Re: Language translation is (nearly) the worst option

I would imagine that the other path of throwing everything away, and starting from scratch in a totally different but supported system, will be even more trouble

I refer the honourable gentleFruit to the current Capita Civil Service pension system as a prime example..

I know, lets take a complicated historical system and do a big-bang cutover to a system that we haven't even got yet! After all, we've got two years two months because of our total inability to manage projects so what can go wrong?

[Larry D]

Java is legacy

I have coded COBOL, PL/1, etcetera. I did a Java course in 1995 @ Sun ! It's old.

[JacobZ]

One of the problems with COBOL (and other old languages) is not just that the code is old and the programming expertise is scarce; it's that the code often IMPLICITLY implements business requirements that are not EXPLICITLY documented anywhere. The Requirements docs or design docs or functional specs are probably long gone. There are likely to be critical chunks of code where the last person who knew why it did a particular thing - or did it a particular way - retired decades ago.

That is a level of understanding - and a level of caution - that an LLM is never going to achieve. It's a big part of what other posters have referred to as the problem of ensuring that the replacement code is functionally equivalent to the code it is replacing.

And I'm guessing the people proposing this have as little understanding of what it was like to develop in the Olden Days as do the people selling off IBM over this latest scare.

[Yet Another Anonymous coward]

And a cheap outsourced to IBM India programmer wouldn't have the same problems?

This is IBM's issue, it's not that AI can replace COBOL, it's that AI can do the same shitty job as IBM 'consulting' but not charge $10k/day

[MrC]

Even though COBOL is _supposed_ to be self-documenting sometimes you sometimes had to jump through hoops to make it do exactly what you wanted, especially if you were writing client/server code (eg using SCOBOLX on Tandem kit, which dates me). As a result we made sure that we included comprehensive comment blocks to let future maintainers know why we did what we did to keep to the requirements specs. If you now get AI to re-write functional changes to old COBOL code then it'd probably be a good idea to keep COBOL as the base language and also keep the original comment blocks (or if AI is that good then re-write the comment blocks to reflect the new changes). Otherwise future maintenance just gets even harder and errors could creep in.

[Anonymous Coward]

What's to say that Anthropic and other AI code people get you hooked and then hike the prices, once all the software developers have been sacked due to software companies they work for going bust.

[Elongated Muskrat]

Anyone not expecting this is being criminally naïve. All this "AI" bollocks is being developed and pushed hard with billionaires' money. Nobody gets to be a billionaire without being a ruthless psychopath. It absolutely is a bait-and-switch first-one's-free situation.

1) Give it away for free.

2) Sell it at a loss.

3) Get lock in.

4) Crank up the price, and boil that frog.

5) Profit.

The only problem with this, is, of course, that it doesn't fucking work properly, so number 3 is a bit of a sticking point. Still, since it becomes between 2 and 4, I look forward to those ruthless bastards losing the farm on it.

[StefanoW]

How will ai slopware be tested and maintained?

Having too much experience with the deleterious effects of inadaquate software testing, I have to ask who(, how and when) is going to validate ai authored applications? Not forgetting that cobol apps are "well understood" who (what) is going to maintain ai slopware?

[Elongated Muskrat]

Re: How will ai slopware be tested and maintained?

What do you mean you can't validate nondeterministic output, you just... errr... errrrrm... bear with me...

[Anonymous Coward]

Who would you trust if you did decide to port COBOL?

The company who just *think* their LLM can read COBOL or the company who can write a compiler that *definitely* can parse COBOL?

Which to choose, output that may compile if you are lucky ('cos you aren't getting any more trustworthy reasoning for the choices made) or the result of Abstract Syntax Tree transforms that are mathematically provable to retain semantics (except in these cases, which we admit and print out so that humans can have a look)?

[James Anderson]

COBOL is not obsolete

It is a domain specific langage for accounting and general business admin. It does arithmatic as understood by accountants and tax collecters that most other languages just dont.

Just as FORTRAN is an ancient but still relevent language for scientific applications.

Its long history is actally an advantage as incremental improvements have been well tjought out.

[Yet Another Anonymous coward]

Re: COBOL is not obsolete

Assuming you have been regularly rewriting your system to take advantage of these new programming paradigms and not just patching the machine code for a system you lost the source for in 1980

[J.G.Harston]

Basterds! Just as I dig out my university COBOL assignments, get myself a Windows COBOL compiler, and refresh my COBOL skills to jump into the gravy boat, they find a way to get rid of the jobs.

[Yet Another Anonymous coward]

The problem is you need to be an expert on how a particular COBOL compiler from the 1970s, that was modified for the needs of a company that we aquired, interacts with RPG, CICLS , JCL and a specific accounting package that was developed in-house in 1980.

[Slant Four]

so how does it/would it work?

COBOL convertors of yore were deterministic - which is to say during the tool development they got persons with deep knowledge of COBOL (working with target language experts if they weren't themselves) to create the syntax and logic convertor rules. And they then tested this with real production code and iterated/updated the tool from project to project as edge cases came up (i.e. the companies providing these tools were always "connected" in a meaningful way with client project teams)

Being deterministic, give convertors of yore the same COBOL program over 1000 iterations and you get the same target code.

Now AI is non-deterministic, you train it on something but over 1000 iterations you won't get the same target code.

On top of this, what specifically are you going to train the AI on, what text books, that explain 100% how to convert say COBOL to say Java? (1)

I have no clue if such text books exist but any such book, no matter how good, cant cover off every syntactical variation (given experience tells us people "abuse" programming languages with weird/obtuse code). So unless you have a tool vendor engaged to update AI "logic" (as vendor convertors of yore did) then the AI will keep tripping up.

Summary: What input documents will AI be trained on that allows it to do the conversion?

This obviously puts aside the elephants in the room that I and others have discussed around all the ecosystem "stuff" that supports the running of the COBOL code.

Bluck

(1) a quick google search shows lots of books teaching COBOL programmers Java (and visa verse) but not any lengthy tomb on converting code.

[Anonymous Coward]

Ho Hum !!!

Once again the idiots who are trying to make a fortune on the back of 'AI' 'bounce' the stock market for profit.

1. 'AI' will NOT be able to do the job of Converting a COBOL System to a Java System that replicates the same functionality and output.

2. The resulting code will not be maintainable even if we forget 1.

3. You are simply changing the problem to another problem.

4. Once again 'AI' is looking for the 'lock-in' opportunity.

5. The problem as stated by many on 'El Reg' is not COBOL BUT replicating a mainframe system including all the supporting OS s/w systems.

6. There are 1001 tricks of the trade when building/running/maintaining these systems on the mainframes (Lost Knowledge).

7. All the lost knowledge will come back and bite you when trying to do this simple 'AI' conversion !!!

8. The only solution is to train new people with the right skills and they convert the code ... once they fully understand the existing system.

8. Requires the few people with the skills to be paid well to teach a new generation for this work.

9. Requires the companies to take the financial hit to do the work.

10. Requires IBM et al to support the whole process as they can easily make things more difficult !!!

11. In a nut shell ... probably will not happen as the risks either way are huge ... keep paying IBM et al to keep the mainframes running :)

:)

[Slant Four]

What's the target platform the investors imagined?

Was the share price drop predicated on IBM investors thinking IBM's mainframe business is moving to say Linux based hardware thus mainframe sales would plunge?

This is even more irrational than thinking these COBOL applications will move to say Java running on a mainframe. At least in this scenario the Java code (or whatever the target is) has access to all the related mainframe subsystems.

There is no way you are doing a code conversion AND moving it off a mainframe. No hardware platform (outside of Tandem) has the same RAS levels (Reliability, availability, and serviceability) as a mainframe which is also why many customers utilize mainframes.

So IBM's mainframe business is not at risk and it appears your average Tech investor is clueless.

Bluck

[Yet Another Anonymous coward]

Re: What's the target platform the investors imagined?

The share price drop was based on high speed trading algorithms predicting that other slower trading algorithms would sell based on the idea that retail investors (ie suckers) would sell based on any "AI+software company" news

Profitable investors don't care about how this affects the company, just on how other investors predict other investors will think other investors will react

[chriskno]

Feeling guilty

I know the COBOL programs I wrote in the early seventies on an IBM 360 with 32K memory had the Y2K problem - no space for the 19 in the year - so I felt a little guilty as 2000 approached. As I'm 79 in a couple of months I'm not going to start feeling guilty again about old Cobol programs, but I have enjoyed being reminded of JCL, CICS etc. so thanks for making an old boy smile.

[FordPrefect]

Having witnessed the results of code from AI please warn me before this hits any banking or air traffic control systems. So I can move my money elsewhere and ensure I never transit that country's airspace.