× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Ed - any progress at getting IBM Partners to get their code compatible with 50? (and other than purchased software problems, given what Ed said, I think everyone should run 50(try explaining to some CEO that you didn't think it was "necessary"
to go that high...))

Jim Franz
----- Original Message ----- From: "Ed Fishel" <edfishel@xxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Thursday, December 15, 2005 1:48 PM
Subject: RE: Security level 50



Jim Damato wrote on 12/15/2005 11:13:44 AM:

One of the guys used to work with the iSeries at IBM.  I'm not sure to
what capacity.  I haven't had time to flesh out his knowledge of how
security level 50 would effect performance.

Really, it's not about performance problems -- it's more about the
suggestion that performance might be better if we weren't at 50.  We run
a pretty big iSeries server and we upgrade it when it doesn't meet our
run-time windows or threatens to do so.  We've had long stretches of
time where we've run with ASP at 80-90% of capacity without worrying
about performance, and we've had times when we've tuned the heck out of
the system and it hasn't been enough.

I'm trying to anticipate a time down the road when growth and contention
cause batch jobs to run too long, and some wise guy says "didn't those
guys say that security level 50 slows down the system?"  Then I'll have
to prove them wrong or back down to 40 or 30 along with a host of other
tuning stabs in the dark.

It's seems like the list is saying either:

"I've never seen a performance degradation"  or "IBM said there could be
performance degradation, but actual results may vary depending on your
system and applications"

A little history of security level 50 may be helpful. When security level
50 was first created back in V2R3, one of the big differences between
security level 50 and the other levels is that code was added to API and
other user domain and system state program interfaces to validate pointers
used in their parameters. At the time developers were told to maximize the
performance of security levels 10 to 40 and not worry about level 50. As a
result some very creative, but slow, ways were used do some of the
parameter validation. Then a few release ago the decision was made to do
parameter validation at security level 40. At that time performance studies were done and changes were made to significantly reduce the overhead needed
to do the parameter validation. As a results, the performance of security
level 50 was improved.

My belief is that most applications today will not see any performance
difference between the top 3 security levels. But if the applications does
something like opening the same file hundreds (thousands?) of times a
minute the parameter validation overhead will be magnified and may be
noticeable.

Ed Fishel,
edfishel@xxxxxxxxxx

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.