CICS Trace

CICS trace records a step-by-step history of what CICS did. When a transaction fails or hangs, trace shows the exact path it took and where it stopped.

Types of trace

• Internal trace keeps recent trace entries in a memory table inside the CICS region. It is always available but holds only limited history.
• Auxiliary trace writes trace entries to a dataset. It holds much more history and survives a CICS restart.
• GTF trace writes trace entries to the system GTF dataset. It is used when the problem spans CICS and other subsystems.
• Exception trace records only errors and unusual events. Keep it on always; it costs very little.

Controlling trace with CETR

• CETR is the CICS transaction that controls tracing. Type CETR on a terminal to open its panels.
• You can turn standard and exception tracing on or off, and choose which CICS components are traced.
• Trace only the components related to your problem. Tracing everything slows CICS down and fills datasets fast.
• Increase the internal trace table size with the TRTABSZ SIT parameter when you need longer in-memory history.

CEDF - Execution Diagnostic Facility

• CEDF is the CICS debugger for transactions. Type CEDF on, then run your transaction to step through it command by command.
• It shows each EXEC CICS command before it runs, lets you view and change working storage, and lets you suppress commands.
• Never leave CEDF on for all users in production. It pauses every transaction and looks like a hang.

Example: writing your own trace entry

• A program can write a user trace entry with EXEC CICS ENTER TRACEID. This helps you follow your program logic in the trace.
• WORKING-STORAGE SECTION. 01 WS-TRACE-DATA PIC X(30) VALUE 'ABOUT TO UPDATE ORDER FILE'. PROCEDURE DIVISION. EXEC CICS ENTER TRACEID(999) FROM(WS-TRACE-DATA) RESOURCE('ORDFILE') END-EXEC.
• TRACEID is a user number. FROM holds your message and RESOURCE names the related resource.
• Search the formatted trace for your trace id to find exactly where your program was.