Verifying whether objects are restored successfully

You can use the job log or an output file to determine which objects are restored successfully.

These messages tell the number of objects that are restored and the number of objects that are not restored. An object is counted only if it fits the selection values you specified. For example, assume that library LIB1 has 75 objects. The names of 74 of those objects begin with the characters ORD. You specify RSTOBJ OBJ(ORD*) OBJTYPE(*ALL) SAVLIB(LIB1). If all objects restored successfully, the completion message says that 74 objects were restored to library LIB1. You are not notified that 1 object was not restored.

For example, assume that library DB1 has 20 objects with dependent files. You specify RSTLIB SAVLIB(DB1) RSTLIB(DB2) DFRID(D1). If 5 of the objects cannot be restored because they have dependent files, message CPI373C says that 5 deferred objects remain to be restored.

A diagnostic message is sent if one of following situations happen:

An object could not be restored

The reasons why the system cannot restore an object successfully are as follows:

• The object exists on the system and is being used. Restoring an object requires an exclusive lock for most object types.
• The object is being saved or restored by another job.
• The object on the media is damaged.
• The user does not have the necessary authority to restore the object.
• The object does not have a valid signature.
• The object type is not supported in an independent auxiliary storage pool (ASP).
• The user profile does not exist on the system.
• The system found a validation error.
• The deferred files cannot be restored.

Security information was changed

Under some conditions, the system might do the following tasks:

• Revoke public and private authority
• Change object ownership.
• Change the object's primary group.
• Not link to the authorization list.

An integrity change occurred

• Journaling cannot be started for an object that was being journaled at the time of the save operation or when the QDFTJRN data area or the journaled library inheritance rules indicate journaling should be started for the object.
• A logical file is restored over a deleted and recreated physical file.
• The QAUDJRN (audit) journal was created by the system. You receive message CPF7088. If you restore the operating system and the QAUDLVL system value is not *NONE, the system creates the QAUDJRN if it does not exist. This ensures that security auditing is restarted for your system.

Using An output file: Most restore commands create output that shows what was restored. You can direct this output to a printer (OUTPUT(*PRINT)), a database file (OUTPUT(*OUTFILE)), a stream file, or a user space. The default for restore commands is not to create output. You must request it each time you run the restore command. Or you can change the default for the OUTPUT parameter for restore commands by using the Change Command Default (CHGCMDDFT) command.

You can print the output and save it. Or you can create a program to analyze and report on the information in the output file.

You can use the OUTPUT parameter with these commands:

See the information center topics for each restore commands for the names of the model database outfiles that they use for output. The RSTLIB and RSTOBJ commands and the QSRRSTO API use the QASRRSTO restore output file.