Incremental COBOL to Java/C# Migration Roadmap

A big-bang approach to modernization is not always 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:

• Compatibility of Java and COBOL Structures and data-formats
• Reading and writing data to VSAM, CICS and Sequential files
• Reading and writing data from SQL (Exec SQL - DB2)
• IBM MQ Messaging middleware
• Accessing Sequential Files
• Communication between COBOL and Java
• Long term objectives: Roadmap for moving from VSAM to SQL

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:

• Use of the structure in LINKAGE-SECTION
• Use in reading/writing VSAM files.
• Use in MOVE-ing data structures/groups.

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:

• IBM Java / MQ libraries - needed to read / write (Ebcdic encoded) data from IBM MQ
• Generation of Data-Access-Objects (DAOs) suitable for encoding and decoding the said Ebcdic encoded data.

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.

Accessing Sequential Files

Many COBOL programs use Sequential files to store and retrieve data. Reading and writing Sequential files through the translated Java application involves two steps:

• Data Data-Access-Objects (DAOs) compatible with COBOL structures
• Java classes for reading/writing these structures from sequential files.

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.

Communication between COBOL and Java

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:

• Direct Communication between Java (or C#) and COBOL, using CICS Sockets and Java JCICS
• Creation of a common shared data-store such as an MQ or SQL, which both applications can read and write.

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.

Long term objectives: Roadmap for moving from VSAM to SQL

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

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