Instruction execution protection (IEP)

Instruction Execution Protection (IEP) is an IBM Z® hardware function that enables software to mark certain storage areas as non-executable. With storage allocated in a non-executable state, this helps to protect systems from errors such as stack overflow and malicious attacks. CICS® can use instruction execution protection to protect z/OS® storage requested by CICS for its internal use and CICS-managed storage (including CICS dynamic storage areas) from instruction execution.

Hardware and software requirements

To use instruction execution protection, CICS must run on a level of IBM Z hardware and operating system that support IEP. IEP is supported on z/OS 2.4 and later. z/OS 2.4 and z/OS 2.5 require APAR PH39134. If the hardware and operating system supports instruction execution protection, message DFHSM0160I is issued during CICS initialization.

Overview of IEP for CICS-managed storage and CICS DSAs

By default, instruction execution protection for CICS-managed storage and CICS dynamic storage areas (DSAs) is disabled, even if IEP is supported by the IBM Z hardware and operating system in use. You must enable it by specifying the feature toggle com.ibm.cics.sm.iep=true (see Specifying feature toggles). If IEP is available and enabled by the feature toggle, message DFHSM0161I is issued during CICS initialization.

Not all DSAs are protected from instruction execution. Some DSAs, which are listed below, are never protected from instruction execution so that it is still possible to request storage that is not protected from instruction execution, for example:

Depending on the attributes of the program, CICS loads the program into one of these unprotected DSAs.

The following DSAs are always created but they are never protected from instruction execution:
  • PCDSA
  • PUDSA
  • EPCDSA
  • EPUDSA
  • RDSA (read-only)
  • ERDSA (read-only)
The following DSAs are not protected from instruction execution if transaction isolation is active:
  • UDSA
  • EUDSA

If an attempt is made to execute an instruction in a DSA that is protected from instruction execution (that is, a DSA other than the ones listed above), an 0c4 program interrupt occurs and CICS issues abend AKES. If the program interrupt is caused by application code, the AKES abend is converted into an ASRA abend and presented to the application. Message DFHSR0623 is issued and an exception trace entry is made to help identify the cause of the error. Fields in DSECT DFHTACB and the Program Error Program (PEP) COMMAREA identify the 0c4 program interrupt as a result of instruction execution protection. Diagnostic information, such as dumps of the Storage Manager, indicates whether instruction execution protection is enabled and the execution protection status of the affected DSA.

Although the allocation of storage used by individual tasks running in the CICS region is not increased by instruction execution protection, the distribution of that storage within the DSAs is changed and you should expect an increase in DSA storage requirements.

Overview of IEP for z/OS storage requested by CICS for internal use

6.2 and later Applies to 6.2 and later.

When CICS needs to obtain z/OS storage for its own internal purposes, it issues a STORAGE OBTAIN call that specifies the EXECUTABLE=NO option for the majority of such requests. This protects CICS internal use of z/OS storage from errors such as stack overflow and malicious attacks. This feature applies to 24-bit, 31-bit, and 64-bit z/OS storage. Note that this is not subject to the control of the feature toggle com.ibm.cics.sm.iep={true|false}, which enables or disables IEP for CICS-maintained storage only. (The z/OS storage discussed here is not managed nor owned by CICS.)