Mainframe COBOL to Java, C# & Cloud

Mainframe COBOL to Cloud Migration: Roadmap & Checklist

There are big financial incentives to migrate Mainframe applications to Cloud: Whether the mainframe applications are re-hosted or translated to new languages, the migrated system will require testing - the single BIGGEST expense of the project.

Given the cost and effort involved, it makes more sense to opt for a long-term solution - moving the application to a new language and architecture which can be maintained by new developers.

This paper focuses on a long-term solution which involves changing the codebase from COBOL to a cloud-friendly language/framework such as Java or C# (.NET). This approach offers the following benefits:

A successful move from Mainframe COBOL to the cloud requires the following issues to be addressed:

Checklist Item

How can it be resolved

Conversion of COBOL code To Maintainable & Cloud-friendly languages: Java or C# High-Quality Translator

The most cost effective and low risk approach to Java / C# is using a high-quality translator which can produce maintainable and functionally correct Java/C# code. SoftwareMining Translation tools achieve this by catering for 16 Features Essential for Successful COBOL to Java Conversion Projects

From CICS (and other Transaction Processors) to Application Servers CICS Libraries
Java and C# Application Servers (Weblogic, WebSphere, Tomcat, and IIS for Microsoft .NET) provide much of these functionality. The Translator must be able to generate code which will utilize such technologies.

Out of the remaining CICS functionality,
  • Some can be handled by clever translations (for example, CICS READ/WRITE statements to Object-Relational persistence Models)
  • Some need to be provided in libraries implemented in Java or C#
SoftwareMining's Translation approach caters for all these scenarios.
For more information about SoftwareMining's CICS libraries and modernization approach please see Approach to Migration of CICS Cobol to Java / C# .

Online BMS / MFS Applications - Support for migration of BMS operations to legible statements Handling Legacy Screen Formats
A full solution should cater for two aspects:
Access to Queue framework MQ Series
Most legacy COBOL applications use queueing framework for passing messages between modules. Once translated, during testing phase the new system should be able to communicate with the legacy MQ Series.
Beyond the testing phase, the new application should be able to use any other commercial or Open-Source queueing system.
SoftwareMining translates to interface which allow implements to communication with any queueing system.

Conversion of JCL to Unix or Windows Shell Scripts Viable solution to JCL translation
Most mainframe shops rely heavily on JCL scripts. A successful deployment on the cloud requires the JCL solution to work hand-in-hand with the converted Java or C# application.

A viable JCL solution needs to address:
  • Language Translation from JCL to Unix or Windows scripts (legacy JCL scripts are particularly illegible to new developers)
  • Support for a wide set of functions and utilities usually used by JCL scripts. E.g. EXEC PROC, SORT, IEBGENER, IEFBR14, ...
For more information see SoftwareMining's JCL solution.

Data-Files: KSDS Indexed Files to SQL Database Data Migration
While many COBOL applications have already been moved to SQL Database, there are still many which use KSDS files to their data.

SoftwareMining conversion automatically addresses the migration of VSAM / KSDS structures to SQL databases schemas by catering for the following issues:
  • Redirecting all KSDS API to the SQL database (through use of an Object-Relational Model)
  • Generating SQL Schemas for the KSDS files
  • EBCDIC to ASCI character conversion
  • Providing data-population mechanism

COBOL / DB2 Applications The conversion of COBOL + EXEC SQL to Java / C# needs to change the dialect of SQL - from COBOL centric (using Host-Variables, Null-Indicators) to Java (using '?') or C# centric.

Additionally, for performance reasons, the converter will also need to try and reduce the amount of data-based communication, as these may have higher overheads on the Cloud.
There may also be performance issues when communicating between DB2 on mainframe and external Java/C# applications. For more information, see detecting cause of performance issues.

Data-Files: IMS and other Database to SQL Database In some cases, the database migration can be performed in same manner as KSDS approach. For other cases, such as IMS DB, the database migration needs to be performed in a separate stage by creating a "middle-data-access-layer". For further information please see COBOL Platforms.

Assembler or other variants (e.g. Algol code) Assembler type scripts are generally used to provide extensions to Operating-System functions. They often do not contain any "Business-Logic" which need to be translated.
The use of assembler code to be reviewed case by case. In many cases they can be replaced simply by Java and C# libraries, which offer a much more rich framework and libraries than COBOL.

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