After you’ve migrated your COBOL programs to COBOL Version 5.2 or 6.1, it’s time to begin an initial rollout. As always, be sure to refer to the IBM Migration Guide. Following those guidelines will generally make the migration go more smoothly.

Before you roll out your COBOL Version 5.2 or 6.1 programs, set up some comparative testing. Run the data from the previous COBOL release you were using. Later, when you run your new programs, you can compare them to the old programs. This will help you quantify the benefits of migrating to the new release to business leaders. Every machine cycle saved allows other applications to use those saved cycles for better performance.

Rolling Out Your Programs

Begin your initial COBOL Version 5.2 or 6.1 rollout with one business application and document the migration process. This will serve as a template for subsequent rollouts. During and after the initial rollout, seek feedback that will help you inform other business units on the success and encountered issues of the rollout. Discovering issues early on will make it easier to correct them and adjust your template for later rollouts.

After the initial COBOL Version 5.2 or 6.1 rollout, go back to that comparative testing we talked about for an early idea of potential savings. See what worked and prepare to move forward, but don’t begin rolling out everything.

Only convert those applications that can benefit from the new versions of COBOL. Start with your highly arithmetic, floating-point or complex mathematical applications. These application types will take advantage of the z architecture of COBOL Versions 5.2 and 6.1 and will benefit from higher levels of optimization. If applications do not take advantage of the z architecture extensions, or would not benefit from higher levels of optimization, you should leave them in their current versions of COBOL.

As a side note, for sites with 24/7 CICS regions, replacing PDS with PDSE won’t be easy. What you can do is dynamically insert program objects ahead of your load libraries in the CICS RPL. This will provide a way for you to take advantage of new COBOL Version 5.2 and 6.1 programs for CICS.

Continue this COBOL Version 5.2 or 6.1 rollout path, releasing programs that will benefit from the new COBOL version you’ve decided to go with and testing those against their previous versions to calculate savings.

Reviewing Your COBOL Migration Strategy

Before you roll out, it may be useful to go back and review the steps that you’ve taken. For your convenience, here is a list of things to note, compiled from past blog posts on the subject:

1. 1. Don’t convert your COBOL programs to Java. This requires sacrificing efficiency for cost saving, and the cost saving you generate will be short-lived and evolve into a series of long-term pitfalls costing you more money.

1. 1. The first step in a COBOL Version 5.2 or 6.1 migration strategy is roadmap planning. You need to understand your current programs, consider some potentially problematic areas you could happen upon when migrating them, understand your hardware machines, and determine which version of COBOL you’re going to migrate to (there’s an explanation for why you have a choice).

1. 1. If you have a choice between COBOL versions, which is better? Starting at COBOL Version 6.1 eliminates duplicate compiler upgrades twice, once to 5.2 and again to 6.1. However, by migrating to COBOL Version 5.2 first, you can save costs by leveraging the IBM Enterprise COBOL trials for both 5.2 and 6.1 to gain maximum experience and application comfort before making a formal decision to upgrade.

1. 1. A large percentage of these migration problems are data related, so thorough testing is crucial to discovering them. The testing you do now will save you from countless hours of debugging, potentially losing revenue and disappointing your customers.

1. There are several types of performance optimization available in COBOL Versions 5.2 and 6.1, but you may need some guidance on how to identify and use these new COBOL optimization features.

Digital business is driving more mainframe activity. Mainframe shops should optimize their programs so they perform well against the modern demands they face from new and growing digital engagement. The best way to optimize your COBOL programs is to migrate them to COBOL Version 5.2 or 6.1. Good luck along your journey.

You’ve tested and debugged your COBOL programs, now it’s time to optimize them. In this post, we’ll provide an overview of the types of performance optimization available in COBOL Versions 5 and 6, as well as direct you how to identify and use these new COBOL optimization features.

IBM COBOL Versions 5 and 6 have provided more than a few types of optimization to date, and more are likely to arrive in future releases and through on-stream COBOL maintenance. It’s important, however, to provide a measurement of your gains using a performance profiler like Compuware Strobe.

It’s imperative to provide application performance baselines before and after optimization so capacity and performance specialists can get the data they need. This data can provide future guidance for your applications and be significant to reducing your 4HRA costs.

Implementation Hints and COBOL Optimization Opportunities

Before you start looking for big optimization opportunities, start small. Run with OPT(0) to flush any data format problems, then move to OPT(1) or OPT(2). Make sure you test for accurate results at each optimization level, as some bugs have appeared only with higher OPT levels.

When you’re ready to search out optimization opportunities, here’s what IBM has been focused on:

• PERFORM statements that can be eliminated, made more efficient by “block reordering” or replaced with more efficient inline code. These optimization processes are especially helpful if the PERFORMs are frequently called because it removes subroutine calls, which add overhead, especially if they’re called repetitively.
• COMPUTE statements, especially anywhere significant arithmetic is involved. This moves arithmetic to higher-performing, newer instructions, such as SIMD. Decimal arithmetic can be exceptionally fast using the newer DFP features on newer z Systems hardware, z9 and higher. Conversions to and from DECIMAL were especially slow on COBOL Version 4 and below. The new DFP conversion instructions (CONVERT FROM/TO PACKED) on the z13 accelerate a COBOL “DIVIDE A BY B GIVING C.”

There are also compile options available during testing that help programmers identify issues that would affect application optimization:

• RULES(NOLAXPERF) will issue warnings for inefficient coding practices, as well as compiler options that can impact performance.
• NUMPROC(PFD) can significantly improve decimal and zone-decimal processing; however, the data must adhere to specific IBM system standards (refer to the IBM programming guide for more information).

Areas of Greatest Return

There are significant areas of improvement in COBOL Versions 5 and 6 and in hardware systems that that could accelerate your COBOL programs.

Binary Floating Point (BFP)

COBOL Versions 5 and 6 have significant performance improvements when optimizing PERFORM statements and anywhere there’s significant arithmetic. Version 5 will use all 16 BFP registers. Older COBOL versions used only the original four BFP registers. Using register arithmetic is faster than using memory and swapping to/from registers. Having 12 more BFP registers increases register use, keeps memory use at a minimum and helps optimize hardware cache use.

Vector Registers

The z13 Systems introduced vector register instructions, enabling COBOL to use the z13 single instruction, multiple data (SIMD) features to help arithmetic performance. There are 32 vector registers on the z13 and there is a movement to use more SIMD instructions to further performance gains, according to IBM Systems Magazine. In his SHARE presentation, Tom Ross described how the z13 instructions accelerate COBOL arithmetic calculations, including integer and floating point computations, and string manipulations like string search and string comparisons.

Decimal Floating Point (DFP)

Another significant area of improvement involves decimal arithmetic acceleration using the DFP feature on the newer machines. DFP was implemented starting with the z9 Systems and enhanced for each successive machine (five total) through the z13. PACKED-DECIMAL data in your COBOL programs could easily benefit and be especially quick for complex calculations.

Conversions to and from decimal and other data formats could be accelerated with DFP conversion instructions, too. IBM has shown that replacing decimal conversion instructions generated by the COBOL Version 4.2 compiler could be many times faster by just using the newer DFP conversion instructions. Elimination of conversions that usually involve the use of common subroutine calls with in-line DFP instructions can reduce CPU usage and increase performance.

Single Instruction, Multiple Data (SIMD)

A final area of great return, the SIMD feature on the z13 Systems can be exploited by COBOL Version 5.2 and 6.1. Functions like INSPECT TALLYING or the REPLACING statement can benefit. We’ll probably see future COBOL versions exploit more SIMD features.

Keeping Hardware and Software Up-to-Date

COBOL has just started with optimization and use of new features on the newer machines. You’ll definitely see those advantages appear in newer releases of COBOL. This fact makes it imperative to keep your software and hardware up to date. This list is not in any way complete, but types of optimization that we’ve encountered include:

• Statement deletion: Some COBOL statements are just gone, and if your debugging tool isn’t enabled, you’ll have problems.
• In-lining: Instead of calling a subroutine/function as the COBOL code implies, optimization could instead insert the code in the COBOL stream. You’ll see no subroutine/function call.
• Arithmetic type substitution: This is an equivalent way to perform the calculation. Use of DFP on all z Systems machines and use of SIMD on z13 are common COBOL Version 5 and 6 techniques to accelerate arithmetic computations.

Hardware provides the features but you can’t take advantage unless you keep your software up to date. Plan a regimen to update both hardware and software. Updating the hardware but not the software will likely lead to discussions around ROI as your optimization benefits decrease. Keep statistics and measure with the proper tools. You’ll need to show progress and that will keep the skeptical ROI discussions to a minimum.

It’s inevitable you will encounter challenges when migrating to COBOL Version 5.2 or 6.1. They don’t preclude the benefits of migrating, but they exist. According to IBM, a large percentage of these migration problems are data related, so thorough testing is crucial to discovering them. The testing you do now will save you from countless hours of debugging, potentially losing revenue and disappointing your customers.

Keep in mind there are changes to COBOL Versions 5.2 and 6.1 that affect how debuggers operate, so your toolset must support those changes. There are some small external changes to the 5.2 and 6.1 languages that COBOL programmers deal with every day; however, the internal changes are more extensive.

The “back-end” of COBOL Versions 5.2 and 6.1 has radically changed and keeps changing, even daily. It’s imperative to use a toolset that both is enabled to and can continuously deliver support for frequent changes made to these new versions.

Here are some best practices to follow to properly test and debug COBOL programs you’re migrating:

1. Prepare Your Testing Environment

Brush off your testing suites and introduce a strict regimen for testing. As you move through your applications, you’ll become more experienced and will encounter problems that are familiar and repeatable. Categorize the problems you find and build a test suite that finds those common problems related to both data and poor coding practices. Likewise, optimize your testing by ensuring you have the latest IBM compiler and Language Environment maintenance up to date. Refer to the IBM COBOL fix list for this information. A systematic plan must be adopted to keep the compiler and Language Environment update to date with monthly fixes. Testing with outdated maintenance would be wasted time and effort.

2. Fix Your COBOL Programs

Before you start nonchalantly migrating COBOL programs, you should analyze each one and determine where fixing is required. Our colleague Glenn Everitt wrote about the importance of this a while back. His conclusion: if you neglect fixing your COBOL programs early on, your migration efforts will be more difficult than you can imagine. We agree. When testing each application lined up for migration, verify that each provides the correct results, performs according specifications and scales to expected norms. Remove all exceptions and abend conditions too.

3. Start Unit Testing

Unit testing of mainframe applications is also important. This process allows developers to test the small parts of an application to find and fix low-level bugs before moving into testing processes that involve larger parts.

However, unit testing is one of the weakest spots in the mainframe development life cycle. Because it’s a tedious manual process that sucks time and energy away from other development tasks, which must be accomplished for code to move forward, unit testing often disregarded or left incomplete.

Fortunately, the dearth of unit testing in mainframe environments is gradually changing with the advent of automated unit testing tools that allow developers to:

• Validate code changes immediately
• Eliminate dependency on specialized mainframe knowledge
• Automatically collect and keep test data with unit tests using tools like Compuware
• Automatically generate unit tests and test assets

Automated unit testing makes it easier to deliver quality with velocity.

The idea of automation and testing applies to migrating your programs to COBOL Versions 5.2 or 6.1 too. Unit testing would ensure program quality early on, preventing future migration issues, and automation would accelerate that testing in the already time-consuming migration process.

4. Invest in Source Debuggers

