Several CICS releases ago, IBM added dump tables. And at first glance, the enhancement doesn't seem to add up to much. But when you dig deeper into how they work, CICS dump tables are useful for managing problems in online systems.
CICS dump tables definitions
CICS maintains two sets of dump tables -- one for transaction dumps written by CICS to the DFHDMPA and DFHDMPB data sets and one to manage system dumps written through SDUMP macros. These tables are dynamically built by CICS and CEMT commands. No macro or CICS System Definition file resource definitions are involved.
CICS transaction dumps.You can display CICS' transaction dump table with the CEMT INQ TRDUMPCODE command. The inquiry displays various attributes, the first of which is the four-byte transaction ABEND code. It's important to remember that codes beginning with "A" are transaction ABENDs issued by CICS when something bad happens. Those starting with "EYU" come from CICSPlex System Manager. All others belong to application transactions that have killed themselves with the EXEC CICS ABEND command.
For each transaction dump code you'll see flags that indicate if the ABEND should be accompanied by a transaction and/or system dump. Note that suppressing both types is also a valid choice.
Other fields list how many times the ABEND occurred, along with the maximum number of dumps CICS should take. You also have the option of shutting down CICS if you deem the particular ABEND gruesome enough to warrant the action. Finally, there's the dump scope flag that, if set to RELATED, sends system dump (SDUMP) requests to regions connected through MRO to the ABENDing task. I've never used this option, but I bet it'd be fun to watch if you're having a slow production day.
CICS system dumps.The CEMT INQ SYDUMPCODE command displays the system dump table. CICS identifies system dumps by the OS ABEND code or message numbers without the DFH prefix. The system dumps have most of the same attributes as transaction dumps, including the current number, the maximum, scope and CICS shutdown.
Probably the most important parameter controls whether CICS applies MVS' Dump Analysis and Elimination (DAE) to the ABEND. This is handy for sloppy applications that tend to produce a lot of system dumps. On the other hand, you should set your system dumps to NODAE if your shop is serious about first failure data capture and correcting bugs the first time they happen. Just be sure to increase your DASD budget accordingly.
Dump entries of both types can be created and discarded at will. Creating a dump table entry at startup or through automation can eliminate those dumps you know you don't want. Similarly, discarding a dump entry gives you a chance to start over with CICS' dump processing defaults. Note, however, that you create entries with the CEMT SET command as if you're modifying an existing entry, being careful to include the ADD parameter that tells CICS it's new.
Despite all this control, there are still times when CICS will dump every time, DAE suppression or not. We recently ran into a third-party product that took program checks in a CICS global user exit (GLUE). CICS treated the GLUE ABENDs seriously enough that each program check created a system dump. This problem alone got me a spot on storage management's speed dial list.
Uses for CICS dump tables
As mentioned above, it's nice that we manage these dumps, but you may wonder where the true value lies. I can think of several examples.
What if you want to shoot an application ABEND but the control blocks you need are outside the scope of a transaction dump? Create or modify the transaction dump table entry to take at least one system dump, which should include the entire region's address space. If you need an associated data space you might have to resort to automation or some way to modify the default SDUMP parameters passed by CICS.
The trick of identifying system dump codes by message number vastly expands the situations in which you can collect dumps and is much easier to use than creating automation. For instance, one of the problems with debugging short on storage (SOS) conditions is that CICS doesn't always purge the culprit and a transaction dump may not have all the information you need. But CICS issues message DFHSM0331 for SOSes beneath the 16 M line, which makes it a snap to create a system dump code of SM0131 with the system dump flag enabled. Thus configured, CICS will manfully take an SVC dump when it runs out of storage.
I'm sure everyone reading this column has undergone the frustration of finding that the one system dump needed to fix the problem was suppressed. Setting the system dump flag to NODAE quickly fixes that problem while you wait for the problem to recur. I also use the waiting period to get my story straight before I have to talk to management.
Conclusion
CICS is full of nifty things that are worth more than face value if you dig a little deeper. I have found dump tables to be very helpful when the diagnostic information I need isn't available through default channels.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at mstansberry@techtarget.com.
