What happens when you restore objects
When you restore an object, the system takes different actions depending on several conditions.
An object on this system is like a container. The object has information about the container itself, such as the owner of the object and the last time it was saved. This is the information you see when you display the object description (DSPOBJD command). The object also has contents, such as the records in a database file or the instructions in a program.
When you restore an object, the system takes different actions depending on the following conditions:
- Whether the object to be restored already exists.
- The allow object differences (ALWOBJDIF) parameter on the restore command.
Whether the object was saved on a different system
(serial number of the processor) or logical partition.
With a few exceptions that relate to security, the contents of the object are always restored. If the object exists, the system compares the object description information about the system copy and the media copy and then makes decisions. For most information, the media version of the information is restored. For security-relevant information, such as the public authority and the object owner, the system version is left unchanged. In a few cases, such as the size of the object and the date it was restored, the system determines a value when the object is restored.
The allow object differences (ALWOBJDIF) parameter on the restore commands is primarily for security protection and integrity protection. For example, if system security is important to you, you might want to take special action if someone attempts to restore an object whose owner has been changed. Or, if the member information about a database file does not match, you might have problems with the integrity of your data. You can use the ALWOBJDIF parameter to prevent this.
The default value for the ALWOBJDIF parameter is
*NONE. This means that if important differences exist between the
media version and the system version of an object, you want the system
to notify you and not restore any differences. Normally, you should
use the default value. However, when you are restoring your information
to a different system or logical partition, such as during a disaster
recovery, you should specify ALWOBJDIF(*COMPATIBLE) which allows differences
that are compatible with existing database files.
You can specify a combination of up to four values on the ALWOBJDIF parameter to allow specific types of differences for the restore operation: *FILELVL, *AUTL, *OWNER, and *PGP. The *FILELVL value attempts to restore physical file data when the file level ID or the member level ID of the physical file on the system is different from that of the physical file on the save media. The *AUTL value allows differences in authorization lists. The *OWNER value allows differences in object ownership. The *PGP value allows differences in the primary group.
Table 1 shows examples of the effect of the ALWOBJDIF parameter.
| Object characteristic that differs | Value for object after restore operation | ||
|---|---|---|---|
| ALWOBJDIF(*NONE) specified | ALWOBJDIF(*ALL) specified | ALWOBJDIF(*COMPATIBLE)
specified |
|
| Object owner | Object is not restored | Existing value1 | Existing value1 |
| Object primary group | Object is not restored | Existing value3 | Existing value3 |
| Object auditing | Existing value | Existing value | Existing value |
| Authorization list, restore over existing object: | |||
| Object on media is secured by an authorization list and object on system is not secured by an authorization list | Object is not restored | Object is restored and is secured by authorization list of object on system2 | Object is restored and is
secured by authorization list of object on system2 |
| Object on media is not secured by an authorization list and object on system is secured by an authorization list | Object is restored and is secured by authorization list of object on system | Object is restored and is secured by authorization list of object on system2 | Object is restored and is
secured by authorization list of object on system2 |
| Object on media is secured by an authorization list and object on system is secured by a different authorization list | Object is not restored | Object is restored and is secured by authorization list of object on system; message is sent to user2 | Object is restored and is
secured by authorization list of object on system; message is sent
to user2 |
| Authorization list, new object restored: | |||
| Object is restored onto different system or logical partition than it was saved from | Object is restored and is not secured by an authorization list | Object is restored and is secured by the same authorization list that secured the object when it was saved, if the authorization list exists2 | Object is restored and is
secured by the same authorization list that secured the object when
it was saved, if the authorization list exists2 |
| Database files: | |||
| Creation date for file | File is not restored | File is renamed on the system; copy is restored from media with media creation date; message is sent to user. | Logical file is not restored. System attempts to restore physical file data4 |
| Creation date for member | Member is not restored | Member is renamed on the system; copy is restored from media with media creation date; message is sent to user. | Logical member is not restored. System attempts to restore physical member data4 |
| Physical file data: | |||
| Level identifier for file | Physical file data is not restored | File is renamed on the system; copy is restored from media with media creation date; message is sent to user. | System attempts to restore physical file data4 |
| Level identifier for member | Physical file data is not restored | Member is renamed on the system; copy is restored from media with media creation date; message is sent to user. | System attempts to restore physical member data4 |
|
|||