As mentioned earlier, changes to COBOL Versions 5.2 and 6.1 affect how debuggers operate, so you should invest in source debuggers that support these newer versions. Modern debuggers provide the best experience and direct access to data from the COBOL programmer perspective. Avoid using a source tool unintended for 5.2 and 6.1. That’s like stepping through machine code and will severely hinder debugging. We’ve worked with many customers to successfully migrate their applications to COBOL Versions 5.2 and 6.1 using a variety of Compuware’s application debugging, fault and failure management, and performance analysis tools, including:

• Xpediter for visual, interactive debugging, even if programs are compiled OPT(2)
• Abend-AID for abend analysis of 5.2 and 6.1 programs, including optimized programs
• Strobe for profiling of 5.2 and 6.1 programs, including optimized programs

5. Utilize Compile Options

Utilizing compile options will help you identify testing issues prior to moving programs into production. There are several compile options that may be beneficial to identifying issues in tests, but these are the core options worth noting:

• • SSRANGE identifies out-of-range table issues, generating an IGZ006S message when an index or subscript points to storage beyond the bounds of a table. The use of SSRANGE should be restricted to testing, as IBM has indicated it can increase CPU time by an average of 18 percent.

• • ZONECHECK either generates warnings or causes a program to abend if the zone bits are not numeric. It will insert IF NUMERIC class tests in front of any zoned decimal variables acting as sending fields.

• • DIAGTRUNC generates warning messages during the compilation to alert the programmer that, during a move statement, the receiving numeric variable contains fewer integers than the sending field. This can help ensure truncation will not create an issue.

• • RULES(NOEVENPACK) generates a warning message when the packed data contains an even number of digits. According to the Enterprise COBOL for z/OS Programmer Guide V5.2 (or V6.1), packed data should always have an odd number of digits to prevent truncated data. However, systems programmers can change the warning message to an error, forcing a coding change.

• RULES(NOLAXPERF) will issue warnings for inefficient coding practices, as well as compiler options that can impact performance.

Ensuring you properly test and debug COBOL programs early in the process will prevent bigger issues from inhibiting your progress through the ensuing steps of a migration. The benefits will be noticeable in the next phase of your plan, application optimization.

Converting COBOL programs to Java can create a multitude of problems, including performance issues. Migrating to a newer version of COBOL can yield desired reductions in CPU costs without the headaches caused by migration to Java. In this post we’ll discuss the difference between COBOL Version 5.2 and 6.1 to help you determine which release you should migrate to first.

To start, let’s look at some fundamental differences between COBOL Version 5.2 and 6.1. Per IBM’s announcement of COBOL Version 5.2, the upgrade included new and improved features such as:

• Support for the new IBM z13 hardware
• New, restored and enhanced compiler options for ease of migration and programmer productivity
• New features added from the ISO 2002 COBOL Standard
• New IBM extensions to COBOL
• Product-related enhancements

However, more improvements and features were added in the release of COBOL Version 6.1, including:

• Increased compiler capacity
  This provides a new “back end” that converts the intermediate form of a program to machine code. It resolves problems in previous COBOL versions that failed to compile very large COBOL programs. Large programs are typically those that used “code generators.” These code generators spew out a lot of code and use a lot of CPU and memory resources. The IBM “back end” for COBOL Version 6.1 uses 64-bit storage to overcome this problem. You may use more CPU to compile a program with 6.1 than with 4.2, but if you run the program several times a day, you will end up using far less CPU during run-time.

• New COBOL language features
  More new language features were added from the ISO 2002 COBOL Standard, introducing the use of ALLOCATE, FREE and INITIALIZE statements.

• New and enhanced compiler options
  These new options ease migration and improve programmer productivity, but to implement some of them, you may have to consider how they’re to be used and when to use them properly. For example:
  • VSAMOPENFS allows compatibility with “file status 97” in pre-COBOL Version 6 programs
  • SUPPRESS/NOSUPPRESS allow debuggers to use the copybook information in the listing
  • SSRANGE sub option enhances range checking for subscripts, reference modifications group ranges and indexes at run time
  • Diagnostic message for ZONECHECK(MSG) compiler option assists the detection of invalid zoned decimal data items
  • LVLOPTION was replaced by a seven-character build level identifier in the format PYYMMDD to the compiler listing header

