Critical business value is often locked in 3270-screens and transactions calling other transactions, calling ehmm… other transactions. Layers on layers were developed over the years and they do their job very well, being relevant for decades.

If you want to make (some of) them accessible from outside the mainframe, there are several options. Let’s take a look at 2 ways I’ve seen and used in the past:

• you add z/OS-connect into the picture
• you add HATS into the picture

z/OS-connect is doing really well if there is a one to one relationship: you want an API from an existing transaction. That means you might need to create new transactions first if you want an API which requires a good understanding of the involved other transactions you need to call.

HATS is doing really well in transforming green screens into services, by executing actions on those green screens and returning values you need without modifying any of your production code. The risk is smaller as you know your user interface quite well + you’ll be able to have good results faster.

However, if you want to become more flexible, have richer interoperability and reduce technical debt, there is a generative AI – based approach to create services from your existing COBOL-applications.

To be able to create services from your existing COBOL-applications and limit the source to what’s really needed for that service, it’s key to have a clear view of what’s happening under the hood.

A tool that understands your code and its relations to create a metadata repository will help you. IBM’s ADDI (Application Discovery) is made for this job, being able to analyze for instance Cobol, PL/I and Assembler.

In a next step Z Refactoring assistant connects to the metadata repository to pull out exactly the stream of needed sources and transform these into a brand new and easier to maintain service.

In an optional last step, you can transform your new service into Java.

JOBOL vs. AI-generated Java?

Transformations from COBOL to Java often result in something nor the Java developer, nor the COBOL developer like because these transformations do not really understand your code and rather translate line per line into JOBOL, Java written the COBOL-way.

watsonX for Z does better and uses AI to understand what the COBOL is doing, and transforms it into object oriented Java using AI.

On top of that, tests can be generated for the COBOL (based on listingfiles and compiled cobol binary), to validate new Java by running an equivalence test using JUnit.