AFCG
Explanation
A transaction has issued a sequence of file control requests that would cause the file to deadlock itself. This response arises for different reasons depending upon the file type.
If the file is being accessed in non-RLS mode, the response is caused by the transaction making conflicting requests against the same CI. For example, if the file is being accessed using LSR, a self deadlock will arise when an attempt is made to read a record that is in the same CI as a record that is the subject of a READ UPDATE or WRITE MASSINSERT request issued by the same transaction.
If the file is accessed in RLS mode there is no CI locking, but self deadlock responses can still arise. They are caused by sequences of requests that are either logically meaningless or which cannot be performed by VSAM RLS.
With VSAM RLS the most likely causes of this abend are as follows:
-
Two successive READ UPDATE requests against the same record by the same transaction without an intervening REWRITE, DELETE or UNLOCK command.
This is an incorrect use of file control requests.
-
A transaction has created a record by WRITE MASSINSERT and then, without terminating the WRITE MASSINSERT sequence by issuing an UNLOCK request, the same transaction has attempted to modify the same record by issuing a READ UPDATE or DELETE request.
This sequence of requests fails if VSAM has not written the record out to disk. The only way to guarantee that the record has been written to disk is to issue the UNLOCK request.
-
A transaction has updated or deleted a record using a browse for update sequence and then, without terminating the browse for update sequence by issuing an ENDBR request, the same transaction has attempted to modify the same record by issuing a separate READ UPDATE or DELETE or WRITE request.
This sequence of requests fails if VSAM has not written the record out to disk. The only way to guarantee that the record has been written to disk is to issue the ENDBR request.
If the file is used to access a coupling facility data table, then self deadlock responses are caused by sequences of requests that are either logically meaningless or which cannot be performed by coupling facility data tables support.
For coupling facility data tables, the most likely cause of this abend is as follows:
-
Two successive READ UPDATE requests have been issued against the same record by the same transaction without an intervening REWRITE, DELETE or UNLOCK command.
This is an incorrect use of file control requests.
System action
The task that would have entered deadlock is abended with a CICS transaction dump.
User response
Examine the previous requests made by this transaction against this file to identify the cause of the deadlock, then correct the error. In some cases (particularly when the file is being accessed in RLS mode or is using a coupling facility data table) this abend may indicate a programming error in the program that issued the file control requests.
When the file is being accessed in RLS mode, if the programming error is a READ UPDATE with RIDFLD specified followed by a DELETE with RIDFLD specified, consider using the feature toggle com.ibm.cics.rls.delete.ridfld to allow the DELETE with RIDFLD command to succeed. This is intended as a migration aid when you are converting to RLS from local VSAM with CILOCK=NO specified in CICS. For more information, see VSAM RLS.
Module
DFHEIFC, DFHDMPCAApplicable releases in Version 6
- beta
- 6.3
- 6.2
- 6.1