This information provides documentation requirements and diagnosis procedures for problems with hung terminals. Use this information if this problem occurs while you are using TSO/VTAM. This procedure helps you determine when the hang occurred and what was happening at that time.

1. If the problem occurs during logon or logoff, get the recommended documentation and go to Reporting the problem to IBM.
   The recommended documentation is:

   • VTAM® full buffer contents trace.

     To see the data in the buffer contents trace, set CONFTXT=NO in the TSOKEY00 member of SYS1.PARMLIB before starting TSO/VTAM.

   • GTF trace of SVC 93 and SVC 94 entries. See Table 1 to determine what document describes the SVC 93 and SVC 94 entries.
   • TGET/TPUT trace.

     The TGET/TPUT trace creates trace entries for all TGET/TPUT/TPG data except address space ID TPUTs.

     You can get the TGET/TPUT trace by issuing the MODIFY TRACE command with TYPE=TSO. The MODIFY command is described in z/OS Communications Server: SNA Operation.

   • Dump of the nucleus, CSA, and user's address space.

     If you think you might not be able to re-create the problem, take a dump before you try to clear the hang.

     If input (such as ATTN, RESET, or ENTER) clears the hang, both a dump and traces may be necessary. You may want to start the traces, take a dump with the terminal hung, clear the hang, and then stop the traces.

   • Collect additional general information:
     • Try to determine whether the error is related to a certain type of hardware or a certain protocol (SNA or non-SNA).
     • Try to determine whether the hang is related to a particular application program or type of application program (full-screen, graphics, and so on).

       If so, do other similar types of applications also hang?

2. Was the last data that was sent from the application program to VTAM sent to the terminal before the hang occurred?

   To determine this, look for a VTAM buffer contents trace entry that corresponds to the last TPUT trace entry.

   If you see these corresponding entries, the output was sent to the terminal.

3. If the keyboard locked after data was sent to the terminal, check the outbound buffer contents trace entry for:
   • Bracketing indicators in RH byte 2
   • Change direction indicator in RH byte 2
   • Write control character to unlock the keyboard in byte 2 of the output request unit

   If an end bracket was sent, the keyboard should be available.

   If a change direction was sent and the keyboard has been unlocked, the keyboard should be available.

   If a TGET is issued after a full-screen TPUT, TSO/VTAM should unlock the keyboard.

4. If the keyboard has not been unlocked, see what TPUT was issued last. (The option flag bytes in the TPUT entry show what TPUT it is.)
   • For a NOEDIT or TPG TPUT, TSO/VTAM will not unlock the keyboard. The application program is supposed to send a write control character to unlock the keyboard.
   • For other TPUT options, determine whether a TGET is outstanding.

     If a TGET is outstanding, TSO/VTAM should unlock the keyboard.

     If no TGETs are outstanding, contact the group responsible for the application program.

5. If the last activity before the hang was input from the terminal, was the data passed to the application program?(If it was, the TGET trace entry corresponds to the inbound VTAM buffer contents trace entry.)
   • If so, determine whether the application program ever issued another TPUT.

     If the application program never issued another TPUT, contact the group responsible for the application program.

   • If data has been received by TSO/VTAM, but it has not been sent to the terminal, go to Reporting the problem to IBM.
6. If you have not identified the problem, go to Reporting the problem to IBM.