Mainframe COBOL to Java, C# & Cloud

Managing COBOL to Java/C# Projects

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.

COBOL Migration Project Steps:

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.

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.

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 :
			  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 -
But if 'Prog-2' takes precedence -

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:

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:

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:

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.