When you are running CICS® with storage protection, the majority of your application programs should execute in user key, with all their storage obtained in user key. You only need to define EXECKEY(CICS) on program definitions, and TASKDATAKEY(CICS) on the associated transaction definitions, for those programs that use facilities that are not permitted in user key, or for any special "system-type" transactions or vendor packages.
You should only specify TASKDATAKEY(CICS) for those transactions where all the component programs have EXECKEY(CICS), and for which you want to protect their task lifetime and working storage from being overwritten by user-key applications. For example, the CICS-supplied transactions such as CEDF are defined with TASKDATAKEY(CICS).
Note that you cannot specify EXECKEY(USER) on any programs that form part of a transaction defined with TASKDATAKEY(CICS) because, in this situation, a user-key program would not be able to write to its own working storage. Transactions abend with an AEZD abend if any program is defined with EXECKEY(USER) within a transaction defined with TASKDATAKEY(CICS), regardless of whether storage protection is active.
You cannot define a program so that it inherits its caller’s execution key. The execution key and data storage keys are derived for each program from its program and associated transaction resource definitions respectively, which you either specify explicitly or allow to default; the default is always user key. Table 45 summarizes the various combinations of options.
EXECKEY | TASKDATAKEY | Recommended usage and comments |
---|---|---|
USER | USER | For normal applications using the CICS API |
USER | CICS | Not permitted. CICS abends any program defined with EXECKEY(USER) invoked under a transaction defined with TASKDATAKEY(CICS). |
CICS | USER | For programs that need to issue restricted MVS™ requests or modify CICS-key storage. |
CICS | CICS | For transactions (and component programs) that function as extensions to CICS, such as the CICS-supplied transactions, or which require the same protection. |
For most applications you should define your programs with EXECKEY(USER), and the related transactions with TASKDATAKEY(USER). To obtain the maximum benefits from the CICS storage protection facility, you are recommended to run your application programs in user key storage. Specifying USER on these options has the following effect:
It also means that all storage directly related to the programs within the transaction is obtained from user-key storage.
However, user-key programs of transactions defined with ISOLATE(YES) have access only to the user-key task-lifetime storage of their own task.
USER is the default for both the EXECKEY and TASKDATAKEY options, therefore you do not need to make any changes to resource definitions for existing application programs.
Most application programs can be defined with EXECKEY(USER), which is the default value, and this is the option you are recommended to use in the majority of cases. These include programs that use DL/I or DB2® and programs that access vendor products through the resource manager interface (RMI) or a LINK command.
However, some application programs need to be defined with EXECKEY(CICS) because they need to use certain facilities that are listed later. Widespread use of EXECKEY(CICS) diminishes the protection offered by the storage protection facility because there is no protection of CICS code and control blocks from being overwritten by application programs that execute in CICS key. The ISOLATE attribute in the transaction definition does not provide any protection against application programs that execute in CICS key--that is, from programs defined with EXECKEY(CICS). Any application program causing a protection exception when defined with EXECKEY(USER) must be examined to determine why it is attempting to modify storage it is not allowed to modify. You should change a program’s definition to EXECKEY(CICS) only if you are satisfied that the application program legitimately uses the facilities described below.
Direct use of some MVS macros and services is undesirable, even in a CICS application defined with EXECKEY(CICS). This is because they may cause MVS to suspend the whole CICS region until the request is satisfied.
Some COBOL, PL/I, C, and C++ language statements, and compiler options, cause operating system functions to be invoked. See Programming in COBOL, Programming in C and C++, and Programming in PL/I for information about which of these should not be used in CICS application programs. It is possible that some of these functions may have worked in previous releases of CICS, or at least may not have caused the application to fail. They do not work when the program is defined with EXECKEY(USER). When the use of prohibited options or statements is the cause of a protection exception, you should remove these from the program rather than simply redefine the program with EXECKEY(CICS). The use of prohibited statements and options can have other side effects on the overall execution of CICS, and these should be removed.
If you decide to protect the CWA by specifying CWAKEY(CICS), you should restrict the programs that are permitted to modify the CWA to as few as possible, perhaps only one. See Using the common work area (CWA) for information about how you can control access to a protected CWA.
See Using the TCTTE user area (TCTUA) for information about using TCTUAs in a storage protection environment.
CICS ensures that when control is passed to a PLT program, a global or task-related user exit, or a user-replaceable program, the first program so invoked executes in CICS key, regardless of the EXECKEY specified on its program resource definition. However, if this first program LINKs or XCTLs to other programs, these programs execute under the key specified in their program definitions. If these subsequent programs are required to write to CICS-key data areas, as often occurs in this type of situation, they must be defined as EXECKEY(CICS).
In a CICS region with transaction isolation active, these TRUEs and GLUEs run in either base space or subspace (see MVS subspaces), depending on the current mode when CICS gives control to the exit program. They can also modify any application storage. The URMs and PLT programs execute in base space.
For programming information about the execution of GLUEs, TRUEs, URMs, and PLT programs in a CICS region running with storage protection, see the CICS Customization Guide.
If two transactions have an affinity by virtue of sharing task lifetime
storage, the transactions must be defined as ISOLATE(NO), or the programs
must be defined as EXECKEY(CICS). You can use the CICS Interdependency Analyzer
to check the causes of transaction affinity. See the CICS Interdependency Analyzer for z/OS User's Guide and Reference
for more information about this utility. The first of these options is the
recommended option, because CICS system code and data is still protected.
In addition to executable programs, you can define tables, map sets, and partition sets as program resources. EXECKEY has less relevance to these objects, because they are not actually executed. However, EXECKEY does control where non-executable objects are loaded, and thus affects whether other programs can store into them.
Map sets are not reentrant (BMS itself updates fields in maps when calculating absolute screen positions). However, map sets should not be modified by application programs; they must be modified only by CICS, which always executes in CICS key. CICS always loads map sets and partition sets into CICS-key storage.
If an application program executing in user key attempts to modify CICS-key storage, a protection exception occurs. The protection exception is processed by normal CICS program error handling, and the offending transaction abends with an ASRA abend. The exception condition appears to the transaction just as if it had attempted to reference any other protected storage. CICS error handling checks whether the reference is to a CICS-key dynamic storage area (DSA), and sends a message (DFHSR0622) to the console. Otherwise, CICS does not treat the failure any differently from any other ASRA abend. See CICS Problem Determination Guide for more information about the storage protection exception conditions.
[[ Contents Previous Page | Next Page Index ]]