Why would a scanner in TS state be less likely to cause an TS abort (aka "delay") than not? I don't recall Ben's objection.
That's not Ben's point. When a scanner is not in the TS state, he can load a value (a chain field for example) and then be interrupted (by I/O, timer, whatever) before he has a chance to use it. Then an updater can get control and change in storage the point that the scanner has already loaded. The updater can get in and out before the scanner is ever resumed, so no TABORT occurs, neither to the scanner (because he was not in TS state) not to the updater (because the scanner did not read the field while the updater was changing it). Then later when the scanner is resumed, he is now working with obsolete data. On the other hand, if the scanner is in the TS state, then if he is interrupted, a TABORT will occur for him. Therefore, the scanner will know that he has to retry. This makes interrupts a non-issue. Dave At 9/19/2012 09:56 AM, McKown, John wrote:
Ah. I misunderstood your meanings of "delay", where I interpreted that as the CPU itself "stopping" as it does in a interruptible wait state. And "need" in "scanners and updaters all need to be in the TS state" as "are required to be in TS state in order to have a fetch or update cause a TS abort". A TS abort will occur regardless of the TS state of the scanner. I guess I still don't understand Ben's "he can quite easily be delayed". Why would a scanner in TS state be less likely to cause an TS abort (aka "delay") than not? I don't recall Ben's objection. -- 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>
Dave Cole REPLY TO: [email protected] ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow Road VOICE: 540-456-8536 Afton, VA 22920 FAX: 540-456-6658
