Mainframe COBOL to Java, C# & Cloud

Essential Features for Successful COBOL to Java or C# Conversion Projects

COBOL to Java conversion projects usually have three high-level objectives: Keep costs down, news system should be maintainable by new developers and have reasonable performance.

To meet these requirements, SoftwareMining has identified the following translation features as essential for successful COBOL to Java / C# projects:

Translator Feature

Why is it important

Procedure Division Copy-books should be translated to classes/methods, shared between programs rather than duplicated in every program The original COBOL developers went to great length to reuse the code in Procedure Division Copy-books. The converted Java / C# system should NOT introduce duplicates of this code into all program referencing them. The converter should be able to apply re-factoring patterns in order to reuse such code.
Minimize the number of generated Data Access Objects (DAOs) generated from COBOL's 01 level definitions. The translator should be aware of previously generated DAOs and reuse them when possible. It reduces the number of generated classes, and improves maintenances and application load times
Remove unreferenced data-structures It removes dead code, leading to smaller application sizes
Remove unreferenced variables Simplifying applicaion and removing dead code improves application maintenance
Remove un-reachable program statements Leads to improving application maintenance
Remove or reduce GOTO statements Java and C# languages do not support COBOL's GO TO statements. However, while they can be supported via a framework library, the COBOL to Java/C# convertor must make every effort to remove them.

On average, SoftwareMining Converter removes approximately 70% of the GOTO Statements.
Precision vs Performance
COBOL's numeric variables can go up to 32 digits. To achieve the same, java uses BigDecimal data types (C# uses Decimal data type).
These have much lower performance levels, so COBOL numeric variables and operations must be converted to BigDecimal types only when necessary.
Performance should not be sacrificed for of precision, or vice-versa
Support for COBOL Pointers Ideally, in the long run, all COBOL Pointers would be replaced by references to "objects". But until then, support of COBOL Pointers within the translated Java and C# system allows the new system to quickly move into production.
Use COBOL emulation only when necessary.
Some of the translated Data-Access-Objects need COBOL emulation features such as REDEFINES, OCCURS-DEPENDING, COMPUTATIONALs and POINTERS. The translator should distinguish when such features are needed. When not required, the translator should generate simple classes which by-passes the dependency for the emulation.
Avoiding unnecessary emulation will result in better runtime performance of the converted Java & C# system
VSAM / ISAM to Object-Relational-Model (ORM). ORM is familiar to most Java and C# developers.
The approach also increases legibility to COBOL developers trained in Java & C#
Migration of KSDS/Indexed file structures to SQL Database Use of SQL Database has become standard in new applications. It simplifies maintenance, and increases integration prospects
Embedded SQL (EXEC SQL) - convert from COBOL to Java / C# dialect This allows a new system to be run and tested against the existing database.
SoftwareMining's converter also provides SQL database migration features
Embedded SQL (EXEC SQL) - convert DB2 utility calls to native Java / C# functions Sometimes COBOL apps make calls to DB2 just to gain access to functions abscent from COBOL. E.g.
Significant runtime performance gains can be achieved by translating such statements to calls to native Java/C# utilities.
Binary compatibility with legacy data files (including sequential files) Ability to read/write files generated by mainframe provides continuity and integration
Support for multiple programs in Single file We have encountered COBOL files with upto 20 PROCEDURE DIVISIONs.
Translation to Java/C# uses a combination of inner classes to achieve the same access to data-items
EBCDIC to ASCII conversion - even at runtime This makes it easier to switch over from mainframe while also allowing for integration of translated Java application with other mainframe COBOL systems
JCL to Unix / Windows Shell Scripts Most large COBOL applications include a large set of JCL Scripts, and the migration of JCL is an essential part of the overall project.

Download COBOL to Java / C# Conversion Tool  (Release date: 2023-01-09)

View translation examples:    COBOL to Java    COBOL to C#   CICS/BMS statements

Comments & Feedback:       
* Name :
* Company email:

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