COBOL source code migration is inevitable. In the near future, whether your site has VS COBOL II programs or still has OS/VS COBOL programs, if you change your source code during maintenance, you must migrate the compiler to Enterprise COBOL.

Introduction

What are the reasons to migrate to Enterprise COBOL? They vary from site to site. In some cases, a business need has application development managers clamoring for the features necessary to support XML processing. In other sites, systems programmer managers want to have all business applications run above the line. While in others, data center managers want to eliminate the cost of unsupported software. Finally, there is the inevitable drive to use the latest version of CICS or DB2, both of which require Enterprise COBOL to compile programs (refer to "IBM Software Support Lifecycle Policy" for additional details). Whatever the reason is at your site, and you are not alone, you have the task of assisting the application programmers in migrating their source code to a new compiler.

Anyone who has been in this industry long enough probably remembers the change from OS/VS COBOL to VS COBOL II. Oh, sorry, my mistake; there are only a handful among us who might remember, because it was so frighteningly long ago! Just the same, IBM's Tom Ross has been presenting his COBOL migration slides at SHARE for quite a number of years. I can recall the VS COBOL II to COBOL for OS/390 version, as well as several other iterations. Naturally, the latest presentation has now been upgraded for Enterprise COBOL.

Let's see how one approach works. In this article, I'll briefly describe the overall process, review the tools that were used, and explain the code that supported the process.

The Basic Process

I devised an "early warning system" at a client site some time ago to assist in the remediation and migration effort of existing VS COBOL II programs. It was based, in part, on the information contained in the IBM COBOL migration guide. The migration guide (see "Resources" for the full title and publication number) contains a wealth of information regarding ways in which your site can perform the migration to Enterprise COBOL

A project was begun to prepare for the eventual COBOL code migration. (Refer to "How to migrate..." for other considerations.) The project consisted of several, short-term, high-impact phases:

• Identify obsolete modules
• Identify undesirable load module attributes
• Modify ChangeMan to assist with identification and remediation

You can refer to "How to migrate..." for other considerations.

The site used Serena Software's ChangeMan as their software change management system. All application load modules were placed into two production-level libraries: one for batch, the other for CICS. This implementation significantly helped with load module analysis.

Identify Obsolete Modules

As befits a site that had successfully gone through the Year 2000 effort, as well as several extended internal and external projects, this one was well-positioned to start identifying load modules that were no longer executed in production. The Change Management group worked with the Performance Measurement group to obtain use counts to help identify candidates for removal. Monthly scans of the production load libraries were run to maintain current statistics.

Application group managers were notified on a regular basis regarding modules that were candidates for removal. One of the advantages of this kind of clean-up is the inevitable reduction in the number of programs the application programmers have to remediate.

As programs were identified as obsolete, the application programmers used other software tools to locate and to remove the batch jobs, control cards, and copy books that were used by those programs. You may find, as I did, that even though an application was retired, some of the batch jobs continued to run in the production stream and produced output that was no longer needed. A simple scheduling change can save your site any related charge-back costs associated with those unnecessary batch jobs. All mainframe-based change management products provide the ability to remove obsolete components from production libraries.

Identify Undesirable Load Module Characteristics

When you review the contents of your site's application load libraries, you should be able to discern how much work you have to perform to upgrade your source code. Topics to review include areas that IBM has already identified as significant hurdles:

• Mixed RES
• NORES
• Invalid ABEND routines

In the first instance, the VS COBOL II compiler allowed a combination of RES and NORES modules. Actually, this has nothing to do with source code migration and everything to do with an incomplete Language Environment (LE) migration. The NORES modules still contain all of the older, non-LE runtime components. Knowing this, you'll have the information you need to identify, to correct, and to test those components.

NORES modules should be next on your list of modules to eliminate. There no longer is a RES/NORES compile option with Enterprise COBOL. All compiled output is defaulted to RES. Again, NORES components contain older runtime load modules. For you to successfully recompile them you must also ensure that an adequate test plan is in place to guarantee that the code performs in the same way as was designed (and in the way it has operated - probably for years). Note: You can change your site's compile options long before you begin to use Enterprise COBOL.

Finally, invalid ABEND routines - especially any 24-bit Assembler programs - must be removed from your programs. This is just a good housekeeping technique. Plus, it will allow the programs to run above the line (assuming there are no other 24-bit components link-edited into your programs). Replace all invocations with a call to CEE3ABD. Make certain that you pass it an error return code with the appropriate PICTURE clause size; in this case, PIC S9(9).

Software Tools

The tools I had available for this project were: Edge Portfolio Analyzer, BatchPipes, and ChangeMan. I tied them together by using ISPF dialog components and REXX programs. What follows is a brief description of the tools and how they were used.

Edge Portfolio Analyzer

Towards the back of the COBOL migration guide is a reference section that describes software tools designed to assist you with the migration effort. My favorite is the Edge Portfolio Analyzer (EPA) from the Edge Information Group. (Refer to "Resources" at the end of this article for contact information.) Carl Gehr and company have put together a product that does just about everything you need to identify every aspect of a load module. The product is easily installed, and it comes with a wide variety of pre-built reports. Some of these included items that were crucial to the project's goals:

• Mixed RES components
• NORES components
• 24-bit Assembler abend routines

In addition, you can take the raw data and load it into any database engine (DB2 samples are provided) to let you run ad hoc queries. You can also build customized reports to suit your project's specific needs.

My approach to working with EPA was two-fold: First, I built a set of weekly batch jobs to process each of the site's load libraries. I took the output of the EPA analysis and then processed it. In this manner, I created management reports about the status of the application portfolio. I also saved the individual load module reports to members of a data set. This let application programmers quickly view how their code was established in production - it was a quick and easy reference. Second, I modified the site's ChangeMan compile processing to include a step to run EPA and to evaluate the results.

As I stated earlier, EPA comes with an existing set of reports that quickly let you identify problematic programs to remediate. It also gives you the flexibility to customize a set of reports to suite your site's particular needs. You can use IBM's DFSORT to filter records for additional processing. If you are fluent with SAS Institutes' SAS, you can generate reports with statistics to the Change Management administrator and to application programmer managers.

I suggest that you schedule your EPA analysis to run after your change management software has finished updating your site's application batch and online load libraries. Monitor the progress of your remediation program and make certain you identify any newly errant components. Ongoing application programmer education will ensure that continued "bad practices" are eliminated.

I was fortunate the site I was working with recognized the importance of the Edge Portfolio Analyzer. Between the vendor-provided reports, the ability to drill down into the statistics, and the capability of constructing your own reporting tools, this was a powerful adjunct to getting the job done.

BatchPipes

The tool I used to process the output from EPA was IBM's BatchPipes. By using pipes commands in a REXX routine, I was able to create output files that were custom-made for this remediation process. One set of jobs took the entire load library and made the output available on a member name basis. Another created summary statistics reports for senior management.

BatchPipes (Pipes) is the "Swiss Army Knife" of utility programs. I'm still astonished that IBM doesn't provide this program product as part of TSO. Pipes lets you quickly and efficiently massage record streams and perform various processes on each level of data. Combined with REXX, Pipes gives you an inordinate amount of scripting power. In this instance I used Pipes to parse the output of standardized reports. Alternatively, you can code DFSORT OUTFIL statements to perform similar processing.

Note: Report scraping, which is what I employed, is based on a predetermined format. If Edge changes the format of the report, the REXX (BatchPipes) routine will no longer produce valid results. Obviously, it is essential to test any new release of EPA and trace the REXX code prior to releasing the update to the general population to ensure consistent results.

Code That Drove the Process

ChangeMan's batch compile process offers a unique environment for cross-checking various aspects of input source code and the resulting load module. For this COBOL migration project, I included a step after the link-edit to invoke EPA on a copy of the load module.

When you compile a COBOL program with ChangeMan, a batch job is generated comprised of a series of steps to process the program. These steps are built using a set of imbedded ISPF skeletons. As part of the migration project, a new ISPF skeleton was added to ChangeMan's processing - specifically for batch programs - right after the load module was link-edited and just before the final step was executed.

The ISPF skeleton is shown in Figure 1. This contains three steps and invokes EPA and the REXX post-processor. We'll go through each of the steps in detail.

The first step copies the load module from ChangeMan's temporary staging dataset to a newly created, temporary partitioned dataset. This was done for two reasons. The first was designed to let EPA perform its processing without affecting the ChangeMan-created dataset. The second was to enforce compliance with the site's program naming standards. This step will fail if the name of load module does not match the name of the source program. In many instances, particularly for older batch programs, a link-edit control card renamed the load module. By failing the batch job at this point, the application programmer was given the opportunity to correct the link-edit control cards and to update any associated production JCL in accordance with current site standards.

The second step invokes EPA, with most of its options, to analyze the load module. The results are sent to the SYSPRINT DD. This is a newly created, temporary, sequential file. As I mentioned earlier, EPA produces a highly structured report that details how the load module was compiled and information about all of the CSECTs it contains.

The third step invokes TSO and runs a REXX routine to read the sequential file created in the previous step. This is where the main processing occurs.

BatchPipes - Slices and Dices

The REXX routine reads the name of the COBOL program and the level of COBOL that was used to compile it. The REXX routine then uses BatchPipes to read the EPA report. BatchPipes strips off the headers and trailers to let the routine focus its attention on the body of the report. For this project, I searched for three specific strings, each separated by spaces:

• RES
• NORES
• CS-ABEND

The terrific thing about BatchPipes is that it can do this with only a few statements and, at the same time, place the output of each search into a compound variable. Figure 2 shows how this is done. The DROP statements remove the report headings and summary information. The FANOUT statements lets BatchPipes perform the three levels of searching. The greater than sign (>) sends the resulting report to the ANALYSIS DD statement.

After the variables are loaded, the REXX routine engages in the logical process of identifying good from bad. In this case, the following tests are performed:

-If the load module contains only RES components, then the step ends with a return code of zero and the batch job completes successfully. Note: When this routine processes an Enterprise COBOL program, nothing happens. The code is bypassed based on the value contained in the variable LANGLVL.

-If the load module contains both RES and NORES (mixed RES) components, the step ends with a non-zero return code and the batch job completes unsuccessfully. Appropriate information and error messages are written to the job log to let the application programmer diagnose and correct the program. Figure 3 shows an example of this code.

As you can see, the compound variables are tested to see if the stems contain a value greater than zero. The REXX routine's exit code is set to 12. The error message subroutine is invoked with a series of message numbers. A final test is performed to see if there are any ABEND CSECTs; if there are, additional error messages are issued.

-If the load module contains the CSECT ABEND, the step ends with a non-zero return code and the batch job completes unsuccessfully. Again, the appropriate information is written to the job log so that the application programmer can undertake corrective action.

At this site, the program, ABEND, was a homegrown Assembler abend routine that predated ILBOABNO and was AMODE=24.

-The most difficult test is when a load module contains NORES components. If it does, additional work is performed to determine if there is a high or low degree of complexity to change the program to RES. This complexity factor is based on the number of other subordinate programs that are either included with, or included by, this program. The complexity factor report is built during the weekly EPA load library scans.

When the error message subroutine is invoked, it reads the number of words that are passed and loops through those values to select the corresponding text message for inclusion in the job's output log. That code is simply too long to include with this article.

The corrective actions that application programmers would undertake when the REXX routine failed the batch job included:

• Removing ABEND and implementing CEE3ABD
• Finding the correct (replacement) RES modules
• Presenting NORES module to the ChangeMan Administrator for exclusion based on complexity

After the appropriate action was taken, the program was recompiled and tested.

The time required to perform this entire series of checks was very small and the amount of overhead associated with the REXX processing was insignificant. The overall affect on the entire ChangeMan batch compile process was low.

Note: Because of the modular nature of this update, it was easy to remove from ChangeMan when it was no longer required.

Conclusion

The net result of this project: The site had an early warning system for the identification of potential problems and a mechanism that allowed their application programmers to correct them.

Depending on how management at your site views the necessity of your COBOL migration, you usually have at least two options. A forced march or a slow flow though ongoing maintenance. Irrespective of your site's decision, you must take a complete library assessment to understand the complete scope of what is contained in your production load libraries. This preliminary analysis serves as a benchmark to:

• Identify areas that require attention
• Prioritize the work effort
• Allow you to measure the progress of your remediation

Note: These are generic guidelines, because each site has a different set of historical artifacts in their load libraries and an equally divergent set of management prerogatives. I hope that you can make use of the tools I've presented here to make your migration and remediation easier.

Resources

• Enterprise COBOL for z/OS Compiler and Runtime Migration Guide (GC27-1409)
• Edge Portfolio Analyzer (http://www.edge-information.com)
• BatchPipes for OS/390 Version 2 Release 1 (5655-D45)
• ChangeMan ZMF (http://www.serena.com)

 

Sidebar 1:

IBM Software Support Lifecycle Policy Summary

IBM's Software Support Lifecycle Policy can be found at http://www.ibm.com/software/support/lifecycle/. This site lists all of IBM's program products and the dates on which the various versions have been released and when they will no longer be supported.

I've extracted the information about CICS, COBOL, and DB2 and presented it below. As you can see, IBM recently announced that DB2 Version 7 will no longer be supported after next year. This means sites that want to compile DB2 COBOL programs must use Enterprise COBOL. Based on the statements on IBM's web site and current software release activity, I am predicting that CICS Transaction Server 2.3 will be withdrawn by mid-year next year. If so, then any changes to CICS COBOL programs will also be required to use Enterprise COBOL.

I hope you take advantage of the time available to migrate your compiler before you are forced to.

 

Product name	General Availability	Withdrawn from Support
CICS Transaction Server for OS/390 V1.3	March 26, 1999	April 30, 2006
CICS Transaction Server for z/OS V2.2	January, 25 2002	April 30, 2008
CICS Transaction Server for z/OS V2.3	December 19, 2003	LMK estimate: Apr 2009
CICS Transaction Server for z/OS V3.1	March 25, 2005	N/A
CICS Transaction Server for z/OS V3.2	June 29, 2007	N/A
OS/VS COBOL	--------	June 1994
VS COBOL II	--------	March 2001
COBOL for OS/390 Version 2 Release 1	May 23, 1997	December 31, 2004
COBOL for OS/390, V2R2	September 29, 2000	December 31, 2004
Enterprise COBOL for z/OS and OS/390 V3R1	March 29, 2002	April 4, 2004
Enterprise COBOL for z/OS and OS/390 V3R2	September 27, 2002	October 3, 2005
Enterprise COBOL for z/OS V3.3	February 27, 2004	April 30, 2007
Enterprise COBOL for z/OS V3.4	July 1, 2005	N/A
DB2 for OS/390 Version 6	June 30, 1998	June 30, 2005
DB2 for OS/390 and z/OS Version 7	March 30, 2001	June 30, 2008
DB2 for z/OS Version 8	March 26, 2004	N/A
DB2 for z/OS Version 9.1	March 16, 2007	N/A

 

Sidebar 2:

How to migrate...

The actual process of converting COBOL source code can take two paths:

• During maintenance, as a natural course of business
• Mandated change (a forced march)
  • Application by application
  • Entire site

How you do this at your site is up to the internal politics and business savvy of your data center, business users, and application programming groups.

Some of the thinking that needs to be applied to a large project like this is:

• Recognize the need to eliminate problems
• Realize that taking early, proactive, steps helps reduce later implementation costs
• You always need more time than you first estimate to test changed components

Identifying errant components early gives the Change Management group and the application development managers the ability to assess the complete scope of the work effort and to estimate the cost, thereby providing adequate resources to perform the work.

One obvious benefit to this activity is that some application development managers may identify retired applications and remove obsolete components from the system. This kind of clean-up benefits the application group and the entire organization by eliminating remediation on non-used programs.

Figure 1: ChangeMan ISPF skeleton to invoke EPA and REXX post-processor for analysis and validation

 

//*)IM CMSKL30

)CM

)CM !! INSERT INTO CMN$$LNK RIGHT BEFORE BAT90... ONLY FOR COBOL !!

)CM

)CM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

)CM COBOL STANDARDS ROUTINE

)CM FUNCTION: RUN EDGE ANALYZER TO VALIDATE LOAD MODULE

)CM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

)CM

//TCPYLOD EXEC PGM=IEBCOPY,

// COND=(4,LT)

//SYSPRINT DD DUMMY

//TCOPYIN DD DISP=SHR,DSN=&&&&LOAD

//TCOPYOUT DD DISP=(,PASS),DSN=&&&&TEMPLOAD,

// UNIT=SYSDA,SPACE=(TRK,(4,2,6),RLSE),

