IBM launches AI-powered Watsonx for translating COBOL programs into Java code

[Alfonso Maruccia]

In context: Despite being designed in 1959, the COBOL programming language is still widely used in applications deployed on mainframe computers. COBOL offers secure, reliable and transactional performance, and it is still managing around 70% of modern bank transactions worldwide.

IBM is launching a new AI-powered service designed to "assist" companies and programmers in transitioning ancient COBOL code into the modern, cloud-centric era. Watsonx Code Assistant has been specifically trained to provide a quick, accurate and hopefully reliable way to manage and convert COBOL programs by using natural language prompts.

Watsonx Code Assistant (WCA) leverages the capabilities of IBM's Granite foundation models, which have been trained on open-source code repositories like GitHub for a total of more than 1.6 trillion code tokens (words and parts of words). IBM says that Granite has been further polished by filtering toxic, sensitive or copyright-protected code, with programmers fluent in COBOL and Java working side-by-side to create thousands of pairs of "functionally equivalent programs" for the IBM Z platform.

Translating code literally line-by-line, IBM explains, works "about" as well for programs as it does for natural language. But translating COBOL into Java this way is not feasible, as the final result is a "JOBOL" code that's difficult to both read and maintain. IBM programmers worked on Granite models to ensure that the syntax of each COBOL program was expressed correctly in Java.

Richard Larin, product lead for IBM Watsonx Code Assistant, says that the Big Blue programmers know COBOL and Java languages on z/OS "better than anyone." Granite AI models benefit from that industry-leading knowledge, so that they know how to handle IBM customers' use cases. IBM researchers compared Watsonx Code Assistant with ChatGPT, finding that WCA was able to outperform OpenAI's LLM in COBOL-to-Java translations.

WCA is now capable of turning "individual COBOL business services" into object-oriented Java code, but IBM is already working on the next step of the service. In a future release, WCA is expected to acquire "validation testing" capabilities with automated test case generation and new COBOL or Java service validation.

Finally, Watsonx Code Assistant can provide a big helping hand to IT administrators working on the Red Hat Ansible Lightspeed platform. Ansible is an automation service for infrastructure management, hybrid cloud deployment, network configuration, application deployment and more, IBM explains.

Thanks to Watsonx Code Assistant, admins can use natural language prompts (in English) to "automatically generate" task recommendations for Ansible Playbooks. Adherence to best practices in task creation and maintenance is seemingly guaranteed, as approximately 4,000 developers participated in the technical preview of the service.

Permalink to story.

https://www.techspot.com/news/100644-ibm-launches-ai-powered-watsonx-code-assistant-translating.html

 

[human7]

Excellent. And sad. I imagine programming languages like assembly won't be far behind this.

I never learned COBOL. but it was always on my list of things to learn. I've used SAS and SQL and I imagine COBOL isn't very different.

Still, it is nice to see more programming language translation features coming out. That area has always been fairly under-developed in the programming world.

 

[ChrisH1]

I did many conversions over decades, for all sorts of languages to Java and others, and my opinion is this: well run sites where they have all their source code and it's written in good well structured programs in general don't need conversion services, they can manage conversion just fine themselves. The people who want help, and generally a 'silver bullet', are the ones having millions of lines of spaghetti code they don't understand that they want transformed into object-oriented well documented maintainable Java. And that rarely happens.

Also, there are very, very few COBOL programs. They are generally COBOL and something else, a database like DB2/IMS/Adabas etc, and/or some online transactional system such as CICS/IMS or some IDE COBOL generating system like Adabas Natural, and bespoke printer code, with all sorts of interfaces such as direct TCP/IP exchanges, MQ Series and so on, and they do not live in isolation, they are run via JCL, usually from some sort of scheduling tool in a complex environment that also has to be considered and converted. It isn't easy.

 

[jlanus]

