Recently we faced a lot of AFCY abends in our CICS AOR region. There were also an equal number of AZI6 abends encountered at the same time frame in our FOR region.
"Problem: The AOR issued a direct read to a remote file. Before the request was sent to the FOR, there was a suspend for KCADDR. After 12 secs the KCADDR suspend timed-out with a PURGE and this caused the AFCY.
Diagnosing the problem
The normal flow for a CICS file control request varies if the file has never been opened and if the file is Local or Remote. In this case, the problem is occurring with files that are Remote.
The following is what occurs for a file control request and the dataset has not been through OPEN processing; that is, the file is CLOSEd:
REMOTE - Control will pass into DFHFCFS for OPEN_FILE. CICS will issue KCADDR ENQUEUE for the FCTE address to issue a DataTable Connect to see if this dataset is in fact a DataTable. If it is not, the DEQ is issued and the request is Function Shipped to the FOR. There is no KCADDR ENQUEUE on the starting address of module DFHFCFS as there was for the LOCAL case above. From this point on the requests are function shipped.
In your case the file was Remote but there was a KCADDR ENQUEUEs for the FCTE and a KCADDR ENQUEUE for a starting address of a module (like DFHFCFS would have done for a Local file). The module that did the KCADDR ENQUEUE was CAFC's OPEN/CLOSE module FCSDRVR. CAFC replaces DFHFCFS with their FCSDRVR module. The ENQUEUE should not have been done since the FCT is remote.
My site uses CAFC (a NETEC product).
The resolution that was provided in the site was: "Contact NETEC if you need a Zap to prevent the KCADDR ENQUEUE."
I went through the explanation but I am sorry to say that I am not that familiar with the functions of CAFC and KCADDR in this context.
Can someone tell me what is the cause of such abends?
I am also providing you with the related information that I got from the CICS dump if it gives some insight on the issue:
AOR:
CICS Control Block Information:
System EXEC Interface Block(SYSEIB) at address 00042494:
Task Start Time: 09:02:48
Transaction ID: TDYD
Task Number: 14870
Last CICS Command: READ
RESP Condition: NORMAL
RESP Condition Reason: 00000000
Data Set ID: FMDD
File Name: FMDD
User EXEC Interface Block (EIB) at address 0017F0D0:
Task Start Time: 09:02:48
Transaction ID: TDYD
Task Number: 14870
Last CICS Command: IGNORE CONDITION
RESP Condition: NORMAL
RESP Condition Reason: 00000000
Data Set ID: TDDB
File Name: TDDB
CICS Internal Trace:
14870 QR AP F600 TDA ENTRY WRITE_TRANSIENT_DATA
14870 QR AP F601 TDA EXIT WRITE_TRANSIENT_DATA/OK
14870 QR RS 0500 RSDU ENTRY STOP_TDUMP
14870 QR RS 0501 RSDU EXIT STOP_TDUMP/OK
14870 QR AP 04EI FCFR EXIT READ_UPDATE_INTO/PURGED TIMEOUT,0,0,0,00000000,,LENGTH_OK,NO,NO
14870 QR AP 2000 PCPG ENTRY ABEND
For AZI6 Trace in FOR:
CICS Control Block Information:
User EXEC Interface Block (EIB) at address 204C00D0:
Task Start Time: 09:02:48
Transaction ID: RF07
Task Number: 57466
Terminal ID: <AAQ
Last CICS Command: DEQ
RESP Condition: NORMAL
Data Set ID: n/a
CICS Internal Trace:
57466 AP DD24 ZIS2 EVENT IRC INBOUND REQUEST HEADER:
57466 AP FD8D ZIS2 EXIT IRC 1E3966F0,NORMAL
57466 AP FD0D ZIS2 ENTRY IRC 1E3966F0,RECV_ABORT
57466 AP FD44 ZAND ENTRY TACB_CREATE <AAQ
57466 AP 0741 ABAB ENTRY CREATE_ABEND_RECORD
57466 AP 0742 ABAB EXIT CREATE_ABEND_RECORD/OK
57466 AP FDC4 ZAND EXIT TACB_CREATE
57466 AP FD8D ZIS2 EXIT IRC
57466 AP FC01 ZARQ EVENT MRO/LU6.1 STATE SETTING TO FREE
57466 AP 2000 PCPG ENTRY ABEND
I would also like to know if there is any possible resolution to this abend.
I also sincerely apologize for the length of this post. In the process of sharing as much information that I have on this abends, I might have made the post long to read.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
In the transaction-definition (the PCT as I've called it for decades), what value is assigned to the DTIMOUT parameter (deadlock timeout), which has a format of MMSS?
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
AFCY's occur most frequently (although not exclusively) when accessing Remote Files and are preceded by an AFCI abend. They go hand and hand.
You should speak with your CICS System Programmer and/or Support personnel about increasing this timeout value or perhaps, they may have another suggestion as the problem could be in the application program having exclusive control on a CI for a long period of time, causing other tasks to timeout.
Another possibility is to ensure that you're file has an optimum data CISZ, because on a READ FOR UPDATE, the entire CI is locked-out, so no other task can update another record (or the same record) which belongs to that CI.
