As a general rule, the documentation you submit for an APAR should include all the material you would normally use to do problem determination. Some of the documentation is common to all CICSPlex® SM problems, and some is specific to particular types of problems.
Make sure the problem you have described can be seen in the documentation you send. If the problem has ambiguous symptoms, you should document the sequence of events leading up to the failure. Tracing is valuable in this respect, but you might be able to provide details that a trace cannot give. You are encouraged to annotate your documentation, provided your annotation is legible and does not cover up any vital information. You can highlight data in any hard copy you send, using transparent highlighting markers. You can also write notes in the margins, preferably using a red pen so that the notes are not overlooked.
Remember, if you send too little documentation, or if it is unreadable, the change team will have to return the APAR. Be sure to prepare your documentation carefully and send everything related to the problem.
Guidelines for the general documentation you will need are shown in Documentation needed for problems with CICSPlex SM. However, you must find out from the Level 2 representative exactly what documentation you need to send for your specific problem.
Here is a list of the general documentation you might be asked to submit for a CICSPlex SM APAR:
For example: if you are using the EXEC CPSM application programming interface (API); if you are calling or customizing the dynamic transaction routing program, EYU9WRAM; or if you are using real-time analysis status probes, the Support Center needs a source listing of the relevant code that matches the executable version.