Steps for analyzing session hangs

Determine the cause of a reported SNALINK LU0 hung terminal.

Before you begin

The first step in analysis is to determine whether the SNALINK LU0 is actually hung or if one of the sessions using SNALINK LU0 to transfer data is hung. When the SNALINK LU0 is the only connection between two hosts, an actual hang in the SNALINK LU0 application impacts all data flowing for TCP/IP. This can include TELNET, FTP, and any other application.

Procedure

Perform the following steps:

  1. Does all traffic across the SNALINK LU0 stop? A VTAM® buffer trace of the SNALINK LU0 application can be used to see whether any data is being passed. If data is still flowing on the session, the SNALINK LU0 is not hung. You need to determine which TCP/IP application or component is failing. If there is no data traffic, continue with Step 2. You can also check SNALINK LU0 traffic by doing multiple VTAM displays of the SNALINK LU0 application. The SEND and RECEIVE data count should increase for an active session. Often, using the VTAM display to obtain the status of the TRLE might provide useful information.
  2. Issue NETSTAT DEVLINKS to determine the status of the SNALINK LU0 TCP/IP device. If the NETSTAT output shows that the application is trying to connect, check the VTAM and SNALINK LU0 consoles for information about a previous error or abend. If NETSTAT indicates "negotiating," verify the session type. You might require a session_type of SINGLE; see the z/OS Communications Server: IP Configuration Reference for information about configuring session types. If NETSTAT indicates “connected” or “sending,” continue with Step 3.
  3. At this point, you should determine the last SNALINK LU0 activity or processing. This is best accomplished with the debug trace. Contact your IBM® Software Support Center with information about the last activity from the SNALINK LU0 console and debug trace.
Parent topic: Session hangs