Workload management considerations

zCX instances are managed by the z/OS Workload Manager (WLM) based on policy service class goal definitions. Optionally, you can cap CPU and real memory resources using WLM resource group association. CPU and memory resource capping for zCX may require additional capacity planning and performance analysis. In addition to this section, use the z/OS MVS Initialization and Turning Guide for information on planning real and auxiliary storage resources.

Defining WLM service classes for zCX address spaces

One or more service classes should be created for your zCX instances. The service class should have a single performance period specified with a velocity goal. Response time goals are not appropriate for zCX instances, as WLM is not aware of transactions executing inside an instance.

Multiple zCX instances can share the same service class if they have similar performance objectives and host similar workloads, such as Docker containers. The service class should have a specified importance level to indicate the importance of meeting the service class goals compared to other workloads and service classes running on the same z/OS system or sysplex. The performance goals and importance levels may need to be adjusted over time to ensure that the zCX instances have sufficient access to CPU resources.

Exploiting zIIP and general purpose processors for zCX workloads

If sufficient zIIP processors are available (greater than or equal to the number of zCX virtual processors), the majority of zCX instance processing can execute on zIIPs. However, if the zIIP processors are heavily used or constrained, zCX virtual processors may be dispatched on general purpose processors depending on the configuration of the z/OS system. Dynamic changes to IIPHONORPRIORITY at the system or service class level will immediately take effect for zCX.

zCX workloads, like all others, require capacity planning for memory (fixed and auxiliary), standard CPU, and zIIP CPU to ensure that the system-wide performance, availability, and resource goals are met. More information on using zIIP processors can be found in the Using System z Integrated Information Processor (zIIP) section of z/OS MVS Planning: Workload Management in z/OS MVS.

System level option:
  • Parameter IIPHONORPRIORITY in parmlib member IEAOPTxx controls whether zIIP-eligible work is allowed to overflow to standard processors when there is insufficient capacity on zIIPs. The default is YES. Specifying NO means standard processors will not process zIIP-eligible work unless they are required to resolve contention for resources. zIIPs that are overworked may struggle to offload work to standard processors in a timely manner.
Service class level:
  • Specifying NO in the Honor Priority field when defining a service class in the WLM service definition explicitly prevents the overflow of zIIP-eligible work to standard processors. There is an exception if contention for resources with standard processor work must be resolved. Specifying DEFAULT indicates that the current value of the IIPHONORPRIORITY parameter in parmlib member IEAOPTxx is used for the zCX work in the service class when there is insufficient capacity on zIIPs.

Resource capping for zCX address spaces

You can optionally limit the amount of CPU and real memory that zCX instances can consume through the use of WLM resource groups or tenant resource groups. When limiting CPU consumption, consider whether the limit should apply to standard processors only or include specialty processors as well. You can include specialty processor usage by specifying the "Include Specialty Processor Consumption" attribute while defining resource groups or tenant resource groups for zCX. If overflow to standard processors is enabled for zCX workloads and you only want to limit the amount of overflow onto standard processors, you can accomplish this by specify a limit and indicating that specialty processor usage is not included. If you are enabling resource groups or tenant resource groups for sub-capacity licensing of IBM software deployed in zCX there are some additional considerations, see Using the IBM License Metric Tool for sub-capacity pricing.

You can cap real memory (auxiliary storage cannot be capped) by specifying the amount of real storage that service classes associated with a resource group can consume at any given time. zCX instances can potentially consume a lot of memory, so capping should be strongly considered. Instances are capped by specifying the memory pool size of the related service classes. When the resource group reaches a threshold slightly below the specified size, the system pages out real storage to limit usage. Therefore, the limit should be above what was configured for the zCX instances. During initialization of a zCX address space, zCX determines if the allocation of fixed real memory will impact the system or resource group. A determined critical impact will prevent the zCX instance from initializing.

  • For resource groups: The service class associated with the zCX instance must specify the name of the associated resource group.
  • For tenant resource groups: An associated tenant report class must be defined when specifying the tenant resource group. WLM classification rules must specify the tenant report class association for the zCX instance.

Classification rules for zCX

WLM classification rules are needed to associate the zCX instances with a service class and optionally a report class. zCX instances can be classified under Subsystem type STC. Qualifiers job_name or userid can be used to identify zCX instances.