AFCF: VSAM file deadlock with another task

What it means

When a task updates a recoverable file, CICS locks each record it changes and keeps the lock until the unit of work ends at the next syncpoint. Another task that wants one of those records has to wait. Now suppose task A holds record 1 and asks for record 2, while task B holds record 2 and asks for record 1. Neither can ever go on.

For VSAM files in non-RLS mode, CICS file control looks for this. When a request would complete a circle of waits like that, CICS abends the task that is about to enter it with AFCF. Its updates are backed out, which releases its locks, and the other task gets its record and carries on. If a task would deadlock with itself, for example by making conflicting requests against the same control interval, the code is AFCG instead.

Files opened in RLS mode work differently. VSAM RLS manages their record locks, and a long wait for one of those ends in AFCV. File control also only sees its own locks. A deadlock between a record lock and some other kind of resource, such as an ENQ, isn't caught this way. Those tasks wait until a deadlock timeout (DTIMOUT) ends one of them with AKCS, or for good if the transactions have no DTIMOUT.

Common causes

• Two transactions update the same records in a different order. This is IBM's first example and the most common case.
• Two transactions update records in two recoverable files, one doing file A then file B and the other doing file B then file A.
• Long units of work that hold many record locks, such as a loop that reads and updates many records without a syncpoint.
• A conversational transaction that holds record locks while it waits for the user to press Enter, which stretches the time other tasks can collide with it.
• A batch-style task running in the region that updates the same records as online transactions.

How to find the problem

1. Find the DFHAC message for the abend in the region's message log. It names the transaction and the time.
2. In the transaction dump, EIBDS shows the last file the task used, and the trace shows the request that was refused.
3. List the other transactions that update the same file or files, and compare the order in which they read for update, write and delete records.
4. If the problem only appears under load, check which transactions run at the same time as the failing one. The clash needs two tasks working on overlapping records at once.

How to fix it

• Make every program update records in the same order, for example in ascending key order, and touch files in a fixed order.
• Keep units of work short. In long update loops, take a syncpoint every so many records so locks are released sooner.
• Use pseudo-conversational design so no task holds record locks while waiting for terminal input.
• Let the abended transaction be run again. Its updates were backed out, so rerunning it doesn't apply anything twice.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s CICS documentation for your release.