DCELLI.AUG IMPLEMENTING DUMP ANALYSIS AND ELIMINATION UNDER CICS by Donald R. Celli NaSPA member Donald Celli has been in data processing since 1981. He's been a system programmer since 1983, concentrating in CICS. His experience includes MRO and non-MRO environments, with and without DL1. A component of MVS known as Dump Analysis and Elimination (DAE) provides for the elimination of unnecessary dumps. A dump is deemed unnecessary if a dump for the same symptom has already been taken. The symptoms collected by DAE are stored in SYS1.DAE and copied to the System Queue Area (SQA) when a SET DAE=xx system command is issued. The xx causes SYS1.PARMLIB member ADYSETxx to be used to control DAE start-up options. The SET DAE=xx command would normally be part of the IEACMDxx member of SYS1.PARMLIB so that DAE is automatically activated during IPL. When an SVC dump is about to be taken, or when a dump is about to be written to the dataset defined by a SYSMDUMP DD statement, DAE constructs the symptom string and scans the collection of symptoms in the SQA to see if a dump has already been processed for this problem. If so, and provided other factors do not overrule its decision, the dump is suppressed. The details of DAE are discussed in MVS/XA System Initialization and Tuning. With CICS 1.7, a global user exit in program control was introduced that allows the system programmer to implement a similar dump suppression facility. The complete source for an exit that is enabled for the XPCABND exit point is included in Figure 1. This global user exit module will simulate the actions of DAE for a CICS region. Note: This code was designed and tested under CICS Version 1.7. It should work exactly as written for CICS Version 2.1.1. Howver, I am unable to determine at this time how it would need to be modified to function under CICS 3.1. The following explains the exit design, discusses its limitations and offers ideas where it may be improved. A brief discussion of the global user exit facility is probably in order. There exist in a number of CICS management modules exit points where the system programmer can influence the normal course of action that CICS would take. This allows a certain degree of customization without actually having to (shudder) change the management module itself. A number of restrictions apply to code that executes as a global user exit. It must be written in assembly language. It may not invoke any CICS services unless the exit is part of dynamic transaction backout. It communicates its changes to the default CICS action by setting a return code in register 15. In order for user code to be invoked by the CICS exit manager, the exit must be enabled. This is accomplished with a command level ENABLE request. The parameters of the request identify to CICS the exit point (in our case, XPCABND) at which our code is to be called, the name of the program that handles the exit and a number of other details that are better explained in the CICS documentation. For a more detailed explanation of the facility, refer to the CICS/VS 1.7 Customization Guide. The exit that is used to accomplish DAE for CICS is XPCABND. This exit is invoked by the program control program (DFHPCP) just prior to invoking dump control. If, upon return from the exit, register 15 is set to zero, the dump will be taken. If, on the other hand, register 15 is set to a four, the dump is suppressed. For our dump suppression exit to work, it needs a way to keep track of the dumps that have occurred. This is accomplished by using a global area, which is acquired by CICS when the exit is enabled, to build a table of CICS dump symptom strings. When the exit is invoked, it will construct the symptom string, scan the table to see if the entry exists, and if so, suppress the dump. Included in the sample code is a limit check to ensure that the table does not overgrow the area provided. In such an event, no additional symptoms will be added, but suppression will continue for those symptoms that have been collected up to that point. The symptom string that I devised is the concatenation of transaction-id, abend code, program-id, PSW address and interrupt code. Most of these fields are obtained from the transaction abend control block (TACB) that program control constructs prior to invoking the exit. The first 24 bytes of the global area are used to construct the current symptom key. A simple table scan then looks for a matching entry. If none is found, the entry is added, provided there is room, and the dump is allowed. If a match is found, the dump is suppressed, and no further action by the exit is required. On my wish list for improving this facility is the ability to dynamically control which fields make up the symptom string. If you decide to implement the exit at your site, you should consider the types of abends that tend to happen at your shop and come up with your own dump identifiers. What works for me might be too selective, or may be not selective enough. Another bell or whistle that could be added is the unconditional suppression of less than useful abends, such as AKCT (terminal read time- out). After coding the exit, the only other requirements for incorporating it into your system are as follows: An entry must be made in the PPT (or the program must be defined via RDO), and the exit must be ENABLEd. A good approach is a program that is included in the post-initialization PLT (PLTPI) to issue the ENABLE request. Don't forget to include the global area and global area length options; The exit does check and simply puts itself to bed if no area has been provided. It is also possible for you to use CECI to issue the ENABLE request in your running system. If you have Omegamon for CICS from Candle Corporation, use the CEXD and CEXP commands to see that your exit is enabled and to find out the address of its global area. Omegamon also allows you to list the table and see that the dump symptoms are being added. /* 1050 Was this article of value to you? If so, please let us know by circling Reader Number 00.