Managing COBOL to Java / C# conversion project

The following summary reflects our extensive project management experiences gained from assisting clients in converting their COBOL applications to Java or C#. The outlined steps are applicable to the migration of mainframe COBOL applications with VSAM/KSDS data files, CICS Transaction Processing, ILE COBOL on IBM ISeries, Tandem systems, as well as platforms utilizing CODASYL databases like BULL, Unisys, and VAX. It's worth noting that the conversion of COBOL/DB2 (SQL) applications tends to be more straightforward, often requiring fewer data-related migration steps.

Download Free Trial

SoftwareMining Translating & Documenting COBOL Programs

Run Translated Mainframe Application

Flowchart-Documentation of COBOL programs

See How it works

COBOL Migration Project Steps:

Prepare Test-Scripts for the COBOL application
Data-Migration (and EBCDIC to ASCII conversion)

VSAM Prep 1 - Create a simple COBOL program referencing all the Main VSAM structures
VSAM Prep 1 - Clean-up Main VSAM Data-Structures

Call Chain Analysis
Translation Sets
Addressing Job Control Language scripts (JCL)
Managing Test Schedules
Performance testing
User interface redesign (for Online Applications)
User acceptance testing

Prepare Test scripts for the COBOL application

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.

For the online part of the application, this involves noting the result of the selection of datasets, dates, function keys, as well as noting the resulting changes.
Batch programs often result in the generation of new data-files (Sequential or Line-Sequential). Given the same input data, the new Java or C# applications should produce the same result. The test scripts should note the input and output data. This would allow "diff" type tools to be used to compare the results generated from the legacy and the new system.

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, and before the last of the COBOL/JCL resources have left the organization. Their COBOL, as well as the application knowledge, will be very useful in all phases of the project - from testing, data-migration, JCL migration, to integration
Moving forward, these resources will need proper training in the target language (Java or C#) prior to the start of the project.

Data Migration for VSAM Files (Including 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 significant difference 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. After migration to a database, such fields will be represented as numeric columns, and the actual numeric values will be stored, rather than the binary representation of the value. This simplifies data comprehension in the database.

The Data-Access-Objects are utilized for a one-time EBCDIC to ASCII conversion - eliminating the need to work with EBCDIC after the migration and departure from the mainframe.

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.

The system will create database columns for "main" fields, and not fields REDEFINE-ing others. Move main fields to the root-group or first-group of the File-Definition.
Indexed fields/Groups should not belong to "Redefined" fields: Redefined fields will not get created.
Avoid multiple "01" level File-Definitions
Note programs which use a different FD structures for same data-file. This information will be used in our next step to merge multiple File-Definitions, representing a single structure into a single database table

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:


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

When migrating data to SQL databases, the previously mentioned data structures will be consolidated into a single table. SoftwareMining's COBOL Converter offers the flexibility to achieve this task using either heuristic algorithms or configuration files, ensuring synchronization between both COBOL programs and their usage of the same database table.
However, the translator possesses a 'first-come, first-serve' capability. As a result, the names of tables and columns will depend on the sequence in which the programs are translated. Therefore, the following naming conventions will be employed in the example above:

If 'Prog-1' is translated first -

CLIENT-REC-1, IDEN, FILLER, BAL

But if 'Prog-2' takes precedence -

CLIENT-RECORD, ID, FORENAME, SURNAME, and BALANCE

It is advisable to consolidate the most comprehensive data-file definitions within a dedicated COBOL program. This program can then serve as the initial candidate for translation.
The translation of this program will result in the creation of SQL tables and Java/C# Data-Access classes (Object-Relational), paving the way for the subsequent step: the construction and population of the SQL database.

For further information, please see Mainframe CICS VSAM to Java Conversion.

COBOL Call Chain Analysis

Large applications often consist of hundreds or even thousands of programs. Commencing the translation process alphabetically may not always be the most efficient approach: program "A" might call program "Z," which is not scheduled for translation until later.
The call chain analysis process is designed to identify all programs and data files involved in a chain. Identifying the associated list of programs allows for their collective translation, while prioritizing the data files for the data migration process.
SoftwareMining's COBOL Analytics & Translation Tool also provides Call-Chain Analysis - invaluable in identifying the artifacts and organizing their translation accordingly.

Translation Sets

We recommend against translating the entire application on day one, all at once. Ideally, sets of related programs should be identified through the call chain analysis mentioned above and translated incrementally. While the testing team is engaged in their tasks, work can commence on identifying the next call chain, its translation, and subsequent testing phases.
Allocate a day for translation and compilation of each program set.

Please note that the data migration phase must have been completed for datasets accessed within this call chain.

Addressing Job Control Language Scripts (JCL)

Job Control Language (JCL) scripts are similar to shell scripts and serve various purposes, including:

Launching batch programs: JCL needs to be translated into Unix or Windows shell scripts to initiate the new programs.
Sorting data files: While SoftwareMining provides Java/C# SORT and other utilities commonly used in JCL scripts, the JCL itself needs translation into a shell script.
Generation Data Groups (GDG): Similar to version control for data files. During the migration of VSAM files, an additional column may be added to the SQL table to provide the same functionality, rendering GDG JCL scripts redundant.
IDCAMS: Used for extracting data from VSAM Files to sequential files. SoftwareMining provides utilities for extracting data from the new SQL tables.

In most cases, call chain analysis tools can also scan JCL files and demonstrate the association of a JCL file with COBOL programs. SoftwareMining's translation tool can then be used to convert JCL into Unix/Windows Shell Scripts.

Managing Test Schedules

The development of COBOL test cases and test harnesses should ideally begin earlier in the project. Functional testing can be seen as a form of regression testing, where the goal is to execute the same tests in the new language and reproduce the results in the new system.
The time allocated for testing naturally depends on the complexity of the programs within the chain and the chain's length. However, rough estimates suggest around five sets of call chains per developer-day. Typically, the initial few test sets may take longer to complete. This initial delay is due to developers and testers needing time to become familiar with the new system and to address technical challenges that often arise at the project's outset.
Once a certain level of confidence in the new code is attained, a spot-testing strategy may be adopted.

Performance Testing

Performance requirements for both batch and online applications can often be addressed through different approaches:

Batch Programs: These programs typically need to run within a predefined timeframe. Performance-sensitive programs can benefit from parallelization, which is often relatively straightforward to implement. For instance, program logic can be slightly adjusted to process records A to M in one thread and N to Z in another.
Additionally, when deployed in a cloud environment, different batch processes can be launched on different processors, distributing the load effectively across multiple processors.
Online Applications: Challenges may arise when dealing with a large number of concurrent users. Such applications can benefit from load-balancing techniques employed with multiple application servers.

User Interface Redesign (for Online Applications)

After performing a significant overhaul of the language and architecture (transitioning from COBOL to Java or C#), there can be advantages to redesigning the user interface to leverage modern HTML/Browser technologies.

For instance, a SoftwareMining client revamped data entry screens to display 100 records, a significant increase from the 24 lines available on the mainframe terminal. Additionally, they introduced new drop-down boxes, menu items, and radio buttons to streamline data entry, resulting in a reported 15% increase in the efficiency of the data-entry pool and corresponding cost reductions.

Translating COBOL screens, whether in BMS, DMS, ILE, or other formats, produces character-based HTML screens that closely resemble the original screens. However, the translated system offers a plug-and-play architecture, allowing manually redesigned JSP or ASP.NET interfaces to be seamlessly integrated without altering any of the business logic code.
SoftwareMining also provides a Screen Designer for modernizing translated BMS screens, facilitating efficient screen modernization.

User Acceptance Testing (UAT)

User Acceptance Testing is a critical phase, particularly for online applications, where end-users play a pivotal role in validating the system's readiness for production use. During UAT, users will conduct a series of tests that encompass various aspects, including:

Functional Equivalence: Ensuring that the new system's functionality matches the original COBOL application, addressing any deviations or discrepancies.
Response Time: Evaluating the system's performance, responsiveness, and latency to meet user expectations.
Usability: Assessing the user interface for intuitiveness, ease of navigation, and overall user-friendliness.
Data Integrity: Confirming that data migration and transformation processes have preserved data accuracy and consistency.
Scalability: Verifying that the application can handle expected user loads and data volumes without performance degradation.
Security: Ensuring that the system maintains data security and access controls, protecting sensitive information.

UAT serves as the final validation step before a new system is deployed into production. It allows end-users to confirm that the system meets their needs and requirements, and any issues or concerns can be addressed before the system goes live.

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

Managing COBOL to Java/C# Projects