// DSORG=PO,RECFM=U,LRECL=0,BLKSIZE=32760

//SYSIN DD *

COPY INDD=TCOPYIN,OUTDD=TCOPYOUT

SELECT MEMBER=((&CMPNAME,,R))

//*

//RUNEDGE EXEC PGM=EPA,PARM='/ACDFIPTVW',

// COND=(4,LT)

//STEPLIB DD DISP=SHR,DSN=SYSOEM.EPA.LOADLIB

//PDS DD DISP=(OLD,PASS),DSN=&&&&TEMPLOAD

//SYSPRINT DD DISP=(,PASS),DSN=&&&&EPALIST,

// UNIT=SYSDA,SPACE=(TRK,(4,2),RLSE),

// DSORG=PS,RECFM=FBA,LRECL=133,BLKSIZE=0

//MACHINE DD DUMMY

//MRSUM DD DUMMY

//SUMMARY DD DUMMY

//XREF DD DUMMY

//SYSUDUMP DD DUMMY

//SELECT DD DUMMY

//*

//CHECKEPA EXEC PGM=IKJEFT1A,

// COND=(4,LT)

//SYSPROC DD DISP=SHR,DSN=SYS9.CMN&SUBSYS..REXX

)SEL &SUBSYS NE &Z

// DD DISP=SHR,DSN=SYS9.CMN.REXX

)ENDSEL &SUBSYS NE &Z

//EPALIST DD DISP=(OLD,PASS),DSN=&&&&EPALIST

//ANALYSIS DD SYSOUT=*

//SYSTSPRT DD SYSOUT=*

//MESSAGES DD SYSOUT=*

//SYSUDUMP DD SYSOUT=*

//ABNLIGNR DD DUMMY

//RATINGS DD DISP=SHR,DSN=SYS9.CMN.CONTROL.LIST(RATINGS)

//NORESOK DD DISP=SHR,DSN=SYS9.CMN.CONTROL.LIST(NORES@EX)

//MODULE DD *

&CMPNAME

//SYSTSIN DD *

%CMNCKEPA &LNGNAME

//*

 

Figure 2: BatchPipes statements parse the output of the EPA report

 

/* Remove report heading and footer, then copy to output

Split the file into three segments:

- Find any RES statements and put in one holder

- Find any NORES statements and put in a second holder

- Find any ABEND statements and put in a third holder

*/

 

'Pipe (EndChar ?) ',

'< dd=EPAList ',

'| Drop First 12 ',

'| Drop Last 180 ',

'| NFind 1 ',

'| a: Fanout ',

'| > dd=Analysis ',

'? ',

'a: ',

'| Locate / RES / ',

'| Stem AnyRes. ',

'? ',

'a: ',

'| Locate / NORES / ',

'| Stem AnyNoRes. ',

'? ',

'a: ',

'| Locate / CS-ABEND / ',

'| Stem AnyAbend. '

intRCode = RC

If intRCode > 0 Then Do

intECode = 28

Say ' Invalide file read from EPAList file.'

Exit intECode

End

 

Figure 3: REXX logic determines if there are mixed RES components

 

/*

If there are both RES and NORES components, then fail this compile

*/

If AnyRes.0 > 0 & AnyNoRes.0 > 0 Then Do

intECode = 12

Call EMsgRtn 4 7 8 9

If AnyAbend.0 > 0 Then Do

Call EMsgRtn 20 5 10 19

End

Else Do

Call EMsgRtn 20 6

End

End

 

NaSPA member Larry Kahm is president of Heliotropic Systems, Inc., an IBM Business Partner located in Fort Lee, NJ. He has 20 years of experience working with systems and application programmers, vendors, and management to ensure that business applications are developed, maintained, and enhanced with the appropriate set of tools. When not training to run in the ING NYC Marathon, he's busy helping clients with their office networks and home computers.

 

Forward this page to a friend

Your Email: *

Your Name: *

Send To: *

Enter multiple addresses on separate lines or separate them with commas.

Message Subject: (Your Name) has forwarded a page to you from NaSPA.com

Message Body: (Your Name) thought you would like to see this page from the NaSPA web site.

Your Personal Message: *

Your vote:

1

2

3

4

5

No votes yet