Technical Blog Post
You have received a CICS abend, but no system dump is produced, why?
Whether a problem can be resolved in a timely manner depends heavily on the documentation, especially dumps, that can be captured at time the error occurred.
You have the choice of two different types of CICS dumps to help you with problem determination. They are the transaction dump, that only contains storage related to the transaction that abended, and the CICS system dump, that contains storage from the entire CICS region. The type of dump to use for problem determination depends on the nature of the problem. In practice, the system dump is often more useful, because it contains more information than the transaction dump. The rest of this blog entry will be concentrated on how to unsuppress the system dump.
A dump can be suppressed in various ways. Basically there are two SIT parameters that can suppress the dump globally: DAE and DUMP.
DAE (Dump Analysis and Elimination) is a z/OS level suppression, it only suppresses dumps that it believes are duplicates, or similar to one that occurred recently within a given period of time. If that's the case, you need to reset the DAE so it will allow a dump to be taken if the problem happens again. Or you could just set the DAE to No, so the system dump will not be suppressed by the MVS Dump Analysis and Elimination component.
DUMP is a CICS level SIT (System Initialization Table) parameter that is used to suppress or enable system dumps. Besides coding a value of YES for the DUMP parameter in the system initialization table, you could also use the CEMT command to change the dump option on-the-fly to allow CICS to start taking dumps without recycling the region. To change the DUMP attribute, you can issue:
- CEMT SET SYSTEM SYSDUMP
- CEMT INQUIRE SYSTEM command, and then overtype the DUMPING option from NOSYSDUMP to SYSDUMP.
If system dumps are not suppressed by either of the above mechanisms, the dump table options determine whether or not you get a dump for a particular dump code. You can inquire on transaction and system dump code attributes using CEMT INQ TRDumpcode and CEMT INQ SYDumpcode respectively. From the output screen, place the cursor against the result that you are interest in and press ENTER, CICS will display an expanded format for that dump code that is more convenient to read and overtype. Look first to see if attribute SYSDUMP is specified for the dump code. The attribute needs to be SYSDUMP if a system dump is to be taken. If the attribute is shown to be SYSDUMP, look next at the maximum number of dumps specified for this dump code, and compare it with the current number. If they are the same, it means the maximum number of dumps have already been taken, and you need to reset the current value to zero.
Below are two common commands to cause system dumps to be taken:
- CEMT SET TRDUMPCODE(trdumpcode) SYSDUMP MAX(1) ADD
- CEMT SET SYDUMPCODE(sydumpcode) SYSDUMP MAX(1) ADD
For example, if you want the region to take a system dump on abend code AD2R, you could use:
CEMT SET TRD(AD2R) SY MAX(1) ADD
If you want a dump to be taken on CICS message DFHAP0001, you could issue:
CEMT SET SYD(AP0001) SY MAX(1) ADD
I hope this information helps you get a CICS dump when it is needed!
If you would like to see the CEMT commands in this blog being entered into a CICS region, see the IBM Support TV video on YouTube that I created to answer the same question ⇒ How do you get a system dump when an abend occurs in CICS Transaction Sever?