RNQ1218: Record already locked

What it means

RNQ1218 is an ILE RPG runtime message for file status 01218, record already locked. When a program reads a record from a file opened for update, the database locks that record until the program updates it, releases it or reads another one. A second job that wants the same record for update has to wait. If the lock isn't released within the file's record wait time, the read fails. The database reports the lock first, and the message just above RNQ1218 in the job log, usually CPF5027, names the job that holds it. When the lock is held through another open of the file in the same job, that message is CPF5032 instead.

This is a file status, not a program status. File errors go to the file's error handling first. That means the error indicator or (E) extender on the operation, then the INFSR subroutine named on the file. A MONITOR group catches it too. Only when none of those is present does the RPG default handler send the inquiry.

RNQ1218 is the inquiry form. Someone has to answer it at the screen, or in QSYSOPR for a batch job. Here the R (retry) reply is useful. It tries the same read again, which often works once the other job has moved on. RNX1218 is the escape form of the same condition. It doesn't wait for a reply and is what MONITOR or a caller sees.

Common causes

• An interactive program read a record for update, showed it on a screen and is still waiting while the user has the screen open and has walked away.
• A batch job is updating many records under commitment control and holds the locks until it commits.
• A program read a record for update and never updated or released it, so the lock lasted until the next read.
• Two programs in the same job have the file open separately, and one holds the record the other wants.
• The record wait time on the file is very short, so normal brief contention turns into errors.

How to find the problem

1. Read the job log with DSPJOBLOG. The message just above RNQ1218, usually CPF5027, names the job that holds the lock and the record number.
2. Run DSPRCDLCK FILE(ACCTLIB/ORDHDR) with the real file name to list current record locks and the jobs that hold them.
3. Look at the holding job with WRKJOB to see what program it is running and whether it is waiting at a screen.
4. Press F1 on RNQ1218 for the file, the RPG procedure and the statement that did the read.

How to fix it

• For the waiting job, reply R once the other job has released the record. Reply C if you can't wait.
• Read records for display without a lock, for example CHAIN(N), and read them again for update just before writing the change.
• Release record locks the program no longer needs, and commit more often in long batch runs.
• Handle the status in the program. Code CHAIN(E) or READ(E), then if %STATUS(file) is 1218 wait and try again, or tell the user the record is in use.
• If contention is normal and short, raise the record wait time with CHGPF or OVRDBF and the WAITRCD parameter.

Technical reviewer: Albert Joseph, WND Software.

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