Enterprise COBOL Migration

Looking back at 2021, Lessons Learned

Did you know….

Enterprise COBOL is the language that runs the world economy and those enterprises that use COBOL recognize the challenge in front of them today.?

• Ensure your entire COBOL ecosystem remains in top working order,
• Leverage advanced functionality version 6 offers, not too mention reduced MSU consumption,
• Software currency matters, certainly from a security standpoint.

Clients understand that their current release of COBOL will be withdrawn from IBM support April of 2022.??

IBM Enterprise COBOL Version 6 is where you need to be.

This article will focus on how you get there.?

Even a small mainframe client could easily have hundreds to thousands of COBOL programs running on Version 4.2 and prior compiler release levels.

Where do you start?

Organizations may have migrated to Enterprise COBOL v4.2, but they likely still have tons of programs running on older versions of the COBOL compiler.???Evolving Solution has developed an Enterprise COBOL Migration offering that will look at your entire COBOL portfolio and using your system, compile all source using version 6 of the compiler.?Traditional compiler output such as object modules are not created. ?However, the compiler listings are saved for follow-on analysis that is performed by Forecross.??

The impact of the Enterprise COBOL v6 compiler on your applications can be seen in two areas:

1. Possible program changes that can be determined by the v6.2 compiler itself
2. Possible program changes that can only be determined at run time because they relate to data content that is handled differently in v6.

It is important to keep these two areas in mind when evaluating and planning for your upgrade project.

As it relates to “Where to Start…” it helps to think about an Enterprise COBOL v6 migration as having three parts:

1. Determine the scope and assess all in-scope programs for compile-time issues, e.g., mass compilation with listing capture and programmatic analysis,
2. Define a bounded pilot project to address run-time issues and build a migration project model for the remainder of the application suite,
3. Conduct the main migration project according to the findings and model from the pilot.

It is possible to roll items 1 and 2 into a single engagement where the inventory is mass compiled, reduced, assessed and reported followed by a pilot of your first 100 Programs.

Is it really necessary to compile your entire COBOL portfolio?

Assuming an impact assessment must be done across the board, then this challenge could be real. ?If your COBOL portfolio is large and even if your focus is limited to mission-critical applications, this could still involve hundreds or thousands of programs.

The only practical way to address this challenge is through automation.??

Forecross Corporation has built processes that automatically submit compile jobs, with the outputs saved to datasets for further analysis. Their analysis will include extraction of relevant data such as error messages into files or spreadsheets that can be sorted, queried, and counted. With Forecross tooling, it is even possible to automate some of the code corrections.

The extent of any automation efforts should be based on the number of programs in scope. And while building or buying automation to assist in the impact assessment may seem like overkill on a small body of code, the risk of errors introduced by manual processes is great.

The bottom line is that leveraging automation during the compilation phase is extremely valuable and should be given serious consideration.?

Forecross brings the required automation to the table for the client and this, in turn makes entire portfolio compilation a reality.

What are typical findings from such an assessment?

This is best explained by viewing sample output from such an engagement, consider the following three slides.

Here we see average compile time. A process was developed by FORECROSS that submitted the jobs.?These ran through the weekend.

By programmatically studying the listings, the following statistics are gathered.

Using tooling developed by Forecross that models IBM Migration Best Practices, tables such as the following are created.

What skills must a clients’ AppDev team develop to support their migration to Version 6?

The skillset the client must develop is “The confidence to identify a COBOL source object, compile it under version 6, ?address the compiler errors and then know how to test to capture data challenges”.?

Migrating from COBOL version 4 to 6 can be seen as compile to find and fix known incompatibilities followed by testing to find and fix the potential data compatibility errors.?

The portfolio migration assessment offering is used by clients to identify the known issues. Fixing them is simple and in most cases Forecross has automated the code correction.?

But, its important to remember that testing must be done in order to try to shake out the potential run-time issues related to data compatibility. For example, your test plan might want to include programs that don’t have any compile-time issues but that are likely to have run-time ones.

