Investigating terminal waits

Read this section if you have any of the following problems:

Note that, if you have one or more unresponsive terminals, that is terminals that are showing no new output and accepting no input, this does not necessarily indicate a terminal wait. If you have this problem, use CEMT INQ TERMINAL to find the transaction running at the terminal, and then CEMT INQ TASK to find out what resource that task is waiting on. When you know that, look at Table 9 to find where you can get further guidance.

If all the terminals in the network are affected, and CICS® has stalled, read What to do if CICS has stalled for advice about how to investigate the problem.

If yours is a genuine terminal wait, remember when you carry out your investigation that terminals in the CICS environment can have a wide range of characteristics. A terminal is, in fact, anything that can be at the end of a communications line. It could, for example, be a physical device such as a 3270 terminal or a printer, or a batch region, or it could be another CICS region connected by an interregion communication link, or it could be a system that is connected by an LUTYPE6.1 or APPC (LUTYPE6.2) protocol. If LUTYPE6.1 is in use, the other system might be another CICS region or an IMS™ region. With APPC (LUTYPE6.2), the range of possibilities is much wider. It could include any of the systems and devices that support this communications protocol. For example, apart from another CICS region, there might be a PC or a DISOSS system at the other end of the link.

If you eventually find that the fault lies with a terminal, or a resource such as DISOSS, the way in which you approach the problem depends on what type it is. In some cases, you probably need to look in appropriate books from other libraries for guidance about problem determination.

Terminal waits--first considerations

Before taking a systematic approach to the problem, here are a few preliminary considerations that could point to a simple solution.

If none of these considerations applies, you need to start a systematic investigation into the reason for the wait.

Terminal waits--a systematic approach

You first need to determine the type of terminal involved in the wait, and the type of access method in use for that terminal. Both of these factors influence the way you perform problem determination.

Your strategy must then be to find where in the communication process the fault lies. These are the basic questions that must be answered:

  1. Is the problem associated with the access method?
  2. If the access method has returned, or has not been involved, is terminal control at fault?
  3. If terminal control is working correctly, why is the terminal not responding?

To answer most of these questions, you will need to do some offline dump analysis. Use CEMT PERFORM SNAP to get the dump, and then format it using the formatting keyword TCP. Do not cancel your task before taking the dump. If you do, the values in the terminal control data areas will not relate to the error.

What type of terminal is not responding?

You can check the terminal type either online, using a system programming command, or offline, by looking at the appropriate TCTTE in the formatted system dump.

Online method

Use the transaction CECI to execute the system programming command EXEC CICS INQUIRE TERMINAL DEVICE. This returns one of the terminal types identified in the CICS Resource Definition Guide.

Offline method

Look at the formatted dump output you have obtained for keyword TCP. First, identify the TCTTE relating to the terminal, from the four-character terminal ID shown in field TCTTETI. Now look in field TCTTETT, and read the 1-byte character that identifies the type of terminal. You can find what terminal type is represented by the value in the field from the description given in the CICS Data Areas.

What type of access method is in use?

You can use both an online method and an offline method for finding the type of access method being used by the terminal that is not responding.

Online method

Use the CECI transaction to execute the system programming command EXEC CICS INQUIRE TERMINAL ACCESSMETHOD. This returns the access method in use by the terminal.

Offline method

You can find the access method for the terminal from the TCTTE. Look in field TCTEAMIB, which is the byte name definition for the access method. The CICS Data Areas relates values to access methods.

The most common access method is VTAM®, identified by a value of TCTEVTAM. The problem determination procedures outlined below focus exclusively on VTAM. You might also find either of these values, each being of special significance for problem determination:

If you have any other access method, for example Start of changeBSAMEnd of change, you need to adapt the guidance given here accordingly.

VTAM in use--debugging procedures

The sections that follow give guidance about debugging terminal waits when the access method is VTAM.