• Runtime and product-related enhancements
  For RENT compiled programs, WORKING-STORAGE will be acquired from HEAP storage and will be initialized at the COBOL program call and not when the program object was loaded. This can help applications by:
  • Freeing storage below the 16MB line and using storage in the HEAP
  • Reducing storage usage and performance tuning in Table SORT
  • Improving performance for INSPECT, UNSTRING, SEARCH ALL (exploiting z13 features such as SIMD)

Which Version Is Better?

To reiterate the final thought from our last post, migration to both COBOL Version 5.2 and 6.1 is a smart idea. It’s true that starting at COBOL Version 6.1 eliminates duplicate compiler upgrades twice, once to 5.2 and again to 6.1. However, by migrating to COBOL Version 5.2 first, you can save costs by leveraging the IBM Enterprise COBOL trials for both 5.2 and 6.1 to gain maximum experience and application comfort before making a formal decision to upgrade. There will not be any Single Version Charging (SVC) changes during these trial periods. Consult the IBM announcement letter Enterprise COBOL Developer Trial for z/OS, V6.1 for more details.

Keep in mind COBOL Version 5 can be ordered until September 2017, so you have a limited time to take advantage of the benefits from migrating to this version. Also, consider that COBOL Version 5.1 doesn’t support the z13 and 5.2 is the recommended first choice for the first migration phase because it provides XML compatibility with the Enterprise COBOL Version 3 parser.

Be sure to use ZONECHECK and ZONEDATA to identify “improperly formatted data fields.” It has been said that many migration problems are data related. Data that was accepted as valid (or not detected as invalid) by Enterprise COBOL Version 4.2 and earlier could now be invalid with COBOL Version 5.2 and 6.1.

And, of course, spend some time reading through the migration guides for each version to get a better sense of where you’re going:

• Enterprise COBOL V6.1 for z/OS Migration Guide
• How to take advantage of the new Enterprise COBOL V5/V6 compilers – Migration!
• Migration recommendations to Enterprise COBOL V5 and V6

Performing a Migration

The following steps and, admittedly very technical, information should help guide you on your migration journey.

1. 1. Prepare to Migrate
      To prepare for a migration to the latest version of COBOL, consider whether you have programs that were last compiled under OS/VS COBOL, or COBOL V2. You need to upgrade the code to Enterprise COBOL 4.2 before migrating to anything higher. Add FLAGMIG4 and FLAG(I,I) to identify necessary coding changes. Next, determine what programs you want to upgrade. Focus on applications that consume CPU resources as candidates to convert first. Note that migration to PDSEs is required. Try to do that when you are at Enterprise COBOL V4.2. Also, note there will be more work datasets required during compile time.

1. 1. Brace for Compile Time “Shocks”
      There are a few “shocks” to brace for. Compile time CPU usage will rise five to 15 times its current volume, depending on the optimization level. Meanwhile, compile time memory usage will rise upwards of 20 times its current level. IBM requires the region size of the compile step to be a minimum of 200MB. Many shops are having to utilize a default size of 500MB or 0M because of the amount of storage required for optimization.

1. 1. Find Invalid COBOL Data
      Invalid COBOL data must be found using repetitive testing during the migration process. This data generally cannot be found using a compiler feature or option, but programmatically can be found using COBOL statements such as IF NUMERIC. You can use compiler options such as SSRANGE to flush out the problems during testing.

1. 1. Stay Up to Date
      Keep the service updates for the compiler and LE up to date. Several PTFs are resolved nearly every month. Refer to the IBM COBOL Fix list web page for this information.

1. 1. Learn and Watch for Pitfalls
      As usual, there are a few pitfalls to watch for. It’s important to learn from what others have gone through. Refer to literature and bug lists on the above-mentioned fix list web page. Also, make sure you repetitively resolve problems in each of your applications. It will get easier for later migrations as you build a comprehensive list of common errors in your codebase.

