Storage control is affected by Storage protection introduced in CICS/ESA 3.3 and Transaction isolation introduced in CICS/ESA 4.1.
Storage protection protects CICS® code and control blocks from applications, and transaction isolation protects tasks from each other.
The ESA/390 subsystem storage protection facility works in a way that enables you to prevent CICS code and control blocks from being overwritten accidentally by your application programs. It does not provide protection against deliberate overwriting of CICS code or control blocks. CICS cannot prevent an application obtaining the necessary access (execution key) to modify CICS storage.
Transaction isolation extends this storage protection to provide protection for transaction data. Accidental overwrites of the transaction data by an application program of another transaction can affect the reliability and availability of your CICS system and the integrity of the data in the system.
The use of storage protection is optional. You choose whether you want to use storage protection facilities by means of CICS system initialization parameters described in the CICS System Definition Guide. For information about transaction isolation, see Transaction isolation.
CICS allows you to run your application programs in either user-key or CICS-key storage. (See Storage categories for definitions of the terms user key and CICS key.) CICS storage is automatically protected from being overwritten by application programs that execute in user-key storage (the default). The concept of isolating CICS code and control blocks (CICS internal data areas) from user application programs is illustrated in Figure 129.
The terms in Figure 129 relating to storage keys and execution keys are explained under Storage categories.
When you are running with the storage protection facility active, CICS separates storage into two categories:
In a CICS region with transaction isolation active, a CICS-key program has read/write access to CICS-key and user-key storage.
There are two associated execution modes:
The terms "user key" and "CICS key" thus apply both to storage and to the execution of programs with respect to that storage. They are reflected in the resource definition keywordsused in TRANSACTION definitions. See the CICS Resource Definition Guide for more information.
The execution key controls the type of access your application programs have to CICS-key storage. The default is that application programs are given control in user key. You should define CICS key only for those programs where it is essential that they execute in CICS key. The programs you might select to run in CICS key are typically those that are written by system programmers, and are usually designed to provide special function in support of user applications. Such programs are generally considered to be an extension of CICS rather than part of an application. Some examples of such programs are described in CICS-key applications.
The storage protection facility does not protect CICS code and control blocks from being overwritten by this type of program, or by ordinary application programs that you choose to execute in CICS key.
To run your programs in CICS key, you should use the execution key parameter (EXECKEY) on the program resource definition. See Selecting the execution and storage key for an explanation of EXECKEY. The EXECKEY parameter determines the key in which CICS passes control to an application program.
Transaction isolation uses the MVS™ subspace group facility to offer protection between transactions. This ensures that an application program associated with one transaction cannot accidentally overwrite the data of another transaction.
Some of the benefits of transaction isolation, and its associated support are:
Transaction isolation prevents data corruption and unplanned CICS system outages caused by coding errors in user-key application programs that cause the storage of user-key transactions to be accidentally overwritten. Prevention of accidental transaction data overwrites significantly improves the reliability and availability of CICS regions.
If an application program overwrites CICS code or data, CICS can fail as a result. If an application program overwrites another application program’s code, that other application program is likely to fail. Whereas this is a serious interruption in a production region, the effect is immediate and the program can generally be recovered so that the terminal user can retry the failed transaction. However, if an application program of one transaction overwrites the data of another transaction, the results often are not immediately apparent; the erroneous data can be written to a database and the error may remain undetected until later, when it may be impossible to determine the cause of the error. The consequences of a data overwrite are often much more serious than a code overwrite.
CICS also protects itself against applications that pass invalid addresses that would result in CICS causing storage violations. This occurs when an application program issues an EXEC CICS command that causes CICS to modify storage on the program’s behalf, but the program does not own the storage. In earlier releases, CICS did not check ownership of the storage referenced by the passed address, and executed such commands with consequent storage violations.
CICS validates the start address of the storage, and establishes that the application program has write access to the storage that begins with that address, before executing the command.
This address checking is controlled using the CMDPROT system initialization parameter. If a program passes an invalid address to CICS as an output field on the API, an AEYD abend occurs. It is completely independent of storage protection and transaction isolation.
Transaction isolation aids application development in the testing and debugging phase. If an application tries to overwrite CICS or another application, or if it tries to pass a storage address it does not own for CICS to write to, CICS immediately abends the task and reports the rogue program’s name and the area it tried to overwrite. This saves much time trying to debug what is a common problem in application development environments.
[[ Contents Previous Page | Next Page Index ]]