Many organizations using the IBM System z have begun to use zIIP processors to help reduce the overall cost of their mainframe environment. But…
Assuming Everything Will Run on the zIIP
One of the biggest mistakes you can make is assuming that everything that is eligible to run on the zIIP will actually run on the zIIP. Although this may seem like a reasonable assumption, it neglects to take into account what is sometimes referred to as the Generosity Factor.
When you activate your zIIP processor, some percentage of the relevant workload will be redirected off the main CP onto the zIIP – but not 100% of the workload. When an enclave is created by a product you are using, a parameter can be set to impact the CPU percentage that z/OS can make eligible to run on the zIIP. Think of this percentage as the Generosity Factor because it tells the system how generous to enable the workload for the enclave to be eligible for zIIPs.
For example, if you look at the IBM Db2 12 for z/OS documentation in the section titled “Authorized zIIP uses for Db2 processing,” you will see the following:
SQL request workloads that use DRDA to access Db2 for z/OS® over TCP/IP connections and native REST calls over HTTP
Up to 60% of the Db2 for z/OS instructions execute such SQL requests when running in Enclave SRB Mode and accessing Db2 for z/OS.
This means that the generosity factor for distributed SQL requests in Db2 is 60%. There is a bit of nuance to how this is actually implemented, but the net result is that you will only get up to 60% of this workload to run on zIIPs.
Digging deeper into the documentation, you will see that other types of processing will have different generosity factors. For example, up to 100% of parallel query child processing can be run on the zIIP (after reaching a CPU usage threshold).
So far, we have discussed the generosity factor for Db2, which is an IBM product. But ISVs also can make workloads run by their products zIIP-eligible. ISVs that zIIP enable workload using enclave SRBs typically are not going to throttle the redirection of their workload like IBM does. Although the API provides an option to set a “generosity factor,” it is uncommon to be anything other than 100 percent. That said, be sure to understand how each of your ISV products works regarding zIIPs, including if they set a generosity factor other than 100%.
It is essential to understand that not everything zIIP eligible can or will run on the zIIP. Another common mistake is not understanding that it is not possible to specifically direct the workload to run a zIIP. The workload can be specified as zIIP-eligible, but the decision whether to run on the zIIP or not is made at execution time by the Workload Manager (WLM).
Why might zIIP-eligible work not be run on the zIIP? Perhaps there are no zIIPs installed and available to be used. Or maybe the zIIPs that are available are all busy. Or, as we just discussed, perhaps the generosity factor comes into play. Although the workload is eligible, it falls outside the permitted percentage for this specific type of work.
Lack of Planning
As with most things, proper planning and preparation will go a long way toward successfully implementing zIIPs in your organization. Perhaps the most significant thing to consider is how much workload you will have that is zIIP-eligible and how many zIIPs you will need to deploy to support that workload.
Of course, Db2 is most likely to be the primary consumer of zIIP capacity, but don’t forget other workloads such as Java, zCX container extensions, and XML processing. IBM publishes a nice list of zIIP-eligible software you should consult and compare to your environment’s needs.
Once you know your zIIP potential, you need to ensure sufficient zIIP capacity to process it. The more zIIP-eligible workload you have, the more zIIPs you will need to process it effectively.
Another consideration that is sometimes not handled appropriately is setting the IIHONORPRIORITY parameter correctly. IIHONORPRIORITY is a z/OS system setting that is maintained in the IEAOPTxx parmlib. There are two options: YES and NO.
Setting IIPHONORPRIORITY to YES indicates that standard CPs may execute zIIP-eligible and non-zIIP-eligible work in priority order – if zIIP processors are unable to execute all zIIP-eligible work. YES is the default.
On the other hand, if you specify IIPHONORPRIORITY=NO, work will not receive help from standard processors when there is insufficient zIIP capacity. This means that most work will wait for zIIP capacity to become available. There is a caveat: standard CPs can help when it is considered necessary to resolve contention for resources with non-zIIP processor eligible work.
The fundamental tradeoff is performance versus cost. You deploy zIIP processors to save money, so directing workload to the processors and keeping it there might seem to make sense. However, the potential performance implication is considerable, and therefore not only is YES the default, but it is the recommendation.
The best practice approach is to ensure sufficient capacity (for both zIIP and general-purpose CPs) to process your workload, set Honor Priority to YES, and monitor the situation so that there is minimal need to redirect workload from zIIPs back to your general-purpose CPs.
Lack of Understanding
The last common mistake we’ll discuss here is a lack of understanding. To fully appreciate the cost-savings potential of zIIPs, you need to understand how IBM MLC software pricing and billing works. Of course, this is a complex topic that requires more space and time than I have here to explain fully. So, instead, I will offer some advice.
The first thing you need to know is what IBM pricing metric is in place at your organization. If your shop uses a full-capacity metric or tailored-fit pricing, then every MSU that you can redirect from the general-purpose engine to a zIIP can save you money. On the other hand, things become more difficult if you are using a sub-capacity metric.
There are numerous sub-capacity pricing metrics offered by IBM, including WLC, AWLC, EWLC, AEWLC, MWLC, and zNALC. At this point, don’t worry too much about the acronyms and what they mean. The general idea for sub-capacity pricing is that you pay based on your MLC software’s peak, monthly rolling-four average (R4HA) usage (by LPAR). IBM MLC software includes most system software, compilers, and selected system management tools.
The R4HA is calculated based on system utilization in MSUs. Each IBM machine has an MSU rating. This capacity is consumed by the LPARs and applications on the machine on an on-demand basis. As application consumption is based on, often unpredictable, demand, CPU/MSU may be very high or low at any moment in time. To allow for these brief spikes in consumption, IBM calculates the R4HA every five minutes. Each hour, the system takes the average of these 12 five-minute values. After four hours, the system will then have an actual “Four-Hour Average.” As the system runs, the calculation continues to “roll,” so you then have a continuously updated Rolling Four-Hour Average (R4HA). Each month, via the SCRT report, your organization reports the peak R4HA utilization to IBM, and a bill is generated based on that report.
So, with sub-capacity pricing, redirecting workload to zIIPs may or may not impact your monthly IBM software bill, depending on whether the workload is shifted during a peak. This means that sometimes using zIIPs will save you money, and sometimes they won’t!
Earlier, I mentioned tailored-fit pricing with full-capacity pricing. Tailored-fit pricing is not exactly a complete capacity metric, but it is not based on an R4HA peak. Therefore, any zIIP redirection from general-purpose CPs to zIIPs will save you money, eventually, when you use tailored-fit pricing.
The Bottom Line
To gain the benefit of zIIPs, you need to understand what they offer and how they work and plan appropriately for your organization’s workload and pricing agreement with IBM.
Craig Mullins, Copyright Craig Mullins Consulting, Inc
Find Out More
Learn more about Relocate.