Re: IBM objects with modified authority and v5r2 --> v5r4 upgrade

On Thu, Aug 21, 2008 at 1:09 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

Charles Wilt wrote:

<<SNIP>>

But box involved runs my team's application system, so I'm trying to
help the admin team.

We've got an unknown number of IBM objects whose authority has been
modified. For instance, QAFDMBRL which is the outfile template for
DSPFD, was modified to allow our programs to use CRTDUPOBJ on it. In
particular, our application profile was given a private authority to
it.

The /admin team/ really needs to implement a System Change Management
process that has all customizations added to a script to be run after an
upgrade. What transpired is an indication that a CM process needs to be
implemented, corrected, or improved.

No argument from me or the _current_ admin team.

If piecemeal recovery is acceptable, add each of the recovery actions
to the newly implemented or corrected system change management [script].

After a v5r2 --> v5r4 upgrade on our QA system QAFDMBRL was back to
the IBM default of *PUBLIC change with no additional private
authorities.

That suggests *PUBLIC has *CHANGE? Hmmm... that seems excessive;
i.e. that authority would allow any *peon user to issue a CHGPF
QSYS/QAFDMBRL given that user has access to a command line.?

Well I checked another v5r4 box, and *PUBLIC was *CHANGE. You are
correct in that wouldn't make sense from as an IBM default, so there
must be something changing it, but I don't know what.

If an object is deleted before being restored anew as part of an OS
install, all customized authorities would be lost. I do not recall the
processing for the model output files in QSYS, I think they are almost
all deleted before restore, and I believe the install joblog records the
/file deleted/ activity.

Makes sense.

Initial thought. dump the authorities to all objects on the v5r2
production system and all objects on the v5r4 QA system and figure
out which ones were modified on production.

Maybe not worth the effort to make comparisons. Many objects which
did not get deleted as part of the upgrade would maintain the same
authority; i.e. no difference, does not imply unmodified. To truly
determine what were modified, requires reviewing each, irrespective of
matching or unmatched authorities... thus a generally exhaustive check
with or without a comparison.

I don't disagree. We'll need to compare to a clean install v5r4 box
to see catch all the mods.

But for getting past the upgrade to v5r4, having the authorities match
is enough.

Secondary thought, can any combination of RSTUSRPRF and RSTAUT using
the full system save tape from just prior to the upgrade result in
having the v5r4 IBM objects given the same modified authority the
v5r2 versions had?

The best bet for the specific case, would probably be to RSTUSRPRF
the /application profile/ and then perform the RSTAUT for that user
profile. Since authorities are additive, the operation is fairly safe.
I would prefer not to perform a more global restore of users &
authorities unless the private authorities are known to have been
generally additive of the *EXCLUDE authority, such that they will be
preventing versus granting access; readdressing access failures and
requests, thus giving the opportunity to reevaluate. However, again,
restoring the profiles and authorities is a generally safe operation;
and important option if reevaluating authority requirements could be
[considered] too costly.

Ok, I was thinking it would be, but I've never used it like we're discussing.

Thanks Chuck!

Charles Wilt