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.
Before taking a systematic approach to the problem, here are a few preliminary considerations that could point to a simple solution.
If you do find a message there reporting some terminal error that can be related to the task, it should give you an idea of why the task is waiting. You can find an explanation of the message and a description of the system action in response to the error by using the CMAC transaction, or by looking at CICS Messages and Codes.
It is also possible that the CSNE log entry will show that an error was detected, but that no action was taken by TACP or NACP. This could occur if the line or terminal was out of service, or if the error actions had been turned off in the user exits of DFHTEP and DFHNEP. In such a case, the CICS code enabling the waiting task to be resumed would never be executed, and the task would wait indefinitely.
If none of these considerations applies, you need to start a systematic investigation into the reason for the wait.
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:
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.
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.
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.
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.
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.
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.
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 BSAM
, you need to adapt the guidance given here accordingly.
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.
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.
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.
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.
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.
===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.
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.
TCTECCV = 0 the task has been started by a terminal
TCTECCV = 1 the task has been started by ATI
TCTTEOIC = 1 ATI is waiting to start
TCTECTI = 1 there is ATI work for ZCP to do
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
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.
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.
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.
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.
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.
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:
Now go to the dump of the remote region, and use the terminal ID to locate its TCTTE. Check in field TCTESQP of TCTENIB to make sure that the session qualifier pair matches that in the local system. It should be made up of the same terminal IDs, but with their order reversed.
Now go to the dump of the remote region, and use the session instance identifier you have found for the remote task to locate its TCTTELUC. The TCTTE precedes the TCTTELUC in the dump.
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.