IBM Transaction Server OS - Manual (Page 23)

Protecting applications from one another
The transaction isolation function offers storage protection between application
programs, ensuring that one application does not accidentally overwrite the storage
of another.
Transaction isolation ensures that user-key programs 1 execute in their own
subspace, with appropriate access to any shared storage, or to CICS storage. Thus
a user transaction is limited to its own view of the address space. In general,
transaction isolation ensures that each user-key program is allocated a separate
(unique) subspace, with appropriate access to any shared storage or to CICS
storage. They do not have any access to the user-key task-lifetime storage of other
tasks. Existing applications should run unmodified provided they conform to
transaction isolation requirements. However, a minority of applications may need
special definition if they:
v Issue MVS macros directly
v Modify CICS control blocks
v Have a legitimate need for one task to access or share another task’s storage
Some existing transactions may share task-lifetime storage in various ways, which
may prevent them running isolated from each other. To allow such transactions to
continue running without requiring that they run in the base space (where they
could corrupt CICS data or programs), a single common subspace is provided in
which all such transactions can run. They are then isolated from the other
transactions in the system that are running in their own subspaces, but are able to
share each other’s data within the common subspace.
You may have some transactions whose application programs access each other’s
storage in a valid way. One such case is when a task waits on one or more event
control blocks (ECBs) that are later posted, by another task, either an MVS POST
or ‘hand posting’. For example, a task can pass the address of a piece of its own
storage to another task (via a temporary storage queue or some other method) and
then WAIT for the other task to post an ECB to say that it has updated the storage.
Clearly, if the original task is executing in a unique subspace, the posting task will
fail when attempting the update and hence fail to post the ECB, unless the posting
task is executing in CICS key. CICS therefore checks when a WAIT is issued that
the ECB is in shared storage, and raises an INVREQ condition if it is not.
Storage for the timer-event control area on WAIT EVENT, and storage for event
control blocks (ECBs) specified on WAIT EXTERNAL and WAITCICS commands,
must reside in shared storage.
2
You can use the Transaction Affinities Utility to identify those transactions whose
programs issue WAIT EVENT, WAIT EXTERNAL, or WAITCICS commands, or MVS
POST macros.
1. User key defines both the storage and execution key for user application programs.
2. Shared storage is allocated from one of the user-key shared dynamic storage areas, below or above the 16MB boundary (SDSA or
ESDSA).
Chapter 1. Introducing transaction affinities 7