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
vIssue MVS macros directly
vModify CICS control blocks
vHave a legitimate need for one task to access or share another task's storage
Some existing transactions may share
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
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 de®nes both the storage and execution key for user application programs.
2.Shared storage is allocated from one of the
Chapter 1. Introducing transaction affinities 7