back to article IBM says GenAI can convert that old COBOL code to Java for you

IBM is giving its mainframe customers a tool infused with generative AI to translate COBOL code to Java as part of application modernization efforts. The watsonx Code Assistant for Z is set to be available sometime in Q4 2023. Big Blue says it can speed translation of COBOL to Java on its Z mainframes. As Reg readers will …

  1. DJV Silver badge

    It will be interesting to see a side-by-side comparison between the original and converted code, along with a comparison of the speed of execution and the physical output generated.

    Going by some of the more "interesting" output from various LLM/AI systems of late, I suspect it might be a case of "accounting software in" and "Vogon poetry out".

    1. Anonymous Coward
      Anonymous Coward

      Converting Cobol to Java

      Is like converting rabbits into squirrels. What's the point?

      1. DJV Silver badge

        Re: Converting Cobol to Java

        Depends on whether or not you like hiding up your nuts for later!

    2. Skwn

      Wondering about the same

      Does the AI actually understand the programer logic Deon the procedural Cobol and turn it into OO programing inferring classes Or is just another interpreter?

  2. elDog

    Skip the Java - go straight to Rust (or whatever the new flavor is today)

    Java must be at least 30 years old already. The J2EE libraries that I worked with 15 years ago were creaking with their baggage.

    Not sure I'd really like to see the output product from COBOL-68 (last version I knew) to a modern language. DATA DIVISION: OBVIOUS-123 meet obfuscation_xyz.

    1. Charlie Clark Silver badge

      Re: Skip the Java - go straight to Rust (or whatever the new flavor is today)

      The age of the lanugage isn't important but I'd agree that Java isn't a great target language. Then neither is Rust. Python might make a better fit conceptionally and for users though it's even "older" than Java. However, IBM/RedHat wants to make money through it's awful JBoss environment.

      1. Michael Wojcik Silver badge

        Re: Skip the Java - go straight to Rust (or whatever the new flavor is today)

        Java is thoroughly integrated into the IBM z environment and subsystems such as CICS and IMS. Python and Rust are not, and migrating COBOL mainframe applications to them would be a miserable experience.

        For these sorts of applications, the programming language is much less important than integration with the zOS environment.

        It's all going to end in tears anyway, for applications of significant complexity. Many of these applications have decades of stovepiped changes to business logic and integration with other applications. They typically have very few tests, accurate specifications, or documentation available. The business processes are defined by what the existing programs do, and nothing else. The first stage of any such migration is application portfolio analysis, even just to identify which programs are actually being run and what sources they probably were built from, and that's a major undertaking in itself. Converting to another language without introducing changes in behavior is very difficult.

        And that's not even touching on the vagaries of IBM mainframe COBOL, such as its nested-PERFORM behavior (hint: it's not a stack); or the differences among various IBM COBOL product releases.

        Disclaimer: I make wads of filthy lucre from a competing product, so of course I would say that, wouldn't I?

        1. Stork Silver badge

          Re: Skip the Java - go straight to Rust (or whatever the new flavor is today)

          You remind me of my last project before I left IT. I came in as tester on this project of a modern application which should replace some old, hard to maintain but business critical mainframe code.

          On the question of when it went live, the answer was “August”. According to a senior tester it had also been August the year before, and it was still August when I left a year or so later.

          No one dared pulling the old code, just in case, they were not completely sure what other processes used it.

        2. Anonymous Coward
          Anonymous Coward

          Anonymous for an obvious reason

          In an almost 50-year career in IT, I committed numerous sins, none more black than TD2907, a Hospital Billing System main file update (batch) program.

          I had maybe 2 years experience in coding when I was assigned this gem (but I did have a Bachelor's in Computer Science from UC Berkeley, so yoo-hoo me!)... mine to write from scratch. In my defense, this was a tape master file update program, and the input transaction file did not 'exactly' match the sequence of the master file. I had to 'infer' matches that may be out of order with the master file. Not going into why, just go with me here. So I had to juggle things in an two in-memory stacks (one for the txn file, one for the master file) to try and line up the transaction with the master file, and do a four way match-merge (txn file, master file, internal txn stack internal mf stack). Yes, all this in COBOL.

          I built a construct that was a multi-level PERFORM/PERFORM VARYING/PERFORM UNTIL structure maybe 4-5 levels deep. At one point, when I had found what I needed, I just branched out (GO TO) of the entire structure, leaving all the loops unresolved. Much easier than trying to exit gracefully.

          Yeah, sloppy, but I was a raw kid. Probably best I moved on to systems, then database, then management, then ops then vendor management, then retirement (in that approximate order).

          But I digress: I would love to see what this tool would to trying to parse that pile of dog vomit.

          (Yeah, that system got replaced decades ago, and should have been done using a database from day 1... but we're talking early 1970s.)

          1. Peter Gathercole Silver badge

            Re: Anonymous for an obvious reason

            If you're talking early '70s, there were few database implementations available (certainly not any commercial RDBMS), and most of what there were would have been CODASYL type databases that require an order to the data in a list to allow datastream cursors (not the SQL type) to move through the dataset in a sequence.

            IIRC, it was very bad practice to move the cursor backwards in a dataset, as in many systems, you could only rewind it back to the beginning of the dataset and then move forward again until you found the record you were looking for..

  3. Kevin McMurtrie Silver badge

    Curious choice

    Java doesn't support domain-specific languages yet, but other JVM languages do. A COBAL to Java translation is a drastic change. Maybe it's intentional, though. Some DSLs get out of control as they age.

    I hope I never have to see COBOL that was written by a cheap contractor then fed through an AI trained by code from cheap contractors.

    1. Michael Wojcik Silver badge

      Re: Curious choice

      "COBOL", with two O's.

      While the quality of the generated Java source is definitely one area of difficulty, the bigger issues are likely portfolio analysis – we often encounter customers who aren't sure which of their tens of thousands of COBOL programs are actually run in production, or what sources they're built from, reliance on odd aspects of IBM COBOL behavior, and (for the promise of eventual migration away from the mainframe) dependencies on zOS features and subsystems.

      People have been selling COBOL-to-Java conversion tools and services for decades. It's rarely gone well, and source language conversion isn't most of the work. So throwing an LLM at that part, even if it doesn't create a dog's breakfast (and I wouldn't count on that), is only optimizing a fraction of the problem.

  4. This is my handle


    What's old is new again

    We were looking at tools (no ML mentioned -- this was during the AI winter) to convert COBOL to Java back in the oughts. HP3000 & what would now be called a Z-class mainframe were the source systems, and clusters of blades running Linux as the target enviroment. A colleague and I even wrote some code to generate Swing User Interfaces from 3270 screen definitions as a POC. I wasn't there long enough to see it into production fruition but it was kind of fun.

    1. Doctor Syntax Silver badge

      Re: Meh

      I'd guess before that somebody must have had a go at COBOL to C using YACC and LEX.

      1. yoganmahew

        Re: Meh

        I heard a story, almost certainly apocryphal, that a UK bank had converted COBOL to C++. The resulting mess was so bad, the developers would fix bugs by eyeballing the original COBOL, updating it and then reconverting to C++. It ran, but it was untouchable ever after.

        1. Version 1.0 Silver badge
          Thumb Up

          Re: Meh

          The big factor for COBOL is that the code is "readable" and quite easy to interpret what it's doing even if you are not a programmer. Accountants could always review what was happening, they might not look at the COBOL and see a problem when the code was created initially, but when a problem was seen afterwards then the accountants could read the code and tell you where your issues were happening. Try doing this in Java and having the accountant understand it ... e.g.




      2. Peter Gathercole Silver badge

        Re: Meh

        For languages based on MicroFocus Cobol (including IBM's own VS COBOL for AIX and I presume OS/2), the compiler output was intermediate virtual machine language code that was mostly interpreted (although I think they did have a executable object output form that effectively included the runtime interpreter in the executable - it was little faster and much more memory intensive than the interpreted modules).

        I don't think that I would have wanted to try to debug the intermediate code, though.

        I wonder how good the generated Java is? Good enough to allow you to maintain the code while ditching the original COBOL? I wouldn't have thought so, so you then ask for further work, do you still work in COBOL and re-translate, or fix the Java?

        1. Michael Wojcik Silver badge

          Re: Meh

          Micro Focus Visual COBOL (the current descendant of the original MF COBOL line, and the flagship COBOL product), now owned by OpenText, still compiles initially to an intermediate representation. That can be interpreted at runtime, or converted to native code (in various object formats), .NET CL, or JVM bytecode. Such "generated" code isn't interpreted at runtime, if it's native (and it's JITted if it's CL or bytecode).

          The runtime is typically dynamically loaded, not statically linked.

          As an aside, you can decompile COBOL-sourced CL into, say, C# or VB.NET, and it's not awful. It will have a bunch of COBOLisms, but it's readable. If you use the Managed OO COBOL language variant you can actually write OO COBOL for CL that looks very reasonable when decompiled into another .NET language. But traditional procedural COBOL using the idioms of COBOL'74 or COBOL'85, plus the various extensions that vendors loved to toss in, can be very messy when converted to another language.

      3. Roland6 Silver badge

        Re: Meh

        Given there were a number of COBOL-to-C tools around in the 80s and given the simplicity of Java compared to C, I don’t see the value “AI” is actually contributing other than marketing pixie dust.

  5. MOH

    Dunno where Omdia are getting their figures from , but Cobol developers aren't expensive. Competent ones who actually know what they're doing yes, but that's not usually an option for mid-level managers keen on hitting their bonus targets.

    Should be a fair bit of work in a year or two when all the not-quite-right AI conversions start costing a small fortune and they need proper developers.

    1. NeilPost Silver badge

      It’s not just code conversion - the last thing you want is poorly documented incomprehensible code translated into new more poorly documented code.

    2. david 12 Silver badge

      I don't why they always say that it's "COBOL" programmers who are expensive. This is a "CICS, IMS, DB2" tool. It's the "CICS, IMS, DB2" programmers who are expensive.

  6. Lil Endian Silver badge

    Programming is independent from language

    (A) COBOL supports many vital processes

    So don't try to squish it through a mincing machine and trust it.

    (B) The bad news is it's been working for a little long.

    Longevity is not a sign of weakness, a lack of headcount knowledgeable in COBOL is the problem.

    (C) "If you can find a COBOL programmer, they are expensive..." + there are billions of lines of COBOL code...

    Sounds like a reason for learning COBOL for some, it's a supply/demand no-brainer.


    Programming consists of logic with one of three choices in program flow: sequence; condition and iteration. All programming logic follows this, and all languages accommodate it[1]. If you're a programmer, you can code your program in any language you know[2] .

    Converting code autonomously is essentially starting from scratch, autonomous reverse engineering, without the human taking hands-on until testing - that won't leave any bugs. (Hugely impacts A)

    If (A) is important, you really don't want to risk this approach, it creates a mind fuck.

    (B) appears to be/is the case because of FOTM, it's chic to code in Python/Rust/Java... or whatever. It doesn't matter[2].

    If you combine (A), (B) and (C) it's clear that's what is "needed" is for more COBOL coders, not a farcical "AI" fix. (A) because the $Corps should stop fucking about and help themselves by not scrimping, and (C) benefits the programmer. They combine to (B).

    [1] If that's not the case, it's beyond the scope of the significant context.

    [2] If it's the right language for the job.

    1. martinusher Silver badge

      Re: Programming is independent from language

      I might be thick or something but I tend to think that its easier to learn COBOL than it is to translate millions of lines of code --- and verify that the translated code is working correctly. I also think it would be relatively easy to make a COBOL to JVM compiler -- the real issue is the "old, legacy code" but the fact its running on obsolete hardware. The code will always work, the hardware will require periodic maintenance and upgrading.

      1. Lil Endian Silver badge

        Re: Programming is independent from language

        ...its easier to learn COBOL than it is to translate millions of lines of code...

        Agreed. That's what I meant in the bit (Hugely impacts A) but you put it much more concisely[1]! The problem is $Corps want to cut out as many programmers from programming as they can, leaving just the ones that can make automated tools to replace said programmers. It won't work, hence: because the $Corps should stop fucking about and help themselves by not scrimping.

        As far as legacy H/W goes, generally speaking I'd have thought COBOL to be a highly migratable across platforms, thanks to the likes of CODASYL.

        Like I said, programming is independent from language. If one can program already, essentially all you're doing is learning some new catch words - unlike learning a new natural language, the diversity of which is broad, yet still underpinned by the same objectives, ie. to communicate about objects/actions etc.

        [1] Note to self: posting when knackered leads to drivel... watch it!

        1. Peter Gathercole Silver badge

          Re: Programming is independent from language

          Coding in one language is not always translatable into learning another language.

          If you've never programmed in an OO language, that becomes a huge issue to writing efficient code. Similarly, anybody from pretty much any language would be completely floored by APL or Forth, and Lisp and Smalltalk may also be sufficiently foreign to a lot of people. I know I don't like Python, merely because of the importance of whitespace and indentation.

          There is a group of languages where programming can be very similar, for example, Fortran, Pascal, Algol, C and many C derived languages. The concepts around programming these are very similar. But COBOL is right on the edge of this, as are some of the other business languages like RPG before version 3 or 4. There are just some very foreign concepts around the program flow.

          I remember my first job, where I had to learn RPG/2 after having learned APL, PL/1 and C at university. It took me most of the first week to work out that there was an implied input-process-output loop, and that conditional execution worked more like it does in machine code than it does in most traditional languages. COBOL is not quite that bad, but the last time I looked at it, you had to define what your input and output records looked like before you actually got to write any real executable code (I know, it was in a batch environment, things have moved on).

          1. Lil Endian Silver badge

            Re: Programming is independent from language

            I think you're missing my point, and that's my bad. Let me rephrase the statement "programming is independent from language" as "programming is independent from coding". Same thing. And yes, they're sweeping statements, but if viewed definitively I argue that the underlying point stands.

            Learning different programming languages, ie. coding in that language, involves learning that language's semantics and syntax. Learning programming, that's logic, and involves logical steps which relies on sound program flow - the aforementioned sequence/condition/iteration. In essence, the programming part does not need to be relearned. Yes, there's a difference between OO and procedural program structures, but the individual functions, the actual working bits, are still made of the same program flow.

            Program design at its lowest-ish level: anything but a trivial program and CISC/RISC assembler are bound to require a different number of instructions, but that program flow will contain the same options of sequence/condition/iteration. In essence the top-down program flow would be close enough to be perfectly recognisable.

            One does not need to relearn programming when learning a new language. But there might be a more convenient program flow for a given language/use case!

            Programming != Coding

            [...floored by APL or Forth... -- I'll add Algol, if I may!]

            1. Peter Gathercole Silver badge

              Re: Programming is independent from language

              I don't think I have missed what you are saying, I just think that you're looking at it with the blinkered perspective of someone who knows languages from a certain family of languages.

              I disagree about Algol. Algol is sufficiently like Pascal, and I've seen people put mostly Pascal through a C compiler with macros and pre-processor directives hiding the differences. Algol is quite complicated compared to, say, Fortran (especially if you are looking at contemporary versions of Fortran), but it is still in the same family of languages that I grouped together. That devil is in the detail.

              But if you actually do write some APL, you will see that the normal constructs like loops and conditional execution just don't exist. Yes, there is a conditional GOTO, but don't even consider using it, as the code will run like a snail. I guess that if you've never done it, you just don't really understand. I may characterize it like trying to read Chinese languages while only knowing Latin based ones. Yes, they are both interpreting marks on a medium as a vocal language, but you do it in different directions, and you have the difference between phonetic and pictographic symbols. It's difficult to compare, because the fundamental constructs are just not the same. Going back to APL, if you've worked in S or GNU R, you may have some inkling of the difference,

              The important thing about APL is that you treat data items as a whole, so you have an array, you treat it as a single data item, not iterate over it with a loop.This almost makes APL like the ultimate functional language, although what you define are actually operators which work like arithmetic operations rather than functions. If you don't know this, you will struggle. This means that you have to start the process with a different perspective, so the entire process differs from beginning to end.

              I understand the fundamental thing that you're saying. Being able to break a problem down and concisely describe it in a process in a language is a skill in itself, but not all parts of that process are compatible in all language, so are not transferable.

              1. This post has been deleted by its author

              2. Lil Endian Silver badge

                Re: Programming is independent from language

                To which family of languages does machine code belong?

                1. Peter Gathercole Silver badge

                  Re: Programming is independent from language

                  The problem with many people nowadays is that they look at 'machine code' and think that it is one thing, and the same across all processors. It's not, although with the reduction in deployed processor types to Intel and ARM for maybe 90%+ of the deployed systems, maybe that is not such an untruth as it used to be.

                  In my view, machine code is not one thing, and needs to be treated per architecture as it's own language outside of a family, although I think that you could put all of the generations of Intel x86 into a family, as you could s360-z16, RS/6000 to Power10, PDP-11 to VAX, because although they have changed, there is a strong resemblance between the generations, with each generation being largely a superset of the last.

                  There are rare examples where two different machine codes for different processors may be similar enough to be considered an extended family, for example NS16032/32016 and VAX-11, where the construction of the instruction set and register layout are very similar, although different (this was by design when the NS16032 was designed, the VAX-11 instruction set was taken as a deliberate model).

                  But I would say that there are sufficient differences from, say, PDP-11 and Power so that skill is only marginally transferable, and the difference between stack based machines and register based machines is very marked, and requires a different mindset.

      2. Michael Wojcik Silver badge

        Re: Programming is independent from language

        I also think it would be relatively easy to make a COBOL to JVM compiler

        Writing a COBOL-to-anything compiler is hard. Even if you just stick with a single dialect – say COBOL'2002 (ISO/IEC 1989-2002) without the OO support or optional features – it's a tough language to parse (it's not LL(1)). And a single dialect won't get you far, since non-trivial applications often combine "programs" (what would be object modules in other languages) compiled from sources in a variety of dialects. Then you have to make various implementation decisions because the standard leaves critical aspects up to the implementation.

        Once you have a working COBOL compiler, targeting JVM bytecode as a backend is certainly possible. We do it. But it's mostly useful for integrating with other JVM languages, using JVM frameworks, or writing OO COBOL. It doesn't help much with migrating COBOL applications from the mainframe because it's the mainframe environment which really matters to those applications.

      3. Roland6 Silver badge

        Re: Programming is independent from language

        >” the real issue is the "old, legacy code" but the fact its running on obsolete hardware.”

        In my experience the issue isn’t so much the hardware - although that may be the motivation to migrate it, but the operational paradigm behind the design of the code: code written to read sequentially from mag tape will still be limited compared to code written to access a RDBMS.

    2. abend0c4

      Re: Programming is independent from language

      a lack of headcount knowledgeable in COBOL is the problem

      It really isn't. COBOL is not very complicated and any competent programmer should be able to pick up the rudiments in an afternoon. If you accept the "lack of practitioners" argument, there should never been any new programming languages because, by definition, no-one will initially know how to use them (there are plenty of other arguments for deprecating the growing number of same-but-different computer languages, but unfamiliarity isn't one of them).

      The problem with COBOL is not the language itself, it's the environment in which it is used that is largely unfamiliar to programmers today. It implies the use of decimal arithmetic and rather arcane teleprocessing monitors (which schedule lumps of code that respond to asynchronous events such as green-screen terminal I/O) and extremely old-fashioned hierarchical databases. None of these things becomes more familiar by presenting an interface in Java (or, indeed, PL/I which is also still in use).

      If you're still using CICS/IMS for key applications, you really ought to be thinking about moving on. The longer you leave it, the more difficult it will become, but COBOL won't be the issue.

      1. Lil Endian Silver badge

        Re: Programming is independent from language

        Your logic seems fallacious. Just because there's a potentially higher headcount doesn't mean there isn't a shortage. We know there's a dearth of COBOL experience currently, but you're saying there isn't. I don't get it, apols if I'm blind to your point.

        ... there should never been any new programming languages because, by definition, no-one will initially know how to use them...

        Again: wut? That's blatant non sequitur fallacy.

        The problem with COBOL is not the language itself, it's the environment in which it is used that is largely unfamiliar to programmers today.

        Here I agree.

        1. abend0c4

          Re: Programming is independent from language

          If you can learn the language in an afternoon, there is by definition not a shortage of capable people - there's simply an unwillingness to learn or to offer training. People will happily learn Rust or Python to get a job, so why not COBOL? Having said that, I don't really have any time for employers who simply employ people based on their having exactly the right skills for their requirements at that particular moment: that's why they're landed with all these legacy systems that they find themselves unable to maintain.

          1. RichardBarrell

            Re: Programming is independent from language

            > I don't really have any time for employers who simply employ people based on their having exactly the right skills for their requirements at that particular moment

            I'll argue that if your organisation still has COBOL in it in 2023 then you should expect to still have COBOL in it in the year 2223. No contractors are going to live that long. Plan accordingly and set up training that can create the skills you need instead of just praying that you'll be able to find them outside.

            1. Roland6 Silver badge

              Re: Programming is independent from language

              Trouble is too many programmers, who themselves are fixated on only using specific programming languages, believing that learning and using other languages will somehow make them less saleable…

          2. Lil Endian Silver badge

            Re: Programming is independent from language

            If you can learn the language in an afternoon, there is by definition not a shortage of capable people...

            Well, you continue to conflate potential and actual. There is by observation a shortage of capable people.

      2. Brewster's Angle Grinder Silver badge

        Re: Programming is independent from language

        One of the problems is firms insisting that 30 years experience programming counts for nothing when you switch to a new language. All understanding of programming somehow wiped from y our memory and you must start from scratch with every new system.

        But most of us hitting fifty must have direct experiences of those arcane contraptions you describe. While decimal arithmetic is now coming into fashion, because binary floats should be nuked from orbit.

      3. Michael Wojcik Silver badge

        Re: Programming is independent from language

        COBOL is not very complicated and any competent programmer should be able to pick up the rudiments in an afternoon.

        Rubbish. The COBOL 2002 standard is half again as long as the C99 standard (COBOL has over a thousand keywords), and it doesn't cover any of the many vendor extensions and quirks. There are dozens of COBOL dialects, with wide variations in syntax, semantics, and runtime behavior. COBOL is full of traps for the unwary, such as inadvertent scope termination and implementation-defined PERFORM behavior. Anyone who's actually worked on COBOL translation can tell you that your claim is complete bullshit.

        This will be particularly true when maintaining code written by someone else. I've run into plenty of COBOL developers who are unfamiliar with, and puzzled by, COBOL idioms and constructs they haven't used themselves: keyword variants, abbreviated conditionals, tables, arcane uses of verbs like INSPECT and UNSTRING...

  7. that one in the corner Silver badge

    If this really worked as well as they claimed

    Wouldn't their best course of action be to keep quiet and use it as their secret weapon? Get IBM in to convert your COBOL and they could either quote cheaper than other contractors/consultancies to get the gig *or* charge the usual going rate, get it done in a week but charge for the whole six months up to the delivery date.

    The hope (!) is for the total amount of COBOL in the world to go down, so there is only a finite (if large) amount of it to work on: why not maximise how much of that IBM gets to hoover up?

    Unless, of course, it isn't quite as good as claimed.

    In which case they will get upfront fees from the poor sod trying to use it, then a seemingly never-ending stream of maintenance and training fees as they "help the project through that last ten percent that turned out to be trickier than was anticipated". When the plug finally gets pulled, IBM have "been nothing but supportive" but the contractor was just not up to the task and the COBOL lives on.

    I wonder how it will all pan out; anyone running a book on this, I have some pocket money left?

    1. Neil Barnes Silver badge

      Re: If this really worked as well as they claimed

      There is the old joke about the COBOL programmer whose skills were in such demand prior to y2k that he made a fortune and spent it by having himself frozen for a few thousand years... come the year 9999 or so, he is defrosted to the words 'We understand you know COBOL?'

      1. Lil Endian Silver badge

        Re: If this really worked as well as they claimed

        Sensibly the programmer sorted the cryogenics software for Y2K compliance before being frozen, with: PIC 99/99/9(4) - or he might have been defrosted retrospectively!

      2. Peter Gathercole Silver badge

        Re: If this really worked as well as they claimed

        My statement that I had done some APL 40 years ago generated a job offer the other year.

        I got a call from an agent who was desperately trying to find anybody who even admitted that they had used it. Seeing it listed under my university experience many, many years ago was enough to offer the contract at some stupidly high rate without even a formal interview.

        I'm sure I could have blustered my way through, but the job was in Sweden, and I didn't really want to work abroad, even though I probably could have earned a small fortune.

  8. Carstairs

    COBOL often plays with money - and some of it might have been yours ...

    Do you want unreliable-AI-of-choice translating from COBOL to whatever? Especially as much (probably most) COBOL is dealing with someone's finances - e.g. payroll, pension, social security, unemployment, ...

    And if people chose to use AI for the translation, do you think they'll bother with proper testing?

    Translators like f2c (a well-designed, well tested, Fortran to C translator) - yes. Flakey AI - definitely no.

  9. John Klos

    They want to help people move from an old, solid and established language to a something that'll likely get stuck on specific version of a JVM that can't be updated any more five years from now and will require a dedicated machine for fear of toppling the whole fragile edifice... so they can get more hands on the code.

    That seems like lighting the house on fire to get rid of the rodents.

  10. Fred Goldstein

    COBOL is a really easy language to learn and even easier to maintain, as they go, because it is verbose. No, not fashionable, and it assumed that the programmer was a touch typist, not a hunt-and-peck artists like the authors of C and Unix. COBOL also makes it easy to visualize dollars (or Euros or quid) and cents (or pence). It lets you put decimal points into a number that is *not* floating point, because that's how money works. So they should teach people COBOL, not try to translate it. I'm sure there's a fine COBOL compiler available for the POWER processor family, too. And probably a usable one for IA64.

    Over 25 years ago my then employer was doing a joint venture with a big consulting company that hired thousands of kids out of college and sent them to its own boot camp, then assigned them to live for months at a client site. You know them. We heard about one of their projects, pre-Y2K by some years, to convert a program from COBOL to Java. They hired coders in India. They took each line of COBOL and turned it into some lines of Java. Theoretically it did the same thing, but in practice it ran a couple of orders of magnitude slower. Totally useless.

    1. Peter Gathercole Silver badge

      I don't know that there is a good COBOL compiler for POWER. IBM discontinued their (rather poor) one for AIX over 20 years ago, when they realised that for all financial institutions liked POWER as a platform, they weren't going to migrate code from Mainframe to POWER/AIX (they also retired CICS/6000 around the same time).

      I do seem to remember an article on El. Reg. a few years back about an IBM COBOL compiler for Linux (specifically to assist customers migrate code to the Cloud), but I don't know who else would have produced one for POWER/AIX.

      1. Michael Wojcik Silver badge

        AIX is still one of the supported platforms for Micro Focus Visual COBOL. Also for MF Enterprise Server, if you need CICS, JCL, or IMS.

    2. Michael Wojcik Silver badge

      COBOL is a really easy language to learn and even easier to maintain

      No, it really isn't. I deal with customers trying to maintain their COBOL applications all the time. Extant non-trivial COBOL code tends to be very difficult to understand at anything beyond the level of a few adjacent statements, with meaningless variable, paragraph, section, and program names, and few or no comments. Real-world production applications often involve hundreds of COBOL programs plus modules written in other languages, JCL (or other scripting languages on other platforms), and arcane environmental dependencies. Don't confuse easy-to-read statements with overall comprehensibility.

      (Even the statements themselves can be difficult in the general case.)

  11. Howard Sway Silver badge

    IBM says GenAI can convert that old COBOL code to Java

    This has the air of having been needed because they'd converted most of their old COBOL programmers to younger Java ones.

    If the COBOL program is of a more modern variant that supports object oriented styles, it should be a fairly straightforward translation. If it's an ancient variety with a huge data division where the program churns through each record from an input file, the Java translation will probably be a mostly single class monstrosity that performs way slower than the compiled COBOL equivalent.

    There are some potential issues due to string length being fixed in COBOL, but not Java, which might cause bugs in the translated code. Otherwise line-by-line a translation program should be a fairly trivial exercise, as COBOL is a very straightforward language. I don't see why you'd want to try and use AI to do this though, surely it's a relatively easy bit of coding.

  12. Anonymous Coward
    Anonymous Coward


    If the user no longer wants to use COBOL for their ancient systems because its expensive to maintain into the future...

    then why not convert their business process to a modern setup and just pay COBOL programmers to maintain current systems until that's done?

    1. Lil Endian Silver badge

      Re: Why?

      For corporates and large orgs this is usually a political (non-)decision. Anyone that okays the decision to replace an existing, and importantly working, business critical system risks committing professional suicide if the project borks or if the rolled-out system is discovered to contain flaws and it's "too late". So the C Suite and D Suite types don't want to go there. Not that they usually suffer penalties for incompetence, usually quite the opposite: a golden handshake and a role in another firm, or as a government adviser!

  13. Anonymous Coward
    Anonymous Coward


    It used to be "Garbage In, Garbage Out"..................

    Now we get "COBOL In, Java With Embedded Malware Out"...............

    ...........and of course the hapless COBOL dependent organisation gets to pay extra..........for the malware!

    Is this progress?

    Correction: It must be progress....someone mentioned AI!!!!!!

  14. Caff

    Its not the cobol programmer that is expensive - its a cobol programmer who understand the application/product that is hard to get. And that salary is unlikely to change much no matter what programming language the code is in.

    If they want a banking application programmer to maintain code for mortgages they will need to understand how mortgage products work to know what the impact of a code change on an interest calculation is. Same with investment products and pensions.

  15. ericmyrs_

    Is it GOTO or COMEFROM

    I wonder how it deals with the ALTER instruction.

    That shit is the stuff of nightmares.

    1. Neil 44

      Re: Is it GOTO or COMEFROM

      I seem to remember that ALTER was an implementation of what became GO TO .... DEPENDING ON .... on most later platforms.

      Even that will be a challenge to convert!!

      Maybe if my pension fund is a little short I should go back to my first profession : COBOL Programmer!

  16. trevorde Silver badge

    Alternate headline

    AI takes COBOL code no-one understands and converts it to Java code no-one understands

  17. trevorde Silver badge

    Meanwhile at Oracle...

    [Larry Ellison to engineer] Did you say 850 *billion* lines of COBOL to be converted to Java?

    [engineer] Err, that's right. All the banks, public utilities and mission critical apps are using it.

    [LE] ... and they want to convert it *all* to Java?

    [eng] Err, that's right...

    [LE] I'M MINTED!

    1. Kevin McMurtrie Silver badge

      Re: Meanwhile at Oracle...

      The chances of IBM using or recommending Oracle's Java are zero.

      The only companies I know of using Oracle's Java are already using their database. It must be a package, like buying cable TV and cell phone plans. Get $100000 off your Oracle Java license with the purchase of a $5000000 Oracle Database and suitable trade-ins of open source compatibility?

  18. Anonymous Coward
    Anonymous Coward

    Code formatting

    Hope it outputs the code in columns 8, 12, 17 and every 4 characters after column 17...

  19. Neil 44


    I remember the first C++ environments: the C++ *Pre-processor* took your C++ code and "generated" C code which could then be compiled.

    The C code wasn't "human readable"

    I'm imagining what the Java generated will look like and how non-maintainable it will be!

    1. F. Frederick Skitty Silver badge

      Re: C++

      I worked on a system that was based around a core written in Pascal and then run through p2c to generate C code. The resulting C code was unintelligible by humans, but necessary since it needed to integrate with other libraries written in C.

  20. LessWileyCoyote

    Brings back horrible memories of ancient code with stacked nested IF statements, some with ELSE, some without, and no check on whether it was possible to create an input that wouldn't trigger a single one of those statements. Which led to adding something like PERFORM FATAL-ERROR-ROUTINE (from which there was no return) at the end of such horrors, to catch "can't possibly happen" events.

  21. Mostly Irrelevant

    Why would you ever want to do this? You'd end up with Java programs with all the same limitations of the old COBOL programs. Better off to build a new system to replace the old one than convert 40 year old code paradigms.

    Additionally, why would you need generative AI to do this? It seems like something tailor-made for rules-based AI.

  22. Bebu Silver badge

    "IBM shows off its sense of humor" ... again?

    Have to wonder whether big blue has run this up the flag pole to see who salutes?

    If I recall correctly this was one of the Drop the Dead Donkey's Gus' favourite phrases. (Such equally inspiring utterances such as suggesting the aligning of your water fowl weren't apparently neccessary in his time. :)

  23. Sooty

    I'd be curious how it would handle some of the stuff I used to work with. complex recursive calculations. They failed testing once because the testers compared it to an excel spreadsheet, but excel got it wrong because it uses floating point numbers. The Cobol code was designed not to because they aren't accurate enough.

    1. Peter Gathercole Silver badge

      I suspect it was not because floating point was not accurate enough, but that when treating currency, COBOL works to a limited precision, with well defined rounding rules, often as Binary Coded Decimal data (which is treated like integer arithmetic, with an implied decimal point - it's like working in pennies or cents, and then working out pounds or dollars by shifting the decimal point).

      It gets more interesting when you're trying to do interest calculations, because trying to do this with great accuracy often gets different answers to working to limited precision with rounding. And you have to remember that there are different floating point representations, and accuracies, all of which can affect results.

  24. Arthur Daily

    Thank HR for Critical systems failure

    Thank or Blame HR. Succession planning is not hard. But when you tell greybeards they are rubbish and not wanted - and untrainable.. Many of us COBOL programmers grew up with assembler language as well, so the design of data structures was tight and orderly. In addition overflow and edit checking was standard - everywhere (now optional?). Even IBM sort/merge is nearly a full grown GREP. Growing up, Pascal or ADA was the rage, fully typed too. But hey, strong typing and declarations - was inconvenient for shithouse programmers, Vs many COBOL super-programmers that I knew. Java is rubbish - I can see that RUST or C+ would be just as easy to convert. My sins included COBOL recursion to cover date based business rules in a spreadsheet format some consultancy company decided was good.

    You will get my attention when Watson flags recursion and the dreaded interprocess communication layer . I have seen too many Indian conversion projects where transaction file header and footer records get turfed. So what if a CSV file is processed twice, or the is a typo, and some silently not processed at all. Solution: Just pay people what they are worth. And do code walkthroughs with top people.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like