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. <
[email protected]> 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 <[email protected]> On Behalf
> Of Seymour J Metz
> Sent: Tuesday, October 5, 2021 3:33 PM
> To: [email protected]
> 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 <[email protected]> on behalf
> of David Spiegel <[email protected]>
> Sent: Tuesday, October 5, 2021 1:37 PM
> To: [email protected]
> 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*smetz3&data=04*7C01*7C*7C
> >> 66d0453903554718720608d98822bd8d*7C84df9e7fe9f640afb435aaaaaaaaaaaa*7
> >> C1*7C0*7C637690505140660718*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> >> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=Lx
> >> w1EM03nZsemipAC1ktZCbgKrL*2BedD7*2BDDlG*2Fiwn*2B8*3D&reserved=0__
> >> ;JSUlJX4lJSUlJSUlJSUlJSUlJSUl!!GryZGb6B1VCs0SfC!TBwvJ8AO8e9VuDJE7lIsI
> >> SBnAl6KAhctOQOxm3s7DJUmS0PMKUDPz75eQK5LiSU-R24$
> >>
> >>
> >>
> >> ________________________________________
> >> From: IBM Mainframe Discussion List <[email protected]> on
> >> behalf of Joe Monk <[email protected]>
> >> Sent: Monday, October 4, 2021 9:11 PM
> >> To: [email protected]
> >> Subject: Re: PL/I vs. JCL
> >>
> >> USS is a VTAM term for Unformatted System Services.
> >>
> >> USS has always meant Unix System Services.
> >>
> >> Joe
> >>
> >> On Mon, Oct 4, 2021 at 7:30 PM Mike Schwab <[email protected]>
> >> wrote:
> >>
> >>> U.S.S. Unformated System Services, until Unix System Services tried
> >>> to take it over.
> >>>
> >>> On Tue, Oct 5, 2021 at 1:24 AM Paul Gilmartin
> >>> <[email protected]> wrote:
> >>>>
> >>>> On Mon, 4 Oct 2021 17:35:41 +0000, Seymour J Metz wrote:
> >>>>
> >>>>> While TSO does not support unambiguous truncation for command
> >>>>> names, it
> >>> does for keywords. I don't know about ICCF.
> >>>>>
> >>>> Unambiguous truncation is treacherous. Addition of new
> >>> commands/keywords can break
> >>>> legacy art. For that reason I eschew abbreviations in code and
> >>> pedagogy. The worst
> >>>> case occurs when one command is a proper prefix of another command.
> >>>>
> >>>> I freely abbreviate on a command line.
> >>>>
> >>>> ________________________________________
> >>>> On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:
> >>>>> I have no problem with the DD/member ambiguity:
> >>>>> \edu with the message: INFO IBM-MAIN
> >>>>
> >>>> -- gil
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --- For IBM-MAIN subscribe / signoff / archive access instructions,
> >>>> send email to [email protected] with the message: INFO
> >>>> IBM-MAIN
> >>>
> >>>
> >>>
> >>> --
> >>> Mike A Schwab, Springfield IL USA
> >>> Where do Forest Rangers go to get away from it all?
> >>>
> >>> --------------------------------------------------------------------
> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions,
> >>> send email to [email protected] with the message: INFO
> >>> IBM-MAIN
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> - For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to [email protected] with the message: INFO
> >> IBM-MAIN
> >>
> >> ---------------------------------------------------------------------
> >> - For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to [email protected] with the message: INFO
> >> IBM-MAIN .
> >>
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to [email protected] with the message: INFO IBM-MAIN .
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
