Mainframe COBOL to Cloud Migration: Roadmap & Checklist

Whether the target is Amazon AWS, Microsoft Azure, private cloud or other - there are big financial incentives to migrate Mainframe applications to Cloud.

The BIGGEST expense of the such projects is often the Testing phase: ensuring the same functionality in new application, whether it was rehosted (re-compiled with a new compiler, and deployed on to the cloud) or translated to new languages.
Given the cost and effort involved in Testing the new application, many organizations are opting for the long-term solution, and Translate the code-base to a new language to allow continued maintenance 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:

• Reducing application runtime costs by moving Mainframe to cloud
• Reducing application maintenance costs by making it accessible to a new pool of Java/C# resources
• Integration of new technologies to the application

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 The solution should be based on Application-Server deployment and should: Avoid using screen emulators and focus on Browser based technologies such as JSP / ASPX The translator Should convert legacy BMS operations to meaningful statements, as many of the COBOL screen manipulation statements would be foreign to new developers.
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. Assembler programs should 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.

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