CICS® storage protection is intended to prevent application programs erroneously overwriting CICS programs and control blocks. The occurrence of a protection exception in a new program running in a system with storage protection active probably indicates an error in the application program. However, when existing programs which need to be defined with EXECKEY(CICS) are first migrated to a system with storage protection active, protection exceptions may well occur.
Any application program causing a protection exception when defined with EXECKEY(USER) must be examined to determine why it is attempting to modify storage that it is not allowed to modify. Its definition should be changed to EXECKEY(CICS) only if it is determined that the application program is legitimately accessing CICS key storage, and the exception is not the result of an application error.
Programs might also be incorrectly link-edited as reentrant, and, as a result, loaded by CICS into one of the read-only DSAs (RDSA, ERDSA). When such an incorrectly defined program attempts to modify itself, or another program tries to modify it, a protection exception occurs. The program should be checked to see whether it should be redefined as non-reentrant, or whether the program should be changed to be truly reentrant. The protection exception might indicate that the program uses poor programming techniques that could result in other problems if uncorrected.
Transaction isolation protects the data associated with a user transaction
from being overwritten by EXECKEY(USER) programs invoked by other user transactions.
If transaction isolation is active, the occurrence of a protection exception
in a new transaction indicates a probable error in the transaction or program
definition. An interdependency may exist between two or more transactions.
In a system running without transaction isolation, a transaction can read
or write to the task-lifetime storage of another transaction. The IBM® CICS Interdependency Analyzer for z/OS®
helps
to identify potential dependencies. Ideally such interdependencies should
be removed. If interdependencies cannot be removed, define all affected transactions
with ISOLATE(NO). For further details about defining transactions, see the CICS Resource Definition Guide. For more information about the
CICS Interdependency Analyzer
,
see the CICS Interdependency Analyzer for z/OS User's Guide and Reference.
When migrating from a CICS 3.3 system to CICS Transaction Server for z/OS, Version 3 Release 1, it may be helpful to alter all transaction definitions to include the ISOLATE(NO) option. Then gradually change the definitions to use ISOLATE(YES) as interdependencies are removed. This facilitates manageable migration to a system that takes full advantage of the transaction isolation facility.
Command protection prevents CICS from updating storage if the storage address is passed as a command output parameter by a transaction that is not authorized to update that storage. The transaction terminates with abend code AEYD. The exception trace entry AP 0779 supplies details of the failing program and command. When migrating to a system with command protection enabled, EXEC commands that pass unauthorized storage are identified and can be corrected.
The following is a summary of some of the causes of protection exceptions that can occur in user key programs:
In previous releases of CICS, these may have worked, or at least may not have caused the application to fail. However, the use of these statements and options can have other effects on the overall execution of the CICS system, and should be removed where possible.
Protection exceptions occurring in programs resident in the ERDSA and RDSA are caused by the program not being truly reentrant. It might be that the program should not be defined as reentrant, or it might be that the program should be reentrant but is using poor coding techniques which should be corrected rather than making the program non-reentrant. For example:
In some cases, for example EXEC CICS READ DATASET INTO () LENGTH() ..., the LENGTH value specifies the maximum length that the application can accept, and is set by CICS to contain the actual length read on completion of the operation. Even if the program does not have RENT specified, using a variable in the program itself for this length could cause problems if the program is being executed concurrently for multiple users. The first transaction may execute correctly, resulting in the actual record length being set in the LENGTH parameter, which is then used as the maximum length for the second transaction.
In a system running with transaction isolation enabled, protection exceptions
can occur in programs with EXECKEY(USER). Such an exception is caused by one
transaction using a USER-key program to read or write to the USER key task-lifetime
storage of another transaction. This may highlight a program error or an interdependency
between two transactions. The IBM CICS Interdependency Analyzer for z/OS
can help to
identify potential transaction interdependencies. Examples of transaction
interdependencies are: