Re: Restore Drops Group's Authority

Although described sufficiently well, it may be worth stating explicitly, that the CRTAUT for the library is not used during a restore. As written, I am not sure how generally clear the quoted snippet is. So, to add to that, regarding the quoted text...

What defines the scenario is not that the library name is different, just that the object by the same name and type does not already exist in the library. In a Disaster Recovery [DR] scenario the same rules apply; i.e. the scenario of restore File A new into Library X, into the same library [name] as from where it was saved, will exhibit the same authority results as when restored new into library Y. In either case the authorities users have to the object after the restore, will be the same irrespective of the target library X or Y.


For those interested in some more specific details, I offer...

Even when a restore is an effective /create/, what authority was saved, is assigned to the new restored object. Only non-restore create requests will use the CRTAUT() from the library, to assign to *PUBLIC. On non-restore create requests the AUT(*LIBCRTAUT) parameter specification is available on many commands that do or can create an object. The authority information that is both saved and restored:
- the authority to the owner
- the *PUBLIC authority
- the primary group *PGP authority
- and when an object is associated with an *AUTL object, that association is saved and restored as well.

Thus if the Group's authority was established by ownership instead of by private authority, the restore would maintain the authority.

Privately held authorities are those authorities assigned to users other than the object owner, *PUBLIC, or the PGP. The private authorities are lost by save & [a scratch] restore. A _scratch-restore_ of an object, is a restore where the object by the same name and type does not already exist in the library into which it is restored. In a restore-over, the existing object maintains its authority and ownership settings -- and ALWOBJDIF() may need to be used to enable the restore. A _restore-over_ of an object, is a restore where the object by the same name and type already exists in the library into which it is restored.

The private authorities will be lost during scratch-restore because those authorities held by other users were not saved. The private authorities are not saved with the object because they are not part of the object; as noted in the other post, those private authorities are stored with each *USRPRF. This is the why the RSTUSRPRF, RSTxxx, RSTAUT sequence of operations is performed to recover authorities of the restored objects after a scratch-install as part of a full DR. The same sequence of actions can be done for any one, or a list of objects, for example a library and all of its objects; albeit an expensive exercise if for only a few objects, so using *AUTL looks real good by comparison.

Purposely omitted: Any attempt to explain the unidirectional nature of private the authorities, and thus a clarification on why, although not impossible to save and restore private authorities with the object, it is not currently offered by save/restore [except I believe, optionally, with BRMS?].

Regards, Chuck