Effective Cross-Product Utilization: Revisited

311
vote
Author: 
Larry Kahm

To mark my sixth anniversary of writing for NaSPA, I decided to revisit my first article and revamp it for a new audience. This article examines how one site incorporated one of the features of their change management system with the features of their dump analysis tool to help applications programmers determine the cause of development and production abends.

Introduction

When an abend occurs during a production batch run, an application programmer can determine the offending instruction by using a variety of actions and tools. Some application programmers try to determine what went wrong by recompiling a program to obtain a listing that contains the offset of the code in error. Usually the compile is done in a test environment (possibly with "home grown" JCL and compile options), but pointing to the production source and copy libraries. Sometimes application programmers, having attended a vendor training session for a product, continue to use the sample compile deck long after the class is over. Unfortunately, copy members may have been modified between the time the program was put into production and the time the abend occurs. This leads to ambiguous results in tracking down the offending instruction, which is not desirable when a production batch cycle is waiting to be restarted.

This article describes how I provided one method of handling these abend situations by using one product to support another. The application programmers at this site now have a "fast path" to obtain the compile listing and begin their program analysis. Consequently, any down-time from production abends can be substantially reduced. Similarly, development time is improved with faster problem resolution.

Background

I recently worked with a major insurance company in the New York City metropolitan area on a significant enterprise-wide project. A significant portion of the application programming staff was provided by offshore-based consulting firms, and the majority of the staff was located in India. It was my belief that the application programmers could have used the site's existing software tools more effectively to reduce, and then eliminate, the error-prone possibilities inherent in program development and subsequent recompilations.

This site had been using CA's Endevor for many years as its mainframe change management system. Endevor, by default, keeps the last compile listing (in a proprietary compressed form) before a program is installed in production. My goal was to use the Endevor compressed listing to provide as much information as possible and to drive the abend detection process.

The site was also using IBM's Fault Analyzer to perform dump analysis; this product had replaced Compuware's Abend-AID several years ago. However, few application programmers, if any, were aware of the product. None of them, to my knowledge, realized they needed a side file to help them; nor did they understand how easy it was to create one.

While the IBM product literature describes a step that can be used to create a side file when a program is compiled, this was not part of the Endevor process. I was not about to try to convince anyone in the Change Management group to modify the compile process to include an extra step for a "third-party product." However, there was nothing to prevent the use of this utility after the compile was completed. Just the same, this utility requires specific compile-time options. The obvious factor was to ensure all of the required Fault Analyzer compile options were included with the Endevor compile. That way, the post-processor could write the appropriate records to the side file.

Tangential to my overall project responsibilities, I developed an ISPF dialog to assist the application programmers. The design of the data entry panel is very straightforward. Using as few fields as possible, application programmers enter the name of the program, indicate their Endevor system and subsystem (which identifies the compressed listing data set), and specify whether the program is batch or online. A batch job is submitted to process the files.

The ISPF Dialog

The ISPF dialog helps application programmers to perform a key, and potentially time-consuming, function with greater ease; that is, detect errors in program abends, irrespective of whether the program is in development or production. It is accomplished by using the Endevor compressed listing that is saved at the completion of a successful compile.

The dialog submits a batch job that extracts the compressed listing from the production library (or, for development, from the current Endevor compile) and uses an IBM utility to create the appropriate side file for diagnosing the cause of an abend.

To access the dialog, application programmers navigate through a series of ISPF options. A panel, similar to the one shown in Figure 1, is displayed. Almost all of the fields on the panel are required. After the Enter key is pressed, a batch job is submitted to process the information. A message is displayed that indicates the name of the side file into which the records are placed, and reminds the application programmer of the specific Fault Analyzer option to use.

Figure 1Figure 1

Figure 1: Endevor - Fault Analyzer data entry panel

An Overview of the Batch Processing

Here's a brief overview of what takes place within the batch job.

The preliminary steps delete and then allocate the working partitioned data sets required in the job. Because the batch stream only processes one member at a time, there was no design requirement to use the features of a PDS/E. One file contains the output from the compressed listing, while the other contains the output of the Fault Analyzer utility (the side file).

Another step takes the Endevor compressed listing and expands it, as shown in Figure 2. This is done using a standard CA-supplied Endevor utility program. It simply uses SCL to identify the input file name (the compressed listing data set), the output file name (the temporary partitioned data set), both of which are coded in the JCL, and the program name to be expanded.

 

//*                                                 
//JS030    EXEC PGM=NDVRC1,PARM='BC1PNCPY'          
//CONLIB   DD DISP=SHR,DSN=SYSPROD.ENDEVOR.LOADLIB   
//COMPLIST DD  DISP=SHR,DSN=&NDVRCLST   
//PDSLIST  DD DISP=OLD,DSN=&MYNDVRDS 
//SYSPRINT DD  SYSOUT=* 
//BTSERR   DD SYSOUT=*                             
//SYSUDUMP DD  SYSOUT=D
//SYSIN    DD *                                    
     COPY INPUT DDNAME=COMPLIST
              OUTPUT DDNAME=PDSLIST
              UNPACKED
      UPDATE IF PRESENT  MEMBER=&NDFAPPGM
/*

Figure 2: Abridged batch routine that expands Endevor compressed listing

The next step invokes an ISPF Edit macro to edit the expanded listing file and reformat it.

Another step invokes the Fault Analyzer utility to read the listing, parse the contents, and place the output into the appropriate side file.

After the batch job completes, the programmer can view the source within Fault Analyzer by using the appropriate IDIOPTS statements.

The Batch Job Details

Now that you know what goes on in the job, we can take a closer look at the details.

The abridged JCL to execute this job is shown in Figure 3. This example depicts the processing for a batch COBOL program. Let's look at what is going on in each of these steps.

 

//JS050    EXEC PGM=IKJEFT01                             
//SYSPROC  DD DISP=SHR,DSN=SYSUSER.ISPF.ISPCLIB     
//         DD DISP=SHR,DSN=SYSPROD.OEM.ISPCLIB         
//ISPPLIB  DD DISP=SHR,DSN=SYSPROD.IBM.ISPPLIB         
//ISPMLIB  DD DISP=SHR,DSN=SYSPROD.IBM.ISPMLIB         
//ISPSLIB  DD DISP=SHR,DSN=SYSPROD.IBM.ISPSLIB
//ISPTLIB  DD  DISP=(OLD,PASS),DSN=*.JS040.CPYOUT2      
//         DD DISP=SHR,DSN=SYS1PROD.IBM.ISPTLIB       
//ISPTABL  DD DUMMY                                    
//ISPLOG   DD DUMMY                                    
//ISPPROF  DD DISP=(OLD,PASS),DSN=*.JS040.CPYOUT1        
//SYSTSPRT DD  SYSOUT=*                                   
//SYSUDUMP DD  SYSOUT=D                                
//SYSPRINT DD  DUMMY                              
//MESSAGES DD  SYSOUT=*                                 
//SYSIN    DD  DUMMY
//SYSTSIN  DD  *
ISPSTART CMD(%EMACASEQ &MYNDVRDS(&NDFAPPGM) NDVRDBG1 &DEBUG)</p>
//*                                              
//JS060    EXEC PGM=IDILANGX,PARM='&NDFAPPGM (COBOL ERROR '
//LISTING  DD  DISP=SHR,DSN=&amp;MYNDVRDS                  
//IDILANGX DD  DISP=SHR,DSN=&amp;NDFAPSDS                      
//SYSUDUMP DD  SYSOUT=D                                    
//*                                                       
//*--------------------------------------------------------
//* CHECK TO SEE IF MEMBER NAME MATCHES PROGRAM-ID        
//*--------------------------------------------------------
//*                                                        
//JS070    EXEC PGM=IKJEFT1A,PARM='NDVRDBG2&DEBUG&'
//SYSPROC  DD DISP=SHR,DSN=SYSUSER.ISPF.ISPCLIB          
//         DD  DISP=SHR,DSN=SYSPROD.OEM.ISPCLIB         
//SYSTSPRT DD  SYSOUT=*                                   
//MESSAGES DD  SYSOUT=*                                    
//SYSTSIN  DD DUMMY                                      
//NDVRINFI DD  *                                          
)TBA 10                                               
&NDFAPPGM!&MYNDVRDS&NDFAPSDS                             
/*                                                        
//*

Figure 3: Abridged batch job to process compressed listing and create side file

The job's fifth step invokes ISPF in batch mode. The REXX ISPF Edit macro NDVRDBG1 is invoked to edit the expanded compressed listing of the program. I will discuss the details of this processing in the following section.

The sixth step invokes the IBM utility, IDILANGX, which reads the COBOL listing file and writes the appropriate records to the Fault Analyzer side file.

The seventh step invokes another ISPF Edit macro to verify that the member name matches the PROGRAM-ID in the COBOL program. This is to ensure that Fault Analyzer can process the side file correctly. If the names do not match, the Edit macro renames the side file member name to the PROGRAM-ID.

The REXX Exec

The abridged code from the Edit macro, shown in Figure 4, performs validations on the data in the listing, and creates a file that is capable of being read by the post-processor.

/* Get rid of everything before the start of the compile listing */

'Find "Invocation parameters" '

'(CurLine) = LineNum .ZCsr'

If CurLine > 2 Then Do

'Label 'CurLine-2' = .Here'

'Del .ZFirst .Here'

End

/* Get rid of everything after the end of the compile listing */

'Find "End of compilation" '

'(CurLine) = LineNum .ZCsr'

'(LineLast) = LineNum .ZLast'

If LastLine -2 > CurLine Then Do

'Label 'CurLine+2' = .Here'

'Del .Here .ZLast'

End

/* Build a string of all options used to compile the program */

'Find "Options " First' /* always start of parms */

'(CurLine) = LineNum .ZCsr'

LineFrst = CurLine + 1

'Find "ZWB" ' /* always last parm */

'(LineLast) = LineNum .ZCsr'

Do i = LineFrst to LineLast

'(DataLine) = Line 'i /* dot (.) is used as a delimiter */

If Pos('5655-G53',DataLine) > 0 Then /* Enterprise COBOL */

Iterate

If Left(DataLine,1) = 0 Then

DataLine = Word(DataLine,2)

strCobOp = strCobOp || '.' || Strip(Left(DataLine,25))

End

strCobOp = strCobOp || '.' /* here's where we get the last .*/

/* Determine if there are any options that will not work... */

Do i = 1 to strOpt.0

If Pos(strOpt.i,strCobOp) = 0 Then Do

strEFlag = 'Yes'

j = j + 1

Notify.j = strEMsg4 Strip(strOpt.i,'B','.')

End

End

If Pos('.LIST.',strCobOp) = 0 Then Do

If Pos('.OFFSET.',strCobOp) = 0 Then Do

strEFlag = 'Yes'

j = j + 1

Notify.j = strEMsg5

End

End

 

Figure 4: Abridged REXX ISPF Edit macro that processes the expanded Endevor compressed listing

Let's review what is going on in this Edit macro:
  • All of the compressed listing data surrounding the COBOL compiler listing is removed.
  • Because this is designed for COBOL programs, all of the compile-time options are placed into a single "dot-delimited" variable (as opposed to an array), for easy searching.
  • The known list of required Fault Analyzer options is compared to this variable. If any of the required options is not found, an error message is issued. However, all of the variables are still checked.
  • The file is saved.

If an error message is generated by this routine, the output is placed in the ddname, MESSAGES. A note in the SYSPRINT (and emphasized in the ISPF dialog's tutorial) directs application programmers to review this file.

After the batch job completes, the application programmer can launch Fault Analyzer and establish the appropriate set of options to analyze the abend. He or she can immediately begin problem determination by reviewing the exact line of code at which the program abended.

Conclusion

By incorporating the features of one product with the features of another, a higher degree of consistency has been achieved. I was able to take the existing, unused Endevor output file and turn it into a constructive input file for application programmers to use with Fault Analyzer.

This ISPF dialog lets application programmers focus on problem resolution, not on the need to recreate a program listing. By using this solution, application programmers are assured that they are working with a compile listing that matches the load module executing in the production (or development) environment. This results in a better use of programmer time - especially during a middle of the night production abend - and particularly if it affects the batch stream's critical path.

Application programmers who use this facility appreciate that they have a compile listing that matches their program. They do not have to worry that their compile deck is using invalid compile options, back-level system data sets, or outdated copy books. They can be more productive in a matter of a few minutes, using the program products that are available.

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.

 

 

 

 

 


No votes yet

Comments

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Lines and paragraphs break automatically.
  • You can use context links in the text to create context-related links to pages or sites that provide additional information about a word or phrase.
  • Allowed HTML tags: <br> </p> <p> <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <object> <embed> <script>
  • You can use <object>, <embed> and <script> tags from the following sites to add media to your posts:

  • Each email address will be obfuscated in a human readble fashion or (if JavaScript is enabled) replaced with a spamproof clickable link.
  • You may link to images on this site using a special syntax
  • You may quote other posts using [quote] tags.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You may link to webpages through the weblinks registry

More information about formatting options

Syndicate content