Re: object authorities, now have to add QSYSOPR back

Ooh ooh ooh!  Mr. Kotter!  Mr. Kotter! (Sorry, late at night flashback.)

Anyway, I've been working with exactly this issue.  I recommend the following:

1. Create a "master" authorization list
2. In it, put your authorized users
3. Also in it, put *PUBLIC *EXCLUDE
4. Set the objects to AUTL(autlname) and *PUBLIC *AUTL

Now, every file is at the mercy of the authorization list.  Why is this important?  Because you can change authorizations for all 3500 objects just by making a single change to the AUTL, and you don't need to lock the objects! Booyah!!!!

There are other nuances, such as whether to use a group profile rather than individual profiles in the AUTL (I prefer groups), whether you should handle exceptions with multiple AUTLs or with adding private authorities (depends on the number and variety of exceptions), that sort of thing.  But for sure, I find AUTL for everything my new best friend.

:)


On 5/20/2020 4:44 PM, Gerald Magnuson wrote:

I thought I was almost done... removing *PUBLIC from my production database
library....
I have a few objects that need specific authority to allow a very small set
of users to download, or have those CPYTOIMPF, or CPYTOSTMF commands. some
objects come in through FTP, and they wind up being owned by user profile
that runs job...

but I ran into many more cases of our job scheduling tool, running commands
like "clrpfm", or setting data areas, or CPYF directly, not within a
program. and these all run as QSYSOPR, and can't be ran (without levels
of effort above what I am doing...) as QPGMR.
so, I am having to grant QSYSOPR *ALL or *CHANGE authority.

since it appears I am going back through the objects(about 3500), should I
make a *AUTL? would it just be as easy to mass perform "grtobjaut qsysopr
*all/*change" ?