1. Understand the Impact of New Compile Options
   When compiling, adding new compile time options will help quantify the impact. IBM recommends compiling with SSRANGE, ZONECHECK and OPT(0) to flush out all table misuse and invalid data, and recompiling with NOSSRANGE, NOZONECHECK and OPT(2) for QA and production.
   • SSRANGE can average as much as 18 percent more CPU.
   • ZONECHECK will add an IF NUMERIC before any numeric statements, which also will increase the CPU time of the run.
     • SSRANGE, ZONECHECKS and other options will definitely speed up the ability to clean up bad zone bits.
     • Compile with NUMPROC(PFD), which is more efficient.
   • ZONEDATA will confirm the zoned part of decimal data is valid and provide compatibility with prior COBOL Version 6.1 compiler behavior.
   • RULES will cause the compiler to issue warning messages when detecting non-standard or poor coding practices that were tolerated prior to COBOL Version 6.1. Systems personnel can change the warning to an error to force changes.

Deciding which COBOL release you want to migrate to first and then following through with a stable migration requires a well-researched and carefully considered plan. As you begin migrating your COBOL applications, testing and properly debugging early in the process are also vital to avoiding future problems.

Today, digital business is driving more mainframe activity, according to a survey from BMC. Instead of sacrificing application performance to save a little cash, you should optimize your mainframe programs so they perform well against the modern demands they face from new and growing digital engagement.

The best way to optimize your COBOL programs is to migrate them to the latest version of COBOL, spanning COBOL Version 5 and 6. The first part of that strategy involves roadmap planning.

First Steps Migrating to the Latest Version of COBOL

There are a few first steps you need to take before beginning a migration to the latest version of COBOL:

1. Read the Migration Guide for the COBOL release you will be upgrading to.

The correct guide can be found via the IBM Enterprise COBOL for z/OS documentation library. It will provide the cautionary points pertinent to your migration, but up front, there are a few to consider, including:

• Source language incompatibilities when migrating from OS/VS COBOL and VS COBOL II to any newer COBOL version
• Data problems undetected by the compiler must be found by repetitive testing (some helpful compiler options: SSRANGE, RULES and DIAGTRUNC).
• JCL, REGION size and more work datasets are required (there are major changes to REGION size)
• Some compiler options have been removed, such as NUMPROC(MIG) (refer to your Migration Guide for a complete list)
• Executables must be in PDSE libraries
• OS/VS COBOL or VS COBOL II programs should be upgraded to COBOL 4.2 before recompiling with COBOL Version 5 or Version 6

2. Determine a business application to serve as the template for upgrading others.

A suggested approach is to use a business application that has encountered elongated run times to see the potential impact of recompiling problematic code under COBOL Version 5 or 6. You don’t have to recompile every program, just those you think might benefit from the new compiler and advanced optimization. Use mainframe profiling tools to set a performance baseline before you start. For example, Compuware Strobe, our application performance monitoring and analysis tool, can capture the information for later use.

3. Analyze the load library modules to determine the release of COBOL the business application was last compiled under.

When going about this, refer to your Migration Guide to learn about changes that may be necessary to make within the code for those modules compiled in earlier versions of COBOL. There may also be compile options that have been deleted, have changed in function or offer new options. Portfolio Analyzer—accessed via the Library Utility (3.1) of Compuware File-AID file and data management tool—allows you to view and export COBOL and PL/I compiler options for all releases to a .CSV file for later analysis.

In addition to these steps, there are other preliminaries that will ease the migration execution, including learning from your own and others’ mistakes and making sure you understand your hardware machines.

Learning from Mistakes

Although migrating older COBOL programs to the latest version of COBOL presents fewer pitfalls than converting them to Java, you should still consider potential hazards that may crop up along the journey.

For one, there’s a chance you could take on too much at one time. It’s best to stick to a small application or set of applications to start, as mentioned in point two above. You can learn from that experience, and apply your new understanding to other application migrations to prevent recurring missteps.

