×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.
As an Amazon Associate we earn from qualifying purchases.