Transaction isolation is activated at the region level by setting the TRANISO option in the DFHSIT to ‘YES’ (the default is ‘NO’). Once activated, transactions are run as isolated based on parameters in the TRANSACTION definition.
Unfortunately, some older applications rely on the ability of one task to access another task’s storage, meaning these applications couldn’t take advantage of transaction isolation without recoding. Transaction isolation also increases a task’s virtual storage utilization, making it difficult to implement in a region that was virtually storage-constrained.
Reentrant program protection expands storage protection by allowing reentrant programs to be loaded into read-only storage in one of the CICS read-only dynamic storage areas (RDSAs). If reentrant program protection is active, any attempt to overlay a reentrant program in CICS storage will result in an S0C4 abend.
Reentrant program protection is activated at the region level by setting the RENTPGM option in the DFHSIT to ‘PROTECT’ (this is the default; to de-activate, set RENTPGM to ‘NOPROTECT’). Once activated, any load module that has been linked as RENT will be loaded into read-only storage. The best part of reentrant program protection is that it has literally no overhead at run-time.
Because the program binder performs no validation of the RENT attribute, it’s quite common for programs that are actually non-reentrant to be linked as RENT. If this is the case, setting RENTPGM to PROTECT will cause any non-reentrant activity to abend, making the program unusable. This problem can be resolved without recompiling by relinking the program as NORENT. Only truly reentrant programs should be linked as RENT if reentrant program protection is to be used.
Command protection was introduced to plug a loophole in storage protection and transaction isolation, commonly known as the “hired gun” effect. This comes into play when a program issues an EXEC CICS command that returns data, but passes CICS an invalid address for the receiving field. CICS is still in control and running in CICS key when the data is returned, so CICS will overlay whatever storage is found at the return address provided, regardless of the key the user task is assigned. When command protection is in effect, CICS will validate the first byte of the address passed with the EXEC CICS command to ensure the requesting program actually has authority to write to that storage area; if the program doesn’t have authority, CICS will abend the task with an AEYD abend. The key limitation to command protection is that only the first byte is tested; if the return data area starts at a valid address but then continues into an invalid area, CICS will allow the overlay to occur.
Command protection is activated at the region level by setting the CMDPROT option in the DFHSIT to ‘YES’ (this is the default; to deactivate command protection, set CMDPROT to ‘NO’). Once activated, CICS will validate the first byte of any return area on every EXEC CICS command that’s processed. Because CMDPROT offers limited protection at the expense of some additional overhead on every command, CICS regions without active storage violations tend not to make use of it.
Dealing With Storage Violations
Even with these protection options active, some storage violations may continue to occur, but now the majority of violations are self-inflicted. If a CICS region is set so every application transaction is running in user key with transaction isolation, storage protection, command protection and reentrant program protection active, it still has the authority to overwrite its own user storage. Every transaction has a unique set of storage areas that are acquired as the storage is needed. Note that programs can acquire storage explicitly via the EXEC CICS GETMAIN command, but the bulk of a task’s storage is acquired by CICS to fulfill a request. For example, when an EXEC CICS LINK is issued, CICS must acquire storage to retain the current state of the transaction, and LE must acquire program-related storage, including working storage.
Each of these storage areas has increased by 16 bytes to hold the leading crumple zone and trailing crumple zone. While the program is never given addressability to the leading crumple zone, the trailing crumple zone can be inadvertently addressed by using more storage than was requested; for example, by overrunning a table past its OCCURS clause. Since the trailing crumple zone is often followed by the leading crumple zone for the next storage area, it can be overlaid in the same way. Even though CICS might not detect such a storage violation until task termination, the fact the transaction in control at the time the violation was found is also the culprit means the dump CICS produces is much more likely to contain sufficient information, especially in the CICS trace table, to identify the cause of the violation.
Preventing Storage Violations
There are two COBOL coding errors that between them account for the vast majority of storage violations: incompatibility in the DFHCOMMAREA length and table index overruns. In most cases, neither of these errors will be intercepted by the CICS protection functions described earlier.