① Explainer · Licensing concept
Work that runs on a zIIP does not count toward your MLC MSU. That is the whole point: move eligible workload off the general purpose processors and your monthly software bill drops with it. Here is the math, and the trap that quietly reverses it.
A zIIP is a processor IBM does not let you bill software on. Every MSU you move there is an MSU that leaves your monthly charge.
A zIIP, the System z Integrated Information Processor, is an IBM specialty engine that runs eligible workloads outside the general purpose processor pool. Because Monthly License Charge (MLC) software is billed on general purpose MSU, captured as the rolling four hour average, any work that runs on a zIIP instead is removed from the MSU count that drives the bill. The zIIP capacity itself carries no MLC. That is the offload: shift eligible cycles to a processor IBM does not meter for software, and the metered peak falls.
Eligible workloads commonly include Db2 for z/OS query parallelism, Java under the JVM, XML System Services parsing, IPSec encryption, and selected ISV products written to exploit the engine. The eligible percentage swings enormously by application, from near zero on legacy COBOL batch to a large share on Java heavy or analytic Db2 work. The offload is real, but it is not free money: if the zIIP is saturated at peak, z/OS spills the work back to general purpose processors and the MSU reappears in your bill. The worked example shows both the gain and the spill.
One LPAR at a peak four hour window. Total demand is 1,000 MSU of work. We vary how much eligible work actually lands on the zIIP versus spilling back to general purpose processors, and read the billed MSU.
| Scenario | Eligible work | Lands on zIIP | Spills to GP | Billed MSU (GP) |
|---|---|---|---|---|
| No zIIP | 350 | 0 | 350 | 1,000 |
| zIIP undersized | 350 | 180 | 170 | 820 |
| zIIP sized for peak | 350 | 350 | 0 | 650 |
| zIIP plus tuning | 420 | 420 | 0 | 580 |
With no zIIP, all 1,000 MSU is billed. Size the zIIP to absorb the full 350 MSU of eligible work at peak and the billed general purpose MSU drops to 650, a 35% reduction in the number your MLC rides on. Undersize it, and 170 MSU spills back, recovering only part of the saving. Tune applications to raise the eligible share and the billed number falls further. The lever is not buying a zIIP, it is having enough zIIP to hold the eligible work at the peak window.
The offload leaks in predictable places. A zIIP sized for average load saturates at the peak window, the exact window SCRT bills you on, so the work that would have lowered your number spills back to general purpose processors. Vendors price MLC on that peak, not the average, so a zIIP that is busy 90% of the month but saturated for the one peak hour delivers far less than its headline capacity suggests. The table below maps the common leaks to the fix.
| Leak | What happens | The lever |
|---|---|---|
| zIIP saturated at peak | Eligible work spills to GP and enters the billed MSU again | Size zIIP to the peak window, not the monthly average |
| Low eligible percentage | Little work qualifies, so little can move off GP | Target Java and analytic Db2 workloads; measure eligibility per application |
| LPAR weighting | zIIP capacity stranded on the wrong LPAR at peak | Align zIIP weights with where the eligible peak actually lands |
| Dispatch overhead | Cost of moving work to the engine eats the benefit on small units | Offload sustained eligible workload, not fine grained bursts |
| ISV not exploiting zIIP | Third party product runs entirely on GP | Confirm zIIP exploitation per ISV product before assuming offload |
zIIP eligibility and offload behavior are defined by IBM and the relevant software vendor and depend on your machine, your z/OS configuration, and your workload mix. The figures above are illustrative of the mechanic; your eligible percentage and peak behavior will differ.
zIIP offload is one of the four levers that move the rolling four hour average, and it works on the same MSU that drives MSU based MLC charges. The capacity you can offload to is shaped by your model capacity rating. Offload is a tuning lever, but the structural savings come at renewal: validating eligible workload, sizing the zIIP estate, and pricing the result into the deal is the work on mainframe cost optimization and MSU optimization.
Audit notice or renewal under 18 months out? We mobilize within 48 hours. Want to know how much MSU your eligible workload could actually move off the bill? Start with your own SCRT data.
A zIIP, or System z Integrated Information Processor, is an IBM specialty engine that runs eligible workloads such as Db2 query parallelism, Java, certain XML processing, and IPSec. Work that runs on a zIIP does not consume general purpose processor MSU, so it falls outside the Monthly License Charge counting that drives most z/OS software cost.
MLC software is billed on general purpose MSU, captured as the rolling four hour average. Work shifted to a zIIP is removed from that general purpose MSU count, so it lowers the R4HA that SCRT reports and therefore the MLC bill. zIIP capacity itself carries no MLC, which is why estates with heavy eligible workload can cut MSU based charges meaningfully, as the worked calculation above shows.
Common eligible workloads include Db2 for z/OS query parallelism and certain utility processing, Java running under the JVM, XML System Services parsing, IPSec encryption in TCP/IP, and selected ISV workloads written to exploit zIIP. Eligibility is defined by IBM and the software vendor, and the eligible percentage varies widely by application, from near zero on legacy batch to a large share on Java heavy work.
If zIIP engines are saturated, z/OS spills eligible work back onto general purpose processors, where it lands in the MSU count again. Undersized zIIP capacity, poor LPAR weighting, and the overhead of dispatching to a specialty engine can all eat into the benefit. The offload only helps if the zIIP capacity exists to absorb the work at the peak window, not just on average.