Incremental COBOL-to-Java Conversion

Large mainframe COBOL applications do not need to be converted through a single big-bang project. SoftwareMining supports phased COBOL-to-Java conversion, allowing selected applications or groups of programs to be converted, tested and deployed while other COBOL components remain in production.

Batch and online components that can be isolated are often suitable starting points. SoftwareMining's call-chain and dependency analysis helps identify related programs, copybooks, files and platform services that should be converted and tested together.

During the transition, generated Java components can coexist with COBOL applications that remain in production. Each phase can be compiled, executed and validated against the original COBOL behaviour before additional components are migrated.

This incremental approach helps organizations maintain production stability while progressively reducing selected dependencies on mainframe technologies such as CICS and VSAM. Existing databases, messaging systems and files can remain in use where the target architecture requires them.

Data Solutions for COBOL and Java Coexistence

Many enterprise platforms, including IBM systems, already support Java through native interfaces such as JCICS or SQL (for example, DB400). This means that accessing COBOL data from Java is straightforward as long as structure compatibility and encoding are managed carefully.

Accessing VSAM and CICS-managed data from Java
DB2 and embedded SQL during phased migration
IBM MQ integration
Accessing sequential files
Communication between COBOL and Java

From COBOL Data Division to Java Data Classes

For each COBOL data structure, SoftwareMining automatically generates a corresponding Java data class with matching fields. The translator analyzes how each field is used and determines where COBOL-compatible data representation is required.

COBOL-compatible data representation is maintained where:

The structure appears in the COBOL LINKAGE SECTION
The structure is used for VSAM file I/O
The structure participates in COBOL-compatible data movement

Where COBOL-compatible representation is not required, standard Java types such as double and BigDecimal can be used. This preserves compatibility where necessary while producing more natural Java data structures elsewhere.

Reading and Writing Data to VSAM, CICS, and Sequential Files

Since Java DAOs are compatible with COBOL structures, they can exchange data directly with legacy files. IBM CICS provides the JCICS Java API, allowing Java applications running within CICS to access CICS services and resources. This can support phased modernization scenarios in which Java and COBOL applications continue to operate within the same CICS environment.

This allows COBOL and Java components to continue accessing compatible data during the phased migration, without requiring the underlying data stores to be migrated at the same time.

Db2 and Embedded SQL During Phased Conversion

COBOL applications frequently access IBM Db2 through embedded EXEC SQL statements. During phased COBOL-to-Java conversion, the existing Db2 database can remain in place while selected COBOL programs are converted, tested and deployed as Java components.

SoftwareMining converts embedded SQL, host variables, null indicators, cursors, SQLCODE handling and transaction operations into corresponding Java database-access code. This allows converted Java components and remaining COBOL programs to continue accessing the same relational database, provided that compatible schemas, transaction boundaries and data-access behaviour are maintained during the transition.

The same approach can be applied to applications using Db2 for i, allowing application code to be converted independently while the existing relational database remains in use.

Learn more about SoftwareMining's support for COBOL, Db2 and embedded EXEC SQL conversion .

IBM MQ During Phased Migration

Applications using IBM MQ do not necessarily need to replace their messaging infrastructure during COBOL-to-Java modernization. Converted Java components can continue to use IBM MQ to exchange messages with existing COBOL applications and other systems.

SoftwareMining's generated Java data classes and runtime libraries handle the COBOL data structures and character encoding required by the application, including EBCDIC data where necessary.

This allows IBM MQ to remain as the messaging layer while COBOL components are progressively replaced by Java, avoiding the need to change the messaging architecture at the same time as the application code.

Accessing Sequential Files

Many COBOL programs use sequential files to store and retrieve data. SoftwareMining generates corresponding Java data classes and file readers/writers, allowing converted Java programs to access the existing files.

During phased COBOL-to-Java conversion, the existing Db2 database can remain in place while selected COBOL programs are translated, tested and deployed as Java components.

Communication Between COBOL and Java

During phased migration, converted Java components may need to exchange data with COBOL applications that remain in production. The appropriate integration method depends on where the Java application is deployed.

Java running within CICS can interact with CICS programs and services using IBM's JCICS APIs.
Applications can exchange data through existing integration mechanisms such as IBM MQ.
COBOL and Java components can continue to access shared relational databases where appropriate.

These approaches allow COBOL and Java components to coexist while functionality is progressively migrated, without requiring the entire application to be replaced at once.

Continue Exploring

If you are evaluating approaches to enterprise COBOL modernization, these resources provide further guidance on strategy, planning, migration and testing: