The following suggestions might help you determine the most efficient, easiest ways to approach API tracing. Some might not be feasible for your installation, but experiment if you can, especially in a testing environment. What you learn under those conditions might easily help you use API tracing most efficiently, when efficiency is most important — during emergency situations in a production environment.

• Do not use a specific block size for trace data sets; allow APPC/MVS to determine the optimal size, to reduce or eliminate the need to suspend tracing activity.
• Overestimate the primary space you need for the trace data set, or use a tape data set and later switch to DASD, especially when first testing a TP. Doing so reduces the chances of wrapping trace entries, and possibly reduces the length of the trial-and-error period to determine the size of an average trace data set for tracing your installation's set of TPs.
• Limit the number of unique LU/TP combinations being traced into a particular data set. For example, use the optional USERID parameter to restrict tracing activity to only specific users. Such limits can prevent:
  • Loss of trace data through wrapping or suspension of tracing activity
  • Complexity of interpreting trace data
  • Adverse effects on performance.
• Try to limit the number of programmers sharing a data set for concurrent traces. This tactic is another way to limit the number of unique LU/TP combinations for a particular data set, so it offers the benefits of that limitation, as well as improving productivity:
  • You can view trace data as soon as you stop the tracing activity for the data set; you do not have to worry about having someone prematurely stop your trace, or about doing the same to another programmer.
  • You do not have to separate your trace data from someone else's, as well as sorting the trace data for separate conversations.