Abstract

COBOL has been around for almost 60 years and is constantly evolving to meet the growing business needs of the modern digital world. Per latest studies, mainframes power 92 of the top 100 banks, 23 of the top 25 airlines, the top 10 insurers, and 80 percent of all corporate data worldwide. Most of these enterprises still have older versions of COBOL. These applications should be upgraded to the latest versions of COBOL to take advantage of the latest mainframe hardware and software capabilities. Also, if a customer is satisfied with the robustness, security and performance of their current mainframe COBOL applications, COBOL upgrade and using the latest z/OS hardware & software is the best modernization bet. In this blog, we will talk about the procedure for updating the COBOL code to the latest version.

Target Audience

Architects, Consultants and Managers looking for summary of insights on COBOL upgrade, Infosys capabilities and IBM’s support for the same

Understanding the basics – COBOL compilers

IBM has announced the end-of-support for various older versions of COBOL compilers and organizations are upgrading to meet up the support timelines. While end-of support could be a compelling reason to upgrade, there are also several benefits that can be achieved with upgrading to the latest COBOL.

COBOL Version 6.4 is the latest version of COBOL that we have today, and IBM has announced their end-of-support for the older compilers. Let us take a moment to understand the COBOL versions and their differences.

Since older compilers were designed in a period when memory was deemed expensive, the compiler optimizations were bound by memory space and the time required for compilation with the least amount of memory available. But today memory has become cheaper, and hardware is more modernized. Compilers now focus on quickly executing compiled programs, rather than earlier generations when they were meant to run faster during compilation. The most recent compiler compromises optimization quality for compilation speed. This implies that, despite requiring several times more memory and longer build times, it is worth the time and resource compared to the runtime benefit provided.

Below is the summary of information on the COBOL compilers and how they evolved over years

The “front-end” of the compiler handles parsing, syntax checking, creating an internal representation of COBOL statements, and creating a dictionary of data objects in the code. The “back-end” is responsible for the actual compilation process, which includes code optimization, generating machine code and object modules, allocating registers, and maintaining debugging information.

As a thumb rule, migrating across different generations in the above table is complex, as the front-end / back-end changes. The target date for updating the system to the most recent COBOL version is being pursued by several enterprises. Post the target support date, the built code is still supported if it runs on a compatible z/OS platform. But if clients encounter any difficulties, their only choice is to upgrade to Version 6. But with time, this cost would go up, as there will be newer COBOL versions and switching between them can get technically complicated.

Planning & executing a COBOL upgrade

Every client environment is unique – the inventory, coding complexity, business complexity and service level agreements to name a few. Hence, the upgrade path is going to be different for each of them. In general, any COBOL migration will have the below steps:

1)    Inventory listing and categorization

2)    Hardware /software set-up

3)    Planning

4)    Compiling, testing and deployment

1)    Inventory listing and categorization

a.     Understand the inventory and segregate the programs by application and versions

b.     List the compiler options for the programs

c.     Segregate the programs by application and complexity

d.     Understand the in-progress projects along with their timelines, complexity, and the impact to the applications

e.     The consolidated inventory details list should contain source code version, compiler options, online/batch categorization, pre-compile options used, called programs, calling programs, code complexity, frequency of execution, application name, application complexity etc.

f.      Identify the performance statistics. Programs with more arithmetic operations/ complex sort logic, that have zoned decimal and comp-3 variables could be the peak CPU hitters within batch window, which serve as ideal candidates to be recompiled for better performance

g.     Identify the components that has missing source code (copybooks / COBOL programs etc.) and identify a mitigation plan

h.     Refer to the IBM migration guide and classify your code for migration complexity

i.      Decide on the migration approach – big-bang /phased and on selective/full inventory recompile

2)    Hardware /Software set up

a.     Understand the hardware and software of all the mainframe boxes (including your disaster recovery box)

The below are the minimum hardware / software requirements for latest COBOL that is chosen as target version. For instance, if the target version is COBOL 6, the below link provides the prerequisite software and service needed for enterprise COBOL version 5 and version 6

https://www.ibm.com/support/knowledgecenter/SS6SG3_6.3.0/migrate/mg5apar.html

This will also help you to plan the compile option – ARCH. This is very critical, as the compatibility should be considered across different boxes to avoid SOC1 errors. For more details refer migration guide.

b.     Select and configure the LE requirements for the first-generation COBOL programs. Programs written in earlier versions of COBOL can run on a variety of runtime libraries, including Language Environment (LE). To find the PTF (Program Temporary Fixes) and LE updates that are required, use migration assistant (https://cobol-migration-assistant.mybluemix.net/assistant)

c.     Get the details on the load library, as the latest COBOL can work only with PDSE load libraries and not PDS load libraries. Some online load modules may be needed 24/7, and careful planning should be made for such cases

d.     Consider installing PTFs for the below along with COBOL

• CICS
• DB2
• Debug Tool
• Fault Analyzer
• z/OS

e.     Enterprise COBOL 5 and 6 programs require more memory than older versions, and TSO user IDs may require 200 MB or more, if not, there could be compilation issues

f.      Set the default compiler options based on requirements after installing the new compiler

g.     Create a list of existing vendor tools, packages, in-house utilities, and their compatibility with the latest COBOL version that you are planning to migrate. Any potential incompatibility should be addressed with suitable solution.

3)    Planning

a.     Based on the above points 1 and 2, plan the migration at application and program level

b.     Backup the old load modules, source code and old compiler

