SoftwareMining •
COBOL to Java & C#
• Predictable & Repeatable
Large mainframe COBOL applications do not always need to be modernized in a single "big-bang" project. SoftwareMining supports phased COBOL-to-Java modernization, allowing selected applications or groups of programs to be translated, 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 analysis can also help identify groups of related programs for translation and testing.
During the transition, newly generated Java components can coexist with COBOL applications that remain in production. Each phase can be translated, tested and validated before further components are migrated.
This phased approach helps organizations maintain production stability while progressively reducing dependencies on mainframe technologies such as CICS, VSAM and legacy databases.
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.
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:
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.
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.
COBOL applications frequently access DB2 using embedded EXEC SQL statements. During phased COBOL-to-Java modernization, the existing relational database can remain in place while selected COBOL programs are translated to Java.
SoftwareMining translates embedded COBOL SQL into Java database access and generates Java DAOs that use standard SQL. This allows translated Java components and remaining COBOL programs to continue working with the same relational database during the migration.
The same approach can be used with Db2 for i applications, allowing application code to be modernized independently of the underlying relational database.
Applications using IBM MQ do not necessarily need to replace their messaging infrastructure during COBOL-to-Java modernization. Translated 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.
Many COBOL programs use sequential files to store and retrieve data. SoftwareMining generates corresponding Java data classes and file readers/writers, allowing translated Java programs to access the existing files.
During phased migration, COBOL and Java components can continue to use the same sequential files without requiring immediate changes to the underlying file architecture.
During phased migration, translated 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.
These approaches allow COBOL and Java components to coexist while functionality is progressively migrated, without requiring the entire application to be replaced at once.
If you're evaluating approaches to COBOL modernization, the following resources may also be useful: