Effective Cross-Product Utilization: Revisited

nid

4333

vid

6775

type

naspa_articles

status

1

created

1201118306

changed

1203001709

comment

2

promote

0

sticky

0

revision_timestamp

1203001709

title

Effective Cross-Product Utilization: Revisited

body

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. <h2>Introduction</h2> 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. <h2>Background</h2> 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. <h2>The ISPF Dialog</h2> 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. [img_assist|nid=4332|title=Figure 1|desc=|link=none|align=left|width=400|height=300] Figure 1: Endevor - Fault Analyzer data entry panel <h2>An Overview of the Batch Processing</h2> 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.   <code> //* //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 /* </code> 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. <h2>The Batch Job Details</h2> 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.   <code> //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) //* //JS060 EXEC PGM=IDILANGX,PARM='&NDFAPPGM (COBOL ERROR ' //LISTING DD DISP=SHR,DSN=&MYNDVRDS //IDILANGX DD DISP=SHR,DSN=&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 /* //* </code> 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. <h2>The REXX Exec</h2> 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 listingLet's review what is going on in this Edit macro: <ul><li>All of the compressed listing data surrounding the COBOL compiler listing is removed.</li><li>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.</li><li>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.</li><li>The file is saved.</li></ul> 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. <h2>Conclusion</h2> 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.

teaser

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.

log

Copy of the revision from Tue, 01/29/2008 - 2:10pm.

format

7

uid

2184

name

jkasza

picture

data

a:27:{s:5:"roles";a:1:{i:0;s:1:"2";}s:13:"AMISDB_MBRPFX";s:1:" ";s:13:"AMISDB_MBRFNM";s:5:"Jenny";s:12:"AMISDB_MBRMI";s:1:" ";s:13:"AMISDB_MBRLNM";s:5:"Kasza";s:13:"AMISDB_MBRSFX";s:1:" ";s:12:"AMISDB_EMAIL";s:16:"editor@naspa.com";s:12:"AMISDB_mtype";s:5:"STAFF";s:15:"AMISDB_orgmbrdt";s:10:"08/08/2006";s:15:"AMISDB_trmstart";s:10:"08/08/2006";s:13:"AMISDB_trmend";s:10:"07/31/2010";s:15:"AMISDB_COMPBILL";s:3:"TEI";s:15:"AMISDB_ADDRBILL";s:18:"7044 S 13TH STREET";s:15:"AMISDB_CITYBILL";s:9:"OAK CREEK";s:16:"AMISDB_STATEBILL";s:2:"WI";s:15:"AMISDB_CTRYBILL";s:3:"USA";s:15:"AMISDB_COMPMAIL";s:3:"TEI";s:15:"AMISDB_ADDRMAIL";s:18:"7044 S 13TH STREET";s:15:"AMISDB_CITYMAIL";s:9:"OAK CREEK";s:16:"AMISDB_STATEMAIL";s:2:"WI";s:15:"AMISDB_CTRYMAIL";s:3:"USA";s:8:"og_email";s:1:"1";s:14:"tinymce_status";s:4:"true";s:14:"picture_delete";s:0:"";s:14:"picture_upload";s:0:"";s:7:"contact";i:1;s:5:"block";a:5:{s:4:"book";a:1:{i:0;i:1;}s:4:"menu";a:1:{i:2560;i:1;}s:15:"taxonomy_ticker";a:1:{i:0;i:1;}s:4:"user";a:1:{i:3;i:1;}s:10:"statistics";a:1:{i:0;i:0;}}}

primary_term

last_comment_timestamp

1201118306

last_comment_name

comment_count

0

taxonomy

Array
(
    [76] => stdClass Object
        (
            [tid] => 76
            [vid] => 5
            [name] => COBOL
            [description] => 
            [weight] => 0
        )

    [41] => stdClass Object
        (
            [tid] => 41
            [vid] => 5
            [name] => ISPF
            [description] => 
            [weight] => 0
        )

    [1302] => stdClass Object
        (
            [tid] => 1302
            [vid] => 5
            [name] => Legacy
            [description] => 
            [weight] => 0
        )

    [332] => stdClass Object
        (
            [tid] => 332
            [vid] => 18
            [name] => Kahm, Larry
            [description] => 
            [weight] => 0
        )

    [558] => stdClass Object
        (
            [tid] => 558
            [vid] => 14
            [name] => Network Support - April-May, 2006
            [description] => 
            [weight] => 0
        )

)

files

Array
(
)

field_author

Array
(
    [0] => Array
        (
            [value] => Larry Kahm
        )

)

field_description

Array
(
    [0] => Array
        (
            [value] => This article takes a look at how one site incorporated some of the features of their change management system with the features of their dump analysis tool with the goal of helping application programmers determine the cause of development and production abends. 
            [format] => 1
        )

)

field_article_pdf

Array
(
)

field_item_type

Array
(
    [0] => Array
        (
            [value] => Article
        )

)

field_article_cost

Array
(
    [0] => Array
        (
            [value] => 250
        )

)

field_temppdf

Array
(
    [0] => Array
        (
            [value] => 
        )

)

iid

links_related

Array
(
)

moderate

0

User login

Sections

Who's online

Syndicate