COBOL was designed by a woman, IMO this is the reason of its endurance.
It was not intended to cover _all_ the fields, but to only be a COmmon Bussiness Oriented Language, a goal that was more then accomplished.
Women are waaay more practical thas us males.

As it happens with all languages, there are good programs and horible programs.
I know it, because the programs I first wrote were horrible and I rewrote all of them in order to have a decent codebase. Hundreds of thousands of LOC.
After that my code was very similar to modern language code.
Of course, it was the scructure. When I learned to program (in the '60s) reading the manuals, those concepts like molularity, cohesion or coupling were unknown by all of us. And the use of the GO TO verb was accpeted.
Little we knew that we could write COBOL using lowercase, which makes the code much more readable. This is a small sample, but my COBOL code written in LC and well indented looked like any modern language's.

Once I wrote a COBOL to VB translator.
It was a several months very intensive attempt.
When it worked I lost interest and discarded it, because the translated program did exactly the same as the original.
I wasn't transforming a vintage program into a modern one.
IMO it can't be done.

I liked @ChrisH1 comment, agree a lot.

 

[ferrellsl]

I had to take two semesters of COBOL in college in the late 1980's and even then our professors were saying COBOL was a dying language. Ultimately they were wrong of course.

Of all the languages I've ever learned, it is my most hated. A single space in the wrong spot and your program was completely useless and your code had to be broken up into 4 divisions; the Identification Division, Environment Division, Data Division, then the Procedure Division. A very rigid and unforgiving language but it was great for processing large amounts of ASCII data for payroll, personnel records, or inventory/stock control and billing.

For those who are interested, we had to use COBOL coding sheets to write out our code in pencil before converting the code to 80-column punch cards on the keypunch machine for input into the mainframe/compiler. See: https://www.mainframestechhelp.com/tutorials/cobol/coding-sheet.htm

These coding sheets helped us to keep all our code in the proper columns and divisions......God, it was awful.

 

[alexandercsalas]

I had to take two semesters of COBOL in college in the late 1980's and even then our professors were saying COBOL was a dying language. Ultimately they were wrong of course.

Of all the languages I've ever learned, it is my most hated. A single space in the wrong spot and your program was completely useless and your code had to be broken up into 4 divisions; the Identification Division, Environment Division, Data Division, then the Procedure Division. A very rigid and unforgiving language but it was great for processing large amounts of ASCII data for payroll, personnel records, or inventory/stock control and billing.

For those who are interested, we had to use COBOL coding sheets to write out our code in pencil before converting the code to 80-column punch cards on the keypunch machine for input into the mainframe/compiler. See: https://www.mainframestechhelp.com/tutorials/cobol/coding-sheet.htm

These coding sheets helped us to keep all our code in the proper columns and divisions......God, it was awful.

I'm very grateful things have changed since then. I started using COBOL about 10 months ago. While I also don't think too fondly of the language myself, there's a plethora of tools available to new programmers making it a little bit less intimidating

While I wouldn't recommend anyone start on the mainframe as a COBOL developer, I recognize that it's still relevant, and will continue to be for the foreseeable future

 

[ferrellsl]

I'm very grateful things have changed since then. I started using COBOL about 10 months ago. While I also don't think too fondly of the language myself, there's a plethora of tools available to new programmers making it a little bit less intimidating

While I wouldn't recommend anyone start on the mainframe as a COBOL developer, I recognize that it's still relevant, and will continue to be for the foreseeable future

I'm glad to hear that things have improved. Back in the day, the smarter programmers made sure that they numbered the back of their punch cards. A complete program would sometimes be spread across several hundred of these cards and if you accidentally dropped those cards and got them out of order on your way to the card reader where they had to be read for input into the mainframe, you were essentially screwed and had to go back and create a whole new stack of cards in the correct order. I recall watching several classmates dropping their unnumbered cards and it was entertaining to watch them have a meltdown, yet they had been warned by their professors and students as well.

Nothing like having to sit down and transfer your code sheet to Hollerith cards all over again!