Overview of CICS storage protection and transaction isolation

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.

Storage protection

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.

Figure 129. Protecting CICS code and control blocks from user application programs
 Diagram showing CICS (executing in CICS-key) with READ/WRITE access to CICS-key and User-key storage and all CICS and user code and data areas. The user application has only READ access to CICS-key storage, code and control blocks, and has READ/WRITE access to User-key storage and user application programs and data areas.

The terms in Figure 129 relating to storage keys and execution keys are explained under Storage categories.

Storage categories

When you are running with the storage protection facility active, CICS separates storage into two categories:

CICS-key storage
is used for CICS system code and control blocks and, at the discretion of the installation, other code and data areas that require protection from overwriting.

In a CICS region with transaction isolation active, a CICS-key program has read/write access to CICS-key and user-key storage.

User-key storage
is where application programs and their data areas normally reside.

There are two associated execution modes:

  1. CICS system programs run in CICS key. CICS-key execution allows a program read-write access to both CICS-key and user-key storage.
  2. Application programs normally execute in user key. User-key execution allows a program read-write access to user-key storage, but only read access to CICS-key storage.

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.

Defining the execution 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

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:

Reducing system outages

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.

Protecting application data

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.

Protecting CICS from being passed invalid addresses

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.

Aiding application development

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 ]]