RE: Performance problem - Authority check exceeded guideline

John:

It'll be hard for anyone to tell about your environment without knowing more 
than you probably want to broadcast. To start, we have no clear idea whether a 
problem exists. You didn't indicate if you were investigating performance due 
to poor response times or whatever or you were simply running reports and this 
item caught your eye. However, assuming you aren't seeing serious performance 
issues right now, there are a couple steps you can take to start any fixing you 
might want to do.

First, run a CL script that repeats this command for all of your user profiles:

 ==> dspusrprf usrprf(&next_prf) type(*objaut) +
       output(*outfile) outfile(mylib/objaut) +
       outmbr(*first *add)

Since I have no idea how many profiles and objects you have nor how private 
authorities might be used, I can't guess how long this will take nor how big 
the resulting file will be. Ideally, even with a lot of profiles and objects, 
the file will be small.

The command can be run against small groups of profiles, a few at a time over a 
number of days, to minimize any impact. I'd probably include a check in the 
loop to see if an entry appears on a data queue; that allows a clean way to 
interrupt the job in the middle by sending an entry. Or you might start it up 
and let it run over a weekend. Whatever works best. It isn't that important to 
have absolute up-to-the-minute data for this. You're looking for significant 
areas right now and gross numbers will work.

What you'll get might be a big mess of details that seems impossible to make 
sense of. However, with SQL, you could make some useful summaries. You might 
extract counts by library; you might count by owner; you might see how many 
primary group entries appear. You might find a commonly used object that has 
private authorities assigned for nearly every user. A bunch of summaries can 
give you all kinds of info about the scope of your problem -- if one really 
exists.

Also go to the iSeries Security Reference and review topic 5.11, How the System 
Checks Authority. Review the examples and use data from your file above to help 
guage impacts.

http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/QB3ALC04

Perhaps you'll find that one of your libraries has objects authorized by a 
bunch of private authorities when nobody needs authority except for the library 
itself -- why authorize objects if you can't get past the library? Perhaps 
you'll find that private authorities are used where primary group might work 
best. Perhaps you'll find that some IBM profiles have private authorities to a 
bunch of your application objects. QPGMR? Sheesh, I just checked one old system 
and QPGMR had a huge list; whenever QPGMR runs a process and needs to have 
authorities checked, it's got to be ugly. Don't underestimate the impact of IBM 
profiles.

Nobody knows yet in your case. This might be the start of a major rework of 
your authority scheme. Take some time to gather a repository of info, and see 
if patterns come out.

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

>   7. Performance problem - Authority check exceeded guideline
>      (jdyer@xxxxxxxxxx)
>
>We're running performance tools on an iSeries 820 at V5R1, and the Advisor 
>reports PFR2581 "Authority check rate exceeded guideline ... maximum rate 
>(was) ... 536 checks per second ... these checks may have used as much as 
>31% of the processing unit". This warning is present in every sample. 
>
>Based on information found in a 1997 Midrange-L message thread on this 
>topic, we wrote programs to examine the system and reveal any objects for 
>which one or more private authority rules were found to have lesser access 
>rights than a public authority rule. All instances were corrected, without 
>noticeable effect.
>
>Interestingly, the above referenced Midrange-L discussion thread is the 
>ONLY mention of this topic revealed by either Google, Copernic Agent or 
>the IBM Technical Database search engine.
>
>Does anyone have a suggestion regarding a strategy to reveal the source of 
>this issue?

-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com


__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455