CPF3203: Cannot allocate object for file

What it means

CPF3203 is an escape message with the text "Cannot allocate object for file &1 in &2." The Clear Physical File Member (CLRPFM) command lists it among its errors, and other commands that change database files report lock failures the same way.

"Allocate" is the IBM i word for getting a lock. A database file has several parts that can be locked on their own. They are the file object, each member, the data in each member, and the logical files and access paths built over it. A command that changes the file has to lock every part it touches in a strong enough state. Clearing a member, for example, empties the access paths of the logical files over it too, so a job reading through one of those logical files is in the way as well.

If another job holds a lock that conflicts, the command waits. When the wait runs out it stops and sends CPF3203, and the file is left as it was. The text names the physical file, but the busy object may be a member or a logical file. Diagnostic messages just before it in the job log often say which one.

Common causes

• A user or a batch program has the file open, either directly or through a logical file built over it.
• A database server job, such as QZDASOINIT for ODBC and JDBC clients, still has the file open from an earlier query.
• Another job holds a lock taken with ALCOBJ. Some applications lock their files for the whole day.
• A save is running against the library. Other jobs can read the file during a save but can't change it.
• Another command is changing the same file at the same moment, for example a CHGPF, a reorganize or an ALTER TABLE in another job.
• Your own job opened the file earlier and didn't close it, which blocks commands that need exclusive use.

How to find the problem

1. Run DSPJOBLOG, put the cursor on CPF3203 and press F1 for the file and library. Read the diagnostic messages above it, which often name the member or logical file that was busy.
2. Run WRKOBJLCK OBJ(ACCTLIB/PAYMAST) OBJTYPE(*FILE) to see which jobs hold locks on the physical file and in what state.
3. Run DSPDBR FILE(ACCTLIB/PAYMAST) to list the logical files and SQL views built over it, and repeat WRKOBJLCK on each of them.
4. For a job you suspect, run WRKJOB and take the option to work with open files to confirm it has the file open.
5. On recent releases the SQL view QSYS2.OBJECT_LOCK_INFO shows the same lock information and can be filtered by library and object name.

How to fix it

• Wait for the other job to finish, or ask its user to leave the program, then rerun the command. Nothing was changed, so a retry is safe.
• In CL, take the lock first with ALCOBJ and a WAIT value, run the command, then release the lock with DLCOBJ. A lock failure then shows up as CPF1002 at a point where the program can retry or tell the operator.
• Close the file in your own job with CLOF or RCLRSC, or have the RPG program that used it end with LR on.
• Move clears and reorganizations to a window when users, client connections and saves are off the file.
• Before ending a job that holds the lock, check what it is doing with the application owner. Ending a server job or an update program can lose a user's work.

What it looks like

Cannot allocate object for file PAYMAST in ACCTLIB.

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