You would need the same user profiles and they should be setup the same as
on LPAR01.

Do a SAVAUT on LPAR01 and then use the RSTAUT command. That should get the
authorities restored. You may need to restore the library as LIB01 before
RSTAUT and rename the library.

Some objects may not like to be renamed example journals.

Darryl.

On Tue, Sep 15, 2015 at 4:11 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

On 15-Sep-2015 13:31 -0600, CRPence wrote:

On 15-Sep-2015 13:11 -0600, Vernon Hamberg wrote:

We've a situation here - looking for ideas.

New LPAR that is to have the same objects but in different
library.

Files in library LIB01 on LPAR01 saved and then restored to LIB02
on LPAR02 with PVTAUT(*NO).

There were private authorities on all these files on LPAR01. There
are NO private authorities on these files on LPAR02 - makes
sense, I know.

We need the private authorities to be the same as they were on
LPAR01 - all users ARE present on both partitions.

So question I was asked, is there a way to apply the private
authorities after the restore, where there is now only the owner's
and a *PUBLIC on the objects?

There have been changes to the data already since the restore -
that just complicates things, I'd say.


A couple ways; the latter probably eliminates some nuances that are
likely to be encountered if there does not exist already an existing
grant-from-outfile data program in which those nuances have already
been identified and accounted-for, but obviously taking a new save
might be even more onerous:

• A CLP [or REXX] that does the Display Object Authority (DSPOBJAUT)
against all the objects in the library [using MBROPT(*N *ADD)] on
LPAR01. Move the data to the LPAR02. Then on the LPAR02, use that
output file data to issue the respective Grant Object Authority
(GRTOBJAUT) requests; optionally omitting the redundant *PUBLIC and
owner authorities.

• Take a new Save Library (SAVLIB) while omitting as much of
unnecessary data using PVTAUT(*ALL) and avoiding save-history using
UPDHST(*NO), Restore Library (RSTLIB) using PVTAUT(*ALL) into an
alternate but new library name [e.g. LIB02AUT or RSTLIB(*SAVLIB);
QTEMP might not be an option given some object types would not be
able to be restored, and the authority to the *LIB object still
would be missing]. Then similar to the aforementioned CLP, have the
program process every object in the newly restored library, issuing
a GRTOBJAUT using the Reference Object (REFOBJ) [and Reference
Object Type (REFOBJTYPE)] specifications.

I long ago had created and used both such programs, but I no longer
have the source or the *PGMs.


I must have accidentally deleted the explanation of "omitting as much of
unnecessary data" and dropped "while including"; that should have stated:

• Take a new Save Library (SAVLIB) while omitting as much of unnecessary
data using SAVFDTA(*NO) STG(*KEEP) ACCPTH(*NO) FILEMBR((*ALL *NONE))
SPLFDTA(*NONE) QDTA(*NONE) while including private authorities with
PVTAUT(*YES) and avoiding save-history using UPDHST(*NO),

Hmm. Looking closer, I mis-remembered available support on SAVLIB;
seems the SAVLIB does not offer the FILEMBR() and the Private Authorities
parameter specification is *YES vs *ALL. Argh. So must use instead the
Save Object (SAVOBJ) instead, and deal with the *LIB object separately :-(


--
Regards, Chuck

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].