Fictional detectives do not often team up to solve a particularly complex mystery; their egos are usually too great to allow such collaboration. The APPC/MVS detectives are different; they are quite compatible. To muster these detectives into an efficient mystery-solving team, consider using the following strategy:

• Using Error_Extract calls:
  • When a TP's processing varies depending on the return code from an APPC/MVS or CPI-C service call.
  • After any Allocate calls to establish a conversation with a TP. Probably the most common error is making sure your program correctly identifies the TP so that APPC/MVS can find and run it. If the TP does not get control, Error_Extract information can help you pinpoint errors in configuration.
• For a test system:
  • Setting up message logging so that a TP message log is produced for each instance of a TP, even when errors do not occur. Once the TP's execution environment appears to be relatively stable (for example, resources are being allocated correctly), reduce message logging to error situations.
  • Setting up and starting an API trace for the TP, limiting tracing activity to a few users. Once the conversation flow between the TP and its partners appears to be correct, and individual service calls are handled correctly, tracing activity can be expanded to encompass more users. More closely approximating a production environment might make interpreting trace data more difficult, but might allow you to detect more potential problems.
• For a production system:
  • Reducing message logging to a minimum. Using cumulative logs, and writing messages only for error situations, can significantly reduce storage constraints and I/O, and might prevent you from having to re-create problems to obtain diagnostic data.
  • Using the API trace facility only when errors occur. As with message logging, some performance degradation might occur during tracing, but you can limit its use to specific TPs, conversations, or users to reduce the impact to your production system.