If you have been unable to get the trace output you need, you can find guidance about solving the problem in this section. You can be very selective about the way CICS® does tracing, and the options need to be considered carefully to make sure you get the tracing you want.
There are two main types of problem:
In terms of destinations, CICS system trace entries belong to one of three groups:
For CICS system tracing other than exception traces and CICS VTAM exit traces, you can inquire on the current destinations and set them to what you want using the CETR transaction.
Figure 23 illustrates what you might see on a CETR screen, and indicates how you can change the options by overtyping the fields. From that illustration you can see that, from the options in effect, a normal trace call results in a trace entry being written to the GTF trace destination. If an exceptional condition occurred, the corresponding exception trace entry would be made both to the GTF data set and to the internal trace table, even though the internal trace status is STOPPED.
Note that the master system trace flag value only determines whether standard tracing is to be done for a task (see Table 26). It has no effect on any other tracing status.
Internal tracing goes to the internal trace table in main storage. The internal trace table is used as a buffer in which the trace entries are built no matter what the destination. It, therefore, always contains the most recent trace entries, even if its status is STOPPED--if at least one of the other trace destinations is currently STARTED.
Auxiliary tracing goes to one of two data sets, if the auxiliary tracing status is STARTED. The current data set can be selected from the CETR screen by overtyping the appropriate field with A or B, as required. What happens when the data set becomes full is determined by the auxiliary switch status. Make sure that the switch status is correct for your system, or you might lose the trace entries you want, either because the data set is full or because they are overwritten.
GTF tracing goes to the GTF trace data set. GTF tracing must be started under MVS™, using the TRACE=USR option, before the trace entry can be written. Note that if GTF tracing has not been started in this way, the GTF tracing status can be shown as STARTED on the CETR screen and yet no trace entries are made, and no error condition reported.
There are several ways in which you might capture the wrong trace data. The following are some sets of symptoms that suggest specific areas for attention:
If you are aware of symptoms like these, it is likely that you do not have the right task tracing options set up. Turn to You are not getting the correct task tracing for further guidance.
If you have this sort of problem, turn to The entries you want are missing from the trace table for guidance about finding the cause.
It is worth remembering that the more precisely you can define the trace data you need for any sort of problem determination, the more quickly you are likely to get to the cause of the problem.
If you are not getting the correct task tracing, use the CETR transaction to check the transaction and terminal tracing options, and if necessary change them.
You can define whether you want standard or special CICS tracing for specific transactions, and standard or special tracing for transactions started at specific terminals. You can also suppress tracing for transactions and terminals that do not interest you. The type of task tracing that you get (standard or special) depends on the type of tracing for the corresponding transaction-terminal pair, in the way shown in Table 25.
You can deduce from the table that it is possible to get standard tracing when a transaction is initiated at one terminal, and special tracing when it is initiated from another terminal. This raises the possibility of setting up inappropriate task tracing options, so the trace entries that interest you--for example, when the transaction is initiated from a particular terminal--are not made.
If you are not getting the correct component tracing, use the CETR transaction to inquire on the current component tracing options and, if necessary, to change them.
First, check that you are only tracing components that interest you. If some other components are being traced, change the options so they are no longer traced for standard tracing or for special tracing, as appropriate.
Next, check that the right tracing levels have been defined for standard tracing and special tracing. Remember that, whenever a task that has standard tracing is running, the trace points that you have defined as standard for a component are traced whenever that component is invoked. Similarly, special trace points are traced whenever special task tracing is being done.
Table 26 illustrates the logic used to determine whether a trace call is to be made from a trace point.
If you are satisfied that the component tracing selectivity is correct but you are still getting too much or too little data, read You are not getting the correct task tracing.
Read this section if one or more entries you were expecting were missing entirely from the trace table.
These cases are considered:
If the trace entry did not appear at the expected time, consider these possibilities:
When you select trace entries by specifying TRANID or TERMID parameters in the DFHTU640 trace control statements, DFHTU640 searches for any transaction attach trace entries that contain the specified TRANID or TERMID. It then formats any associated trace entries, identified by the TASKID found in the transaction attach trace entry data.
It follows that you must have KC level-1 tracing selected for the task in question at the time it is attached if you want to format the auxiliary trace data set selectively by transaction or terminal.
For more details about trace formatting using DFHTU640, see the CICS Operations and Utilities Guide.
If the options were correct and tracing was running at the right time, but the trace entries you wanted did not appear, it is likely that the task you were interested in did not run or did not invoke the CICS components you expected. Examine the trace carefully in the region in which you expected the task to appear, and attempt to find why it was not invoked. Remember also that the task tracing options might not, after all, have been appropriate.
If the earliest trace entry was later than the event that interested you, and tracing was running at the right time, it is likely that the trace table wrapped round and earlier entries were overwritten.
Internal trace always wraps when it is full. Try using a bigger trace table, or direct the trace entries to the auxiliary trace or GTF trace destinations.
Auxiliary trace switches from one data set to the next when it is full, if the autoswitch status is NEXT or ALL.
If the autoswitch status is NEXT, the two data sets can fill up but earlier data cannot be overwritten. Your missing data might be in the initial data set, or the events you were interested in might have occurred after the data sets were full. In the second case, you can try increasing the size of the auxiliary trace data sets.
If the autoswitch status is ALL, you might have overwritten the data you wanted. The initial data set is reused when the second extent is full. Try increasing the size of the auxiliary trace data sets.
GTF trace always wraps when the data set is full. If this was your trace destination, try increasing the size of the GTF trace data set.
If you cannot find an exception trace entry that you expected, bear in mind that exception tracing is always done to the internal trace table irrespective of the status of any other type of tracing. So, if you missed it in your selected trace destination, try looking in the internal trace table.