CPF4128: Not able to allocate objects needed for file

What it means

CPF4128 is an escape message sent at open time. Its text begins "Not able to allocate objects needed for file" and then names the file, the library and the member or program device. It is one of the open failures in the CPF4101 to CPF43FF range. The open fails and the program can't use the file.

Opening a database file isn't free of locks. The system takes shared locks on the file and on the member so that nobody deletes or clears them while the program is using them. Shared locks get along with each other, so many jobs can have the same file open. They can't be granted while another job holds an exclusive lock on the file or member. In that case the open waits for the time set by the file's WAITFILE attribute and then gives up with CPF4128.

The lock in the way is usually short lived. A clear, a reorganize, a restore or an ALCOBJ with an exclusive lock are the usual culprits. That is why the same program often works when it is simply run again a minute later.

In ILE RPG the open error comes back as file status 01216 for an implicit open or 01217 for an explicit OPEN. A file that opens at program start is opened before the INFSR subroutine is active, so the error goes to the default handler and appears as RNQ1216 unless the file is opened under program control.

Common causes

• Another job is clearing the member with CLRPFM, which needs the member to itself.
• RGZPFM is reorganizing the member. With its default options it needs an exclusive lock for the whole run.
• A CL program took an exclusive lock with ALCOBJ ... *EXCL and hasn't released it with DLCOBJ yet.
• The file is being restored, changed (CHGPF), or having a member added or removed in another job.
• The file's WAITFILE value is *IMMED, the default for most files, so the open gives up at once instead of riding out a short lock.

How to find the problem

1. Run DSPJOBLOG, put the cursor on CPF4128 and press F1. Note the file, library and member it names, and the time of the failure.
2. Run WRKOBJLCK OBJ(ACCTLIB/ORDHDR) OBJTYPE(*FILE) straight away to see which jobs hold locks on the file and which lock states they hold. An *EXCL or *EXCLRD lock held by another job is the one to look at.
3. On recent releases, query QSYS2.OBJECT_LOCK_INFO with SQL to see the same lock details, filtered by library and file. This also works from inside an error routine.
4. If the lock is gone by the time you look, check the job scheduler (WRKJOBSCDE) and the history log (DSPLOG) for jobs that ran CLRPFM, RGZPFM, RSTOBJ or similar at that time.

How to fix it

• Run the program again once the other job has finished. Nothing was changed by the failed open.
• Give the open time to wait. OVRDBF FILE(ORDHDR) WAITFILE(30) before the call, or CHGPF FILE(ACCTLIB/ORDHDR) WAITFILE(30) for a permanent change, lets the open ride out a short lock.
• Move clears and reorganizes to a time when no programs use the file. For RGZPFM, ALWCANCEL(*YES) with LOCK(*SHRUPD) lets other jobs keep reading and updating the file while it runs.
• In RPG, declare the file with USROPN and open it yourself inside a MONITOR group. The program can then catch the error, wait and retry, or log which job held the lock.
• Talk to the owner of the job that holds the lock before ending anything. Ending a job in the middle of a clear or restore can leave the file in a worse state.

What it looks like

Error message CPF4128 appeared during OPEN for file ORDHDR (C S D F).

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