Avoiding storage violations in CICS

CICS provides facilities to help you prevent storage violations. When possible you should turn these facilities on, at a minimum, in your development and test environments. By catching the offenders in development and test, you can protect CICS code, control blocks, and transaction storage from being overwritten in your production regions.

Reducing storage violations can decrease down time and improve the data integrity in your regions.

Click on the following links to learn how to prevent storage violations:

Storage protection

Storage protection prevents user application programs defined to use user-key storage from directly overwriting CICS code and control blocks. Steps to turn on storage protection Set the STGPROT system initialization table (SIT) parameter to YES. You can use CEMT INQ SYSTEM to see the status of storage protection in a region. The value of "Storeprotect" will be set to "Active" if storage protection is on. Ensure that the majority of your application programs are defined as user-key applications; that is, with EXECKEY(USER) on the program definitions and TASKDATAKEY(USER) on the associated transaction definitions. USER is the default for both the EXECKEY and TASKDATAKEY options. Therefore, in most cases you do not have to change the resource definitions. See CICS-key applications to determine if you have any application programs that are using facilities that require you to define them with EXECKEY(CICS) and TASKDATAKEY(CICS). Change the resource definitions accordingly.

Transaction isolation

Transaction isolation prevents a user transaction from directly overwriting the user application storage of other transactions. Steps to turn on transaction isolation Setup storage protection in your CICS region as described under Storage protection in this document. Apply the PTF for MVS APAR OA24094 to improve performance by decreasing the overhead of turning on transaction isolation. Specify YES for the TRANISO SIT parameter to turn on transaction isolation globally; that is, for the whole CICS region. You can use CEMT INQ SYSTEM to display the status of transaction isolation in a region. The value of "Tranisolate" will be "Active" if transaction isolation is on. Where necessary, specify ISOLATE(NO) on transaction resource definitions to allow transactions to continue to function if they fail to meet the criteria for the default of ISOLATE(YES). See Subspaces and basespaces for transactions to get a better understanding of the default and to determine whether or not you have any programs that need to share common storage. ISOLATE(NO) provides support for migration, allowing the separation of transactions into their own unique subspaces to be staged gradually. The best approach is to remove transaction interdependencies. However, some programs have a legitimate need for one task to access, or share, the storage of another task. In that case, consider changing the program to use shared storage; that is, storage obtained by GETMAIN commands with the SHARED option (SDSA or ESDSA). Note that VSAM nonshared resources (NSR) are not supported for transactions that use transaction isolation. You should specify ISOLATE(NO) when you define transactions that access VSAM files using NSR.

Command protection

Command protection prevents CICS from modifying storage on behalf of an application program. Steps to turn on command protection To protect CICS itself from modifying storage on behalf of an application program that passes an invalid address in an EXEC CICS command, specify YES for the CMDPROT SIT parameter. This causes CICS to validate the start address of the storage, and establishes that the application program has write access to the storage that begins with that address. Only then does CICS execute the command. If a program passes an invalid address to CICS as an output field on the EXEC CICS command, an AEYD abend occurs. Command protection is completely independent of storage protection and transaction isolation. You can use CEMT INQ SYSTEM to display the value of CMDPROT in your region. The value of "Cmdprotect" will be set to "Cmdprot" if command protection is active.

Reentrant program storage protection

Reentrant program storage protection prevents reentrant user application programs from being overwritten by CICS and other user-key applications. Steps to turn on reentrant program storage protection To protect your application programs from being overwritten by CICS-key applications, specify PROTECT on the RENTPGM SIT parameter for at least your production CICS regions. RENTPGM=PROTECT causes CICS to obtain storage for the eligible programs from MVS key-0 read-only storage. The CICS loader automatically loads programs into the read-only DSAs (RDSA and ERDSA) if you link-edit the programs as reentrant by using the RENT attribute. Programs that you link-edit with RENT and RMODE(ANY) are loaded into the ERDSA. For more details about program eligibility, see Running application programs in the RDSAs. You must specify RENTPGM=NOPROTECT for development regions if you have a development aid package that sets break points in your application programs. Note that the RENTPGM parameter does not depend on storage protection being active in your region and should not cause any additional overhead in your CICS region. You can use CEMT INQ SYSTEM to display the value of RENTPGM in your region. The value of "Reentprotect" will be set to "Reentprot" if read-only storage is allocated from key 0 storage.

Notes

• These facilities protect storage from user application code. They add no benefit to a region with no user code; that is, a pure TOR or a pure FOR (where no DPL requests are function-shipped).
  
  
• If your development and test regions are on the same LPAR as your production regions then you must use caution when turning on these facilities. In this case, it is possible that the overhead of turning on these facilities might affect the performance of your production regions.
  

After these facilities are activated, you will receive message DFHSR0001 reporting a protection exception (0C4) when CICS detects and prevents an attempted storage violation. The X'offset' into the program and the program name will be included in the message. Examine the program to determine why it is trying to modify storage that it is not allowed to modify. Also, make sure that you do not have an error in the transaction or program definition.