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 lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
