Mainframe
COBOL to Java, C#
& Cloud
A big-bang approach to modernization is not always suitable for large mainframe applications. In such cases, the solution is a phased conversion of COBOL modules to Java. In this approach, a small part of the COBOL codebase is translated to Java, tested, and moved to production, allowing it to cooperate with the existing COBOL application. The next iteration will convert the next module.
The solution requires identifying stand-alone modules that can be converted independently. As a starting point, batch and online parts of the application are easily isolated and are good starting points for this solution. Other smaller modules may be identified using SoftwareMining's call-chain analysis module, which identifies and converts the related pieces together as one module. This tool is delivered as part of SoftwareMining's comprehensive COBOL to Java solution.
The key is to ensure seamless cooperation between the newly translated Java components and the existing COBOL code. This approach results in smaller and more manageable Java modules, allows for a clearer testing strategy, and provides a staged path for migrating VSAM/CICS/Mainframe-DB to SQL databases.
The rest of this paper focuses on solutions to individual problems encountered when converting large COBOL applications.
Many platforms such as IBM machines already support Java and provide means of accessing the data through either a Java layer (e.g. JCICS) or SQL (e.g. on DB400). Hence, accessing the data from Java applications is not actually a problem as long as the following issues are considered and addressed:
For every COBOL data-structure, SoftwareMining's translator will generate a Java Data-Access-Objects (DAOs)
which contain the same fields as the original COBOL structure.
During the translation the system will monitor how each field is used by each program.
This allows the translator to determine what level of formatting information is required by every (Java) field.
It can then generate a DAO suitable to the needs of the programs: COBOL binary compatible versions which can be
used in communication with other programs, or pure java (POJO) with significantly better performance.
The following are examples of types of operations where binary compatible formatting information will be
required:
In the above cases, the data representation of the DAO will be binary compatible with the COBOL's
representation.
For all other cases, the translator will use native Java data-types.
E.g. a numeric field originally represented COMPUTATIONAL will be represented as a java "double" or
"BigDecimal".
The use of Java native data-types has a huge difference on the application's runtime performance.
As data in generated Java Data-Access-Objects (DAOs) are compatible with COBOL versions,
the only outstanding issue would passing the data from File-System to the said DAO objects.
For this the DAO's can use IBM Native support libraries: IBM JCICS or other Java libraries provided by the
suppliers.
This will allow the Java version of application to work on same data-files as COBOL application.
EXEC SQL/DB2: The translator will convert Embedded SQL statements from COBOL to Java (or C#) dialect.
The new Java application will therefore have no problem in communicating with DB2 and can co-exist with other
COBOL modules.
The Data-Access-Objects (DAOs) generated for DB400 use SQL, by default, to read and write
their data.
As DB400 provides an SQL communication layer, there will be no issues in Java and COBOL versions with those
applications co-existing.
The only outstanding issue would be passing the data from File-System to those DAO objects.
Many mainframe COBOL applications use IBM MQ Messaging middleware for communication purposes.
Reading and writing MQ data through the translated Java application involves two steps:
The translator will generate suitable Java / C# structures which can communicate with MQ. The generated Java code will have references to IBM MQ library for MQ interface. The communication between COBOL and Java will continue to use IBM MQ as it was originally in the COBOL application.
Many COBOL programs use Sequential files to store and retrieve data. Reading and writing Sequential files through the translated Java application involves two steps:
The translator will generate both of these classes.
The application can continue to use the same data-files used by COBOL application.
For the long term, the Java application can be switched to use database for storage or use XML or JSON
encoded files.
The new version of the application will be independent of COBOL data-formats and more readily communicate with
other platforms and applications.
In this section we consider the situation where the COBOL and Java (or C#) applications need to communicate
directly without a third party software such as DB2 or MQ.
There are different mechanisms available for COBOL and Java (or C#) to communicate:
The first approach involves running both COBOL and Java (or C#) programs in the same CICS region.
This will require significant amount of development work.
The second approach (creation of common shared data-store) is a more preferred method as it requires less
development effort, can be made scalable, and does not require COBOL and Java (or C#) to run in the same
environment.
It can be planned in advance so that a number of iterations can be run through until the entire application is
translated.
The VSAM section above explains how the Java version of application can cooperate with the
COBOL application.
However in the long term it may be beneficial to move the application and data to more standard platforms,
for example from VSAM to SQL (for data).
But such move needs to be carried out gradually and carefully in order to avoid potential pitfalls.
The translated Java application can, over time, use a number of techniques to move from VSAM to an SQL
database.
The VSAM section above explains how the Java version of application can cooperate with the
COBOL application.
However in the long term it may be beneficial to move the application and data to more standard platforms,
for example from ISAM or VSAM to SQL (for data).
But such move needs to be carried out gradually and carefully in order to avoid potential pitfalls.
The translated Java application can, over time, use a number of techniques to move from VSAM to an SQL
database.
© 2025 SoftwareMining is a trademark of Software Modernization Technologies Ltd (UK). Registered in England company no: 07300248. Reg Offices: 79 Stevens House, Jerome Place, Kingston Upon Thames, KT1 1HX, United Kingdom.
