CPF5027: Record in use by another job

What it means

CPF5027 is the database message for a record that is in use. IBM lists it as "Record in use by another job" among the database I/O messages a program can monitor. The text gives the record number and the qualified name of the job that has the lock, in the form job number, user and job name.

Reading a record for update puts a lock on it. Other jobs can still read that record for input, but a second read for update has to wait. The wait lasts as long as the file's WAITRCD value. When it runs out, the read fails with CPF5027. Reading for input never waits, because it takes no lock.

In ILE RPG the condition becomes file status 01218, record already locked, with the escape RNX1218 and the inquiry RNQ1218. In ILE COBOL IBM maps it to file status 9D, record locked. When the lock is held by another open of the file in your own job, the message is CPF5032 instead.

Under commitment control, locks are held until the program commits or rolls back, which can make CPF5027 more frequent.

Common causes

• A user has a record open on an update screen and has left the program waiting, so the lock stays in place.
• A batch job updates many records under commitment control and holds the locks until it commits.
• A program read a record for update and kept the lock, because it neither updated the record nor read another one through the same open.
• The file's WAITRCD is short, so an ordinary brief lock turns into an error.

How to find the problem

1. Run DSPJOBLOG and read CPF5027. Its text gives the record number and the full job name of the job holding the lock.
2. Run WRKJOB JOB(052174/CLERK04/DSP07) with that name to see what the job is doing and which program it is in.
3. Use DSPRCDLCK FILE(ACCTLIB/ORDHDR), or on recent releases query QSYS2.RECORD_LOCK_INFO, to list the record locks currently held on the file.
4. In an RPG program, the program status data structure holds the message ID and its data after the error, so the program can show the user who holds the record.

How to fix it

• Wait and try again. Reply R (retry) to RNQ1218 once the other job has moved on.
• Ask the user holding the record to finish or leave the screen. Interactive programs that hold a lock while waiting for input are the most common cause.
• Change programs to read for input (the N extender in RPG) when they don't intend to update, and to free a record they read for update as soon as they decide not to change it.
• Have long batch updates commit more often so they hold fewer locks for less time.
• Handle the error in the program. Check for status 01218 after the read and show the user which job holds the record instead of an inquiry message.
• Set a sensible WAITRCD with CHGPF or OVRDBF. Don't use *IMMED for files that are updated by several users at once.

DSPMSGD MSGID(CPF5027) MSGF(QSYS/QCPFMSG)

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.