Tips for a Smooth COBOL 5.1 Migration
[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]
Some mainframe sites have already initiated projects to migrate to IBM COBOL 5.1 in hopes of reaping the millions of dollars in CPU savings that come along with the compiler, the first to truly exploit the System z architecture. Other sites are deep into research projects to scope both the effort and the benefits of this migration.
For the practitioners charged with these migration tasks, this is one of those classic first-do-no-harm projects. There are significant benefits to be had but care must be taken not to introduce problems where there previously weren’t any. You certainly don’t want to be halfway through and begin asking yourself, “Why me, why now?”
Compuware has been privileged to be in conversations with our customers about these migration projects. Here are points—some obvious, some subtle—that seem to come up time and time again:
- Plan your work. Break the migration into as many small and discrete steps as possible. Some sites are following the IBM Migration Guide recommendation and migrating programs as they come up for changes. Others are taking a more aggressive approach and looking at application by application migration. The big thing here is consistency across the organization, so when you find yourself in the elevator with the CIO you can give a quick, understandable status.
- Everybody loves a winner. That being said, it would also be very nice to get a major success under your belt as quickly as possible. Not only will it help keep the migration teams motivated, but it will also help to remind management of the benefits of this initiative. Have a DB2 Stored Procedure that gets pounded? Or maybe a CICS application that is tied to your Web site or your mobile apps? Or, possibly a batch job that is consistently showing up in your rolling four hour average used in determining Variable Work Load Charges? Go get ‘em.
- Certain steps just take longer. It’s interesting that the conversion from PDS to PDSE libraries has proven to be a stumbling block at many sites. It could just be changing production JCL is an intimidating proposition! You might want to cook that into your project plan. And don’t forget to over-allocate those PDSE libraries—object modules in COBOL 5.1 are bigger, sometimes much bigger.
- Expect the 80-20 rule. You won’t be very deep into this process when you realize it’s the exceptions that will chew up the most time. Chief among these are programs compiled with very old COBOL compilers (like VS COBOL II). COBOL 5.1 interoperability with older COBOLs comes with a set of caveats; it might be as simple as recompiling those old programs but it might require coding changes as well. It’s also very likely that you have a set of programs that are used across applications; you’ll have to decide when/where to convert those. Finally, kudos to IBM for bending over backwards to help when possible—like relieving the AMODE(24) and the COBOL XML Parser restrictions.
- Unintended consequences. COBOL 5.1 is revolutionary and you should be aware of differences it has introduced. One example is the compile option SSRANGE. It can be invaluable in detecting storage overlays and some sites have taken to compiling with it on in production (and then turning it off via run time options). You can no longer turn it off with run-time options with the new COBOL. A handful of programs with SSRANGE on could quickly eat up any CPU savings brought about by COBOL 5.1.
- Unplanned benefits. This project is guaranteed to touch your Source Control Management (SCM) processes, perhaps ones that haven’t been changed in years. While you’re in there you might consider modernizing that process. For instance some simple changes might reap rewards as you begin to hire next generation COBOL programmers. (I know Compuware would love to talk to you about this.) Another benefit to give some thought to: are you exploiting your zIIPs and zAAPs? Maybe now’s the time. If not now, when?
With this release, COBOL finally exploits hardware innovations IBM has rolled into the System z architecture and has taken code optimization to a new level. Moving to COBOL 5.1 can result in substantial savings and invigorate your mainframe commitment now and into the future. Let’s do it!
Latest posts by James Liebert (see all)
- Failure Ain’t Nothing but a Learning Thing: An Agile Perspective - December 5, 2017
- DevOps and the Mainframe: The Ultimate Win-win - August 29, 2017
- How Do You Define DevOps? Six Interpretations to Help - June 29, 2017