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.
>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
