In CICS Transaction Server for z/OS (CICS TS) there are a vast number of ways a task can be suspended that can lead to a number of ways to investigate those wait states. In this blog, I will focus on the resource type TD_READ wait.

A task is suspended on a resource type of TD_READ if it is trying to read uncommitted data from a logically recoverable transient data (TD) queue. The queue name is displayed in a qualifier. The suspended task is forced to wait until the task owning the write enqueue commits the changes it has made. This is usually a relatively quick wait but there are times when the task can wait for a significant amount of time. I’m going to show you the steps to identify who owns the write enqueue.

If task is held in a TD_READ wait it will appear in the dispatcher domain (DS) of the dump as follows (the dispatcher domain can be formatted with IPCS using VERBX DFHPDxxx ‘DS=1’ where xxx is your release level of CICS like 690 for CICS TS 5.2):

DS_TOKEN KE_TASK T S F P TT RESOURCE RESOURCE_NAME W TIME OF TIMEOUT
TYPE SUSPEND DUE
00000000 11111111 N S N N - TD_READ ABCD S 01:23:45.678 -

You should capture the RESOURCE_NAME from the Dispatcher Domain (“ABCD” in this example). Now go to Transient Data domain (TDP) by entering VERBX DFHPDxxx ‘TDP=1’) and locate the DCTE address for this Transient Data queue by doing a find on this RESOURCE_NAME. You should find it under the “Q NAME” in the Intrapartition TD Queue Summary as seen in the example below:

==TDP: Intrapartition TD Queue Summary
DCTE Q Q INDT TRIG ATI ATI TERMID ATI AID
ADDRESS NAME STATE TYPE OPT LEVEL TRANID FAC /SYSID USERID ADDRESS
12345678 ABCD ENA LG QUE 0 ABCD F 00000000

Next, copy the DCTE ADDRESS (“12345678” in this case) from the Summary and search on that address until you find it in the DCTE heading:

DCTE 12345678 TD Intrapartition DCTE

In the DCTE you need to locate the TDDCT_UOW_OWNING_WRITE_NQ which is an 8 byte field. This field can be found at different offsets into the DCTE depending on the version of CICS you are using. Below are the offsets for the supported versions of CICS:

CICS 5.1 and 5.2: X’C0′
CICS 4.1 and 4.2: X’BC’
CICS 3.1 and 3.2: X’7C’

Copy the contents of the 8 byte TDDCT_UOW_OWNING_WRITE_NQ field and then format the recovery domain (RM) by entering VERBX DFHPDxxx ‘RM=1’). Perform a find for the 8 byte UOW (“ABCDEFGH87654321” in this case) and it will show up as the “Local UOW Id”:

UOW UOW Local UOW Id Stat ||||||||||| SystemLg Keypoint Tran Tran
Address Token ||||||||||| ChainTok Count Num Id
--------------------------------------------------------------------------------
12344321 01010101 ABCDEFGH87654321 infl YNNNNYNBNNN null 00000006 12345 CSMI

At this point, you have identified who owns the write enqueue for TDQ ABCD. Now you will need to figure out what is holding tran num “12345” (tran id “CSMI”) from committing the changes it has made. I have seen multiple reasons why this task has not completed. One example is if the task is in an IRLINK to another region and it is taking a considerable amount of time for that task to return. If this happens, you will need to further investigate why the task isn’t returning. See Resolving IRLINK waits by finding connected tasks in remote CICS regions if this is your problem.

I would love to hear your feedback concerning this blog. As always DO IT JUST FOR CICS!!!!!!!!!!

Join The Discussion

Your email address will not be published. Required fields are marked *