The first step is to look in the CSNE log to see if there is an error message that explains the wait. If it contains an error code, you can find out what it means from the VTAM Messages and Codes for MVS and VSE manual.

Look next for any NACP error codes in fields TCTEVRC5, TCTEVRC6, TCTEVRC7, and TCTEVRC8 of the terminal table entry, TCTTE. Look also for any SNA sense code in field TCTEVNSS.

Is the problem associated with VTAM?

You can find the VTAM process status with respect to the waiting task from fields TCTEICIP and TCTEIDIP in the TCTTE. The following are the values you might find there, and their interpretations:

     TCTECIP          command request in progress
     TCTEDIP          data request in progress

Either of these status values indicates that a VTAM request is in progress, and that the VTAM RPL is active. A response is expected either from VTAM, or from the terminal. You can find the address of the RPL from field TCTERPLA, unless the request was for a RECEIVE on an APPC session, in which case you can find the RPL address from field TCTERPLB.

If a VTAM request is not in progress, the next field of interest is in the VTAM system area of the TCTTE. Find four bytes of VTAM exit IDs, starting at field TCTEEIDA. If any are nonzero, the VTAM request has completed. Nonzero values suggest that VTAM is not involved in the wait. You can find the meanings of the values from the VTAM module ID codes list in the table below.

VTAM submodule identifiers

This table contains Product-sensitive Programming Interface information.

