Constrained transactions
IBM z17 is planned to be the last IBM Z hardware generation to support constrained
transactional execution. On subsequent IBM Z hardware generations, the TBEGINC instruction that is
used to start a constrained transaction will receive an operation exception, and no constrained
transactional execution will be initiated or supported.
Programs currently using constrained transactional execution must dual path their
usage, so that when running on an IBM Z hardware generation that supports constrained transactional
execution, constrained transactional execution continues to be used; but when running on an IBM Z
hardware generation that does not support constrained transactional execution, alternative
mechanisms are used instead.
IBM z17 provides several new Perform Locked Operation (PLO) functions that are
intended to provide a set of alternative capabilities that can be used in lieu of constrained
transactional execution. Note that many other existing serialization mechanisms can also be used to
provide the necessary atomicity as an alternative to the use of constrained transactional execution.
A constrained transaction begins with a TBEGINC instruction and, as with a
non-constrained transaction, ends normally with a TEND instruction and may abort for many
system-defined reasons.
The key difference is that, in the absence of repeated interruptions or other constraint violations, a constrained transaction is assured of eventual completion. Thus, it does not need a fall-back path.
The TBEGINC instruction always completes with CC=0 so it does not need a conditional branch following it.
- The transaction executes no more than 32 instructions.
- All instructions within the transaction must be within 256 contiguous bytes of storage.
- The only branches you may use are relative branches that branch forward (so there can be no loops).
- All SS and SSE-format instructions may not be used.
- Additional general instructions may not be used.
- The transaction's storage operands may not access more than four octowords.
- The transaction may not access storage operands in any 4 K-byte blocks that contain the 256 bytes of storage beginning with the TBEGINC instruction.
- Operand references must be within a single doubleword, except for some of the "multiple" instructions for which the limitation is a single octoword.
Because there is no condition code other than 0 and no need for a conditional branch after the TBEGINC, a constrained transaction has no fall-back path. Therefore, you must be prepared for running in an environment that does not support constrained transactions (bit CVTTXC not on).
Upon abort, control flows to the TBEGINC instruction.