John, At least you have a REAL machine I have z/Pdt which great for development .. Last machines I saw were 968x series,
Scott ford www.identityforge.com On Sep 18, 2012, at 2:57 PM, "McKown, John" <[email protected]> wrote: > 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
