COBOL doesn’t usually make headlines, but it was put in the hotseat when coronavirus created skyrocketing unemployment claims in states including Connecticut, Kansas, and New Jersey. While politicians and pundits were quick to blame the “outdated” programming language, “COBOL Cowboys” founder Bill Hinshaw pointed out that COBOL still reliably runs 95% of all ATM transactions, and the failure lays with the states for failing to properly maintain their backend systems.
COBOL continues to move steadily into the future, and one of the most recent steps was taken when IBM announced the end of support (EOS) dates for Enterprise COBOL 4.2, Enterprise COBOL 5.1, and Enterprise COBOL 5.2 more than a year ago, which means deadlines are looming. In fact, the time for COBOL 5 has come and gone. While code compiled using the outdated versions will continue to run, organizations will no longer have access to support tools such as Problem Management Reports (PMRs) or Authorized Program Analysis Reports (APARs). It’s like landing an airplane without the control tower’s help—it will almost always turn out okay, but that one exception can have devastating consequences.
If your organization relies on COBOL 4, you still have to make the migration to COBOL 6. If that’s a relief, it shouldn’t be. The extended support period compared to COBOL 5 reflects the difficulty of the upgrade. Particularly if your organization is currently running large, complex applications, successfully navigating the migration process should be your highest priority. You’re going to need all the time you can get.
Compiling on COBOL 6
COBOL 6 has some big advantages over older versions such as 4.2 and 5.1. In particular, it’s designed around new compiling instructions that take advantage of the latest mainframe hardware from the z13 onward like 64-bit registers. It delivers a set of features that mainframe users have been requesting for quite some time, improving speed despite the physical limitations that CMOS chipsets appear to have run into. COBOL 6 can also perform much more in-depth optimizations than its predecessors, improving application performance and stability and delivering additional value to the end-user. Of course, there’s no such thing as a free lunch, and all these improvements come at a cost.
Upgrading to COBOL 6 means recompiling every program on your organization’s roster that is currently in production. And that’s if you even know what’s in production, considering you might have COBOL programs dating to the 1960s. That process will take time and money, and you shouldn’t use COBOL 4.2 compiling times as an estimate. Even at OPT(0), the base level of optimization on COBOL 6, compiling time will take longer than it would on 4.2. Increase to OPT(1) and you’re looking at a significant difference.
Our own testing reveals that small programs made up of around 5,500 lines of code will take 32 times longer to compile on COBOL 6’s full OPT(2) setting than they would on COBOL 4 with no optimization. It’s a big difference, but a manageable one when dealing with basic programs. Unfortunately, the problem is exacerbated as programs become more complex.
For a program with around 50,000 lines of code, COBOL 6 at OPT(0) will still use four times the CPU seconds of COBOL 4.2. Step up to the moderate OPT(1) level and you’re looking at an increase of almost 400 to 1. Those CPU seconds come at a cost, so it’s imperative that you explore options to minimize that burden. Fortunately, Cloud Compiling is here to take the demands of compiling off your plate.
For information on how a Compiling-as-a-Service methodology can help you upgrade to COBOL 6 without incurring an astronomical bill, download our most recent whitepaper or reach out to the Cloud Compiling sales team today.