Step 2. Identify the failing component

When you are sure of the exact nature and extent of the problem that you are trying to solve, you must identify which component in the network is failing. You might have strong suspicions about this already, but if not, or you want to confirm your suspicions, continue as follows:
  1. Identify the components of the network that are involved in the request.

    For example, the request might flow from your CICS® region, across TCP/IP to a PPC gateway, then from the PPC gateway through an SNA network to arrive in a mainframe CICS/ESA system where it is to be run.

  2. Check whether each component is running. If a component is running, check whether it has produced any error or attention messages. (Refer to Table 1 for some suggestions about where to look for diagnostics.)
Table 1. Sources of information for following the path of a request
Type of request Local CICS messages (console.msg and CSMT.out) PPC Gateway server messages SNA link trace Remote system's message
TCP/IP intersystem request with CICS family TCP/IP or IPIC support over TCP/IP Yes     Yes
PPC Gateway server configuration Yes Yes    
PPC Gateway server/SNA intersystem request Yes Yes Yes Yes
Local SNA intersystem request Yes   Yes Yes
Note: CICS messages are described in TXSeries for Multiplatforms Messages and Codes. They are very useful in intersystem PD because:
  • They log information on the failing request.
  • During region startup, messages are logged that describe the network name and protocols that the region uses and any errors that are detected in the communication configuration (such as LD, CD and GD entries).

PPC Gateway server messages are described in PPC Gateway server message descriptions.

It is possible that several components have reported the error. However, it is usually the component that initially detects the error that gives the most precise diagnostics. Refer to the message descriptions because they might give you the exact cause of the error.

If the messages do not identify the problem, try turning on the trace in each component and rerunning the failing request. Traces show the calls and responses that are being passed between the different components that might highlight a bad parameter or return code. They tend to be designed for developers of the product and so are not easy to read without the product design information. However, the trace will tell you whether the request even reached a particular component. If you find that the request failed before reaching the remote system, concentrate your suspicions around the component that rejected the request. Check the configuration of this component. Also refer to the information that is given in Common intercommunication errors because it might describe the failure that you are seeing.

If you still cannot determine what is wrong, refer to Getting further help because you need help from the service representative.