Fault Diagnosis Advanced Topics 1
This tutorial will guide you through several advanced capabilities within BMC AMI DevX Abend-AID.
Table of Contents
- Starting BMC AMI DevX Abend-AID
- Adding Your BMC AMI DevX Listing Repository to Abend-AID
- Root Cause Analysis
- Extended Search
- Program Summary Screen
- Field Usage Summary Option
- Other Fields With Same Value Option
- COBOL Perform Flow
- Wrap-up
Starting BMC AMI DevX Abend-AID
To access Abend-AID for Batch within BMC AMI DevX Workbench for Eclipse:
This opens a view into Abend-AID within your BMC AMI DevX Workbench for Eclipse IDE. Integration of the tools needed for developers to do their daily jobs is a key feature of the Workbench experience.
Adding Your BMC AMI DevX Listing Repository to Abend-AID
There are two types of listing repositories that Abend-AID can use, system DDIO files and user DDIO files.
Abend-AID, by default, knows the names of the listing repositories (DDIO files) that were identified during the installation process. The installer would probably not know the names of the user DDIO files.
The Abend-AID Viewer allows users to add their own DDIO file names to the list of known DDIO files. When Abend-AID searches for the listing that matches the abending program, if the listing is found in a user-added DDIO file the listing is merged into the Abend-AID report.
We will step through the process of adding a user DDIO file so that your specific listings are available to you when working with Abend-AID. The file we want to add is called CWEZ000.TOPAZ.XPED.DDIO.
File CWEZ000.TOPAZ.XPED.DDIO was added to the user-specific source directory list. The custom source directory list is stored in an Abend-AID viewer file by TSO userid and will not need to be re-added at the next logon.
Viewing Abend-AID reports will now search the additional DDIO file as well as those specified during installation, to find the listing that matches the abended program.
Root Cause Analysis
When a program abends with a S0C7, S0C9, S0CB, or a data-related S0C4 and the program's listing is located in a DDIO file defined to the source directory, Abend-AID will generate an additional section to the Abend-Aid report named Root Cause Analysis. In some cases, Abend-AID can identify the root cause of the issue. In other cases, it may not identify the root cause, but can provide additional information which can assist the programmer in locating bad data.
Let's take a look at a SOC7 abend generated by a job named CWEZXXX to see how this may help the developer get to a resolution quickly.
In this example, a S0C7 abend occurred in a Compute statement (top red box above). The ‘Current values’ of the fields comprising the abending instruction indicate the value of H-EMP-RATE was invalid, causing the abend. In this situation a developer will need to know where the bad data exists! Since this was a data exception, Abend-AID automatically created the Root Cause Analysis to attempt to identify the location from where the bad data originated.
The Call Detail screen shows the call statement from CWAACOB1 along with the values of the arguments of the call.
If Abend-AID determines the source of the bad data, it is displayed in Item 4. In this case, Abend-AID determined that the bad data came from SA-EMP-RATE in the calling program, CWAACOB1. The report displays the value of H-EMP-RATE in CWAAHOUR and SA-EMP-RATE in CWAACOB1.
Since the bad data was passed from CWAACOB1 to CWAAHOUR, Abend-AID correlated the position in the linkage section to the position in the CALL statement and determined the source of the data.
If the bad data was not passed from a calling program, item 5 can provide some meaningful information if the bad data came from a file that was read, a DB2 table entry, or an IMS variable.
The Recommended Actions section looks at the H-EMP-RATE and identifies lines of code in the procedure division where H-EMP-RATE is modified either directly or indirectly. Also shown are data definitions that directly or indirectly reference the selected field.
Since the field was passed from the calling program, it shows that there were no lines in the procedure division that directly or indirectly modified the code. A more robust example of the Field Usage Summary will be shown later in the in the Extended Search section.
Here you can see that there are other fields that match the value.
Now, let's move on to take a look at Abend-AID's Extended Search Feature.
Extended Search
The Extended Search Listing screen can be used to search the source listing and display statements that directly or indirectly modify the selected field, or to display data definitions that directly or indirectly reference the selected field. This is especially helpful when trying to determine from where the value of a field originated.
Program Summary Screen
The Program Summary Information screen identifies all active modules involved in an abending transaction. Key identification data is summarized for each module used by a transaction up to the abending module. This screen allows you to quickly verify whether the correct version of a module is in use.
As an example, we will find out where the value of variable WMF-NUM-INPUT originated. To do so, we need to locate WMF-NUM-INPUT in Working-Storage.
The value of WMF-NUM-INPUT at the time of the abend is 0001000022. Extended Search can examine the procedure division for instructions directly or indirectly modifying WMF-NUM-INPUT.
Field Usage Summary Option
The Field Usage Summary screen has three sections:
- Modifying Statements - Direct: This section displays lines of code in the procedure division where the variable was directly modified by other variables.
- Data Definitions, either directly or indirectly: This section displays the location of the variable. If it's an elementary item within a group, the group variable is also displayed.
- Modifying Statements, either directly or indirectly: This section displays lines of code in the procedure division where the variable was modified (either directly or by other variables), OR if a higher group level were modified (like moving a variable to the group level, which would modify any elementary items below).
Here you can see the instructions in the Procedure Division where WMF-NUM-INPUT was modified. Also shown is where in Working-Storage it was defined. The line numbers are hyperlinked to give you direct access to the value of the sending field at the time of the abend.
ENT1CNOO has a value at the time of the abend of 0001000022 - the same as WMF-NUM-INPUT. Next we'll check the other two lines of code to find if there are other variables with the same value.
The value of ENT1PH1I is 999 888777 and is not the line of code that set WMF-NUM-INPUT to 0001000022. Next, let's check the last line of code that modified WMF-NUM-INPUT.
The value of ENT1PH2I is 666 555444 and is not the line of code that set WMF-NUM-INPUT to 0001000022.
There are four lines of code where ENT1CNOO is modified directly. The value of ENT1CNOO is 0001000022.
Line 1381 moves zeroes to the field and cannot be the code that set the value of ENT1CNOO.
The value of WMF-NUM-OUTPUT-910 is 0001000022; this could be the line that set value for WMF-NUM-INPUT.
The value of CA-CUSTOMER-NUM is 0001000021 - this is not the line of code that set the value for WMF-NUM-INPUT.
- Line 2018 moves zeroes to the field and cannot be the code that set the value of ENT1CNOO.
- At this point, WMF-NUM-OUTPUT-910 on line 1508 is the only variable with the same value as WMF-NUM-INPUT.
- Notice that there are additional lines of code where ENT1CNOO were modified 'directly or indirectly'. Check those lines to see if there are any additional lines of code where the sending field needs to be checked.
- The Initialize statements in lines 1374, 1375, 2057, and 2058 would not set the value of ENT1CNOO to 0001000022.
- Lines 1381 and 2018 are moving zeroes to the field.
- In lines 1509, 1575 and 1784, the value of variable CA-CUSTOMER-NUM was moved to ENT1CNOO and ENT1CNO1. We saw earlier that the value of CA-CUSTOMER-NUM was 0001000021.
You can continue to use Extended Search to find out where WMF-NUM-OUTPUT-910 was modified but, for the purposes of this Test Drive script, we will stop at this point.
Other Fields With Same Value Option
The 'Other Fields' screen can display other fields and literals that have the same value as the selected field in the Extended Search.
COBOL Perform Flow
The COBOL Perform Flow screen (instructions to view this screen are detailed over the next few pages) lists the active PERFORM PROCEDURE statement flow through the COBOL program that occurred prior to the abend; or for calling programs, the flow prior to the call. This feature is available for Enterprise COBOL only, requires the viewing server to be using the Shared Services component of BMC AMI Enterprise Common Components, and the DDIO listing to have been processed with Shared Services and the COBOL compiler option LIST.
COBOL Perform Flow reports only those PERFORM verbs that exist in the executed module. When you compile with OPTIMIZE(STD) or OPTIMIZE(FULL), any PERFORM verbs used in the source that are converted by the IBM compiler to inline code cannot be displayed.
The Perform Flow screen displays the Perform statements in the order they were executed. This can be helpful if you need to use BMC AMI DevX Code Debug to walk through the code. The sequence of Perform statements can be used to set breakpoints.
The abending line of code is highlighted. You can also go from the list of Perform statements to the specific Perform statement.
Wrap-up
This concludes our look at how Abend-AID provides powerful analysis tools and deep-dive options for data errors leading to abends. We hope that you have enjoyed your look at these capabilities and look forward to working with you to implement some or all of the solution within your systems. Please remember to complete the Test Drive survey, as both your sponsor and our team are very interested in your feedback on the Test Drive Experience.
You can choose from any of the available scripts from the panel to the left or return to the main page here: Welcome to Test Drive