Question & Answer
Question
I have CICS transaction that has been in a FCCFQR wait for a long time. As a result, my CICS region appears to be hung. I'm unable to CANCEL my CICS region to bring it down so I had to use the FORCE command to accomplish this. How can I determine what is causing the transaction to wait for FCCFQR?
Answer
To determine why a transaction is waiting on FCCFQR waits, you will first need to take a system dump of your CICS region at the time it is hanging.
Typically this type of problem means there are some tasks out there which have not completed. So, the first place you should look is in the DS (Dispatcher) domain to see what tasks are in the region. To format the Dispatcher domain, enter VERBX DFHPDxxx 'DS=1' (where xxx is your release level of CICS like 690 for CICS TS 5.2).
In the dump I had, I found system task # 00025 transid CFQR waiting on FCCFQR :
RESOURCE RESOURCE_NAME W TIME OF TIMEOUT XM_TXN_TOKEN `
SUSPEND DUE
KCCOMPAT SINGLE W 09:40:51.265 - 2292F3000000033C
ICEXPIRY DFHAPTIX S 08:10:31.024 - 20B09B000000007C
DMWTQUEU S 08:07:39.582 -
M 08:10:08.740 08:11:08.740 21F1C7000000049C
DMWTQUEU S 08:07:39.497 -
TCP_NORM DFHZDSP W 08:10:30.759 - 20B0A1000000009C
DMWTQUEU S 08:07:39.582 -
DMWTQUEU S 08:07:39.582 -
FCCFQR M 05:27:56.518 - 20B0AD000000025C
DMWTQUEU S 08:07:39.582 -
The following explanation is in section Resource type FCCFQR - wait for SMSVSAM server notification of the IBM Knowledge Center: The system task CFQR can wait on resource type FCCFQR. This is the normal state for this task and means that the task is waiting on an ECB for more work. New work is created for the task when CICS receives a quiesce request from its SMSVSAM server through the CICS RLS quiesce exit program, DFHFCQX. SMSVSAM drives the CICS RLS quiesce exit, which creates a control block for the request and posts the CFQR task to notify it of the request's arrival.
In this case, CFQR was suspended on FCCFQR at 05:27:56 GMT.
Next, you should look at the KErnel domain by entering VERBX DFHPDxxx 'KE=1' so you can find out if in fact things are in SMSVSAM ...
Enter F 'KTCB Table' so that you can find the TCB address for the FO tcb. Enter F 'FO' to find the ktcb*. We are looking for the FO TCB address in this case because the FO TCB will contain the calls to the SMSVSAM server.
KTCB 2093A0D0 KTCB TABLE ENTRY
0000 D2E3C3C2 40404040 2093B168
0020 00000000 5A440DB0 00000000
0040 00000000 00000000 C0000003
0060 2093A0D0 40000000 00AF8110
0080 00000000 00000000 00000000
00A0 2093B168 20939038 00000000
00C0 00000000 00000000 00000000
In the example above, the TCB address x'00AF8110' is at offset x'68'.
Next you should enter the command SUMM FORMAT JOBSUMM from the IPCS command line..
Then enter F 'TCB: 00AF8110' but make sure you use the TCB address that you find in your dump.
When you get to the TCB, enter F LINKAGE to be taken to the stack entry piece.
What you will be concerned with in the LINKAGE STACK area are the fields SASN and PASN. These are the Secondary ASID and Primary ASID numbers.
LINKAGE STACK 00 does not contain these fields
LINKAGE STACK 02 has SASN..00CF and PASN..00CF ... ASID 00CF is the CICS region
LINKAGE STACK 03 also has SASN.. 00CF and PASN..00CF
LINKAGE STACK 04 also has SASN.. 00CF and PASN..00CF
LINKAGE STACK 05 has SASN.. 00CF and PASN..000A
LINKAGE STACK 06 has SASN.. 00CF and PASN..000A
LINKAGE STACK 07 has SASN.. 00CF and PASN..000A and this is the LAST linkage stack entry...
In this case, since 000A is in the last LINKAGE STACK, this means that ASID 000A is in control. So now you can enter the IP SELECT ALL command to see what ASID 000A is:
ASID JOBNAME ASCBADDR SELECTION CRITERIA
.
.
000A SMSVSAM 00FAE600 ALL
.
.
00CF OLUT4A0C 00F80680 ALL
.
.
In this case, you can see ASID 000A is SMSVSAM so I had IBM SMSVSAM support look at my dump and they recommended the APAR OA43280 as a possible fix.
Product Synonym
CICS/TS CICSTS CICS TS CICS Transaction Server
Was this topic helpful?
Document Information
Modified date:
16 January 2015
UID
dwa1170902