Re: Seize/Lock Issues

["R. Bruce Hoffman, Jr." <rbruceh@xxxxxxxxxxxxx>]

As I understand it, one of the differences between the old 4G and new 1T
indicies is that the new ones seize the leaf node only for the update and
the older ones seize the root node.

So if you do al lot of updating and the access paths are being hit for those
updates, then yes, switching should help.

As for the performance data, since the seize still occurs, just at a
different level, I don't know that standard performance tools can show you
any differences other than seize wait times going down.


===========================================================
R. Bruce Hoffman, Jr.
 -- IBM Certified AS/400 Professional System Administrator
 -- IBM Certified AS/400 Professional Network Administrator

"The sum of all human knowledge is a fixed constant.
    It's the population that keeps growing!"

-----Original Message-----
From: Graap, Ken <keg@exchange.gasco.com>
To: 'Midrange' <midrange-l@midrange.com>
Date: Friday, June 02, 2000 2:32 PM
Subject: Seize/Lock Issues


>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
>+---
>

+---
| 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
+---