Re: MCH1001 in S36EE Mode At Security Level 20

Hi, Rich:

What QSECURITY< 30 (e.g. 10 or 20) does is, whenever a user profile is
created, the system automatically ensures that it has *ALLOBJ
authority. That's just how this QSECURITY 10 or 20 feature has always
worked, AFAIK.

Once you change to QSECURITY 30 or higher, it is the system
adminstrator's responsibility to go through all of the user profiles and
remove *ALLOBJ from those who should no longer need it. The system
makes no attempt to do this for you.

Hope that helps,

Mark S. Waterbury

> Rich Loeber wrote:

Hello all.

I am working with a client that runs a lot of interactive programs in
S36EE. They are at security level 20 and I'm getting them ready to move
to level 30. I have the user profiles all organized into groups with just
three groups in total. I have the system journal set up to track AF
errors before making the switchover. Earlier this week, I removed all of
the *ALLOBJ permissions for the non-security officer users thinking that
since they are still running level 20, application processing would not be
affected.

Not so .... I've been getting intermittent reports of MCH1001 errors for a
couple of days now. The first round seemed to be satisfied by granting
access to the QS36F library. I just got another one that seems to be
related to a profile not have access to its own *USRPRF object in QSYS.

The question is, why are they having object authority issues when they are
still running at level 20. The whole point of this was to trap any such
errors in advance and get them corrected before making the change from
level 20 to level 30. The IBM documentation recommends this approach.

What am I missing?

Rich Loeber - @richloeber
Kisco Information Systems
[1]http://www.kisco.com

References

Visible links
1. http://www.kisco.com/