Hex ID Module Description
X'00' ZDSP DISPATCH
X'01' ZARQ READ /WRITE R
X'02' ZLOC LOCATE
X'03' ZDET DETACH
X'04' ZTCP TCP
X'06' ZCRQ COMMAND REQS
X'08' ZSTU STATUS CHANGE
X'09' ZTSP TERMINAL SHARING
X'0A' ZHPX HPO RPL EXEC OS ONLY
X'0B' ZISP ALLOCATE/FREE
X'0C' ZIS1 INTER SYSTEM
X'0D' ZIS2 INTER SYSTEM 2
X'0E' ZABD INVALID REQUEST/ABEND
X'10' ZATI ATI
X'11' ZATT ATTACH TASK
X'12' ZFRE FREE STORAGE
X'13' ZGET GET STORAGE
X'14' ZRAC RECEIVE ANY
X'15' ZRST RESETSR
X'16' ZRVS RECEIVE SPEC
X'17' ZRVX RECEIVE S EXT
X'18' ZSDS SEND NORMAL
X'19' ZSDX SEND DATA EXIT
X'1A' ZUCT TRANSLATION
X'1B' ZUIX USER EXIT
X'1C' ZACT ACTIVATE SCAN
X'1D' ZSDR SEND RESPONSE
X'1E' ZHPS HPO SEND/RECV CALL
X'1F' ZRPL RECV.ANY BLDER
X'20' ZAIT ATTACH INIT
X'21' ZASX ASYN COM EXIT
X'22' ZCLS CLOSE DESTIN
X'23' ZCLX CLOSE DS EXIT
X'24' ZDWE DWE PROCESS
X'25' ZLEX LERAD EXIT
X'26' ZLGX LOGON EXIT
X'27' ZLRP LOGICAL REC
X'28' ZLTX LOSTERM EXIT
X'29' ZOPN OPEN DESTINAT
X'2A' ZOPX OPEN DESTEXIT
X'2B' ZRAQ READAHEAD QUE
X'2C' ZRAR READAHEAD RET
X'2E' ZRRX REL REQUEST EX
X'2F' ZNSP NETWORK SPEC EXIT
X'30' ZRSY RESYNC
X'31' ZSAX SEND COMM EXT
X'32' ZSCX SCIP EXIT
X'33' ZSDA SEND ASYN COM
X'34' ZSKR SEND COMMAND RESPONSE ID
X'35' ZSES SESSIONC COM
X'36' ZSEX SESSIONC EXIT
X'37' ZSIM SIMLOGON
X'38' ZSIX SIMLOGON EXIT
X'39' ZSLS SETLOGON START
X'3A' ZSSX SEND COM EXIT
X'3B' ZSYX SYNAD EXIT
X'3C' ZTAX TURNAROUND EXIT
X'3D' ZTPX TPEND EXIT
X'3E' ZOPA VTAM OPEN ACB
X'3F' ZSHU VTAM SHUTDOWN
X'40' ZQUE TERMINAL SHARING
X'41' ZEMW ERROR MESSAGE WRITER
X'42' ZSYN SYNCPOINT HANDLER
X'43' ZTRA VTAM RPL TRACE
X'44' ZAND ABEND CONTROL BLOCK
X'45' ZCNA CONSOLE CONTROL
X'46' ZCNR CONSOLE REQUEST
X'47' ZCNC CONSOLE ABNORMAL COND.
X'48' ZUAX ATTACH USER EXIT
X'49' ZUOX OUTPUT USER EXIT
X'4A' ZARL LU6.2 APPL REQUEST
X'4B' ZARM LU6.2 MIGRATION
X'4C' ZRVL LU6.2 RECEIVE
X'4D' ZRLX LU6.2 RECEIVE EXIT
X'4E' ZSDL LU6.2 SEND
X'4F' ZSLX LU6.2 SEND EXIT
X'50' ZERH LU6.2 APPL ERP
X'52' ZBKT LU6.2 BRACKET STATE M/C
X'53' ZCNT LU6.2 CONTENTION STATE
X'54' ZCHS LU6.2 CHAIN SEND
X'55' ZCHR LU6.2 CHAIN RECEIVE
X'56' ZUSR LU6.2 CONVERSATION STATE
X'57' ZDST SNA-ASCII TRAN ROUTINE
X'58' ZEV1 ENCRYPTION VALIDATION 1
X'59' ZEV2 ENCRYPTION VALIDATION 2
X'5E' ZXRC XRF TERMINAL RECOVERY
X'5F' ZXTS XRF TERMINAL SCAN
X'60' ZXRL LU6.2 Transaction Routing
X'61' ZINT Initialization Module Ident
X'62' ZXRT LU6.2 Transaction Routing TOS
X'63' ZSTA LU6.2 Application Status
X'64' ZRLP LU6.2 RECEIVE post-vtam
X'65' ZCRT LU6.2 RPL_B state
X'66' ZRAS LU6.2 Slow-down processing
X'67' ZXPS LU6.2 Per sess recovery
X'7D' ZRLG RESPONSE LOGGER
X'7E' ZNAC NACP
X'7F' ZRSP RESYNC SYSTEM TASK
X'80' ZATR ZATR restart deletes
X'82' ZATA ZATA autoinstall
X'84' ZATD ZATD autoinstall delete
X'86' ZGMM GOOD MORNING TRANSACTION
X'8B' ZATS ZATS remote install entry
X'C0' ZQ00 DFHZCQ REQUEST ROUTER
X'C1' ZQIN ZC INITIALIZE
X'C2' ZQBA ZC Bind Analysis
X'C3' ZQCH ZC CHANGE
X'C4' ZQDL ZC DELETE
X'C5' ZQIT ZC INSTALL TCTTE
X'C6' ZQRC ZC RECOVER
X'C7' ZQRS ZC RESTORE
X'C8' ZQIQ ZC INQUIRE
X'C9' ZQIS ZC INSTALL
X'C4' ZTCT DUMMY TCTTE IDENTIFIER

If you suspect that the problem is associated with VTAM, consider using either CICS VTAM exit tracing or VTAM buffer tracing. Both of these techniques can give you detailed information about the execution of VTAM requests. For guidance about using the techniques, read the appropriate sections in Using traces in problem determination.

VTAM in use--is terminal control at fault?