Also, avoid making assumptions about programs before migrating them. Do some analysis up front. You need facts about the programs that help you understand their composition and behavior to make good determinations that help you prevent problems and avoid creating them.

Know Your Hardware Machines: ARCH and OPT

It’s important to understand some background information on COBOL and how various versions affect performance. The type of COBOL version has a significant effect on how you migrate the application.

From the language perspective, COBOL has been upgraded many times—OS/VS COBOL with features of the ANSI 74 standard, VS COBOL II with features of the COBOL 85 standard, COBOL Version 5 had elements of ISO standard 2002 and a future COBOL version may have elements of a newer standard.

But from the performance perspective, one of the past knocks against COBOL was its failure to take advantage of the newest processor hardware machines. IBM mainframe customers bought huge new machines and COBOL didn’t use any of the newest features.

This meant all COBOL versions, from VS COBOL II (1985) through Enterprise COBOL Version 4.2 (2009), used the same back end and generated the same code. Hence, over the course of 25 years, the same older and less efficient code continued to be generated for COBOL and didn’t use any of the new features introduced on the z Systems machines, starting with the z900/800 (CY2000).

Fortunately, this changed with COBOL Version 5.1. All levels of COBOL starting with Version 5.1 are designed to take advantage of the newest machine hardware. Newer hardware machines have features that, if used, tend to offload work to the hardware, reducing CPU consumption and enabling them to run more efficiently.

The COBOL ARCH compile time option controls these features. ARCH(6) is for the z990/890 systems all the way up until z13, which uses ARCH(11). Likewise, the COBOL OPT compile time option controls how complex, and potentially more efficient, of an optimization to generate. OPT(0) is the minimum optimization level and OPT(2) level is the maximum (OPT(0) does not mean “none,” rather “some minimal amount”). Higher ARCH levels tend to generate more use of the newest machine features, while higher OPT levels tend to create more efficient optimizations.

All COBOL versions default to OPT(0). COBOL Version 5.1 defaults to ARCH(6), a z990/z890 code base. (Note: COBOL Version 5.1 doesn’t support ARCH(11), a z13, and programs compiled with ARCH(10) will run on a z13, but will not generate code that exists only on a z13.) COBOL Version 5.2 and 6.1 default to ARCH(7), a z9 code base. However, all COBOL versions allow customers to change the defaults.

Still, a critical concern is the need to set a standard: the highest ARCH level of any COBOL compile should be set to the lowest ARCH level of any machine in your enterprise. For example, if your enterprise consists of a z10, a z11 and a z12, setting the default to ARCH(8) will allow that program to run on the z11 and z12 without problems. However, setting the default to ARCH(10) will cause problems if a program is subsequently run on a z10.

Disaster site hardware is also of special concern, as disaster sites may be at a different ARCH machine level than your production machines. In the previous example, if the disaster site has a z9, you will have problems at the site, as there is the potential for hardware instructions to be generated for an ARCH type higher than your disaster recovery machine.

Determine the Latest Version of COBOL You’re Migrating to

After these initial preparatory steps, you should begin thinking about where you want to go: COBOL Version 5.2 or 6.1. In our opinion, you should first try migrating to 5.2 to maximize experience and eliminate bugs through a couple of test sets.

Although there is no technical reason to start a migration at COBOL Version 5.2 and then jump to 6.1, customers need to determine what’s right for their environment. Consider this:

• Starting at COBOL Version 6.1 eliminates duplicate compiler upgrades twice, once to 5.2 and again to 6.1. However…
• You can save costs by leveraging the IBM Enterprise COBOL trials for both COBOL Version 5.2 and 6.1 to gain maximum experience and application comfort before making a formal decision to upgrade. There will not be any Single Version Charging (SVC) changes during these trial periods. Consult the IBM announcement letter Enterprise COBOL Developer Trial for z/OS, V6.1 for more details.

