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 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||Reduces the number of generated classes, improves maintenances and application load times|
|Remove un-referenced data-structures||Removes dead code, leading to smaller application size|
|Remove un-referenced variables||Removing dead code to improve application maintenance|
|Remove dead code||Removing dead code to improve application maintenance|
|Remove or reduce GOTO statements||Java and C# languages do not support COBOL's GO TO statements. However they can be supported via a framework library. The COBOL to Java/C# convertor must make every effort to remove these. On average SoftwareMining Converter removes approximately 70% of the GOTO Statements.|
| Precision vs Performance COBOL numeric variables can go up to 32 digits. To achieve same java uses BigDecimal data types (C# uses Decimal data type).
These have much lower performance, thus COBOL numeric variables and operation must be converted to BigDecimal types only when necessary.
|Should not sacrifice performance for of precision, or vice-versa|
|Support for COBOL Pointers||Ideally, in the long run all COBOL Pointers should be replaced by references to "objects". But in short, support of COBOL POINTERs within the translated Java and C# system allows the migrated system to quickly move into testing / production phase.|
| Use COBOL emulation only when necessary.
Some DAOs need COBOL emulation such as REDEFINES, OCCURS-DEPENDING, COMPUTATIONALs and POINTERS, but some don't. When emulation is not needed, translator should generate simple classes bypassing emulation features.
|Avoiding un-necessary 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 Relational 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||Allows new system to be ran and tested against existing database. System also provides SQL database migration features|
|Embedded SQL (EXEC SQL) - convert DB2 utility calls to native Java / C# functions|| Sometimes COBOL apps made calls to DB2 just to gain access to functions not present in COBOL. E.g.
EXEC SQL SET :WS-DATE = CURRENT DATE END-EXEC.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|
|EBCDIC to ASCII conversion - even at runtime||Makes easier to switch over from mainframe. Also allows 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 migration of JCL will be an essential part of the project.|
© 2017, SoftwareMining Technologies. All Rights Reserved. "SoftwareMining Technologies" is a trademark of Software Modernization Technologies Ltd (UK). Software Modernization Technologies Ltd. Registered in England company no: 7300248. Reg Offices: 8b Accommodation Road, London NW11 8ED, United Kingdom.