This article provides an overview of the primary options available for CICS problem determination and diagnosis. The various techniques described can apply to both application and systems programming problems as well as to investigation of problems in CICS itself.
The trace (TR) domain handles general CICS tracing. It traces the flow of execution through CICS code and your applications. CICS can help identify the EXEC CICS Application Program Interface (API) commands and resources your applications use. It’s an essential debugging aid.
CICS supports tracing to an internal trace table, held above the 16MB line in the CICS address space, and an auxiliary trace destination. Auxiliary trace is written to a CICS-owned BSAM data set or data sets. Both destinations can fill up as CICS writes trace entries. When this occurs, trace data can wrap and overwrite older trace data. CICS also supports tracing to GTF.
CICS trace points generate CICS trace entries. These are embedded at specific points in CICS code; from these points, trace entries can be written to any currently selected trace destination. Most trace points are used to trace mainline execution of CICS code. Typically, mainline trace points have an associated trace level. Trace levels can vary in value from one to 32, but nearly all mainline trace points have a trace level of one or two.
qLevel-1 trace points are designed to give you enough diagnostic information to fix user errors. They’re located on entry to, and exit from, every CICS domain and major internal domain functions. The information traced includes parameters passed on the call and any output.
Level-2 trace points are situated between level-1 trace points; they provide information that’s likely to be more useful for fixing errors in CICS code itself. You probably won’t want to use level-2 trace points yourself, unless you’re requested to do so by IBM support staff as part of problem investigation.
CICS always performs exception tracing when it detects an exception condition. The exception trace points don’t have an associated ”level” attribute, and trace calls are made from them only when exception conditions occur. You can’t prevent CICS exception tracing even if you have all other CICS tracing turned off. Exception tracing is always written to the CICS internal trace table and, if enabled, to CICS auxiliary trace data set(s). The aim is for First Failure Data Capture (FFDC) and to record data that might be relevant to the exception as soon as possible after it has been detected. Preventing exception trace entries from being disabled ensures the FFDC trace data is always available for analysis.
CICS tracing can be controlled via SIT parameters or interactively with the CICS supplied transaction, CETR. Both methods let you specify the amount of tracing to be recorded, the trace level(s), and trace destination(s). CICS internal tracing can be formatted in a CICS transaction or system dump. CICS auxiliary tracing can be formatted by the auxiliary trace formatting batch program supplied with CICS. For CICS Transaction Server 3.1, this is DFHTU640. The suffix of the name corresponds to the release number of the CICS being used. CICS GTF tracing is an invocation of z/OS GTF trace, and the trace entries are directed to a destination defined to z/OS. This can be either a trace table in main storage or a single external GTF trace data set.
Figure 1 shows an example of the main control panel that’s displayed when the CETR transaction runs.