CPF3130: Member already in use

What it means

CPF3130 is an escape message with the text "Member &2 already in use." The Clear Physical File Member (CLRPFM) command lists it among its errors, and a nightly CLRPFM in a CL program is where most people meet it.

The records of a physical file live in its members. Clearing a member throws all of its records away in one go. The system won't do that while another program could be reading or changing them, so the command needs the member to itself. If any job has the member open, or holds a lock on it, the command waits for a while. Then it gives up and sends CPF3130. The member is left exactly as it was.

The job in the way is often another user or a batch job. It can also be your own job. A program that ran earlier in the same job and didn't close the file still has the member open, and that is enough to block the clear.

Common causes

• An interactive user has the file open, for example someone left on an inquiry or update screen in an order entry program.
• Your own job still has the file open. An RPG program that returned with LR off, a file opened with OPNDBF and never closed with CLOF, or a shared open data path (SHARE(*YES)) all keep the member in use.
• A database server job has the file open. SQL connections from ODBC, JDBC or similar clients run in server jobs such as QZDASOINIT, and these can keep a file open after a query ends so they can reuse it.
• Another job took a lock on the file or member with ALCOBJ and hasn't released it.
• A save of the library or file is running. A save lets other jobs read the file but not change it, so a clear has to wait for it to finish.

How to find the problem

1. Run DSPJOBLOG, put the cursor on CPF3130 and press F1 to see the member and file. Check the messages just before it for the command that failed.
2. Run WRKOBJLCK OBJ(ACCTLIB/PAYMAST) OBJTYPE(*FILE) to list the jobs holding locks on the file. From that screen you can also look at member locks. Note each job's name, user and number.
3. For a job you suspect, run WRKJOB and take the option to work with open files. It shows every file the job has open and how many times.
4. If the only job listed is your own, run DSPJOB OPTION(*OPNF) in that job. A file still shown as open there is what blocks the clear.
5. On recent releases the SQL view QSYS2.OBJECT_LOCK_INFO lists the same lock details and is easy to filter by library and file.

How to fix it

• Wait for the other job to finish or ask the user to leave the program, then run the command again. Nothing was cleared, so a retry is safe.
• In your own job, close the file first. Use CLOF for a file opened with OPNDBF, end the RPG program with LR on, or run RCLRSC to close files left open by programs that have already returned.
• In a CL program, take the lock before you clear: ALCOBJ OBJ((ACCTLIB/PAYMAST *FILE *EXCL)) WAIT(60), then CLRPFM, then DLCOBJ. If ALCOBJ fails you get a clear message (CPF1002) and can retry or alert the operator.
• For a server job that holds the file, talk to the application owner before ending anything. Ending a QZDASOINIT job drops a user's connection.
• Schedule clears for times when interactive users and client connections are off the file, and add MONMSG MSGID(CPF3130) with a retry loop so one busy moment doesn't stop the whole job stream.

What it looks like

Member PAYMAST already in use.

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