Consider a New Approach to Migrating to Enterprise COBOL Version 6
The world economy runs on Enterprise COBOL. Most mainframe shops likely have a COBOL footprint. The latest version of the language, Enterprise COBOL Version 6, features new compiler technology that was re-architected for speed and precision, along with greater interoperability with future-ready technologies.
It is far more efficient in terms of MIPS and MSUs, thereby reducing costs. Risk-wise, it boosts security by replacing older compilers that aren’t supported. Many shops who haven’t yet upgraded will do so soon.
Evolving Solutions works with Forecross Consulting to offer COBOL modernization services. We have over a century of combined experience modernizing and automating mission-critical enterprise applications. In this blog post we’ll cover some of the key experiences and lessons learned about helping enterprises upgrade to COBOL Version 6.
Upgrading Starts With an Assessment
Upgrading is doable. IBM put together thorough documentation to guide you through the technical process. The big challenge is at the project management level. Up to 90% of modernization projects start with a portfolio assessment.
Such an assessment drives three objectives:
- Inventorying the client’s COBOL portfolio, which could include up to tens of thousands of programs
- Identifying which programs should be upgraded
- Testing the upgrade with a small pilot that moves code to Version 6
What comes out of this assessment is a recipe book for carrying out the main upgrade in a way that limits potential issues. Let’s take a deeper look at each part of the assessment.
Guidelines for Determining Which Programs to Upgrade
Most organizations consider upgrading their entire portfolio. This is a costly, technical endeavor, but is possible for smaller COBOL shops. A more tactical approach may be to upgrade a subset. This could include:
- Mission-critical programs. These are the lifeblood of your organization.
- Line of business applications. An insurance company might upgrade its claims management system and upgrade. This moves an entire application at once, isolates IT disruption, and builds expertise for other departments to leverage.
- Programs that can be upgraded simultaneously with application maintenance. This minimizes staff impact but could take years. If there are issues with running mission-critical applications on an unsupported version of the compiler, it may not be a good option.
- Number-crunching applications. Version 6 changes how COBOL handles numerically defined items. This may cause issues in these applications.
- Programs that talk to other vendor packages. These include MQ Series or external sources, programs that talk to the assembler, or older COBOL programs, like those that were compiled with VS COBOL II or COBOL 85.
It’s key to learn about each approach to ensure everything is done right before putting code into production.
A Brief Look at the Upgrade Itself
Upgrading applications to Version 6 requires addressing two issues:
- Finding verbs or parameters that need to be modified, particularly numeric data elements. Developers previously used loopholes in coding, and those loopholes got sacrificed for performance. Forecross Consulting uses automation tools to find those statements.
- Testing in a robust manner that finds isolated errors. It’s impossible to discover those errors without running real data through the program, especially data from unformatted sources like web input or external data feeds.
The Pilot Test: Key Takeaways
A pilot test helps develop and validate a methodology for quickly and accurately migrating several COBOL programs to Version 6.
The idea is to build the test environment, run a representative sample of 75 to 150 programs through it, compare outputs between the production and test environments, then use that feedback to build a recipe for the full migration.
This pilot comes with minimal risk. Nothing goes into production. The testing environment is mirrored from production and runs the same inputs, database, and files then captures the output for comparison. Once again, the key is to use automation, because the syntactic changes to code and the testing are mechanical and largely repeatable.
Some Considerations Around Testing
The biggest challenges for testing are highly integrated databases that support numerous applications. Backups and restores are no big deal for small applications and granular databases, but larger ones require a different technique.
It is critical that the databases and data used in testing are robust and of sufficient volume to trigger the issues Version 6 trips up on. Forecross again uses automation tooling for comparison of the log to give a full picture of the database and help deal with large volumes.
The readiness of the dev test/QA environment, both hardware and supportive tooling, is another thing to consider. This environment lacks the resources of the full production environment.
The Last Word: Insights From A Current Migration
Forecross recently conducted a project with five compiling environments including batch, Db2, CICS, etc. The project assessed more than 14,000 programs and compiled about 13,700 of them, which took 90 seconds per program, on average. Forecross didn’t create load modules or other components, so there was no impact on the development machine. The project used the client’s JCL and procedures, which helps the client eventually handle upgrades themselves.
Out of nearly 14,000 programs, there were 153,000 warnings and only 1,600 programs with no compiler errors. The point is not to be shocked by those large numbers. One mistake around a copy book can generate hundreds of errors.
Syntax issues were found in 311 programs. A few other issues included having data defined but not initialized either in definition or procedurally. Version 6 no longer initializes working storage. Now you get whatever was in memory when the program loaded, which could cause unpredictable results.
These are examples of the issues a migration assessment and testing uncovers. IBM reports that about 25% of migrating customers encounter problems due to the program processing invalid data at run time, a result of the change in numeric data. This reinforces the idea that testing must be done thoroughly.
Want to learn more about the migration process? We’re here to help.
