MVS/ESA 5.2 introduces the subspace group facility, which can be used for storage isolation to preserve data integrity within an address space.
The subspace-group facility uses hardware to provide protection for transaction data. A subspace-group is a group of subspaces and a single base space, where the base space is the normal MVS™ address space as in releases prior to MVS/ESA 5.1.
The subspace-group facility provides a partial mapping of the underlying base space, so that only specified areas of storage in the base space are exposed in a particular subspace. Thus each subspace represents a different subset of the storage in the base space. Transaction isolation, when specified, ensures that programs defined with EXECKEY(USER) 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.
Programs defined with EXECKEY(CICS) execute in the base space, and have the same privileges as in CICS/ESA 3.3.
In general, transaction isolation ensures that user-key programs are allocated to separate (unique) subspaces, and have:
They do not have any access to user-key task-lifetime storage of other tasks.
The defaults for new transaction resource definition attributes specify that existing application programs operate with transaction isolation (the default for the ISOLATE option is YES). Existing applications should run unmodified provided they conform to transaction isolation requirements.
However, a minority of applications may need special definition if they:
Some existing transactions may share task-lifetime storage in various ways, and this sharing may prevent them running isolated from each other. To allow such transactions to continue to execute, a single common subspace is provided in which all such transactions can execute. They are then isolated from the other transactions in the system that are running in their own subspaces, but able to share each other’s data within the common subspace. See The common subspace and shared storage for more information.
CICS-key programs execute in the base space and so have read/write access to all CICS-key storage and user-key storage.
You might have some transactions where the application programs access one another’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, either by an MVS POST or "hand posting", by another task.
For example, a task can pass the address of a piece of its own storage to another task (by 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 fails when attempting the update and to post the ECB, unless the posting task is executing in CICS key.
CICS supports the following methods to ensure that transactions that need to share storage can continue to work in the subspace-group environment:
Any group of related transactions that work in user key in CICS/ESA 4.1 should work under CICS Transaction Server for z/OS®, Version 3 Release 1 if defined with ISOLATE(NO) to ensure they run in the common subspace. This provides support for migration, allowing the separation of transactions into their own unique subspaces to be staged gradually after installing CICS and related support.
You can use the CICS Interdependency Analyzer
to help you identify transactions
that include the commands such as WAIT EVENT, WAITCICS, WAIT EXTERNAL, and
MVS POST. See the CICS Interdependency Analyzer for z/OS User's Guide and Reference manual for more information about
this utility.