Mainframe
COBOL to Java, C#
& Cloud
The following is a summary of project management experiences we have gained from helping our clients convert their COBOL applications to Java or C#.
The steps listed apply to the migration of COBOL applications with VSAM/KSDS data files, CICS Transaction Processing, ILE COBOL in IBM ISeries,
Tandem, as well as platforms with CODASYL databases such as BULL, Unisys, and VAX.
Conversion of COBOL/DB2 (SQL) applications, however, tend to be more straightforward, and many of the data/data-migration steps will not be required.
Testing is one of the biggest tasks in any modernization, rehosting, or writing a brand-new application.
Writing test scripts involves running the COBOL application and noting the behavior.
SoftwareMining's COBOL Converter will translate VSAM Indexed File Definitions (FD) to SQL Tables.
In this design every FD field will get its own database column, and Index Groups will be translated to composite keys.
With closer attention to the following issues, the translator can generate better designs for the database tables,
making the effort in the following clean-up process very worthwhile.
In COBOL, Often different programs use a different File-Definitions structures for access to the same data-file.
For example, Prog-1 may define:
01 CLIENT-REC-1.
05 IDEN PIC 9(5).
05 FILLER PIC X(20).
05 BAL PIC 9(5)V9(2).
01 CLIENT-RECORD. 05 ID PIC 9(5). 05 FORENAME PIC X(10). 05 SURNAME PIC X(10). 05 BALANCE PIC 9(5)V9(2).
However, the table/column names will depend on which program has first been translated. I.e. the following names will be used:
CLIENT-REC-1, IDEN, FILLER, BAL CLIENT-RECORD, ID ,FORENAME, SURNAME and BALANCE
The population of the new SQL tables from VSAM structures is achieved using Data-Access-Objects (DAO) created in the previous step.
One of the significant differences between the original data-structures and the SQL tables is the representation of numeric fields and columns.
For instance, Packed-Decimal fields are stored as Binary Coded Decimal in the COBOL data-file.
However, after migration to a database, they will be represented as number columns, and the actual number values will be stored
- as opposed to the binary representation of the value.
This simplifies understanding the data in the database.
The Data-Access-Objects can also be used for EBCDIC->ASCII conversion. This activity will need to be performed only once.
Large applications may comprise hundreds or thousands of programs.
Starting the translation of the programs alphabetically may not be the best approach:
program "A" may call program "Z," which is not scheduled for translation until later.
The call chain analysis process should identify all programs as well as the data-files involved in a chain.
Identifying the associated list of programs allows them to be translated together, and their associated list of data-files to be prioritized for the data-migration process.
SoftwareMining's Call-Chain Analysis tool can help identify these artifacts and organize their translation accordingly.
For more information, see COBOL Application Analytics.
After identifying testable sets of programs and data files involved in the call chain analysis step above, the identified set of programs needs to be translated and sent to the testing team. Work can then begin on identifying the next call-chain, its translation, and testing.
For a manual rewrite process, translation of each call-chain can take weeks or months, depending on complexity.
For automatic translation, allocate a day for translation and compilation of each set.
Note that the data-migration phase needs to have been completed on datasets accessed in this call chain.
Job Control Language (JCL) scripts are equivalent to shell scripts and are used for many activities such as:
The construction of COBOL test cases and test harnesses should have started earlier in the project. Functional testing can also be viewed as a regression test. The aim is to run the same tests on the new language and to reproduce the results in the new system.
The time schedule allocated to testing is, of course, very dependent on the complexity of the programs in the chain as well as the length of the chain. But rough estimates indicate approximately five sets of call-chains per developer-day. Usually, the first few test sets will take significantly longer to complete. This is due to developers and testers needing time to familiarize themselves with the new system, as well as technical teething issues which often occur at the beginning of all projects.
Once a certain degree of confidence with the new code has been gained, a spot-testing strategy may be adopted.
Much of the performance of the final system depends on the quality of the translation. For example, for a numeric variable, the translator can generate one of the following three types of definitions. The decision can only be made after the translator carefully assesses the usage patterns for the variables in a program:
Having performed a major rejuvenation of language and architecture (from COBOL to Java or C#), it is sometimes advantageous to redesign the screens to take advantage of new HTML/Browser technology.
For example, a SoftwareMining client redesigned data entry screens to show 100 records instead of the 24 lines available on the mainframe terminal. Subsequently, new drop-down boxes, menu-items, and radio buttons were added to the new screens to reduce the amount of typing. The new screen designs reportedly increased the efficiency of the data-entry pool by 15%, and reduced running costs by the same level.
The translation of COBOL screens, be it BMS, DMS, ILE, or other formats, will result in character-based HTML screens that look identical to the original screens. However, the translated system provides a plug-and-play type architecture that allows manually re-designed JSP or ASP to be plugged into the same application without changing any of the business logic code.
This is of course more applicable to online applications. Here users will be looking at a series of tests which surmise all of the above: functional equivalence, response time, usability and so on.
© 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.