Managing zIIP Alternate Wait Time (zIIPAWMT) at the Service Class Level

Why is it useful?
Currently, zIIP Alternate Wait Time (zIIPAWMT) can only be managed at the logical zIIP engine or LPAR level. In environments where both PROD and NON‑PROD zIIP‑eligible workloads execute within the same partition, this limitation makes it difficult to control zIIP spillover to general CPs (GCPs). As a result, lower‑priority NON‑PROD workloads can negatively impact critical PROD workloads by consuming GCP capacity. Managing zIIPAWMT at a more granular level would allow better protection of high‑priority work while still enabling effective zIIP utilization.

Who would benefit from it?
This enhancement would benefit customers running mixed‑priority workloads (PROD and NON‑PROD) on the same LPAR, particularly those with high zIIP utilization. Capacity planners, performance analysts, and system programmers would gain improved control over CPU usage, reduced risk of unplanned GCP consumption, and better alignment of workload behavior with business priorities.

How should it work?
zIIPAWMT should be configurable at the service class level rather than only at the LPAR level. This would allow customers to specify acceptable zIIP wait times per service class, based on workload importance. Service classes where some delay is acceptable (such as NON‑PROD or lower‑priority workloads) could be assigned longer zIIPAWMT values, thereby reducing spillover to GCPs. Higher‑priority PROD service classes could have tighter controls to ensure timely processing. Ideally, this capability would be implemented as a service class attribute, similar to how Service Units (SU) are defined today.