Thanks, that makes a lot of sense. It is for updating "Read Mostly Memory". Since the death of PLMs, I really don't know much about internals any more. I now tend to be a "strict GUPI" type of programmer. Do you happen to know of a z/OS data structure which is "read mostly"? Thinking about it, the CICS definition control blocks: PPT, PCT, FCT, ... are likely "read mostly" except for a few statistics fields. I don't know much about other things, since we are a very primitive shop.
-- 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: Tuesday, September 18, 2012 1:47 PM > To: [email protected] > Subject: The Transaction state (was Model 2827 New Instructions) > > The transaction state is expected to replace many instances of > acquiring either a latch or a lock. It's benefit arises because > latches/locks do not distinguish between a "shared" need vs. an > "exclusive" need, so all latches/locks are, effectively, "exclusive". > > Consider a thousand processes needing to scan a queue and one > process, every year or so, updating that queue. The scan processes do > not need to defend against each other, only against the updater. So a > vast majority of the time, scanners are "unnecessarily" delayed. > "Unnecessary" in the sense that the updater just ain't there, only > other scanners. > > With the transaction state, neither scanners nor updaters need to > acquire any latch or lock. In fact, the scanners don't need to > acquire anything at all. They can simply scan the queue and be > assured (a) their scan will both complete and succeed, and (b) they > will see the queue either prior to update, or after update, but never > mid-update; i.e. they will always see a coherent queue. > > Only the updater needs to use the transaction state ("TS"). Scanners > won't interfere with him. Other updaters (whether they're also in the > transaction state or not!) may interfere. I.e. they may try to update > the same fields at the same time. This is called a "collision"... > > - If both colliders are in the transaction state, then one will win > (and will proceed undisturbed) and one will lose (will TABORT and > will have to retry). > > - If one is in the TS state and one is not, then the one who is not > will win, and the one who is will have to retry. > > Of course, every updater should be in the TS state because if two > colliders are not... well that is what you want to avoid. > > IHTH > 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 > > > At 9/18/2012 02:20 PM, McKown, John wrote: > >I just read up on the Transaction Execution. I now need two things: > >1. Aspirin; 2. a nap. I get the general concept, but the > >restrictions are immense. I guess it is good for a *very* short > >routine which does not update very much storage. The conditions > >under which it can abort are a multitude. I wonder exactly what it > >was that made IBM decide to implement it, as opposed to doing a CPU > >"spin loop". I guess it is the only way to guarantee that another > >CPU simply cannot observe an "in flight" set of updates by *any* > >other code on *any* other CPU. > > > >Now to read up on the other new instructions. > > > >-- > >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
