I can see that a session to be given by Dan Greiner at the upcoming SHARE in San Francisco, February 3-8, 2013 will be a hot ticket.
Dan is the editor-in-chief of the Principles of Operation and SHARE is fortunate to have him be a featured speaker. Tom ----- Original Message ----- From: Steve Comstock [mailto:[email protected]] Sent: Wednesday, September 19, 2012 10:57 AM To: [email protected] <[email protected]> Subject: Re: The Transaction state (was Model 2827 New Instructions) On 9/19/2012 6:25 AM, Peter Relson wrote: > In z/OS 1.13 it is true that the intended "for real" user is Java. > > > z/OS 1.13 provides support for transactional execution only > as a test environment. This is identified by bit CVTTXTE which is > documented in the hold for doc for APAR OA38829 (PTF UA66429): > 398 (18E) BITSTRING 1 CVTCTLFG - System Control Flags > 1... .... CVTTXTE X'80' - A Transactional > Execution test > environment is available. > When only such a test > environment exists, you > should not use > Transactional Execution > in product code. In this > test environment, the > limited diagnostic data > available upon such > failures as program > interrupts may well be > inadequate to debug > programs > > I.e., if that bit is off, you cannot use transactional execution. > If it is on, transactional execution should be used only in a test > environment. Peter, I look at things from an application programmer's perspective. Your comments above provoke some questions for me: 1. In z/OS 1.13, is CVTTXTE set on automatically if the hardware is determined to be a zEC12? 2. If this bit is set on, what defines "a test environment"? 3. Is the message here that it's early days for this facility so applications programmers should not count on the facility being available, and if it is, it might not work as expected? > >> 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"... > > Correction: Scanners *do* interfere with him. Their read access > conflicts with the updater's write access. AND unless the update can > be done with a constrained transaction, none of this does any good > because a fallback path is needed which does obtain the serialization, > and that serialization would need to be obtained by the reader to > serialize against an updater using that fallback path. > Fortunately, with care, many updates can be done with a constrained > transaction. > >> It seems to be an extended PLO instruction. > > In a way, yes. It is a PLO "environment". But much more. Keep in mind, > for example, that PLO serializes only against other uses of PLO. It > does not serialize against (for example) users of CS for the same > field(s). > >>From my read of the doc it appears that TS only serializes with other > code >> equally doing TS. I don't see how non-TS code running a linked-list is >> protected if the TS code removes an item from the list. > > But it is. The point really is that the transactional remover cannot > remove > while the runner is running through that part of the queue because the > runner is accessing data for "read" which conflicts with the remover's > accessing of the same data for "write". Once the runner is beyond that > point > (or if it has not yet gotten up to that point) the removal can occur, so > when the runner gets there it will find the update already done (or if it > is beyond, it will not care that an earlier part of the queue has been > changed). > >> "abort random transactions at a random instruction". > > This capability is not supported by z/OS 1.13. > > Peter Relson > z/OS Core Technology Design > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * Check out our sale of training materials at http://www.trainersfriend.com/SpecialSale/ (sale absolutely ends 19 October, 2012) * Let us know if you are interested in our training materials reseller program ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
