CICS trace: Getting started, formatting and externalizing

Of course, internal tracing comes with overhead. In my own experience, turning trace off saved about 10 to 15% CPU at the transaction level. This is probably why IBM sometimes recommends turning the trace off in production systems. At our own shop, we leave trace off except in regions that support critical applications where we can't afford to have the same problem twice.

Externalizing CICS trace

Since internal trace is ephemeral, there are two ways to externalize trace entries without a dump: auxiliary and GTF trace.

When auxiliary trace is active, CICS writes the entries to the auxiliary trace datasets DFHAUXT and DFHBUXT. Once captured the trace entries must be formatted with the CICS trace utility, DFHTUxxx where "xxx" is CICS' release level. You can select the detail level and trace types of the printed entries. Perhaps even more useful, you can control the utility's output by resource names such as transaction or terminal ID.

You may control auxiliary trace with the CEMT S AUX command or these SIT parameters:

Auxiliary trace has a lot of overhead. As I know from experience, you don't want to start it on a busy system in the middle of the day because it will have a direct impact on performance. Therefore, in production it should be used in circumstances that are limited and easily controlled. If that's too difficult, try to duplicate the problem in test and take your trace there.

My favorite way to externalize trace entries is through MVS' General Trace Facility (GTF) where CICS writes trace records to the GTF trace table. This is very useful if you need to collect debugging information involving several CICS regions or other system components. In my experience, it also causes less overhead than auxiliary trace. The only catch is you have to run MVS' GTF trace capture utility program (AHLGTF) during the activity you want to capture.

Formatting CICS trace

Once you capture the trace information you may format it with the IPCS GTF subcommand. Here is the format:

GF USR(F6C) CICS((xxxx))

Note that you must specify "USR(F6C)" to tell IPCS to invoke CICS' dump utility program. This also means the dump utility program (DFHDUxxx where "xxx" is the release) must be in STEPLIB, ISPLLIB, LPA or the link list. The "CICS" parameter allows you to specify trace record using the same syntax as the auxiliary trace utility. However, you should consult the IPCS User's Guide because not all choices are available.

GTF trace is controlled through the GTFTR SIT parameter. Again, it can be handy to turn on GTF trace when CICS initializes if you have a PLTPI problem. You can also use transaction CETR.

CICS' trace facility can be a profound tool for understanding application and system behavior, given the amount of information it provides. I would recommend turning it on at any odd, idle moment when you want to know more about what makes CICS click, but maybe not in production. They may have taken the source away from us, but we still have the trace.

ABOUT THE AUTHOR: Robert Crawford has been a CICS systems programmer off and on for 24 years. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.