Dave/Mark:
I saw a problem similar to what you are describing but it was in a custom
application written for a very large customer by a very large vendor. The
problem sounds the same so I will describe the one I encountered.
In the problem I saw they were inserting a record into a very large linked
list. They acquired a lock before scanning the list looking for the insert
point. As the list got longer, the amount of time that the lock was held became
longer and similar transactions on other processors were SPINNING, awaiting the
release of the lock. My suggestion was to scan the list first looking for the
insert point, THEN acquire the lock, re-verify the insert point, do the insert
and free the lock. That diminished the amount of time that the lock was held
and fixed the problem. You can also check for excessive spin records to confirm
this.
In fact, a similar technique can be used when using the CS and CDS
instructions. Instead of using the CS and CDS instructions to serialize on a
memory location every time, you can use a normal compare till you find what you
are looking for, then issue the CS or CDS to verify it is still the same.
Bill
> Date: Tue, 13 Jan 2009 10:41:17 -0500> From: [email protected]> Subject:
> Re: z/OS 1.10 upgrade stopped by RLS - SMSVSAM bug> To: [email protected]>
> > Thanks Mark, will do. So, you have not put the toleration maintenance> on
> your current systems for 1.10 yet? That is when we saw the problem,> and that
> was only in our DEV environment. Never even got a chance in> production.
> SMSVSAM has been good for us up to this point as well. If> you have installed
> the maint, the problem only surfaces at cluster open> time, so if dataset
> opens at your shop are only sporadic, and not done> all at once, you may not
> be seeing the problem. On our development> systems, where some of our online
> regions are bounced all the time, we> have 7000+ datasets registered in RLS,
> and my performance guy was> sitting on my doorstep the day after the fixes
> went on DEV, when he was> seeing SMSVSAM go from less than 10 MIPS to over
> 250 MIPS sustained> bursts. IBM has found the source of the CPU sucking, it
> is when they> scan the "table" for a dataset name match in the lock
> structure. The> IBM TEST group load tests in the lab with only 1000 datasets,
> and that> is why they didn't see the CPU jump I am being told.> > Dave> >
> _________________________________________________________________> Dave
> Jousma> Assistant Vice President, Mainframe Services> [email protected]>
> 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G> p 616.653.8429> f
> 616.653.8497> > -----Original Message-----> From: IBM Mainframe Discussion
> List [mailto:[email protected]] On> Behalf Of Mark Zelden> Sent: Tuesday,
> January 13, 2009 10:18 AM> To: [email protected]> Subject: Re: z/OS 1.10
> upgrade stopped by RLS - SMSVSAM bug> > I don't think that is true. But
> perhaps not many are ready to roll 1.10> to production yet. We are a big RLS
> shop but just starting 1.10 now. > We usually order in Dec. or Jan. after it
> has been out a while so > shops like yours can work out the bugs for us. :-)
> > > Actually, SMSVSAM has been behaving fairly well since post z/OS 1.3. Or>
> at least the end of our z/OS 1.3 after many many PTFs were applied. > We had
> problems all the time back then. > > Please keep us posted!> > This e-mail
> transmission contains information that is confidential and may be privileged.
> It is intended only for the addressee(s) named above. If you receive this
> e-mail in error, please do not read, copy or disseminate it in any manner. If
> you are not the intended recipient, any disclosure, copying, distribution or
> use of the contents of this information is prohibited. Please reply to the
> message immediately by informing the sender that the message was misdirected.
> After replying, please erase it from your computer system. Your assistance in
> correcting this error is appreciated.> >
> ----------------------------------------------------------------------> For
> IBM-MAIN subscribe / signoff / archive access instructions,> send email to
> [email protected] with the message: GET IBM-MAIN INFO> Search the archives
> at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
