COBOL to Java Converter - Essential Features

Inventory Analysis

The SoftwareMining tool performs comprehensive analysis on COBOL applications through integrated utilities, enabling:

• Initial Inventory Analysis: Analyzes the COBOL application to detect dependencies, including missing copybooks and calls to absent programs.
• Flowchart Documentation: Generates a visual representation of the application for enhanced understanding and streamlined management.
• Call-Chain Analysis: Identifies interrelated programs requiring concurrent translation. For instance, if program 'A' references programs 'B' and 'C', then they all need to be translated together.

Document as You Go

During the translation process, SoftwareMining Converter offers an optional feature to leverage GenAI for enhanced documentation of the newly generated code. By utilizing large language models, such as ChatGPT, this feature can produce comprehensive documentation directly within the translated codebase. The resulting documentation improves code clarity, making it easier for new developers to understand the purpose and functionality of the implementation architecture.

Code Reuse - Reuse of Data Access Objects (DAO)

Well-written COBOL code reuses common data structures by placing them into shared COPYBOOKS. The SoftwareMining Converter applies the same code-reuse principles to all generated code, ensuring that respective DAOs are reused across all referencing classes.

Furthermore, during the refactoring process, the SoftwareMining Converter continues to identify opportunities for reusing additional DAOs, including those that may have been overlooked by the original programmers.

Remove Unreachable Program Statements

By performing a static flow analysis during the COBOL refactoring process, the converter identifies unreachable code segments and removes them from the translated Java or C# code. This step is essential for improving application maintainability in the COBOL conversion process.

Reduce GO TO statements

COBOL's GO TO statements are not supported in Java or C#. During the refactoring process, the Java/C# conversion tool must make every effort to remove or significantly reduce their usage. However, we acknowledge that complete removal is not always possible, and thus, the Java and C# libraries introduced into the new application should support the remaining GO TO architecture.

On average, the SoftwareMining Converter removes approximately 70% of the GO TO statements from COBOL code during conversion to Java or C#.

Precision vs. Performance Considerations

Java and C# primitive data types do not fully match the functionality of COBOL variables. For instance, COBOL's Packed Decimals can be initialized to values represented by hex or binary, and COBOL numeric variables can handle numbers up to 32 digits. In Java, such numbers are represented by BigInteger and BigDecimal, rather than primitive data types.

The SoftwareMining Converter analyzes usage patterns for each variable to determine the most appropriate representation, ensuring a balance between precision and performance.

COBOL Pointers Support

Ideally, in the long term, all COBOL pointers in the converted Java and C# code should be replaced with references to objects. However, until that transition is fully achieved, supporting COBOL pointers in the translated Java and C# system allows the application to move swiftly into production.

Limiting COBOL Emulation

Some of the translated Data Access Objects require COBOL emulation features, including REDEFINES, OCCURS-DEPENDING, COMPUTATIONALs, and POINTERS. The translator should identify when these features are necessary. When they are not required, it should generate straightforward classes that bypass the dependency on the legacy architectures. Additionally, this approach enhances the runtime performance of the converted Java & C# system.

Procedure Division COPYBOOK Reuse

The original COBOL developers used Procedure Division COPYBOOKs to reduce code duplication. A robust COBOL conversion tool should avoid introducing duplicates of this code into every program that references them, applying refactoring patterns to ensure code reuse. SoftwareMining's translation continues this reuse architecture by converting these COPYBOOKs into classes and methods, which can be shared between programs instead of being duplicated in each one.

Refactoring KSDS/Indexed File Structures to SQL and Object-Relational Classes

A key step in refactoring COBOL applications is improving the code's readability for Java developers who may not be familiar with COBOL. When working with KSDS and Indexed Files, this can be achieved by migrating data from files to an SQL database and refactoring the structures into an Object-Relational Model (ORM) - a widely used architecture among developers. In this model, data is stored in SQL tables, while the code interacts with individual records through CRUD methods (Create, Read, Update, Delete).

For more information on data migration requirements when using the COBOL to Java Converter, visit: Data Migration Requirements.

Embedded SQL (EXEC SQL) - Converting from COBOL to Java/C# Dialect

SoftwareMining's Converter refactors SQL statements from COBOL-specific syntax to Java and C# compatible dialects. This includes translating COBOL-specific constructs like NULL-INDICATORS and SQL-Codes seamlessly into Java and C# formats. This capability allows the newly converted system to run and be tested against the existing database, ensuring a smooth transition during the migration process.

COBOL applications originating from IBM mainframes often use DB2-specific SQL statements to access functions not readily available in the COBOL environment. For example, a COBOL application might use the following DB2 call to obtain the current date in a specific format not natively supported by COBOL:

EXEC SQL SET :WS-DATE = CURRENT DATE END-EXEC.

Referencing such statements introduces performance issues in the new Java application, primarily due to the overhead of network calls, and also creates database vendor-specific dependencies. The SoftwareMining Translation tool refactors these SQL statements to native Java or C# utilities, resulting in significant runtime performance improvements.

Binary Compatibility with Legacy Data Files (Including Sequential Files)

A large part of communication in COBOL applications is performed via binary formats that use a compact representation for numeric values. This includes most file system operations, from SEQUENTIAL to INDEXED and VSAM files, as well as interactions & integration with other external applications. For the translated Java (or C#) application to work seamlessly "out of the box" without extensive manual rework, binary compatibility must be maintained. This requirement is supported by the SoftwareMining libraries distributed with each refactored application.

This approach allows the SoftwareMining Converter to generate more readable code, while ensuring that the complexity of maintaining binary compatibility is managed within the libraries, rather than in the generated code itself.

EBCDIC to ASCII Conversion - Even at Runtime

IBM mainframe applications use the EBCDIC character set. After migrating COBOL code to a Java application, the next challenge is to convert the data from EBCDIC to UTF-8 character set. Unfortunately, this is not a simple character conversion process; it requires detailed information from the File-Definition, including file length, CRLF format, and, most importantly, the position of each Packed-Decimal field. During the refactoring process, the SoftwareMining Converter records all this information, which is then utilized by our utility libraries to perform the conversion.

This approach simplifies the transition from the mainframe and also facilitates the integration of the translated Java application with other mainframe COBOL systems.

For more information please see Migrating EBCDIC Data Files

JCL to Unix/Windows Shell Scripts

COBOL applications typically utilize a substantial set of JCL (Job Control Language) scripts to launch programs, organize, and sort data files. Translating these scripts is a crucial component of the overall conversion project. The SoftwareMining Translation tool addresses this requirement by supporting the translation of 90% of the most commonly used JCL statements, facilitating a comprehensive and efficient migration process.

CICS, MQ, BMS, RACF Support

Most IBM mainframe applications rely on these utilities to simplify the development and maintenance of the application. A successful transition away from COBOL and the mainframe requires not only that such functionality is available in the target Java system but also that the outdated and difficult-to-understand APIs are refactored into a more maintainable form.

For further information, see CICS Support.