Steps for analyzing session hangs (client)

Diagnosing a Telnet client hang.

Before you begin

To assist with diagnosis of a Telnet client hang, it is helpful to be familiar with the components involved and understand which ones interface directly with each other. In the case of a Telnet from an MVS™ client to a remote host, the following occurs:
  • Data is entered by the user and then passed by VTAM® to TSO.
  • Data is passed from TSO to Telnet client code.
  • Data is transferred across the TCP/IP connection to the remote host.
  • The remote server sends data to the target application.
Note: It is suggested that a VTAM buffer trace and a Telnet client trace be run while recreating the problem for initial debugging purposes. A sample of the client trace output can be found in Figure 1. See z/OS Communications Server: SNA Diagnosis Vol 1, Techniques and Procedures or SNA Formats for more information about VTAM buffer trace output.

Procedure

Perform the following steps:

  1. Does the hang affect other Telnet clients? If so, go to Diagnosing TN3270E Telnet server problems. Otherwise, continue with Step 2.
  2. Was the last activity at the terminal input or output? If input, go to step 5. If output, continue with Step 3.
  3. Check the data in the VTAM buffer trace to see whether unlock keyboard is set on in the data stream. If unlock is set on in the data stream, the problem is in the emulator, control unit, or terminal device. If not, check the Telnet client trace to ensure the output data stream matches what is seen in the buffer trace. If the data streams match, the remote host application has not unlocked the keyboard. Contact your IBM® Software Support Center for the host application for more help with the problem. If the data streams do not match, continue with Step 4.
  4. The problem appears to be in the VTAM TSO area. Re-create the error while running the Telnet client trace, a GTF trace of SVC93 and SVC94, a VTAM TSO trace, and a VTAM buffer trace. Contact your IBM Software Support Center for assistance in interpreting the traces.
  5. Check the VTAM buffer trace to ensure input data was received by VTAM and passed to TSO. If the last data entered at the terminal is not in the VTAM buffer trace, the problem is in the PC emulation code or in the control unit. If input data is correct, continue with Step 6.
  6. Is the entered data seen in client trace output? If not, the problem is in VTAM TSO. Follow the instructions in Step 4. If data is in the client trace, the error needs to be diagnosed from the server host. See Session hangs (server) and follow the path for "last activity at the terminal was input."

Results

Documentation listed earlier, but not referenced in the previous debugging steps, can be useful in the following situations:
  • VTAM internal trace
    Note: Data is seen in "BUFF VTAM" VTAM buffer trace entry (entering VTAM from the terminal), but not in the "BUFF USER" VTAM buffer trace entry (passed from VTAM to TSO).
  • Dump of TSO user’s address space
    Note: Data is seen in the "BUFF USER" VTAM buffer trace entry, but not in the VTAM TSO trace or Telnet client trace.

Contact the IBM Software Support Center for assistance with further diagnosis when data is obtained in these situations.

Tip: Information about starting and examining traces is discussed in Step for starting Telnet client traces.
Parent topic: Session hangs (client)