Robert,
There are conditions other than hashing multiple resources to the same
lock table entry that are currently reported as false contention. Some of
these have to do with XES internal processing for lock requests that require
global management because of current or previous resource or lock table entry
contention. They occur for specific patterns of lock requests, and VSAM/RLS is
one application that tends to initiate requests in those patterns. Expanding
the lock structure does not reduce false contention in these cases. APAR
OA61848, targeted for closure later this quarter, will alleviate this problem
somewhat.
Regards,
Bill Neiman
Parallel Sysplex development
IBM
> All,
>
> I can't reconcile RLS lock structure false lock contention between the
> various SMS statistics records.
>
> According to the type 42 subtype 17 we have a lot of false contention
> (field SMF42HCC). However, our type 42 subtypes 15 (storage class response
> time) and 16 (dataset response time) false contention buckets are zero.
> The only exception in the 16's and 17's are fields SMF42GUB and SMF42FUB
> that record locks that hashed to the same entry, which I thought was the
> definition of false contention. However, the statistics in those fields
> are a little more than half than the false contention reported in the
> subtype 15's.
>
> I have SMS dataset monitoring set up for both SMF and IGWDATA.
>
> We are feature level Z (don't ask) so all the statistics should be below
> the line.
>
> Our lock structure is already 1G in size so I'd like to find the root
> cause of the false contention before making it any bigger.
>
> Does anyone have some advice?
>
> Thanks.
>
> Robert Crawford
> Mainframe Management
> United Services Automobile Association
> (210) 913-3822
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
