Re: Another heads up on a restore

On 12-Aug-2014 07:33 -0500, rob@xxxxxxxxx wrote:

On 12-Aug-2014 07:08 -0500, rob@xxxxxxxxx wrote:

IBM owns up to this issue. They just say it's the customer's problem to
solve.
http://www.ibm.com/support/docview.wss?uid=nas8N1017745

Reference #: N1017745 "Restoring Authorization to Objects in QSYS"

I just submitted a DCR that this is BS.
Suggested an exit on SAVSYS, and on RSTAUT, that IBM do this
themselves.

There would be no good justification [that I could imagine] for the IBM i OS code to implement\perform the work /as described/ in that Technote. There would seem to be little reason to perform work on both ends, performing work both during the save and the recovery\post-restore processing, adding unnecessary complexity betwixt. The back-end could identify and correct the issue without any fore knowledge of the Save System (SAVSYS) that was taken. That is true also for a user doing the work, restricting their work only to the back-end; the difference being, that the available external interfaces are as I recall, much less straightforward, most notably because the Display Object Authority (DSPOBJAUT) command is not capable of performing against generic object names and types.

The OS could for example, add a new parameter to Restore Authorities (RSTAUT) to enable a request to perform the work necessary to /correct/ the issue; a parameter such as QSYSPUBAUT() could include special value(s) that direct if\how to perform that corrective action. The feature would need to locate any objects suffering from the illogical\anomalous condition whereby the object has a named *AUTL object but the *PUBLIC authority is not set to directed to the *AUTL; a condition that would normally be prevented by msg CPF2279 "Authorization list &1 cannot be deleted." given the Delete Authorization List (DLTAUTL) would be the seemingly more direct means to effect that condition.

As part of the RSTAUT, the design could be to review all external objects in QSYS looking for those exhibiting the condition, and then perform the effective Grant Object Authority (GRTOBJAUT) request to assign the USER(*PUBLIC) to the AUT(*AUTL); the prior phase of processing, the effect of GRTOBJAUT USER() AUT() AUTL(named) is already visible. IIRC the *AUTL objects can not be interrogated on the back-end [as described in the Technote for the front-end], because the Authorization List objects are restored as /empty/, and are reconnected to the objects that are restored as part of normal Public Authority processing; thus the list of objects shown by DSPAUTLOBJ grows only as each object that references the *AUTL has been restored.

If already multi-threaded the RSTAUT could perform that additional work in a separate thread in the same job, or possibly design a capability to [optionally] perform that work in the background so as to limit the impact to the more typical capabilities of that feature to recover the _private_ authorities. Anyone who would re-apply their customizations would likely opt to bypass that new function, whereas anyone who does not expect to have to re-apply their customizations [of authority granted via Authorization List for objects in QSYS] can recover those specific authority customizations with the standard OS commands for DR; of course those would not re-apply, still potentially will encounter issues whereby authority customizations are lost, for any objects whose authorities get overridden\explicitly-set by QSYFIXUP [or some other] processing that typically would exist as corrective for a public authority SNAFU from a prior release [such as the already-discussed RSTOBJ command].

FWiW: Possibly [though I am in no way recommending this; but one could do so just to test], the /Authority Recovery/ phase of a Reclaim Storage (RCLSTG) request that includes *ALL processing [optionally omitting anything available to be omitted] very probably performs the same /recovery/ that one could effect as described above.