OK, I found Ben's objection and see why it is desirable for a scanner to be in TS state. I agree it is better for the scanner to enter the TS state in order to avoid an orphan pointer error. However, the TS state cannot use "restricted" instructions. <quote> Routine A fetches pointer to block X and is interrupted (non-TS)
Routine B (TS) frees block X (TS) and completes TS Routine A (non-TS) is now redispatched with the orphan pointer. </quote> I don't see how Routine B can free block X. Routine B cannot do a FREEMAIN or a STORAGE RELEASE as these invoke "Restricted" instructions (SVC or PC). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > [email protected]] On Behalf Of David Cole > Sent: Wednesday, September 19, 2012 8:43 AM > To: [email protected] > Subject: Re: The Transaction state (correction) > > Sorry, I use the word "delayed" in an informal sense. Yes, if a > collision occurs, the TS state is aborted, and the recipient of that > abortal will have to retry. That, in an informal sense, amounts to a > "delay" in what the collider was trying to do. > > WRT Ben's objection, if a scanner is not in the TS state, then (as > Ben points out) he can quite easily be delayed. This is why my prior > understanding was incorrect. And this is why both scanners and > updaters all need to be in the TS state. > > Dave > > > > > At 9/19/2012 08:52 AM, McKown, John wrote: > >I must have total misunderstood TS state. I was under the impression > >that the TS would abort if *any* code read or updated any storage > >updated by the TS code. TS state should abort if any interrupt > >occurs while in TS state, even an I/O or External (e.g. timer) > interrupt. > >This means that the "unit of work" (TCB or SRB) cannot be suspended > >or switch to another CPU. > >It would also abort if the TS code tried to use any "unsupported" > >(by TS state) instruction (such as SVC, LAE, et al.). > > I really don't understand what you mean by "no holders of the TS > > state are delayed unless a collision actually occurs". I didn't > > see anything like "delayed" associated with TS state, only > > "aborted". I guess "delayed" could mean that the TS code needs to > > be rerun and this extra CPU usage "delays" the results. > > > >-- > >John McKown > >Systems Engineer IV > >IT > >Administrative Services Group > >HealthMarkets(r) > >9151 Boulevard 26 * N. Richland Hills * TX 76010 817) 255-3225 phone * > >[email protected]<mailto:[email protected]> > >* www.HealthMarkets.com<http://www.HealthMarkets.com>