c.     Recompiling the complete inventory will yield benefits like having uniform version of code across the applications, reduced compatibility issues between the components and reduced complexity. However, the testing efforts will increase due to the volume of code that is recompiled. Depending on the need, choose between selective and big-bang approaches considering the long-term goals, time & cost factors

d.     It is recommended that the lower version of codes to be first migrated to their interim version before the final version, but it may not always be needed. If the code and application is less complex, migrating to latest version will save testing efforts

e.     While doing selective recompilation, validate the compatibility between the called and calling program versions, subroutines used across applications

f.      Execute the pilot phase in the project by selecting the right candidates (consider compiler options/ complexity / performance / application criticality etc.)

g.     Identify the change patterns needed in your old COBOL programs and build automation scripts as needed

h.     Identify the options to handle the missing source codes. There are options of source code recovery ( https://www.source-recovery.com/ ) or rewriting the code or using Automatic Binary Optimizer (ABO) tool to migrate the load modules without the source code

4)    Compiling, testing and deployment

a.     It is recommended that a two-step compile test approach is followed. The first time, compile with developer-grade compiler options – SSRANGE, NUMCHECK, PARMCHECK, INITCHECK, and OPT(0); and then after a successful test, recompile with NOSSRANGE, NONUMCHECK, NOPARMCHECK, and OPT(2), for production.

b.     There will be below items observed during compilation:

• About 20x more memory is required at compile time
• Requires more time to compile a program – 5x to 12x, depending on the optimization level
• More compiler work datasets are (SYSUTx) required in the compilation JCLs. It is recommended to use the new IBM-supplied compile PROCs
• Compiler messages are not in the same part of the listing as in earlier versions. Front-end messages are in the middle and back-end messages are at the end
• Compiler always uses above the 2GB bar storage, so MEMLIMIT must be set to non-zero value

c.     Refer Enterprise COBOL migration guide for the target version for the differences (IBM Documentation – IBM Documentation)

d.     Compare the results before and after comparison to understand the performance and the variation in the output. Test with dev-grade and prod-grade compiler options.

e.     Deploy the changed programs

f.      Make sure to consider the ARCH level across all platforms where the code must run. Say there is a disaster recovery box at a lower hardware level Z13 compared to the production box Z15. The ARCH level set should be compatible for both these boxes.

Tools available

There are several tools available to aid the migration work. Below is the list of tools available

1)    Automatic Binary Optimizer (ABO)

The compilation JCLs need more compiler work datasets (SYSUTx). Utilize the new compilation PROCs offered by IBM, if possible. ABO optimizes previously compiled COBOL program modules to increase application performance and reduce CPU usage without source recompilation. As the code is not recompiled or changed, full functional testing of the ABO-optimized modules is not required. However, application integration testing is recommended to ensure the basic functioning of the applications.

2)    Command Level Conversion Aid (CCCA)

IBM COBOL and CICS/VS Command Level Conversion Aid (CCCA) is a tool to convert old COBOL source code and copy modules to new versions of COBOL.  When converting applications from older versions of COBOL (OS/VS COBOL) to latest versions of enterprise COBOL, the CCCA will help identify those changes and will also convert them automatically in a standard fashion to the latest code. Thus, CCCA can be an option during the planning and development phase to enhance productivity and to reduce manual errors.

3)    Migration Assistant – https://cobol-migration-assistant.mybluemix.net/assistant

This link assists in step-by-step guide / checklist for COBOL migration. This is a very useful place to get references to all needed resources in one place.

4)    Open-source COBOL Analyzer – http://cbttape.org/cbtdowns.htm

This tool helps to get the details of compiler release, compiler options etc.

5)    File-AID – This tool can be used to get the list of compiler options in a CSV and then to excel for easy planning

6)    Infosys SMF LOG Analyzer – This tool helps analyze the logs to get the list of active jobs. Any inactive jobs can be identified and analyzed to obsolete them, thereby working on the right set of modules

7)    Infosys Mainframe Modernization Platform – This platform part of Infosys Modernization suite (https://www.infosys.com/services/application-modernization/offerings/modernization-suite.html) is designed to make the modernization journey easier by automated inventory analysis, identifying the dead code in the inventory. For any rewrite that could be needed, this platform helps to extract business rules. More details on the Infosys tools can be found here – https://www.infosys.com/services/modernization/insights/mainframe-modernization-tools-expertise.html.

8)    Infosys LegMAP – Infosys Legacy Modernization test Automation Platform – LegMAP can streamline and accelerate the mainframe modernization testing with minimum SME support in an automated mode to simplify, streamline and standardize the testing process. This tool is capable of:

a.     Performing automated static code analysis to produce component-based test cases with minimal SME dependency and maximum test data coverage

b.     Performing automated test result validation between old and new environment.

c.     Performing automated testing of all backend changes post execution in old and new environment. Entire process of execution and validation will be E2E automated

d.     Ensuring batch environment is working as usual post -upgrade, by running automated regressions on all batch jobs.

Conclusion

Based on the number of successful migrations done by Infosys in the past decade across domains and across geographies, migrating COBOL to the latest version with the latest hardware and software has shown an average MIPS reduction of 15- 25%. The clients had a cleaner inventory post migration. Latest COBOL features such as JSON parsing are available allowing them to digitize their mainframe applications. Infosys has helped its clients achieve their COBOL migrations with minimal effort by using various in-house tools, on-the-fly automations and best practices.

For more information, please visit Mainframe Modernization or email us at modernization@infosys.com

References:

Upgrading from Enterprise COBOL Version 4 – IBM Documentation

https://ibm-zcouncil.com/wp-content/uploads/2020/05/Reduce-costs-improve-performance.pdf