The headings that follow describe dumps produced by CICS®, the DRA, and DBCTL.
This dump is produced whenever a CICS task terminates abnormally. For a CICS-DBCTL task, that is, a task which has issued a DFHRMCAL request to DFHDBAT, this dump includes:
The recovery token for the task at the point of abnormal termination appears in the TCA (TCARTKN).
The EXEC CICS SET TRANDUMPCODE command and the CEMT SET TRANDUMPCODE transaction enable you to change some of the values recorded in entries in the transaction dump code table, to add new entries to the table, and to remove existing entries from the table. For example, you can specify an action for a particular CICS message, as mentioned in Figure 39.
For information about transaction dump codes, and interpreting CICS dumps, see the CICS Problem Determination Guide.
This dump is produced when a CEMT PERFORM DUMP|SNAP or an EXEC CICS DUMP SYSTEM command is issued, or when CICS abends. CICS specifies all options when issuing this type of dump, for example, CSA and NUC. All MVS™ control blocks appear in this type of dump, including those corresponding to any subordinate TCBs. You can format and analyze this type of dump using the interactive problem control system (IPCS). For guidance on using IPCS, see the OS/390 MVS IPCS User’s Guide.
The EXEC CICS SET SYSDUMPCODE command and the CEMT SET SYSDUMPCODE transaction enable you to change some of the values recorded in entries in the transaction dump code table, to add new entries to the table, and to remove existing entries from the table. For example, you can specify an action for a particular CICS message, as mentioned in Figure 39.
For information about system dump codes, and interpreting CICS dumps, see the CICS Problem Determination Guide.
To help you determine whether a problem is occurring in DBCTL or CICS, examine the CICS transaction or system dump. These dumps include indications of the point at which DFHDBAT passes control to DBCTL and the point at which DBCTL returns control to DFHDBAT. Correlating this with the time at which the problem occurred should tell you whether it was in CICS or DBCTL.
Each page of auxiliary trace output also includes a timestamp, as mentioned in Connection to DBCTL. These timestamps should also help you correlate events in CICS with events in DBCTL.
The DRA’s snap data set is dynamically allocated to the CICS address space when DBCTL is connected. The SYSOUT class used is determined by a parameter in the DRA startup table. The DRA dumps its control blocks (those associated with its own work unit and that of DBCTL) to this data set whenever a high order bit is set in PAPLRETC. (The participant adapter parameter list (PAPL) is a part of the DRA. For guidance on the PAPL and its contents, see the appropriate IMS Customization Guide.) The high order bit is set on if a thread is terminating. It then closes the snap file. The recovery token appears in the dump produced.
When a transaction abends or requests a dump, the following areas are written to the CICS dump data set(s):
DBCTL creates an SDUMP containing diagnostic information for a DL/I request failure from CICS using the system dump data sets from the CICS job.
The DRA produces an SDUMP in the following situations:
However, the DRA does not always take a dump if DL/I sets the high order bit in PAPLRETC. If it does not, it sets the second high order bit on to indicate this. For example:
(See Return codes in DBCTL, Using return codes to find out what kind of dump has been produced and PAPL request and return codes for information on interpreting these return codes.)
An SDUMP is created in a terminate address space request or a terminate thread request while running in DBCTL and under the DRA TCB.
If the SDUMP request fails, a SNAP dump (which contains a subset of the information in an SDUMP) is produced instead. (See Return codes in DBCTL.) The SNAP contains the following subset of the information produced in an SDUMP:
Because the DRA runs in problem state, it cannot access other storage areas, such as CSA or DBCTL storage. This may mean that the SNAP does not contain enough information, and you may have to recreate the failure and use the DBCTL address space dump.
See the IMS Diagnosis Guide and Reference manual manual for a further comparison of the information produced in SDUMPs and SNAP dumps, which you may find useful in diagnosis. The IMS Diagnosis Guide and Reference manual manual also contains information on the IMS™ offline dump formatter (ODF) which you can use to show the layout of IMS blocks referred to in these dumps.
The formatted dump feature of IMS is available with DBCTL. This feature formats the system, database, and data communication areas of IMS. It formats the control blocks and data areas in an IMS region.
See the IMS Diagnosis Guide and Reference manual manual for guidance information on the areas that are dumped.
Control blocks generated by DBCTL have an "eyecatcher" for visual identification. For example:
The recovery token is included in dumps produced by DBCTL. Output is to the IMS log.