CPF1002: Cannot allocate object

What it means

IBM i protects objects with locks. Reading usually takes a shared lock, while changing, clearing or deleting needs exclusive use. There are five lock states, from *SHRRD (shared for read) up to *EXCL (exclusive), and each one is allowed alongside some states and not others.

ALCOBJ lets a program take locks up front, before doing work that needs them. A nightly job often runs ALCOBJ OBJ((PAYLIB/PAYMAST *FILE *EXCL)) before clearing or reorganizing a file. If another job holds a lock that conflicts with the one requested, ALCOBJ waits for the time given in its WAIT parameter. The default comes from the job's class. If the lock still isn't free when the time runs out, ALCOBJ ends with CPF1002 and none of the objects in that request are locked.

The other job may have released the lock a moment later, so a lock holder can be hard to catch after the fact.

Common causes

• An interactive user has the file open, for example in an inquiry program, when a batch job asks for an exclusive lock.
• Another batch job that uses the same object is still running, often because the schedule overlapped.
• A server job, such as an ODBC or JDBC connection, keeps the file open after the client finished with it.
• A previous step of the same job allocated the object at a conflicting level and didn't release it with DLCOBJ.
• The WAIT value is too short for normal activity on the object.

How to find the problem

1. Read CPF1002 in the job log with DSPJOBLOG. It names the object, and earlier messages may name the lock state.
2. While the problem is happening, run WRKOBJLCK OBJ(lib/object) OBJTYPE(type). It lists every job holding a lock and the lock state. For a database file, also check member locks with the MBR parameter.
3. On current releases, the QSYS2.OBJECT_LOCK_INFO view gives the same information through SQL, which is easier to log from a program.
4. Check the jobs that are usually active at that time with WRKACTJOB, and compare the job scheduler entries for overlaps.

How to fix it

• Wait for the other job to finish, or ask the user to leave the program, then run the step again.
• Give ALCOBJ a longer WAIT if the conflict is short-lived, or add a retry loop around it with MONMSG MSGID(CPF1002).
• Ask for a weaker lock if the job doesn't need full exclusive use, for example *EXCLRD so other jobs can still read.
• Reschedule overlapping jobs, or end idle server jobs that hold the file open.
• Release locks your job no longer needs with DLCOBJ. One DLCOBJ is needed for each ALCOBJ.

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