Testing can require significant resources and planning and given the nature the of the testing required, the enterprise should look for ways to apply automation to streamline the process.?

Forecross can help here.

Following the assessment, what does a typical Program Pilot look like?

Our Version 6 Migration Pilot typically consists of 75 to 150 programs.?

A good way to start such a pilot is to lead with our migration assessment discussed earlier where we bulk compile your entire inventory to identify warnings and errors detected by the v6 compiler that must be addressed. This part is easy – brute-force identification.?

But some V6 issues might only occur at run-time. Moreover, they may be triggered from a program that had no compiler diagnostics. Although these programs can’t be ignored, identifying them for inclusion in the Pilot can be a challenge, especially if application knowledge is thin.

Some techniques for Pilot program candidate selection might include:

1. Matching programs with known compiler issues from the Assessment project against a list of the programs that have been modified over the last 1-3 years, as frequently-modified programs are typically the most important in the application, and due to frequent maintenance they may be more likely to have the types of issues that the new compiler does not support.
2. Triaging each application for programs that fit the following criteria:

• Perform significant numeric calculations, especially monetary or other arithmetic that supports positive and negative values
• Include iterative logic (looping)
• Perform mathematical processes on arrays
• dDta from external sources whose accuracy is not under your control
• Have a high negative impact to the business, clients, etc., if the results are incorrect

3. Finally, be sure to include programs that represent your enterprise architecture, such as:

• Batch and online, both with and without database,
• programs that communicate with others that are at older compiler levels, are written in other languages, are proprietary third-party products whose APIs cannot be modified.

Pilot program selection is a collaborative process with the client’s COBOL Subject Matter Experts and our project team.

Other Pilot Project Tips to Consider

Client’s know their most critical programs.??

We advise the client to break the program selections into “PACKETS”.?

This makes the selection process much easier and ensures the Evolving Solutions and Forecross teams stay busy while client SMEs focus on the next program packet.???

Speaking of packets, the first packet is small ~10 programs and batch is our recommendation.

This first packet becomes the scout sent over the hill to see just what we are up against within their Development and Test environment.

There is a fair amount of setup work in their test environment that must take place, for example:

• Copying?the production source code, JCL, load modules, and DBRMs to the project libraries
• Allocating adequate DASD for multiple copies of appropriate databases
• Establishing a test environment for baseline and upgrade parallel testing
• Identifying batch file comparison tools for use in comparing batch outputs
• Creating/identifying test scripts for online program testing
• Identifying all programs called by a pilot program to determine which ones require re-binding
• Identifying the compiler level of all programs that will have been exercised in testing the pilot programs to ensure triage rules have been met
• Collecting project metrics and other relevant information in order to create a model for the full migration effort

We work collaboratively?with client SMEs and their Systems Staff to get all this in place.

Who owns Unit Test?

Our Program Pilot offering takes complete ownership of Unit Test.

That means two tests are performed. One at the current version level and a second at version 6 for the changed programs.?

We use platform tools to compare the output files.?

However, there is quite a bit of knowledge transfer that must take place to be successful.??

After all, the client SMEs do the testing today.?

We need to capture that insight from them so we can perform the testing on their behalf.?

This implies Forecross to client COBOL SME interaction via email as testing progresses and issues are uncovered.?

Similar communication takes place with system level staff as needed, and there is constant interaction with the client assigned project manager.

Client’s appreciate this part of our offering, we take on some of their heavy lifting so they can focus on other areas.??

Keep in mind that while we are performing unit test, we are also building out the complete migration process to be documented as an instruction manual.?? ?

What should the Test Environment look like?

Mainframe clients understand that application modernization testing requires expertise from both the systems support and application development organizations in order to be successful. This is why Evolving Solutions – premier IBM Enterprise Systems experts, and Forecross Corporation, a leader in mainframe application migration, have partnered to provide a full solution for all its COBOL v6 upgrade clients.?

Our approach to this critical testing process is two-fold.?As the chart reveals, there is Baseline testing followed by an equivalent Upgrade Test.?

