Some Suggestions for ATBTRACE START Requests...

Given the scenarios in How APPC/MVS Handles an ATBTRACE START Request, issuing ATBTRACE START requests might seem like tedious work, but how much you have to do depends on the circumstances. For example, if you know that only one user is experiencing problems with TPA's processing, entering one START request with the USERID keyword is probably sufficient to collect all the pertinent trace data. However, if TPA's processing is dependent on correct processing between TPB and TPC, you might need to enter additional START requests for TPB or TPC as well, to collect trace data to determine whether the problem exists in the conversation between TPB and TPC.

Together with your knowledge of the TPs' processing and the symptoms that users experience, the flexibility that the API trace facility provides can help you more easily and efficiently start collecting trace data. The following list includes some suggestions that might help you decide how to use the API trace facility:

If your installation is using VTAM generic resource support for APPC/MVS LUs, use the generic resource name as the value for the LU keyword on the ATBTRACE START request. This capability means that, with only one START request, you can collect trace data when an inbound Allocate request for the specified TP arrives at any of the LUs in the generic resource group. (If the group spans systems, however, you must enter the START request on each system with a member of the generic resource group.)
z/OS MVS Planning: APPC/MVS Management contains possible security requirements related to using the API trace facility, and general information about VTAM generic resource support for the installation.
Consider invoking the ATBTRACE exec through TP profile JCL when you want to collect trace data each time the TP runs. Using TP profile JCL ensures that the START request is issued before the conversation is completely established; however, if another instance of the TP is allocated while the first instance is still running, the subsequent ATBTRACE START request will fail because the trace data set is already in use by another user.
In a production environment, when speed and efficiency are critical:
- Use TSO/E implicit or explicit invocations to start tracing. These invocation methods are ideally suited for dynamically controlling tracing activity for only a few LU/TP combinations. These methods allow you to minimize performance impact by limiting tracing activity to specific LU/TP combinations, and by limiting the amount of time tracing is active.
- If your installation is experiencing problems with multiple TPs on multiple systems, you might start traces through a high-level language program or batch job, rather than issuing multiple START requests through TSO/E. However, you could still easily stop tracing activity through TSO/E, regardless of the method you used to start tracing.