Transactional execution

Start of changez16 is the last machine that fully supports non-constrained transactions. On z17, non-constrained transactions have limited support. See Non-constrained transactions for more information.End of change

Start of changeIBM z17 is planned to be the last IBM Z hardware generation to support constrained transactions. Programs using constrained transactions must dual-path to use constrained transactions when available and alternatives otherwise. See Constrained transactions for more information. End of change

The transactional execution facility is a hardware-based facility that supports the notion of "transactions" through the use of such instructions as TBEGIN, TBEGINC, TABORT, and TEND (all of which are described in z/Architecture Principles of Operation). A transaction either completes successfully or it aborts. When a transaction aborts, with the exception of a new instruction classified as a "non-transactional store", storage is unchanged from the time of the transaction begin from the program's perspective (except for a diagnostic block that can be provided).
  • Only when bit CVTTX is on (in the CVT data area) or bit PSATX is on (in the PSA data area) does z/OS support the use of the TBEGIN instruction. You can check either bit; you do not have to check both.
  • Only when bit CVTTXC is on (in the CVT data area) or bit PSATXC is on (in the PSA data area) does z/OS support the use of the TBEGINC instruction. You can check either bit; you do not have to check both.

The transactional execution facility applies special rules to instructions that are executed within transactional execution mode. Some of these rules are described here. For a complete description, read the section entitled "Restricted Instructions" in chapter 5 of z/Architecture Principles of Operation. Specifically, you can think of instructions executed within a transaction as block concurrent (as observed by other CPUs and the channel subsystem), with the transactional execution facility providing the serialization that you might otherwise implement yourself to accomplish block concurrency (whether that be an instruction such as CS, or an ENQ, latch, or system lock). The details of the block concurrency are important to understand and are part of z/Architecture Principles of Operation. For example, two transactions conflict with each other if both need access to a particular cache line and at least one of them needs to write to that cache line. When such a conflict is detected, the transaction cannot complete successfully, but it might complete successfully upon being retried. The benefit of transactions is that, when no conflict exists, one processor might be able to complete its operation in a simple way, without having to obtain software-managed serialization or utilize serializing instructions to protect itself.

Start of changeThere are two kinds of transactions: non-constrained and constrained. Constrained transactions have additional restrictions. Many instructions are restricted from being used within a transaction. End of change