The first place to look is field TCTVAA1 in the terminal control table prefix, TCTFX. This contains either the address of the first TCTTE on the active chain, or the value X'FFFFFFFF'. If you see the latter value, it means that terminal control does not recognize that it has work to do. If this conflicts with the INQ TASK report you have received that the task is waiting on some terminal related activity, report the problem to your IBM® Support Center.

If field TCTVAA1 points to a TCTTE on the active chain, check that the TCTTE of the terminal your task is waiting for is included in the chain. You can find this out by following the chain using the "next" pointer, field TCTEHACP of the TCTTE. If it does not contain the address of the next TCTTE on the chain, it contains either of these values:

     X'FFFFFFFF'     this is the last TCTTE on the chain
     X'00000000'     this TCTTE is not on the active chain

If you find a value of X'00000000', report the problem to the IBM Support Center.

VTAM in use--is the terminal at fault?

If you have found that the access method and terminal control are not causing the wait, the terminal itself must be waiting for some reason. You need now to look at some fields in the TCTTE for the terminal to find its status.

CICS system dumps contain an index to the VTAM terminal entries. It appears in the terminal control (TCP) summary section of the dump.

Information about the status and attributes of the VTAM terminals appears in an interpreted form at the end of the control block for each terminal entry. The information shown depends on the attributes of the terminal.

The example in Figure 6 shows the index followed by a terminal entry with its interpreted status and attribute information.

Figure 6. Terminal index and terminal entry with interpreted information
===TCP: TERMINAL CONTROL SUMMARY (VTAM TERMINALS)
        TERMINAL                  TASK         IN        ERROR    ACTIVE RPL   WORK    ZNAC    INTERVENTION   AUTOINSTALL
TERMID    TYPE     LOGGED ON    ATTACHED     SERVICE     STATS.    REQUEST     TO DO  QUEUED     REQUIRED       ACTIVITY
 R51       C0         NO           NO          YES      00000000      NO        NO      NO          NO            N/A
 R52       C0         NO           NO          YES      00000000      NO        NO      NO          NO            N/A
 R53       C0         NO           NO          YES      00000000      NO        NO      NO          NO            N/A
 R54       C0         NO           NO          YES      00000000      NO        NO      NO          NO            N/A
 R55       C0         NO           NO          YES      00000000      NO        NO      NO          NO            N/A
 S51       C0         NO           NO          YES      00000000      NO        NO      NO          NO            N/A
 S52       C0         NO           NO          YES      00000000      NO        NO      NO          NO            N/A
 S53       C0         NO           NO          YES      00000000      NO        NO      NO          NO            N/A
 S54       C0         NO           NO          YES      00000000      NO        NO      NO          NO            N/A
 S55       C0         NO           NO          YES      00000000      NO        NO      NO          NO            N/A
 -AAA      C0         NO           NO          YES      00000001      NO        NO      NO          NO            N/A
 -AAB      C0         NO           NO          YES      00000000      NO        NO      NO          NO            N/A
 TCTTE.R51 03B5C420 TCT TERMINAL ENTRY
    0000  D9F5F140 C0000504 03B5C424 00000000  00000000 00000000 00000000 00080000  *R51 ......D.....................*    03B5C420
    0020  00000000 0C000000 C5D5E400 00008080  00000000 00000000 00000000 00000000  *........ENU.....................*    03B5C440
    0040  00000000 00000000 00000000 00000000  00000000 01D80000 00000000 03B22030  *.....................Q..........*    03B5C460
    0060  00000000 00000000 00000000 03B58690  00000000 00000000 03B46390 00000000  *..............f.................*    03B5C480
    0080  00000000 00000000 00000000 00000000  03B430F8 00000000 00000000 00000000  *...................8............*    03B5C4A0
    00A0  00000000 00000000 00000000 00840000  00000000 00000000 00000000 00000000  *.............d..................*    03B5C4C0
    00C0  00000000 80000000 00000000 00000000  00000000 0000003B 01000000 00000000  *................................*    03B5C4E0
    00E0  10000000 00000000 00000000 03B5C618  00000000 00000000 00000000 00000000  *..............F.................*    03B5C500
    0100  3A008400 00000000 00000000 00000000  00000000 FFFF0000 00000000 00000000  *..d.............................*    03B5C520
    0120  00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000  *................................*    03B5C540
    0140  10001000 10000000 00000000 00000000  00000000 00000000 00000000 00000000  *................................*    03B5C560
    0160  00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000  *................................*    03B5C580
    0180  08090000 00000000 00000000 00000000  00000000 00000000 00000000 03B59421  *..............................m.*    03B5C5A0
    01A0  00440000 00001008 D4FD6038 80800014  00000000 00000000 00000000 00000000  *........M.-.....................*    03B5C5C0
    01C0  00000000 00000000 00000000 00000000  00000000 00000000                    *........................        *    03B5C5E0
    TERMID = R51                            EXIT FOOTPRINTS (HEX) = 00000000
    IN SERVICE                              TCTTECA (NO TASK ATTACHED)
    TCTECCV (STARTED BY TTI)                TCTECSM (CA-MODE)
    INPUT STATISTICS (DECIMAL) = 00000000   OUTPUT STATISTICS (DECIMAL) = 00000000
    ERROR STATISTICS (DECIMAL) = 00000000   TCTE1RY (CICS IS PRIMARY)
    TCTELSE (LUC CONTENTION LOSER)          TCTESBIF (SBI/BIS SUPPORTED)

