z/OS Communications Server exit tracing

z/OS® Communications Server SNA exit tracing gives you a way of tracing SNA requests made from CICS®.

You can control it online, using transaction CETR. See Figure 1 for an illustration of the screen you need to use.

When CICS issues an SNA request, SNA services the request asynchronously and CICS continues executing. When SNA has finished with the request, it returns control to CICS by driving a CICS SNA exit. Every such exit contains a trace point, and if CICS SNA exit tracing is active, a trace entry is written to the GTF trace data set. GTF tracing must be active, but you do not need to start it explicitly from CICS. It is enough to start SNA exit tracing from the CETR transaction and terminal trace panel.

Note: The GTF trace data set can receive trace entries from a variety of jobs running in different address spaces. You need to identify the trace entries that have been made from the CICS region that interests you. You can do this by looking at the job name that precedes every trace entry in the formatted output.

You can use this type of tracing in any of the cases where you might want to use SNA buffer tracing, but it has the advantage of being part of CICS and, therefore, controllable from CICS. This means that you do not need a good understanding of SNA system programming to be able to use it. CICS SNA exit tracing also has the advantage of tracing some important CICS data areas relating to SNA requests, which might be useful for diagnosing problems.

Controlling CICS z/OS Communications Server exit tracing

You can turn CICS z/OS Communications Server SNA exit tracing on and off using the CETR transaction. You can specify tracing for just a single terminal, or for all the terminals in the SNA network. However, you cannot select which CICS exits are to be traced. Whenever CICS Communications Server exit tracing is running, you get a trace entry every time a CICS exit is driven by Communications Server.

If you select “normal” CICS tracing for the affected terminals at the same time as you have CICS Communications Server exit tracing running, you can then correlate CICS activities more easily with the asynchronous processing done by Communications Server.

If you must turn on CICS Communications Server exit tracing in an application owning region (AOR) while you are signed-on to a terminal in a terminal owning region (TOR), follow these steps:
  1. Invoke CETR on the AOR.
  2. Press PF5 to call up the CETR transaction and terminal trace screen.
  3. Enter the APPLID of the TOR in the NETNAME field.
  4. Complete other fields as required.
  5. Press Enter.

CICS Communications Server trace entries are always written to the GTF trace data set, and you can format them in the usual way. See Formatting and interpreting trace entries for more information. Direct all “normal” CICS tracing to the GTF trace destination as well, so you get the regular trace entries and the CICS Communications Server exit trace entries in sequence in a single data set. If you send the normal tracing to another destination, you get only the isolated traces from the exit modules with no idea of related CICS activity.

Interpreting CICS z/OS Communications Server exit trace entries

CICS z/OS Communications Server exit trace entries can be identified by their trace point IDs, which are in the range AP FC00 through AP FCFF. Not all the values in the range are used.

The format of the trace entries is similar to that shown in Interpreting extended-format CICS system trace entries. The interpretation string contains the netname of the terminal to which the trace entry relates, if the trace entry was made from a terminal-specific trace point. This makes it easy to identify the terminal associated with the Communications Server request. The trace entries also contain data from one or more selected CICS data fields, for example from the TCTTE. For guidance on interpreting the data values you might find there, see Trace entries overview.