CPF3773: Some objects not restored

What it means

CPF3773 has the text "&1 objects restored. &2 not restored to &4." It is an escape message from Restore Library (RSTLIB), and the object restore command RSTOBJ reports a partial restore the same way. The first number is what worked. The second is what didn't.

Because it is an escape message, a CL program that runs the restore stops at this point unless it monitors for CPF3773. The objects that did come back stay restored. Nothing is rolled back.

The message doesn't list the failed objects. The restore sends a diagnostic message for each one before it ends, so the job log holds the list. The usual reasons are objects in use, objects that differ from the copy already on the system, authority, and storage. IBM's RSTLIB documentation says existing objects that are in use aren't restored, including output queues that are actively spooling. It also warns against running programs from a library while that library is being restored.

Common causes

• An object of the same name already exists and is in use. A file open in another job, or an output queue a writer is printing from, can't be replaced.
• The saved object differs from the existing one in a way the restore won't accept. Owner, primary group, authorization list, and file or member level ID differences are covered by the ALWOBJDIF parameter. With ALWOBJDIF(*NONE), those objects are skipped.
• The user running the restore isn't authorized to the objects or the library. Using any ALWOBJDIF value other than *NONE also needs *ALLOBJ special authority.
• System values that control restores, such as QALWOBJRST, block security-sensitive objects like programs that adopt authority.
• A logical file or SQL view was restored before the physical file it is built over, and the physical file wasn't on the system yet.
• The restore ran into a storage limit, either the ASP filling up or the MAXSTG limit of the user profile that will own the objects.

How to find the problem

1. Run DSPJOBLOG on the restore job and scroll up from CPF3773. Each object that failed has its own diagnostic message. Press F1 on each one for the reason.
2. For a long restore, ask for a list: RSTLIB and RSTOBJ take OUTPUT(*OUTFILE), which writes one row per object with its status, so you can query the failures.
3. For an object reported in use, run WRKOBJLCK on it to see which job holds it.
4. For difference problems, compare the existing object with DSPOBJD and DSPFD (owner, level IDs) against what the save holds.
5. Check the QALWOBJRST and QVFYOBJRST system values with DSPSYSVAL if programs were refused.

How to fix it

• Restore only what failed. Use RSTOBJ with the object names from the diagnostics instead of running the whole RSTLIB again, which would also replace objects that restored fine.
• End the jobs or writers that use those objects before the second restore.
• If the differences are expected, for example a file moved from another system, a security officer can rerun the restore with ALWOBJDIF(*COMPATIBLE) or a more specific value.
• For logical files over physical files in other libraries, restore the libraries with the physical files first. On releases that have it, the DFRID parameter defers dependent objects until their base objects arrive.
• Raise MAXSTG on the owning profile with CHGUSRPRF, or free space in the ASP, if storage was the reason.
• Change restore system values only with your security team's agreement, and set them back afterwards.

What it looks like

1250 objects restored. 3 not restored to ACCTLIB.

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