Re: rstaut 7.3

if not using the PVTAUT(*YES) parm on the save and restore, the only way to get private authorities are to:

1) save user profiles from source along with your data and restore them prior to restoring the data. then RSTAUT

B) create a tool to DSPOBJAUT from each object being saved/restored and another tool to grtobjaut based on the authorities "saved" after the object is restored

Bryan




Smith, Mike wrote on 4/25/2018 11:51 AM:

Thanks.

I'll check that out. It looks like it might be set to *NO

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> On Behalf Of Steinmetz, Paul
Sent: Wednesday, April 25, 2018 11:39 AM
To: 'Midrange Systems Technical Discussion (midrange-l@xxxxxxxxxxxx)' <midrange-l@xxxxxxxxxxxx>
Subject: RE: rstaut 7.3

Mike,

I ran into a similar issue a while back.
The issue wasn't the restore, but the private authorities were not being saved.
The default is *NO, not to save private authorities.
Recheck your save.

Private authorities . . . . . . *NO *NO, *YES

Paul



-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Smith, Mike
Sent: Wednesday, April 25, 2018 11:30 AM
To: Midrange Systems Technical Discussion (midrange-l@xxxxxxxxxxxx)
Subject: rstaut 7.3

We do periodic data refreshes from our production machine to our development machine. We have been doing it the same way for a decade or better and have not encountered this before.

After I performed a refresh after our upgrade to 7.3, I noticed that data authorities didn't seem to restore properly

Files that are QSECOFR owned, but have authority granted to a group profile didn't get the group profile authority restored.