Introduction

As I have recently written (November 2007, Building an Early Warning System to Enable COBOL Compiler Migration), there are sites that will be compelled to migrate older COBOL programs to Enterprise COBOL simply because they must run the latest version of DB2 and CICS. If that’s the case at your site, what have you done to help get the applications programming staff ready to do the work? I was presented with this challenge at a client site and decided to follow a standard project approach:

• You perform the detailed analysis to make certain you clearly understand the issues.
• You migrate the source code.
• You thoroughly test the converted code.

Let’s start with the first aspect of this approach.

Edge Portfolio Analyzer

I’ve uniformly maintained that a key component of a successful COBOL source code migration is the Edge Portfolio Analyzer (EPA). It does an outstanding job of providing you with a completely thorough load library analysis. The Summary Report of a load library shows the extent of the COBOL code that requires your particular attention, as shown in Figures 1a and 1b.

File Edit Edit_Settings Menu Utilities Compilers Test Help
-------------------------------------------------------------------------------
SPF/E EDIT TSOUSER.EPABAT01.SUMMARY Columns 00001 00072
Command ===> Scroll ===> CSR
010753 CSECTS CREATED BY COBOL 895
010754 CSECTS USING ANSI V2 OR V3 COMPILER 0
010755 CSECTS USING COBOL V4 COMPILER 0
010756 CSECTS USING OS/VS COBOL COMPILER 413
010757 CSECTS CREATED BY VS COBOL II 482
010758 CSECTS CREATED BY VS COBOL II RLSE 1.0 0
010759 CSECTS CREATED BY VS COBOL II RLSE 1.1 0
010760 CSECTS CREATED BY VS COBOL II RLSE 2.0 0
010761 CSECTS CREATED BY VS COBOL II RLSE 3.0 53
010762 CSECTS CREATED BY VS COBOL II RLSE 3.E 0
010763 CSECTS CREATED BY VS COBOL II RLSE 3.1 0
010764 CSECTS CREATED BY VS COBOL II RLSE 3.2 0
010765 CSECTS CREATED BY VS COBOL II RLSE 4.0 429
010766 CSECTS CREATED BY VS COBOL II RLSE UNK 0
010767 CSECTS CREATED BY LE CONFORMING COBOL 0
010768 CSECTS CREATED BY COBOL/370 RLSE 1.0 0
010769 CSECTS CREATED BY COBOL/370 RLSE 1.1 0
010770 CSECTS CREATED BY COBOL FOR MVS V1 R2.0 0
010771 CSECTS CREATED BY COBOL FOR MVS V1 R2.1 0
010772 CSECTS CREATED BY COBOL FOR MVS V1 R2.2 0

Figure 1a: Sample EPA Summary Report Results (Part 1 of 1)

 

File Edit Edit_Settings Menu Utilities Compilers Test Help
-------------------------------------------------------------------------------
SPF/E EDIT TSOUSER.EPABAT01.SUMMARY Columns 00001 00072
Command ===> Scroll ===> CSR
010808 OS/VS COBOL CSECTS THAT ARE LANGLVL(1) 1
010809 OS/VS COBOL CSECTS THAT ARE LANGLVL(2) 412
010810 CSECTS USING SYMDUMP OPTION 0
010811 CSECTS USING FLOW OPTION 0
010812 CSECTS USING STATE OPTION 0
010813 CSECTS USING TEST OPTION 0
010814 CSECTS USING RES OPTION 403
010815 CSECTS USING ENDJOB OPTION 0
010816 CSECTS USING OBJ-370 OPTION 413
010817 CSECTS OPTIMIZED USING COBOL OPTION 10
010818 CSECTS OPTIMIZED USING CAPEX 65
010819 CSECTS USING RES BUT NOT ENDJOB 403
010820 CSECTS USING COUNT OPTION - OS/VS COBOL 0
010821 CSECTS USING TRACE VERB - OS/VS COBOL 0
010822 VS COBOL II, COBOL/370 STATISTICS
010823
010824 COBOL CSECTS THAT ARE CMPR2 123
010825 COBOL CSECTS THAT ARE NOCMPR2 359
010826 CSECTS USING TEST OPTION 0
010827 VS COBOL II CSECTS USING RES OPTION 482

Figure 1b: Sample EPA Summar Report Results (Part 2 of 2)

In any given circumstance these numbers, and the condition of the code, will vary. If you discover that you are not certain about the compile options that were used or some other aspect of the load module, you can run any number of EPA External Analyzers to obtain the requisite level of detail.

CCCA

Based on this preliminary assessment, the next step is to actually remediate the code. For this task, I have invariably relied on IBM’s COBOL and CICS/VS Command Level Conversion Aid (CCCA) to generate Enterprise COBOL code.

CCCA, which has been available since the mid-1980s, lets you generate Enterprise COBOL code from any existing COBOL language variant. It uses the same source code and copy books that are handled by your existing compile process. It employs a set of options that applications programmers supply to perform its analysis and subsequent remediation. Some of these options include:

• Generate new source and copy books
• Remove obsolete elements
• Flag manual changes
• Flag FILE-STATUS conditional statements

The product’s dialog panels allow you to establish generic guidelines for all of your programs. They also give you the opportunity to modify the options for specific program requirements.

The code migration takes place in a batch job. The CCCA utilities parse the source code, determine which elements are obsolete and must be replaced, and then perform the appropriate actions. If you provide an output source and copylib dataset, you’ll get converted code, along with a listing that describes the actions that were performed on the code. At the end of the listing is a summary of all the actions taken.

Now the folks in the IBM lab who built CCCA faced a development design decision. They used a VSAM file to keep track of the options used to convert the program, along with the list of programs that were converted (and a myriad of useful cross-reference information). However, because the VSAM file is used for both read and write, they’ve effectively prevented more than one person from using the file at the same time, for example in an application group mode.

So the question arises. How can an application group maximize the results of the EPA Summary Report analysis and perform a mass CCCA migration? Simple: You create a mainframe mashup! Here’s how I built one.

The Mainframe Mashup

The client site where I built this solution uses CA’s Endevor for all source code change management. They store the source code in Endevor’s proprietary BDAM format. To work with a program, you must first extract the code from Endevor and place it in a PDS(/E).

I reasoned that if an application group wanted to know how much work was involved in migrating their code, they would need to work with all (or a subset) of their COBOL source programs. They would also need to see and use an EPA Summary Report analysis of the corresponding batch or CICS load library. From that starting point, it was relatively easy to build the ISPF dialog that would perform these tasks.

Figure 2 shows the dialog’s data entry panel. As you can see, most of the fields are self-explanatory. A pop-up data entry panel obtains the names of the copy book datasets commonly used during compilation.

ISPF Dialog Data Entry Panel

After the application programmer completes the data entry fields, the dialog creates the names of all of the files that will be used in the various batch jobs. Some of the files are allocated during the ISPF session, while the rest are allocated in the first batch job.

 

The first batch job performs the following processing:

 

• Removes any prior versions of the CCCA VSAM files
• Creates a new set of CCCA VSAM files (unique to this dialog so they don’t conflict with anyone using the program product)
• Loads the CCCA VSAM CONTROL file with a modified set of base records
• Extracts the Endevor source code into a PDS/E
• Runs EPA against the specified load library to obtain a Detail Report
• Runs a REXX program to split the EPA Detail Report into separate members (one per load module)
• Invokes ISPF to execute another REXX program

 

This second REXX program performs several tasks. For each source member, it checks to see if a matching EPA Detail Report member exists. If it does, the EPA Detail Report member is parsed to determine the following:

• Does the program contain any DB2 components?
• Does the program contain any CICS components?
• What specific level of COBOL was used to compile the program?
• Does the member name match the PROGRAM-ID?

If the level of COBOL is VS COBOL II or earlier, the REXX program submits a batch job to execute CCCA against that source program using the values obtained from parsing the EPA Detail Report member. Otherwise, if the level of COBOL is later than VS COBOL II, a message is issued to let the application programmer know they can simply recompile the program with Enterprise COBOL.

Unfortunately, a review of the CCCA batch job is outside the scope of this article.

After all of the CCCA batch jobs are submitted, a final batch job is submitted that uses IBM’s FileManager to read the information in the CCCA VSAM CONTROL file and load it into REXX variables. Another REXX program summarizes the results of the status column to categorize the effort involved with the source library that was analyzed. Four categories are established: none, minimal, moderate, and extensive. Figure 3 shows a sample of this report.

File Edit Edit_Settings Menu Utilities Compilers Test Help
-------------------------------------------------------------------------------
SPF/E EDIT TSOUSER.APPLIC.ATION.BATCH.SYSPRINT($INDEX) - 0 Columns 00001 00072
Command ===> Scroll ===> CSR
000460 Pxxyyzzz WARNING 10/26/07 18:44
000461 Pxyxyxy0 WARNING 10/26/07 18:44
000462 Pxyxyx MAN. COMP 10/26/07 18:44
000463 Pzyxyzzzy COMPLETE 10/26/07 18:45
000464 Pxyzyzyz COMPLETE 10/26/07 18:45
000465 Szyzyz COMPLETE 10/26/07 18:45
000466 Sxyzyzyx WARNING 10/26/07 17:20
000467 Xyzxyxx COMPLETE 10/26/07 18:17
000468
000469 No change: 0 0%
000470 Easy to fix: 377 81%
000471 Moderate to fix: 63 14%
000472 Difficult to fix: 23 5%
000473
****** **************************** Bottom of Data ****************************

Figure 3: Sample CCCA Analysis Summary

Note: On a heavily loaded system, I was able to process 500 programs in less than 4 hours. The CCCA batch jobs are all given the same job name so that they are single-threaded through the system, avoiding any contention on the VSAM CONTROL file and using only one JES initiator.

Using EPA’s Summary Report and these CCCA statistics, an application group’s project manager is better able to determine the size and scope of the actual conversion work effort.

Depending on the circumstances, that project manager may decide to have his or her staff run this utility in “live” mode and have it perform the actual code migration. Then he or she can have the application programming staff spend time working on the manual conversions, and devote the necessary time to preparing the appropriate test cases.

Despite having improved the up-front analysis time, I don’t want to discount the fact that there is still significant work involved with the source code change management product, Endevor. Old programs must be checked out (and archived), and the new versions checked in using the new compiler type.

Conclusion

There you have it, a mainframe mashup. I was able to take two very different products, and repurpose them to produce a valuable analysis tool for application group project managers and their staff. Now, the operating system spends the time determining how much work is involved in COBOL code migration, not the application programming staff.

Resources

• Edge Portfolio Analyzer (http://www.edge-information.com)
• COBOL and CICS/VS Command Level Conversion Aid (http://www.ibm.com/software/awdtools/ccca/index.html)
• Enterprise COBOL for z/OS (http://www.ibm.com/software/awdtools/cobol/zos/)

 

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