COBOL to Java and C# refactoring projects are typically driven by three core objectives: minimizing costs, creating a system that is easily maintainable by new developers, and ensuring optimal performance.
To meet these objectives, the converter and refactoring system must address various requirements and handle significant architectural differences between COBOL and modern Java/C# languages.
Without this capability, the generated code may become nothing more than "JABOL" - COBOL written in Java, but harder to read and understand.
The SoftwareMining COBOL Converter employs classical AI techniques to refactor and generate highly maintainable Java and C# code. The following is an overview of some of the essential features, ensuring the highest success rate with the lowest risk for such projects:
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.
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.
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#.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
Download COBOL to Java / C# Conversion Tool (Release date: 2024-10-09)
View translation examples: COBOL to Java COBOL to C# CICS/BMS statements |
© 2024 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.