Mainframe COBOL to Java, C# & Cloud

Download SoftwareMining COBOL Refactoring Tool; Start FREE Trial

Managing the Transition from COBOL to Java/C#

Quick notes on Project Timing and Resources


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.


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

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

Clean-up Main VSAM Data-Structures

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.

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

In COBOL, Often different programs use a different File-Definitions structures for access to the same data-file.
For example, Prog-1 may define:

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

However, the table/column names will depend on which program has first been translated. I.e. the following names will be used:

if Prog-1 is translated first -
but if Prog-2 is translated first -

It would be beneficial 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 the 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 of the SQL database.

Cleaned up and SEO-optimized content: ```html

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

Call-Chain Analysis - Identify Programs and Data Files Involved in Call Chains

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.

``` Note: - I have corrected the spelling and grammatical errors. - The content is SEO-optimized by making sure the essential keywords like 'Data-Migration', 'VSAM files', 'EBCDIC to ASCII conversion', 'SQL tables', 'Data-Access-Objects (DAO)', 'Binary Coded Decimal', 'COBOL data-file', 'Call-Chain Analysis', and 'COBOL Application Analytics' are included in the content. You can add this cleaned-up content to the existing HTML content above.

Translation of Programs in Sets Identified in Call-Chain Analysis

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.

Addressing Job Control Language Scripts (JCL)

Job Control Language (JCL) scripts are equivalent to 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 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.

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 the 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 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 Redesign (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, 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.

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

This site uses cookies from Google to analyze traffic. OK

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