zIIP Eligibility When You Don’t Have A zIIP

(Originally posted 2013-02-15.)

A couple of things have happened recently that lead me to post about projecting the amount of CPU that’s zIIP eligible. (Everything in this post applies equally to zAAPs, of course.)

When we first introduced z/OS specialty engines we introduced the “Project CPU” mechanism, reporting most notably via RMF. (I emphasise “z/OS” because ICF and IFL engines, which don’t run z/OS, don’t have such a mechanism.) This tells you how much work that is zIIP-eligible that is actually running on general-purpose CPs (GCPs).

Note that there are two cases where some zIIP CPU will be projected:

• Where you have no zIIPs in the LPAR.
• Where you have zIIPs but still some work that is eligible runs on GCPs.

This worked fine when you had a workload already running but had no specialty engines. (Of course the workload might grow, but that’s just relatively normal Capacity Planning.) If a workload didn’t yet exist then RMF wouldn’t be able to report on its eligibility. A well-known example of this is IPSec where specialty engines made it more affordable to use the function, at a time when it had become more important to installations. So far so good.

In recent months I’ve heard of cases where software doesn’t run the zIIP-eligible path when it determines there is no zIIP. This is said to be to minimise CPU. Fair enough, but it makes it difficult to assess how much work is eligible for zIIP.

Thanks to Don Zeunert, I now know about PM65448 for OMEGAMON XE for DB2 PE/DB2PM. (He mentioned it in OMEGAMON XE DB2 V510+ zIIP Project CPU when no zIIP present.)

So you can elect to turn on Project CPU for Omegamon XE DB2, or not to. I’m not sure how easy it is to make this product pick up a change in this setting.

My initial reaction was to turn it on for a couple of peak hours and see what number it gave you. I’ve moved on from that to thinking that installations should consider:

• Measuring the CPU consumption by Omegamon XE DB2 with this switched off.
• Turning it on for at least a day and measuring both the benefit and the additional cost in GCP terms.
• Consider leaving it on permanently, or at least semi-permanently if you are about to acquire zIIPs.
• Not rush to turn it off when you install zIIPs and allow the relevant LPARs to use them. (You’re already paying the overhead of zIIP eligibility anyway and you need the diagnostics Project CPU provides.)

I’ve not seen situations where a significant amount of GCP CPU has been wasted by running the zIIP-eligible paths through products. That doesn’t mean it can’t happen – as I see only a small subset of customer cases. But it does suggest to me it’s not a major concern for most customers.

I’m obviously a fan of lots of knobs and dials when I say I think this Omegamon XE DB2 function is nice to see: At least you have the choice. I’d like to see other products do something similar.

So, two questions for you, dear reader:

1. Which other products detect the absence of zIIPs (or zAAPs) and choose not to use the zIIP-eligible code paths when they’re absent?
2. Do any of these products allow you to turn Project CPU back on again, despite the absence of zIIPs?