CPF5032: Record already allocated to this job

What it means

When a program reads a record for update, Db2 for i locks that record until the program updates it, releases it or reads another record through the same open. The lock belongs to the open data path (ODP), the connection the program made when it opened the file. It doesn't belong to the program or the job as a whole.

So a job can lock itself out. If one open of a file holds a record and a second, separate open of the same file in the same job asks for that record for update, the second request fails. That is CPF5032. IBM lists it as "record already allocated to job" among the database messages an application can monitor for.

CPF5032 looks a lot like CPF5027, and both put a program into the same error handling. ILE COBOL sets file status 9D for either one, and ILE RPG treats both as a record that couldn't be allocated. The difference is who holds the lock. With CPF5027 it is another job, and the message names that job. With CPF5032 it is your own job, so waiting longer won't help.

Common causes

• Program A reads a record for update, then calls program B, which opens the same file on its own and reads the same record for update.
• One program has the same file open twice, for example through the physical file and through a logical file over it, and reads the same record for update through both.
• The job runs under commitment control. Record locks are held until COMMIT or ROLLBACK, so a lock taken through one open is still held when another open reaches the record.
• SQL and record-level access are mixed in one job. An SQL cursor or UPDATE holds a lock that a native read for update then runs into.

How to find the problem

1. Run DSPJOBLOG and press F1 on CPF5032. Note the file, the member and the record number. F9 shows the program and statement that made the failing request.
2. Run DSPRCDLCK FILE(ACCTLIB/PAYMAST) while the job is still waiting or stopped. It lists the record locks on the file and the job that holds each one. When it shows the same job, you have CPF5032 and not CPF5027.
3. Look at the job's open files with WRKJOB and the option to display open files. If the file appears more than once, each line is a separate open, and two of them are fighting over the record.
4. Look at the call stack (WRKJOB, call stack option) to see which programs are active, then check which of them read the file for update.

How to fix it

• Release the record before calling the next program. In RPG, free the lock before the call, or read with the N extender (no lock) when the first program only needs to look at the data.
• Pass the data to the called program instead of letting it read the same record again.
• Share one open between the programs with OVRDBF FILE(PAYMAST) SHARE(*YES), so both use the same open data path and the same lock. Check that the programs don't disturb each other's file position.
• Under commitment control, commit or roll back before another open reads the same record for update, or keep all updates to that record in one program.
• Handle the error on the read so the user gets a clear message instead of an inquiry. In RPG check the record-lock status (01218) with an error indicator or the E extender. In COBOL check file status 9D.

DSPMSGD MSGID(CPF5032) 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.