The following is a summary of project management experiences of we have gained from helping our client's migration from COBOL to Java and C#.
The steps listed apply to 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.
Migration of COBOL ESQL applications however tend to be more straightforward, and many of the data/data-migration steps will not be required.
This 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 behaviour.
The translation process will translate VSAM Indexed File Definitions (FD) to SQL Tables.
In this design every FD field will get its own database column. Index Groups will be translated to composite keys.
With closer attention to the following issues, the translator can generate better designs for the DB Tables, making the effort in the following clean-up process very worthwhile.
In COBOL, Often different programs use a different FD structures for access same data-file.
But in SQL world, there should be only one structure for the given data-file.
In this step, the most detailed definition (FD) for each data-file should be selected and placed into a single COBOL program.
The translation of this program will result in generation of SQL tables as well as the java/C# Data-Access classes (Object-Relational). The process is designed to help the next step: the construction and population the SQL database.
For applications running on IBM Mainframes, the Data-Access-Objects above can be configured to communicate with the existing VSAM files instead of communication with an SQL Database.
This means the data-files can be shared between COBOL and Java application. This communication can be achieved by using IBM's Java/ VSAM communication libraries.
The population of the new SQL tables from VSAM structures is achieved using Data-Access-Objects created in previous step.
One of the big differences between the original data-structures and the SQL tables is the representation of numeric fields and columns.
For example, a field may have been defined as COMPUTATIONAL in COBOL. The values of this field will be stored as binary within an Index file. However after the migration they will be represented as NUMBER columns. Ie the values will be displayed as a number (not a binary string). This makes life a lot more simple when it comes to 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 application may comprise of hundreds or thousands of programs.
Starting 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.
The list of programs can be sent for translation, and the list of data-files can be prioritized for migration.
SoftwareMining's Call-Chain Analysis tool can help identify these artefacts and organise their translation accordingly.
Having identified testable sets of programs and data files involved the call chain analysis step above,
the identified set of programs need to be translated and send for to the testing team.
Work can then begin on identifying the next call chain, their 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 of shell scripts and are used for many activities such as:
The construction of COBOL test cases and test harnesses should have started earlier on in the project.
Functional testing can step can also be viewed as a regression test.
I.e. 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 estimate would allow to approximately 5 sets of call-chains per developer-day.
Also, usually the first few test sets will take significantly longer to complete.
This is due to developers and testers needing time to familiarize with the new system,
as well as technical teething issues which often occur in 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 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, one of our clients redesigned data entry screens to show 100 records instead of 24 line (available on the mainframe terminal). Then 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 same level.
The translation of COBOL screens, be it BMS, DMS, ILE or other formats, will result in a character-based HTML screens which would look identical to the original screens. However, the translated system provides a plug-and-play type architecture which 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 ...
© 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.