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) does z/OS support the use of the TBEGIN instruction. Only when bit CVTTXC is on (in the CVT data area) does z/OS support the use of the TBEGINC instruction.
The transactional execution facility applies special rules to instructions that are executed within transactional execution mode. Some of these rules are described below. 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.
There are two kinds of transactions: nonconstrained and constrained. Constrained transactions have additional restrictions. Many instructions are restricted from being used within a transaction.
