CICS / WebSphere

CICS messages are sent to one or more destinations:

• The system console
• A terminal
• A log
• A transient data (TD) queue, such as CSMT for terminal errors and abend messages.

In addition, CICS provides the XMEOUT Global User Exit point to allow system programming interaction with the message being issued.

With each new release of CICS, new messages are introduced and existing messages are updated to reflect new functionality. Of note are the DFHAP1900 system programming interface (SPI) audit messages introduced in CICS 5.1. The SPI commands can change resource definitions dynamically, which if configured incorrectly can lead to failures. They should also be audited for reference purposes. As of CICS 5.1, a DFHAP1900 message is written to the CADS TD queue when a SET, PERFORM, ENABLE, DISABLE or RESYNC command is issued from a CICS non-system task, allowing an auditor or system administrator to monitor such commands. Note, there are some commands, such as SET TERMINAL and PERFORM SHUTDOWN, which are not audited. These exceptions are documented in the IBM Knowledge Center.


CICS transaction and system dumps provide a snapshot of storage areas within CICS at the moment they were taken. System dumps contain components of the z/OS address space, while transaction dumps are limited to transaction-related storage areas. Such detailed information is very useful in problem determination, and can be used together with trace, logs and statistics that provide information about the running of a CICS system over a period of time. As system dumps contain more information than transaction dumps, they are typically more useful and preferred by IBM support, should they be required to investigate a problem.

A dump is taken either by request of a user or in the event of a transaction or CICS abend. To request a transaction dump, issue EXEC CICS DUMP TRANSACTION from a program. Transaction dumps are written to either of the dump data sets DFHDMPA or DFHDMPB. You can determine the status of these dump data sets by entering CEMT INQUIRE DUMPDS.

In some cases you may not get a transaction dump when an abend occurs. Usually this is because either dumping is suppressed or an error occurred that prevented the dump being taken; for example, because no transaction dump data sets were available. To ensure that a dump is taken whenever possible, start your CICS region with the DUMP=YES SIT parameter and specify DUMP=YES in your transaction definitions.

Alternatively, or as a more complete debugging aid, you can request a system dump to be taken in the event of a transaction abend. You can achieve this by entering CEMT SET TRDUMPCODE(xxxx) SYSDUMP MAX(1) ADD, where xxxx is the transaction abend code. Specify a MAX value greater than the current value, which can be seen in the CUR field when entering CEMT INQUIRE TRDUMPCODE(xxxx). The same method can also be used to request a system dump is taken in the event of a CICS message being issued. You can achieve this by entering CEMT SET SYDUMPCODE(xxxxxx) SYSDUMP MAX(1) ADD, where xxxxxx is the CICS message identifier without the DFH-prefix. You can then re-create the problem that coincides with the specified transaction abend or CICS message, or wait for the problem to recur.

Conversely, it is possible to suppress dumps; for example, in cases where the solution to a problem is not yet ready to be applied, and in the meantime you do not wish to be impacted by dumps being written. You can suppress dumps for certain abend codes and messages using the CEMT SET commands described previously, but rather than specifying SYSDUMP and a MAX value, instead specify the NOSYSDUMP (or NOTRANDUMP) option.

3 Pages