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

Actually I think the reason a private authority was added was so that
our programs could do a CRTDUPOBJ.

*PUBLIC *CHANGE wasn't enough.

Restrictions:

1. You must have use (*USE) and object management (*OBJMGT)
authorities for the existing object.


Charles


On Thu, Aug 21, 2008 at 3:34 PM, Carel Teijgeler <coteijgeler@xxxxxxxxx> wrote:

I think the authority *CHANGE for user *PUBLIC is understandable on those
files.

The commands using those IBM supplied files, which originally do not have
any members, have to duplicate their associated output file and add a
member to it, before filling it with data.

It is also common practice and adviced not to change the default settings
on IBM supplied objects, so I wonder why this setup of authority, when the
commands used create a copy at the moment the output file does not exist.
But then, I do not know the philosophy behind this setup.

Instead I would have created my own master (base) files for my application,
based on the IBM supplied files.

With regards,
Carel Teijgeler.

*********** REPLY SEPARATOR ***********

On 21-8-2008 at 12:09 CRPence wrote:

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.

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.?

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.

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.

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.

--
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.