Re: Refresh my memory: what is it that controls the public authority . . .

On 30-Sep-2014 11:11 -0500, James H. H. Lampert wrote:

<<SNIP>> public authority when new programs and files <<SNIP>>
is there any setting (other than the obvious case of the object's
owner not existing on the target system) that can cause a change in
the public authority when an object is restored <<SNIP>>

Portions of the quoted message are snipped per having already been /answered/; dealing with the QCRTAUT System Value (SYSVAL) and Create Authority (CRTAUT) attribute and parameter-keyword on both Create Library (CRTLIB) and Change Library (CHGLIB) commands.

AFaIK the *PUBLIC authority remains unchanged even for the scenario whereby the owner of the object is unavailable [missing or damaged] on the target system; i.e. an owner would be assigned per msg CPI371E, but that effect should not result in any change to the public authority.

If secured by an authorization list, and that *AUTL object is missing or otherwise unavailable, public authority defined via that Aut List will be lost per msg CPI3721; with an associated AUTL(), but not also defining the *PUBLIC authority per AUT(*AUTL), I believe that condition is diagnosed by msg CPI3720.

If the user performing the restore does not have the necessary [special] authorities [e.g. SPCAUT(*SECADM *ALLOBJ)], then as I recall, the saved programs that were defined with USER(*OWNER) [to effect adopted authority of the object owner], the [public] authority of the object and\or the adoption attribute may be changed. I do not recall the diagnostic message or the specific scenario(s) for which the issue arises. In that case the restore of the object completes but the overall restore request would /fail/ with an Escape message indicating that some prior /attribute changes/ were effected during the restore. Similar issues might arise with similar [lack of] attributes for the user performing the restore, but for different origins of [effective] authority changes; e.g. msg CPI3738 regarding the User ID number (UID) and Group ID number (GID) of the owner on media and those on the system.

As I recall the above alluded effect for the adopted authority case, is different than what the Allow Object Restore (QALWOBJRST) system value setting would effect when the effect is limited [i.e. other than *ALL to allow the restore of all objects irrespective any security sensitive attributes, diagnosed by the msg CPD373F]. Clearly, because that scenario actually prevents the restore per the first level message text stating "&1 in library &3 with adopt authority attribute not restored".

A program-described database *FILE object that is restored with the name of an existing [but deprecated] Authority Holder (AUTHLR) object, the file will take the authority defined in the authority holder rather than restoring with the [public] authority from the save.