The values that are given below for fields in the TCTTE are not the only possibilities, but they show important things about the terminal status. If you find any other values for these fields, look in the CICS Data Areas to find out what they mean.

The following are the questions that need to be asked, and some values that could provide the answers.

  1. Is the terminal in service? Look at field TCTTETS of the TCTTE, to find the terminal status. The values that indicate why a terminal was failing to respond include:
      TCTTESPO = 1 and TCTTESOS = 1     terminal out of service
      TCTTESOS = 1 only                 terminal in error recovery
    Look also at field TCTESEST, to find the session status with respect to automatic transaction initiation (ATI) for the terminal. Some of the values you might see are:
      TCTESLGI = 0     CREATESESS(NO) in TYPETERM definition
      TCTESLGI = 1     CREATESESS(YES) in TYPETERM definition
      TCTESLGT = 1     recovering CREATESESS
    A value of TCTESLGI = 0, with TCTESLGT = 0, too, shows that CREATESESS(NO) has been specified in the TYPETERM definition. This means that EXEC START requests and ATI requests cannot cause a session to be created. The request is either queued or rejected when no session is currently established. This can put a terminal into an indefinite wait state, especially if the terminal is a printer.

    A value of TCTESLGI = 1 shows that CREATESESS(YES) has been specified in the TYPETERM definition. This means that CICS is allowed to create sessions for the terminal, so the CREATESESS status is not the cause of the wait.

    A value of TCTESLGT = 1 means that the session is in error recovery. This could explain why there is no response from the terminal.

  2. Has a task been created for this terminal? Look first at field TCTTECA of the TCTTE.
  3. Is there a task related to the terminal? You can find the task session state with VTAM from field TCTEMOST, and, if bracket protocol is required (from field TCTEIBPE), its conversation state with the terminal from field TCTEIINB. The significant values that might provide further clues to the cause of the wait are:
      TCTECSM = 1      the task is in conversation with the terminal
      TCTECSM = 0      terminal control will accept new tasks from
                       the terminal
    Look now at field TCTEIBPE, to see if bracket protocol is required:
      TCTEBPE = 1      bracket protocol is required
    If you find that bracket protocol is required, look in field TCTEIINB:
      TCTEINB = 0      a conversation has not been started
      TCTEINB = 1      a task is in conversation with the terminal
  4. Is the terminal logged on to CICS? Look first at the node session status in the TCTTE. The three stages of session creation are represented by three separate bits, in fields TCTEILOS, TCTEIOPD, and TCTEINSD:
      TCTELOS = 1      the node is logged on
      TCTEOPD = 1      VTAM OPNDST macro issued
      TCTENSD = 1      Start Data Traffic sent
    If all three bits are set, so the value of the byte is TCTENIS, the node is in session.

    You next need to see if the terminal is logging off, or if it has already been logged off. The fields of interest are TCTEINND, TCTEINBD, and TCTEIPSA. The values to look for are:

      TCTENND = 1      the terminal is to be logged off
      TCTENBD = 1      the terminal is logging off because of an error
      TCTEPSA = 1      the session with the terminal ended abnormally
                       --look for any explanatory message on CSMT

    If any of these bits are set, the terminal might not be able to respond to the waiting task.

  5. Should the terminal respond to the task? Field TCTEIPRA tells you this:
      TCTEPRA = 1      the terminal should respond

