Constrained transactions

A constrained transaction begins with a TBEGINC instructions and, as with a nonconstrained 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 following restrictions apply to constrained transactions only:

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.