The availability is treated in the following manner:  A zIIP runs only IBM authorized code. This IBM authorized code includes the z/OS JVM in  association with parts of system code, such as the z/OS dispatcher and supervisor services.  A zIIP cannot process I/O or clock comparator interruptions, and it does not support operator  controls, such as IPL. Java application code can run on a CP or a zIIP. The installation can manage the use of CPs  so that Java application code runs only on CPs, only on zIIPs, or on both. Two execution options for zIIP-eligible code execution are available. These options are  user-specified in IEAOPTxx and can be dynamically altered by using the  SET OPT  command.  The following options are supported for z/OS V1R10 and later releases: GLYPH<SM590000> If a zIIP is available (not busy), the dispatcher suspends the JVM task on the CP and  assigns the Java task to the zIIP. When the task returns control to the JVM, it passes  control back to the dispatcher. The dispatcher then reassigns the JVM code execution to  aCP. GLYPH<SM590000> If no zIIP is available (all busy), the z/OS dispatcher allows the Java task to run on a  standard CP. This process depends on the option that is used in the OPT statement in the  IEAOPTxx member of SYS1.PARMLIB. GLYPH<SM590000> Option 1: Java dispatching by priority (IIPHONORPRIORITY=YES) GLYPH<SM590000> Option 2: Java dispatching by priority (IIPHONORPRIORITY=NO) This option is the default option and specifies that CPs must not automatically consider  zIIP-eligible work for dispatching on them. The zIIP-eligible work is dispatched on the zIIP  engines until Workload Manager (WLM) determines that the zIIPs are overcommitted.  WLM then requests help from the CPs. When help is requested, the CPs consider  dispatching zIIP-eligible work on the CPs themselves based on the dispatching priority  relative to other workloads. When the zIIP engines are no longer overcommitted, the CPs  stop considering zIIP-eligible work for dispatch. This option runs as much zIIP-eligible work on zIIPs as possible. It also allows it to spill  over onto the CPs only when the zIIPs are overcommitted. zIIP-eligible work runs on zIIPs only while at least one zIIP engine is online. zIIP-eligible  work is not normally dispatched on a CP, even if the zIIPs are overcommitted and CPs are  unused. The exception is that zIIP-eligible work can sometimes run on a CP to resolve  resource conflicts. Therefore, zIIP-eligible work does not affect the CP utilization that is used for reporting  through the subcapacity reporting tool (SCRT), no matter how busy the zIIPs are. If zIIPs are defined to the LPAR but are not online, the zIIP-eligible work units are processed  by CPs in order of priority. The system ignores the IIPHONORPRIORITY parameter in this  case and handles the work as though it had no eligibility to zIIPs. zIIPs provide the following benefits: GLYPH<SM590000> Potential cost savings.  GLYPH<SM590000> Simplification of infrastructure as a result of the colocation and integration of new  applications with their associated database systems and transaction middleware, such as  Db2, IMS, or CICS. Simplification can happen, for example, by introducing a uniform  security environment, and by reducing the number of TCP/IP programming stacks and  system interconnect links. GLYPH<SM590000> Prevention of processing latencies that occur if Java application servers and their  database servers are deployed on separate server platforms. 90  IBM 14 Model ZR1 Technical Guide