The output from both the baseline and upgrade tests are expected to match exactly.

Mainframe programs run in batch mode as well as online.?The testing environments provided by the client will support those execution environments and are to be dedicated to the Pilot Project.??

What special considerations surround Database Testing?

Challenges do exist, but they are not insurmountable.?After all, client teams are testing programs that do lots of database access and updates every day!?

For parallel testing which is what we must do here, we start with questions such as:

1. Do you have multiple databases, each supporting on or two applications? Or do you have a massive, integrated database that supports all apps across the board?

• This question relates to how feasible it will be to have multiple copies of the database and how long it might take to backup and restore multiple versions.
• Keep in mind that the database(s) do not have to contain production data, but they MUST contain sufficient volume of data to emulate production, and they must contain robust data that exercises as much of the application code as possible.
• Building a test database with the names of your puppies or favorite cartoon characters, leaving every optional code blank and every date set to your birthday, will not be adequate for the type of testing that must take place in a V6 upgrade!

2. Do your applications use in-line SQL or a data access layer?

• Applications that use a data access layer make it more difficult to determine which tables might have been updated by a given process, which can hamper your ability to use SQL queries before and after testing to ensure the changes were correctly applied.

What approaches can be used when performing Database Testing?

There are a number of approaches, and usually some combination of these will work very well even in the most challenging environment.

• For massive, integrated databases, the testing approach might include techniques such as inserting a ROLLBACK into the pilot program and using the IBM DB2 Log Analyzer to verify test results, or allow the commits to take place and use the UN-DO facility.
• For more modular applications with their own database and in-line SQL, the simple approach of querying the impacted tables before and after each test (baseline and upgrade) can be more than enough.
• There are also DB2 cloning tools that allow the cloning of specific tables so that automated file comparison tools can then be used.

Forecross believes the solution needs to fit the client’s needs.?You should use existing tools to the greatest degree possible, mitigate the risk of unforeseen errors and allow the client to reap the rewards of the new compiler.

You could also apply innovative programming against the pair of database logs that will be updated as part of your version 4 followed by version 6 testing.

Forecross offers all the above capabilities.??

In closing,

Evolving Solutions, working alongside their strategic enterprise modernization partner, provides four COBOL Migration Offerings. This article has focused on the first two offerings:

1.????Portfolio Assessment

• Determine the number of impacted programs in your portfolio,
• Determine what other critical programs should be upgraded as well,?
• Prepare results to support a solid action plan for the main upgrade project.

2.????Program Pilot

• Develop a client-specific methodology to quickly and accurately upgrade any number of COBOL programs to Enterprise COBOL version 6,
• Validate this methodology by converting a representative sample of programs,
• Perform all Unit Testing (with SME guidance),
• Provide support should these changed artifacts move to production.

As clients prepare to move past their Pilot and promote the Version 6 Compiler to production, two additional offerings are available:

3.????Block Compilation and UAT

• Clean compile selected program blocks (100’s to 1000’s at a time),
• Jointly establish testing environment(s),
• Clone/modify batch job streams to support program testing,??
• Support client’s testing of upgraded artifacts,
• Perform error identification and resolution,
• Develop and/or update the migration methodology manual.

4.????Go-Live and Warranty

• Provide up to 80 hours of Go-Live support over a 60-day window for the changed artifacts,
• Revise the Evolving Solutions custom developed Migration Methodology manual based on your Go-Live lessons learned.

Both Forecross and Evolving Solutions would welcome the chance to perform a base assessment, launch a pilot program or any combination of the four offerings above.

Or, if you are an established Version 6 client and would like to convert additional layers of your COBOL Source inventory – effectively turning the clean compile and test keys over to a third party – we can help there as well.

For additional information on Enterprise COBOL Version 6 Migration assistance, reach out to either:

Jim Fyffe, Z Systems Solution Architect; CISSP-ISSMP
[email protected] 
(M) 224-577-5050
        

Or,

Bonnie Castello, Legacy Modernization Specialist,
www.forecross.com 
[email protected]
(M) 415-225-9815