Dealing with protection exceptions

Storage protection, transaction isolation, and command protection are facilities that add data integrity by highlighting application errors. The use of these facilities greatly reduces the number of abends that appear to be CICS® problems.

About this task

With the storage protection facility, there are further situations in which a protection exception (interrupt code 4) might occur:
  • An attempt is made to write to the CDSA, RDSA, ECDSA, ERDSA, or GCDSA when storage protection is active and the application is running in user key.
  • An attempt is made to write to the ERDSA or RDSA when PROTECT is specified for the RENTPGM system initialization parameter.

If transaction isolation (for which storage protection is a prerequisite) is enabled, additional situations can occur:

  • A transaction, defined with ISOLATE(YES), is executing a USER key program and attempts to read or write to another transaction's USER key task-lifetime storage in the UDSA or EUDSA.
  • A transaction, defined with ISOLATE(NO), is executing a USER key program and attempts to read or write to another transaction's USER key task-lifetime storage in the UDSA or EUDSA, but the second transaction is defined with ISOLATE(YES). For a full description of the transaction isolation facility and its use, see TRANSACTION attributes.

If any of these situations occur, CICS abnormally terminates the transaction with abend code ASRA and issues message DFHSR0622, which identifies the DSA over which the program attempted to write. This information is in the TACB and is traced by exception trace point ID AP 0781. It is also useful to know the execution key of the program at the time of the protection exception, and whether the program was executing in a subspace (CDSA, UDSA, RDSA, ECDSA, EUDSA, ERDSA, ETDSA, GCDSA, or GUDSA). This information is in the TACB, exception trace point ID AP 0781 and at the head of the formatted transaction dump.

If the command protection facility is enabled, a protection exception can occur if storage that is passed to CICS as an output parameter through the EXEC interface is not accessible for READ/WRITE by the program that issued the command. The program is passing to CICS storage that it cannot itself update, but it requires CICS to update the storage. The transaction terminates abnormally with abend code AEYD. CICS creates an exception trace entry AP 0779 and saves relevant data in the TACB that is formatted at the beginning of the transaction dump.

It is still possible for CICS to abend when the problem is in the application. For example, command protection only checks output parameters and does not prevent the passing of fetch-protected storage as an input parameter to CICS. When CICS attempts to read such storage, an ASRA abend occurs.