While I never worked with RLS, I found this issue to be an interesting one
to research since I performed
quite a bit of CICS LSR tuning 20 years ago.
>From what I have found in the main z/OS manuals and Redbooks, the lock
structure needs to be enlarged.
Additionally, if the MAXSYSTEM parameter was set higher than it needed to
be, that can cause unnecessary doubling
of the size of the cache entries. The doubling occurs when you exceed 7
and then when you exceed 23.
Since the lock table is used by all clusters participating in RLS, I would
not expect any SMF record to be attributing the false
contention to a specific cluster - it is just an expected side-effect of
hashing.
Conceivably, if there are bottlenecks in the CICS transactions such that
the locks are being held longer than in the past,
that could be contributing to the false contentions, as the hash table
entry is being released more slowly.
In the rare event that there are any VSAM clusters defined to RLS that are
not ever shared, you could consider changing
those clusters back to LSR and perform manual tuning of their pools,
thereby reducing the stress on the lock table.
However, there are application subtleties in doing so - record-level
locking in the RLS case versus control-interval locking in the LSR case.
Allan
On Tue, Oct 5, 2021 at 5:17 PM Crawford, Robert C. <
01feadb2c2d2-dmarc-requ...@listserv.ua.edu> wrote:
> Off and on we VSAM RLS false contention plateaus going over IBM's
> recommended .5% rate. We don't see any kind of triggering behavior in CICS
> or the CICS application.
>
> I would like to at least see the datasets causing the false contention but
> all the false contention buckets in the RMF type 42 subtype 16 records are
> zero. The true contention buckets have values.
>
> It's my understanding the subtype 16 are supposed to have dataset level
> information. I specified several dataset name levels in RMF VSAMRLS
> options. I also see the same dataset levels in SMS display MONDS commands.
>
> Is it possible I'm missing something that causes DFSSMS to write dataset
> level false contention data? Am I looking in the wrong place?
>
> 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
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf
> Of Seymour J Metz
> Sent: Tuesday, October 5, 2021 3:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: EXTERNAL: Re: PL/I vs. JCL
>
> And before that MVS-OE., with MVS before Open.
>
>
> --
> Shmuel (Seymour J.) Metz
>
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!GryZGb6B1VCs0SfC!TBwvJ8AO8e9VuDJE7lIsISBnAl6KAhctOQOxm3s7DJUmS0PMKUDPz75eQK5LMQqR2TA$
>
>
>
> From: IBM Mainframe Discussion List on behalf
> of David Spiegel
> Sent: Tuesday, October 5, 2021 1:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> Maybe they should've left it as "Open MVS"? (OS/390)
>
> On 2021-10-05 13:08, Tom Brennan wrote:
> > I always thought IBM's position on that was pretty silly. If you make
> > up a new three word name, expect it to quickly be turned into an
> > acronym. If they didn't want us to reuse an existing little-known
> > acronym they should have named it something else.
> >
> > On 10/5/2021 9:56 AM, Seymour J Metz wrote:
> >>> USS has always meant Unix System Services.
> >>
> >>
> >> Not unless you have a time machine; Unformatted System Services dates
> >> to the 1970s. Further, the last post here from IBM on the issue said
> >> that USS was not an approved abbreviation for Unix System Services.
> >>
> >> --
> >> Shmuel (Seymour J.) Metz
> >> https://urldefense.com/v3/__https://na01.safelinks.protection.outlook
> >> .com/?url=http*3A*2F*2Fmason.gmu.edu*2F*smetz3data=04*7C01*7C*7C
> >> 66d0453903554718720608d98822bd8d*7C84df9e7fe9f640afb435*7
> >> C1*7C0*7C637690505140660718*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> >> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000sdata=Lx
> >> w1EM03nZsemipAC1ktZCbgKrL*2BedD7*2BDDlG*2Fiwn*2B8*3Dreserved=0__
> >> ;JSUlJX4lJSUlJSUlJSUlJSUlJSUl!!GryZGb6B1VCs0SfC!TBwvJ8AO8e9VuDJE7lIsI
> >> SBnAl6KAhctOQOxm3s7DJUmS0PMKUDPz75eQK5LiSU-R24$
> >>
> >>
> >>
> >>
> >> From: IBM Mainframe Discussion List on
> >> behalf of Joe Monk
> >> Sent:
