CICS has been continually developed and enhanced during its lifetime, and its problem determination data has also been extended and improved during that time. Facilities such as z/OS system dumps, internal and external tracing, exception trace data and built-in diagnostic trap mechanisms, together with a rich set of first failure data capture messages, journaling and SMF data, are all available to assist in problem determination, both at an application and at a system level.
This article, the first of two, focuses on the message and dump problem determination facilities provided with CICS, and gives details on how they may be used and what they can offer in assisting with system problem analysis.
If you encounter a problem with a CICS system, an initial step in identifying the cause is to look at the messages that have been issued.
CICS messages are prefixed with DFH (for CICS), EYU (for CICSPlex SM) or AXM (for the authorized cross-memory server environment). The DFH messages conform to one of two standardized formats: DFHnnnn or DFHccnnnn. DFH, the IBM identifier for CICS modules, is followed by either a fourdigit message number, or two-letter CICS domain or component identifier and four-digit message number. These message identifiers are unique, making it easy to find the description of each message in the documentation that accompanies CICS.
If you have access to a running CICS system, you can use the CMAC transaction to display the description of a CICS message. The description typically includes an explanation of the events leading up to the production of the message, the action that has been or will be taken by CICS and action that you can take. In addition, all messages are described in the CICS Messages and Codes manuals, and the IBM Knowledge Center (which is the recommended reference point for CICS documentation).
CICS messages may be suffixed by action or severity codes. Action codes immediately follow the message number (for example, DFHDB8208D) and provide guidance of the type of action needed. The action codes used are:
• I – Where no action is required
• E – For eventual action, which is required but does not have to be taken immediately
• A – For immediate action, such as mounting a tape
• D – For immediate decision, such as a reply to a request.
Severity codes indicate whether the associated message is reporting an error, and if so, how serious it is. DFHST0210 I is an example of a message identifier, followed by a severity code. The following severity codes are used:
• I – For information only. No action is required.
• W – For an alert. Something may have gone wrong; for example, a program loop, but CICS processing continues.
• E – For an error. Action is required before CICS processing can continue.
• S – For a severe error. CICS processing is suspended until action is taken.