AFCV: VSAM RLS record lock wait timed out

What it means

With record level sharing (RLS), VSAM itself manages record locks, and every CICS region and batch job sharing the data set uses the same locks. A request that needs a record someone else has locked waits. That wait has a limit. If the transaction definition has a DTIMOUT value, that is the limit. Otherwise CICS uses the FTIMEOUT system initialization parameter, which defaults to 30 seconds and can be set from 1 to 4080 seconds.

When the limit passes, VSAM gives up on the request and CICS abends the transaction with AFCV. Just before that, CICS writes two messages that make this abend easier to chase than most. DFHFC0164 says the request timed out waiting for an RLS lock and how many holders the lock has. DFHFC0165 identifies a holder. It gives the transaction ID, task number, unit of work ID, job name, APPLID, MVS system ID, the key of the record and the data set name.

The task that gets AFCV is usually the victim. The cause is the task or job that held the lock, and it may be in a different region or on a different MVS image.

Common causes

• Another CICS transaction holds the lock for a long time, for example in a long update loop without syncpoints, or in a conversational transaction waiting for the user while it holds a record.
• A batch job using Transactional VSAM (DFSMStvs), or another region, holds the record. DFHFC0165 then names a job or an APPLID you might not expect.
• A low DTIMOUT on the waiting transaction, or a low FTIMEOUT for the region, so normal short waits turn into abends.
• A CICS defect with generic deletes. APAR PM02131 (CICS TS 4.1) fixed AFCV when a generic delete waited for a lock on a record past the end of its range. APAR PH17079 (CICS TS 5.3) fixed a lock left behind by a generic delete of the last record in a control interval when replication logging is used, together with VSAM APAR OA58274.

How to find the problem

1. Look in the region's message log for DFHFC0164 and DFHFC0165 just before the abend. DFHFC0165 tells you who held the lock.
2. Use the transaction ID, task number, APPLID and job name from DFHFC0165 to find the holder. For a CICS task, check what it was doing at the time with CEMT INQUIRE TASK in that region if it is still running.
3. Check the waiting transaction's DTIMOUT, and the region's FTIMEOUT value in the SIT parameters printed at startup.
4. If the holder looks idle, check whether it was waiting for terminal input or for some other resource while it held the record.

How to fix it

• Fix the holder first. Shorten its units of work, take syncpoints in long update loops, and don't hold locks across terminal input.
• Schedule batch updates to shared RLS data sets away from online peaks, and have them commit often.
• Use the NOSUSPEND option on file requests where waiting isn't useful. For RLS files, a locked record then raises RECORDBUSY at once and the program can decide what to do.
• Raise DTIMOUT or FTIMEOUT only if the waits are normal for the workload and simply longer than the current limit.
• If you use DELETE GENERIC on RLS files, check that the fixes for PM02131 and PH17079, and VSAM APAR OA58274, are applied for your release.

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.