The zIIP needs help function and Db2

The zIIP "needs help" function enables work in the zIIP queue to be redispatched to another zIIP or a general-purpose processor (GCP) when a zIIP delay occurs.

The IIPHONORPRIORITY parameter in the z/OS® IEAOPTxx member of SYS1.PARMLIB determines whether zIIP-eligible work in the zIIP queue can be redispatched to a GCP when a delay occurs for a zIIP.

IIPHONORPRIORITY YES
The "needs help" function is enabled. YES is the default setting. All zIIP eligible Db2 work, including for Db2 system agents, can run on a zIIP and can be dispatched to another zIIP or GCP if a delay occurs for a zIIP. With this setting, you must configure sufficient zIIP capacity to avoid zIIP eligible work that runs on GCPs, and to protect the return on investment for the zIIP engines.
IIPHONORPRIORITY NO
The "needs help" function is disabled. No zIIP eligible work on the LPAR is redispatched to a GCP if a delay occurs. The work must wait for a zIIP to become available. For this reason, Db2 prevents all Db2 system agents from becoming zIIP eligible at Db2 startup if IIPHONORPRIORITY is set to NO, to avoid any delays that might occur for Db2 system agents that must wait for dispatch to a zIIP.
Important:

Even with the zIIP “needs help” function enabled, sufficient zIIP capacity must be available to be dispatched on-demand. The zIIP engine itself must be able to signal for help from other zIIP engines or GCPs. To achieve dispatching on-demand from a zIIP, at least 1 VH (Vertical High) polarity zIIP must be assigned to the LPAR.

Also, be aware of and evaluate the following limitations for tasks that run on zIIP:

  • Blocked workload support, which provides the means to promote CPU starved workloads, is not enabled for zIIP specialty engines.
  • The zIIP "needs help" function (IIPHONORPRIORITY = YES) can get delayed in a zIIP-constrained environment.
  • Work classified as Discretionary to WLM does not benefit from the zIIP “needs help” function.