COBOL to Maintainable Java & C#


COBOL to Java / C# - Managing Conversion Projects


Before we Start: A note on Project Timing and Resources



Introduction

The following is a summary of project management experiences of we have gained from helping our client's convert their COBOL applications to Java or 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.

Conversion of COBOL/DB2 (SQL) applications however tend to be more straightforward, and many of the data/data-migration steps will not be required.



Steps:


Prepare Test-Scripts in a separate thread

"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 behaviour.


The process of writing test-scripts should be started and continued in parallel with all the other activities.
It would be prudent to start this process early.


Clean-up Main VSAM Data-Structures

SoftwareMining 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. The following



Create a simple COBOL program referencing all the Main VSAM structures - translate this

In COBOL, Often different programs use a different File-Definitions structures for access 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).
While Prog-2 may access the same data using a different structure :
	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).
In migrating the data to SQL databases, the above structures would be merged in a single table. SoftwareMining COBOL Converter can either use heuristics or configuration files to merge the structures, and amend both programs to use the same database table. But the translator has to have a first-come, first-serve capability.

But the table/column names will depend on which program has first been translated. Ie the following names will be used

if Prog-1 is translated first -
CLIENT-REC-1, IDEN, FILLER, BAL 
but if Prog-2 is translated first -
CLIENT-RECORD, ID ,FORENAME, SURNAME and BALANCE 

It would be benefitial if the most detailed definition(s) for each data-file is placed into a single custom made COBOL program which can be translated as the first step.
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.


Data-Migration for VSAM files (and EBCDIC to ASCII conversion)

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, Packed-Decimal fields are stored in Binary Coded Decimal in COBOL data-file. However after the migration to a database, they will be represented as number columns, and the actual number values will be stored - as oppose to binary representation . 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.

Call-Chain Analysis - identify programs and data files involved in call chains

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.



Translation of programs in sets identified in Call-Chain analysis

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.

Addressing Job Control Language scripts (JCL)

Job Control Language (JCL) scripts are equivalent of shell scripts and are used for many activities such as:

Functional Testing

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.

Performance Testing

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

Although the performance of fields defined as "double" is significantly better than the other two, sometimes java's BigDecimal will be required due to its better precision, and sometimes emulation of the original COBOL's will be required (e.g. when writing to a binary compatible Sequential file).
The ability of the translator to distinguish between such cases will make a huge difference to the performance of the new system.

The performance requirement of batch and Online applications can often be addressed by the following different approaches:

User Interface Re-design (for Online Applications)

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.

User Acceptance Testing

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





Share this page







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