Steps for analyzing session hangs (server)

Determine why a session hangs after it was successfully connected.

About this task

The preceding traces are essential to finding the reason for the session hang. Data entered at the client terminal is sent to Telnet on the TCP/IP connection. The TCP/IP packet trace shows the data arriving at or leaving the stack. CTRACE with the option Telnet specified shows the data coming into and out of Telnet (from both the stack and VTAM®). Some processing steps during this time are also included in the trace. The CTRACE with Telnet option shows what Telnet does with this data.

The VTAM buffer trace shows the data as received by VTAM to be forwarded to the host application. Following the data flow through the traces between VTAM, TCP/IP, and Telnet provides an indication of where the problem is occurring.

The following list suggests information to check in the traces. See z/OS Communications Server: SNA Diagnosis Vol 2, FFST Dumps and the VIT or SNA Formats for more information about VTAM buffer trace output.

Procedure

Perform the following steps:

  1. Does the packet trace show data passed to TCP/IP? If not, the problem is in client or emulator code. If data is in the trace, continue with Step 2.
  2. Does CTRACE with TELNET option show data passed to Telnet? The TELNET option shows data coming into Telnet from the stack and also going out to VTAM (the reverse for outbound data). If not, the error is in the TCP/IP platform code. Otherwise, continue with Step 3.
  3. Does VTAM buffer trace show data passed from Telnet? If not, problem is in the Telnet code. Otherwise, continue with Step 4.
  4. Does VTAM buffer trace show data passed to host application? If not, problem is in VTAM code. If buffer trace shows correct data, continue with Step 5.
  5. Does the buffer trace show data coming from the host application? If not, the problem is in the host application. Contact your host application support center for these products. Otherwise, continue with Step 6.
  6. Does the buffer trace show data sent back to the Telnet LU? If not, the problem is in VTAM. Otherwise, continue with Step 7.
  7. Is the last data from the application seen in the CTRACE with TELNET option output? If not, the problem is in Telnet. Otherwise, continue with Step 8.
  8. Does the packet trace show the data sent to the client? If not, the error is in TCP/IP platform. Otherwise, continue with Step 9.
  9. Check the data in the packet trace output to see whether unlock keyboard is set on in the data stream. If unlock is set in the output data, the problem is in the emulator or client code. Otherwise, continue with Step 10.
  10. Check the last data received by the Telnet LU in the VTAM buffer trace. If unlock is set in that data stream, or end bracket or change direction is set in the RH, the problem is in the Telnet code. If none is set, the host application did not allow for unlocking of the keyboard. Contact your host application software support.

Results

If the preceding problem determination shows the error to be in the TCP/IP platform or Telnet code, a dump is needed to allow a more detailed investigation of the problem.