There are a number of COBOL migration strategies an organization can choose from when contemplating the best avenue for upgrading their mainframe environment to the next generation version of COBOL, which spans COBOL 5.1 to 6.1.

But irrespective of which migration strategy an organization selects, it must keep in mind the array of new features, new functionality and new constraints associated with the next-generation version of COBOL.

Beginning in 2013, IBM introduced radical changes to COBOL with the Version 5.1 upgrade. Subsequently, there are a number of options the next-generation version of COBOL has deleted, changed or added, and release-by-release there are additional constraints.

Mainframe shops can improve COBOL migration strategies amidst these changes using modern mainframe tools like application failure resolution and fault management, as well as file and data management, that provide utilities to:

• Analyze your program load libraries to generate a report citing the language release and compiler options
• Provide an enhanced compiler listing showing the offset of every variable in working storage from the start of the static map, not just the offset within each group level
• Analyze your program load libraries to identify applications that would benefit the most by recompiling to the next-generation version of COBOL

According to IBM, performance improvements with the next-generation version of COBOL can be between 10-20 percent. But despite the availability, many mainframe shops are unaware modern tools contain improved functionality for aiding COBOL migration strategies and achieving improved performance.

Modernized mainframe tools providing this functionality can improve COBOL migration strategies organizations use by elucidating the hidden compile track records of older programs, enabling organizations to understand at a deeper level how to migrate programs to the next-generation version of COBOL.

How Modern Tools Improve COBOL Migration Strategies for Older Programs

When moving to the next-generation version of COBOL, organizations need to take into account older programs first. Older programs have the greatest possibility for requiring changes to align with the next-generation version of COBOL, usually with regard to recompilation or coding changes. But adjusting these programs is not a straightforward process. For example:

• Load libraries are no longer used. Programs are bound into PDSE objects. IBM recommends converting to PDSEs as soon as possible.
• Converting applications to use PDSE object libraries is tough. IBM recommends moving to PDSEs prior to migrating to a the next-generation version of COBOL. At sites, where CICS environments are up 24/7, this can be a daunting task. (There are ways to work around this, utilizing both PDS load libraries and PDSE object libraries, until you are able to do the conversion from PDS to PDSE.)
• You can’t use PDS load libraries for programs compiled with COBOL 5 or 6. Program objects are generated by the binder into PDSE object libraries. If you try to bind a next-generation version COBOL program into a PDS, the binder will generate an error.

One of the most pressing issues mainframe shops share is the absence of a utility for reading a PDS and a PDSE, and for showing the release of COBOL and compile options. But a utility specifically designed for this is important for organizations performing COBOL migration strategies because it enables organizations to have to keep track of when a program was compiled.

To improve the efficiency and ease of COBOL migration strategies, organizations require—online or through batch—the ability to generate a report where it would read an entire PDS or PDSE and generate a report on every member in the load libraries or the program object library that would contain the release of COBOL, Assembler or PL/1.

In the case of COBOL, a tool with functionality like this not only should include all of the compile options for the mainline module, but also if there are any statically linked CSECTS that those would be the compile options and the release of COBOL would be listed there as well. This is especially important in CICS, as IBM states in their Migration guide that programs compiled under OS/VS COBOL will not function properly under COBOL 5 or 6.

Neglecting Modernized Mainframe Tools for Improving COBOL Migration Strategies

Due to the complications involved, IBM gives clients one year free of the next-generation version of COBOL so they have time to convert their site to the latest release; however, many organizations are discovering the migration takes longer than the grace period lasts. Consequently, organizations are paying IBM for multiple versions of COBOL. (Cheryl Watson, of Watson and Walker, has recommended several times in her presentations at SHARE that if you feel you need more time, try to negotiate with IBM. Negotiating has worked with a number of clients.)

In view of radical changes being made to COBOL and the time limit pressing down on organizations, they must be shrewd in their COBOL migration strategies, making sure to cover all of their bases by selecting the appropriate strategy and improving that process through the adoption of specialized modern tools.