Manage Learn to apply best practices and optimize your operations.

Automatic default authority

Question: Part 1

I have a very large group profile, approximately 17,000 members. Several times recently, a new member has been added to this group, but the individual's profile did not get the "automatic" default authority. When they attempted to sign on, they received the message "no authority to group profile xxxxxx" and were not allowed to sign on. What could have caused the user to not receive the "automatic" default authority? (Note: I am working on a plan to separate this one large group into at least one other group.)

Question: Part 2

When the above message was received for the second time in a week, I did an EDTOBJAUT command over the group profile. It took forever to run, but more importantly, no one, no matter what their group profile, was able to initiate a PC5250 session while the command was running. Why would editing a group profile's authority lock-up the entire device descriptions?

Paul's response: Part 1

A user profile contains four categories of entries:

1. Every object owned by the profile.

2. Every private authority the profile has to other objects.

3. Every private authority other profiles have to objects owned by this profile.

4. Every object for which this profile is the primary group. The sum of these categories equals the total number of entries for the profile.

The maximum number of entries for a user profile is 5,000,000 and a group profile with 17,000 members is likely to have high numbers for all four categories. Therefore, it is quite possible that you have exceeded the maximum number of entries for a user profile with these additions to your group.

Try running PRTPRFINT against the group profile to see how the profile might be affected by its size.

Paul's response: Part 2

It's difficult to say. The profile this large might own several device message queues or any number of related objects. It's probable that the QSYSOPR message was partially misleading in that some other object needed to be allocated first in order to complete establishing the device lock. If so, because the unknown other object could not be allocated, the device allocation couldn't finish and the message was sent.

If I had to bet, I would bet that you will continue to have strange occurrences around this group profile in the future strictly because of its unwieldy size. Save your self some future headaches and lower the number of members in this group as well as break up the group into more manageable sub-groups.

One way to quickly reduce the size of the group would be to scan for dormant user profiles. You may want to schedule this for off hours, and probably want to do it on a limited set of profiles, but it's a good bet that there are a large number of old profiles that are not used and can be removed from your system. A good security-auditing tool will simplify and automate this discovery process.


The Best Web Links: tips, tutorials and more.

Search400's targeted search engine: Get relevant information on security.

Ask your systems management questions--or help out your peers by answering them--in our live discussion forums.

Check out this Search400.com Featured Topic: Top ten security tips

Dig Deeper on iSeries system and application security

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.