× 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.



Hello everyone on the Midrange-L discussion group...

I've been spending the last several weeks trying to understand why we are
experiencing severe interactive response time slowdowns on our large 730
8-way system. We don't usually see an increase in disk utilization or CPU
usage, just an increase in internal host response time.

I am currently focusing on seize/locks as being the major contributor to
this problem.

As I've analyzed collected performance monitor data I have noticed several
application related lock issues and our development staff is working on
correcting these.

In addition to this, IBM SupportLine keeps mentioning, but with
reservation.... that the problem "may" be related to us being on V4R4 and
not having all of the files on our system defined with: 

 Access path size  . . . . . . . . . . . . . : ACCPTHSIZ  *MAX1TB  

We are slowly in the process of converting our files over to *MAX1TB. 

Most physical files can be changed using the CHGPF FILE(FILELIB/FILENAME)
ACCPTHSIZ(*MAX1TB).

However, this change requires that all logical files defined as *MAX4GB be
recreated. We have LOTS of HUGE logical files and this will take a
significant amount of time to do resulting in several interruptions to users
accessing our critical application. Needless to say, I only want to do this
if we absolutely have to do it. 

Has anyone else heard of, or experienced this problem of  having response
time slowdowns when being at V4R4 with DB file access path sizes of *MAX4GB?

The HELP for the CHGPF command says:

--- Performance Tip ------------------------------
                                                  
For optimum performance, consider whether         
there is high contention for keys within          
the access path when selecting the value on       
this parameter:                                   
                                                  
o  When there is little or no contention for keys,
   specifying the *MAX4GB value generally         
   provides better performance.                   
o  When there is high contention for keys,        
   specifying the *MAX1TB value generally         
   provides better performance.                   


I have been running the Performance Tool Monitor with TRACE(*ALL) in order
to collect detailed Seize/Lock information. 

Does anyone know what kind of data I could expect to see that might indicate
the problem involving "access path size" related seize/lock contention
problems?

I would like a clearer indication that my problem is really related to
"access path size" before taking the system away from my users to "fix" it.

thanx in advance for any information....

Kenneth

****************************************
Kenneth E. Graap
IBM Certified Specialist
AS/400 Professional
Network Administrator
NW Natural (Gas Services)
keg@nwnatural.com
Phone: 503-226-4211 x5537
FAX:    603-849-0591
****************************************


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.