Re: EXTERNAL: Re: RLS False Contention Statistics

2022-01-12 Thread Crawford, Robert C. 
Our MAXSYSTEM is set to 8 although there're only 6 LPAR's in the Sysplex.

The IBM recommends false contention to be less than .5%.  We consistently go 
over that threshold during our prime shift.

Our dirty little secret:  We're running a dozen or so active ESDS' under RLS.  
I know IBM recommends against this but we're pretty much stuck due to the 
application's architecture.  The best we might be able to do is change our 
application's "randomizer" to reduce cross-system/cross-CICS contention.  File 
owning regions (FOR's) aren't an option due to availability concerns.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

“Moy glaz! YA ne dolzhen dobavlyat' v nego puding!”
- Tolstoy
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Attila Fogarasi
Sent: Tuesday, January 11, 2022 4:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: RLS False Contention Statistics

What is your MAXSYSTEMS value?  There is a false lock contention penalty when 
your MAXSYSTEMS value exceeds 7 or 23.  Of course your MAXSYSTEMS has to match 
the actual number of parallel sysplex members :)  Also what is your false lock 
contention rate?  1% is typically acceptable though it really varies with your 
application structure.  Ultimately it is an application design issue, and 
Db2/IMS do a much better job of concurrent data access.

On Wed, Jan 12, 2022 at 2:19 AM Crawford, Robert C. < 
01feadb2c2d2-dmarc-requ...@listserv.ua.edu> wrote:

> 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
>
> "Moy glaz! YA ne dolzhen dobavlyat' v nego puding!"
> - Tolstoy
> Please send requests to mainframe management through our front door at 
> go/mfmfrontdoor< 
> https://urldefense.com/v3/__https://onc.jira.usaacloud.com/secure/Dash
> board.jspa?selectPageId=15466__;!!GryZGb6B1VCs0SfC!TrpjUotsagny5EiQXOx
> Ek8XLA34t_PRZ1cAAEi6zQn9KKZOwLw1z2wVKBGQ6eOWQPuE$ >
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RLS False Contention Statistics

2022-01-12 Thread Bill Neiman 
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RLS False Contention Statistics

2022-01-11 Thread Attila Fogarasi 
What is your MAXSYSTEMS value?  There is a false lock contention penalty
when your MAXSYSTEMS value exceeds 7 or 23.  Of course your MAXSYSTEMS has
to match the actual number of parallel sysplex members :)  Also what is
your false lock contention rate?  1% is typically acceptable though it
really varies with your application structure.  Ultimately it is an
application design issue, and Db2/IMS do a much better job of concurrent
data access.

On Wed, Jan 12, 2022 at 2:19 AM Crawford, Robert C. <
01feadb2c2d2-dmarc-requ...@listserv.ua.edu> wrote:

> 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
>
> "Moy glaz! YA ne dolzhen dobavlyat' v nego puding!"
> - Tolstoy
> Please send requests to mainframe management through our front door at
> go/mfmfrontdoor<
> https://onc.jira.usaacloud.com/secure/Dashboard.jspa?selectPageId=15466>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

RLS False Contention Statistics

2022-01-11 Thread Crawford, Robert C. 
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

"Moy glaz! YA ne dolzhen dobavlyat' v nego puding!"
- Tolstoy
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN