OS/VS COBOL Has Died (Finally)

As all CICSers should now be aware, OS/VS COBOL will not run on CICS TS 3.1. ALIK ABEND will occur if an OS/VS COBOL module is attempting to execute. After going EOS in 1994, OS/VS COBOL is finally officially dead.

Recently we became involved with an organization that was looking at upgrading from CICS TS 1.3 since 1.3 was going End Of Service in April 2006. We suggested they pull down the freebie CICS SupportPac CH1A: Load Module Analyzer.

The function of this Load Module Analyzer is also included in IBM® Debug Tool Utilities and Advanced Functions for z/OS® V6 (5655-P15), and IBM Debug Tool Utilities and Advanced Functions for z/OS V5.1 (5655-M19) with PTF UK05866.

The Load Module Analyzer can be used to determine many different characteristics of load modules. To obtain a list of those modules within a load library compiled using an OS/VS COBOL compiler, use the LMA keyword OSVSONLY.

If you are going to acquire the IBM Debug Tool’s latest version, go ahead and get it now and use the LMA in the Utilities portion of the tool.

When the organization ran the LMA, they received “several hundred” LMA report lines indicating OS/VS COBOL modules found in the CICS load libraries. The system programmer appeared to be surprised by this. We are only five years past Y2K and obviously the detailed inventories captured for Y2K no longer exist or are collecting dust on someone’s shelf.

Now the organization has to convert the existing OS/VS COBOL modules before they move off of CICS TS 1.3. This includes the ones found in the CICS load libraries and those that exist in the batch load libraries. They must also determine if these modules are ever actually used. Is there a corresponding CICS program entry defined for the found module(s)? Are the programs ever used throughout any part of the year?

The organization now faces the potential of running on an unsupported subsystem for at least some period of time past April of 2006.

Finding the Offenders

Another approach we have recommended is the new runtime informational message introduced by the CICS service stream.

For CICS TS 1.3 users, you can also install PK16285: RUNTIME MESSAGE FOR DEPRECATED OS/VS COBOL.

This APAR introduces a new message DFHAP1301 issued when an OS/VS Cobol module is loaded or reloaded. The destination of new message DFHAP1301 is CDEP TDQueue.

For CICS TS 2.2 and 2.3 users, you can install the corresponding PK10480.

Just be aware that these DFHAP1301 informational messages will only occur when CICS loads the offending module. A shop will have many modules that may not be loaded during the period of time from the time of the maintenance application and the time for CICS migration.

Using any of the above approaches will simply point out that there are OS/VS COBOL modules that must be addressed prior to the migration to CICS TS 3.1.

Some organizations have determined that they simply do not have time to do both the COBOL conversion and the CICS migration. These organizations are looking at getting around the COBOL conversion by using products like MacKinney COBOL Interpreter (CI). CI will place a simulation layer between the deprecated COBOL module and the CICS - LE environment. Be aware that you will need to keep the existing batch COBOL as is since major changes in data representations occurred between OS/VS COBOL and say Enterprise COBOL. Although some batch application may easily be upgraded, if it is determined that no data differences of critical nature exist between the old and new COBOL modules.

An Estimator

Some companies will need to trade off conversion time and expense against software simulation product expenses. We are providing the reader with a simplistic COBOL Conversion Estimator. This estimator is Excel spreadsheets that will allow a user to enter some general information about the types and quantities of OS/VS COBOL source modules are being considered for conversion or software simulation. The spreadsheet will use a rudimentary COCOMO model to calculate the Full time Equivalent (FTE) staffing and dollar costs of people, infrastructure, and project time duration.

The Estimator shows a comparison of the conversion of the COBOL systems versus the Software Simulation approach. We currently use the MacKinney CI product, but it could be any CI-type product. We have received no input from MacKinney on this model and have done no validation with them. We have queries up on CICS-L asking for user data on COBOL CI environments but have not received any reply to date.

We are making no recommendation for either conversion or simulation. Much of the decision criteria will be based on how long a conversion project would take, the impact of the conversion on the overall software schedule for the organization, and costs and people required. We will provide you those kinds of estimates and you must decide the best route to take.

The Estimator is available at http://www.mardon-y2k.com/COBCOMTOOL.xls, and the accompanying User Guide is at http://www.mardon-y2k.com/User_COBMIG.doc. These are provided to you on as as-is basis.

Summary

In most cases, our model shows the COBOL CI approach is the better solution from a time, staffing, and cost point of view. But there is a breakeven point where due to the number of modules involved, the conversion is the better approach. Your organization might decide that conversion is the best regardless of cost or time. At least you have an estimate for the conversion that you can use!

Regardless of which approach you take, you must take one. Even if you do not plan to install CICS TS 3.1 in the immediate future, you should run the Load Module Analyzer. Then determine if the load modules are ever actually used. Then locate the corresponding batch jobs containing OS/VS COBOL. Then run the free estimator. Then decide to do one of the approaches with the estimator tool data you now have available.