If the values you have found in all these fields suggest that the terminal status is normal, the terminal is probably waiting for some activity to complete before it responds. The type of investigation you need to do next depends on the type of terminal involved in the wait. You should already have determined this, for example by using the system programming command EXEC CICS INQUIRE TERMINAL DEVICE.

Tools you can use for debugging terminal waits when VTAM is in use

Amongst your debugging tools, two are likely to be of particular use for investigating terminal waits in a VTAM environment. They are:

For a description of the use of these two types of tracing in CICS problem determination, see Using traces in problem determination.

Your task is waiting on a physical terminal

If your task is waiting on a physical terminal, the terminal should first be checked physically to see why it is not responding. If the terminal is at a remote location, you need to ask someone else to check it for you. Some possibilities are:

Consider also the possibility of hardware error in the terminal.

Your task is waiting on a physical terminal

If a session has been acquired and it has not failed, your task is likely to be waiting for some response from a task in the other region. This can apply to any of the interregion or intersystem communication activities--function shipping, asynchronous processing, transaction routing, distributed transaction processing, or distributed program link. No matter which of these applies, it is most likely that the other region is not responding because the related task there has been suspended.

You need to identify the related task in the remote region, and find out the resource it is waiting on. When you have done that, see Table 9 to find out which part of this section to turn to next.

Investigating the related task in the remote region

The first thing to do is to identify the region that is not responding to your local task.

If the task is using interregion communication (IRC), look first at the name of the resource being waited on, returned together with resource type IRLINK by CEMT INQ TASK. The first four characters give you the SYSIDNT of the remote CICS region.

If the task is using intersystem communication (ISC), you need to look in field TCTTEIST of the TCTTE, which points to the ISC system table entry. The first field in the system table entry is the identity of the remote region.

When you have identified the region, you need to take a system dump of it. You can do that either by using the CEMT PERFORM DUMP command in that region, or by using the MVS™ DUMP command. Take a system dump of the local region, too.

Format the dumps using the formatting keyword DS to get a summary of the tasks in each region, and TCP to get the TCTTEs.

First find the TCTTE for the task in the local region. The way you find the TCTTE for the task in the remote region depends on whether you are using LUTYPE6.1 sessions (or IRC) or APPC sessions:

When you have confirmed that you have located the correct TCTTE, look in field TCTTECA. This gives you the TCA address of the task that is not responding.

Using the TCA address as the entry point, you can now investigate the reason why the task has not responded. It is very likely that it has been suspended because some resource is unavailable. Look in the dispatcher and transaction manager summaries. If you can identify your task, you can see what resource it is waiting on.

When you have identified the resource, turn to the appropriate section in this section for guidance about investigating waits on that resource.

Related concepts
VTAM terminal control waits
The resources on which tasks in a CICS system can wait
VTAM buffer tracing
CICS VTAM exit tracing
Related tasks
Formatting system dumps
Related references
The CSFE ZCQTRACE facility
[[ Contents Previous Page | Next Page Index ]]