Dec 27 ’05

CICS & COBOL: Is It Time to Get Rid of Those Old COBOL Programs?

by Editor in z/Journal

IBM has been notifying customers in the past couple of CICS releases that they should be prepared for withdrawal of support for old releases of COBOL. It should come as no surprise that the latest announcement, CICS TS 3.1, confirmed their stance. This article examines the ramifications of that announcement, what customers’ options are if they’re impacted by the announcement, and how to prepare for the inevitable migration. We’ll also cover some new features that have shipped in support of COBOL developers.

One feature, the integrated translator component, was first shipped in CICS TS V2.2. It simplifies the development process by removing the translator step and potentially reduces programmer time and effort.

COBOL, Past and Present

Figure 1 details the numerous releases of COBOL and the status of each. This information isn’t new, and can be found on IBM’s LE Website at www. ibm.com/servers/eserver/zseries/zos/le.

 

Although the oldest releases of COBOL were withdrawn from service/ support many years ago, many customers found they still worked, so they’re still using them. Some customers took into consideration the time and money spent during the Year 2000 conversion projects and replaced the code with current, supported releases. Many merely changed the date routines to accommodate the four-digit year requirements and were lucky enough to produce source that successfully compiled. Many programmers breathed a sigh of relief when it worked. Some customers discovered that the source was no longer available, or couldn’t be guaranteed to match the executable load module that was in production, so they left them intact and tested. Sometimes it worked, so those old modules were moved along the supported chain of applications and allowed to remain.

They weren’t supported, but still executed. Unfortunately, that gave many customers a false sense of security that this old code could escape the migration effort. IBM has been warning customers about this for years, but the beginning of the end came with CICS TS V2. This version of CICS came with an enhancement to the application development process called the integrated translator component. CICS V2.2 documentation detailed the COBOL compilers supported as follows:

It also stated that changes were made to the translators for V2.2 to remove support for pre-Language Environment (LE) compilers such as:

While the COBOL2 option was removed from the translator, customers found that COBOL II source would be translated with the default COBOL3 option and the result was a successful compile and executable module. Technically, it worked even though it was unsupported. The same didn’t apply to old OS/VS COBOL. Changes to the translator restricted the ability to continue any new compiles of these programs.

The result was source that couldn’t be modified or enhanced since it was impossible to translate/compile and produce a new load module. But, if customers were happy to run these programs without changes, the “run-time” environment remained available, though not supported. In this release, IBM also warned: “In the next release of CICS after V2.2, native support for the old language run-times will be removed.” The release after V2.2 will continue to provide object compatibility; i.e., all applications will continue to work.

The direction has been clear, however, that IBM didn’t intend to support the old releases forever. Following is an excerpt from the CICS TS V2.3 Release Guide:

“CICS TS 1.3, CICS TS V2.2, CICS TS V2.3: The Language Environment component of z/OS is required; applications will run unchanged. This function will be removed in the next release of CICS TS.”

The old modules that could run unchanged in CICS would no longer run. Some customers missed this item. In the CICS TS V3.1 announcement letter, IBM states: “OS/VS COBOL modules will not execute in this and subsequent releases of CICS TS.” This is further documented in informational IBMLINK Items:

If customers try to execute OS/VS COBOL modules in CICS TS 3.1, they’ll receive an ALIK abend. No warning, but then again, IBM has been warning in the documentation for years. The light at the end of the tunnel has been extinguished.

What Now?

If you’ve been procrastinating and still have old OS/VS COBOL modules in CICS, there are only two options available:

IBM hasn’t announced the end of service for CICS TS V2.3, so ideally there are still a few years left. Customers could upgrade their systems to CICS TS 3.1 and leave one Application Owning Region (AOR) behind on V2.3 for these applications, although that’s not recommended. It’s also not a long-term solution.

Finding Modules

Customers may have many old libraries with modules and can no longer find the source code for them. There may be many techniques you can use to find the level of COBOL they were compiled with. Figure 2 contains one method. If you run IBM’s utility AMBLIST, it will produce a report as shown in the JCL example. The report shows the attributes of the module and, near the bottom, it lists the code sections (CSECT) and translator used. You can identify the compiler, version and release number from the object via the VR.MD, in this case ’01.03’. From Figure 1, you can see that this module is VS COBOL II Release 1.3. You would expect an OS/VS COBOL module to show ’01.02.’

New Integrated Translator Support

Starting in CICS TS V2.2, IBM provides a CICS integrated translator component that eliminates the need for the translate step in program development, simplifying the development process. Customers that wish to take advantage of this feature need to change their compile process and corresponding PROCs (compile procedures), but may benefit from the ease of use. In the CICS TS V2.2 SDFHPROC library, a new member can be found—DFHZITCL—that contains a sample procedure. In the normal COBOL compile PROC, DFHYITVL, customers execute four steps starting with the TRN (translator) step. This step translated the CICS commands into “native” language statements before compiling the COBOL program. The new PROC contains only three steps, and directly invokes the COBOL compiler with the integrated translator. The program source must be untranslated as input into this step.

IBM continues to support the translators if customers wish to use them, and the original PROC in SDFHPROC remains available, although IBM recommends that customers use the new procedure. Some customers have found that the integrated translator changes the results of the compile and the output they’re used to seeing. The output of the integrated translator doesn’t produce the MOVE and CALL statements that the translator does, and you can’t view the EIB references. This change is documented in IBMLINK items BDC000026949 and BDC000025833. The CICS TS V2.2 Application Programming Guide also contains a reference to this difference, “The CICS-supplied separate translators change the line numbers in source programs, which means that an intermediate listing with the translator-generated CALLS must be used when debugging an application program.”

Customers dependent on the expanded output from the translator step will need to continue using the “old” process and not the integrated translator.

Summary

The demise of old COBOL was inevitable. IBM can’t continue to expend time and resources supporting old releases forever, especially while enhancing the features of existing and new releases. Onward and upward, right? We may be dinosaurs, but we still love our CICZ TS.