Mainframe COBOL to Java, C# & Cloud

Gradual COBOL to Java/C# Migration: One piece at a time


A big-bang approach to modernization is not overly suitable for large applications running on Mainframe computers. In this paper we are using our experiences to provide an overview of an approach which allows translation of part of the application to Java; while allowing the new Java parts to cooperate and co-exist with the yet-untranslated COBOL code.

This approach allows the migration of larger applications to be broken down into manageable pieces, which are completed over a number of years. In this page we are endorsing an iterative approach where a small part of the codebase is translated, tested, moved to production (to cooperate with the existing COBOL application), before the next iteration begins for next set.

The immediate benefits would be to gradually provide access to a larger pool of Java developers for maintenance (and enhancement) of the application, as well as the integration of new technologies (HTML and Web-Services and SOA).
The next benefit materializes after the Java code has been tested and moved into production. At that stage, the datafiles can be gradually migrated from VSAM/CICS/Mainframe-DB to an SQL.
The final benefit is on hardware: Once codebase is in Java and database is in SQL format, the application can be deployed on many different platforms such as a private cloud.

COBOL and Java co-operation: Its a Data problem

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:

Data and Java Data-Access-Objects

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.

Reading and writing data to VSAM, CICS and Sequential files

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.

Reading and writing data from (Exec SQL - DB2)

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.

IBM MQ Messaging middleware

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:

Sequential Files

The Data-Access-Objects (DAOs) generated for Sequential files are binary compatible with the original COBOL structures.
All that is needed is the selection of the underlying character-set: ASCII or EBCDIC. The generated data-files will be interchangeable between the Java and COBOL part of application.
The character conversion can be performed dynamically by SoftwareMining Libraries. Please see |EBCDIC Conversion

Communication between COBOL and Java

In a carefully planned migration, cross-language communication should not be required!
The approach would be to identify and translate the set of programs referenced in the chain using COBOL Application Analytics.

When the translation of entire sets is not possible, then cross language communications mechanisms can be considered. At the most basic level data can be interchanged through reading/writing to file-system. At its most complex, it would be to use web-services. But usually each platform will provide mechanisms with significantly better performance. For example, on IBM platform, JNI libraries can be used to pass the data between COBOL and Java.
However, please note EBCDIC to ASCII Conversion will be required on all communication.

Long term objectives: Roadmap for moving from VSAM to SQL

The generated Java programs access the data through the Data-Access-Objects Layer described above. This data-layer by default uses SQL to communicate with a database. Changing the underlying access mechanism from JCICS/VSAM to the default SQL is as simple as changing configuration.
I.e. data-migration will not involve any changes to business-logic layer and hence no functional testing. (This is unlike previous moves from COBOL/VSAM to COBOL/ESQL where all programs had to be changed).

The big task will be the data-migration activity itself. However, overall the migration should be a very manageable project.

  © 2023 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.