|
Chris, Since you are using group profiles you "shouldn't" have an issue. But since you do, there may be some profiles that are not part of the appropriate groups. Steve's email has good suggestions on resolving this. Chuck ----- Original Message ----- From: "Jnb ZI, Christophe Wenk" <christophe.wenk@kuehne-nagel.com> To: <midrange-l@midrange.com> Sent: Thursday, September 06, 2001 8:35 AM Subject: RE: Private Authority > Chuck, > > We use goup profiles. Yes, every user has the authority which is needed. > Approx 200 profiles. > Chris > > -----Original Message----- > From: midrange-l-admin@midrange.com > [mailto:midrange-l-admin@midrange.com] On Behalf Of Chuck Morehead > Sent: 06 September 2001 03:33 > To: midrange-l@midrange.com > Subject: Re: Private Authority > > > Chris, > > What is your standard method for securing objects? I.e., do you utilize > group profiles or authorization lists? Is every user simply granted > authority to what they need? Out of curiosity, how many user profiles > are there on your system? > > Chuck > > ----- Original Message ----- > From: "Jnb ZI, Christophe Wenk" <christophe.wenk@kuehne-nagel.com> > To: <midrange-l@midrange.com> > Sent: Thursday, September 06, 2001 8:12 AM > Subject: RE: Private Authority > > > > Andy, > > > > It says following: > > > > Cause . . . . . : The guideline was first exceeded in the interval > > > > ending 06.09.01 13:54:03. The maximum rate was 216 checks per second > > and occurred in the interval ending 06.09.01 13:54:03. At the > > maximum rate, > > these checks may have used as much as 6% of the processing unit. The > > > > guideline was exceeded in 1 out of 1 intervals. > > > > > > > > High authority check rates are usually due to private authority > > lookups. A high rate is often found in systems that have migrated > > from a S/38. > > > > They may also occur when new applications have been integrated into a > > > > production system without the private authorities being removed. > > > > Recovery . . . : An authority count above the guideline is > > acceptable > > if your security scheme requires private authorities. A change to > > your security scheme may result in a change to the authority check > > rate. Therefore, you should investigate unexpected increases in the > > cpu utilization due to an increased authority check rate. To avoid > > high authority check rates, eliminate private authorities wherever > > possible. > > > > ==> we have an AS/400 720 and nevery migrated from a S/38. > > I would like to eliminate the private authorities but where to start > > ?? > > > > Thanks > > Chris > > > > > > -----Original Message----- > > From: midrange-l-admin@midrange.com > > [mailto:midrange-l-admin@midrange.com] On Behalf Of Andy > > Nolen-Parkhouse > > Sent: 06 September 2001 03:02 > > To: midrange-l@midrange.com > > Subject: RE: Private Authority > > > > > > Chris, > > > > Is there any more indication of what the problem is? Limits on > > private authorities for an individual profile are in the hundreds of > > thousands, does your report give any context? > > > > The PRTPVTAUT command will allow you to list out the private > > authorities for various objects if that would be helpful. > > > > Regards, > > Andy Nolen-Parkhouse > > > > > Subject: Private Authority > > > > > > Hi there > > > > > > I did run the Performance Tools and checked afterwards the > > > performance > > > > > Adviser. There it tells me that I exceeded the limit of private > > > Authorities with 216. Can anybody tell me what I can do (which > > > command to run) in order to rectify > > > the problem ? > > > > > > Thanks > > > Chris > > > > _______________________________________________ > > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing > > > list To post a message email: MIDRANGE-L@midrange.com To subscribe, > > unsubscribe, or change list options, > > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > > or email: MIDRANGE-L-request@midrange.com > > Before posting, please take a moment to review the archives at > > http://archive.midrange.com/midrange-l. > > > > _______________________________________________ > > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing > list > > To post a message email: MIDRANGE-L@midrange.com > > To subscribe, unsubscribe, or change list options, > > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > > or email: MIDRANGE-L-request@midrange.com > > Before posting, please take a moment to review the archives at > > http://archive.midrange.com/midrange-l. > > > > > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing > list To post a message email: MIDRANGE-L@midrange.com To subscribe, > unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.