How Monthly License Charge Works
IBM mainframe software — z/OS, CICS, Db2 for z/OS, IMS, MQ, compilers — is licensed under Monthly License Charge (MLC), a recurring monthly fee for the right to use the product and access IBM support. Unlike the Processor Value Unit model on distributed systems, MLC is not a one-time entitlement: it bills every month based on capacity consumed, which makes it the most actively manageable large cost in the IBM portfolio. Move the consumption and you move the bill in the very next billing period.
MLC is also tiered and sub-additive — the cost per unit of capacity falls as consumption rises — so workload placement and timing have outsized financial effect. That structure is exactly what optimisation exploits.
MSUs and the Rolling Four-Hour Average
Capacity for MLC is measured in MSUs (Millions of Service Units), and the charge is driven by the rolling four-hour average (R4HA) of MSU consumption — not instantaneous peaks. IBM bills against the highest R4HA recorded in the month for each LPAR or capacity group. The implication is precise and actionable: a single sustained four-hour peak sets your cost for the entire month, so flattening or shifting that peak is the central lever of traditional MLC management.
Soft-capping, which limits the MSUs an LPAR can draw, lets you cap the R4HA at a defined ceiling. Workload scheduling — deferring discretionary batch out of the peak window — pulls the four-hour average down. Both directly reduce the billed figure without reducing real work done.
zIIP Offload: Cutting MLC MSUs
The most powerful MLC lever is the zIIP specialty engine. Work that runs on a zIIP does not count toward MLC MSU consumption — IBM charges no MLC for cycles on specialty engines. Eligible workloads include large portions of Db2 SQL processing, Java workloads, XML parsing, and certain analytics. Shifting eligible cycles from general-purpose processors to zIIPs lowers the R4HA on the priced engines, cutting MLC directly.
zIIP offload is the rare lever that cuts cost and improves headroom at once: every eligible cycle moved off the general-purpose processors reduces the priced four-hour average and frees capacity for workload growth. Maximising zIIP eligibility — especially for Db2 and Java — is the first place to look in any MLC review.
Db2 for z/OS in particular offloads a substantial share of its processing to zIIPs, which is one reason mainframe Db2 economics differ sharply from the distributed Db2 licensing governed by PVU and VPC.
Tailored Fit Pricing: The Cloud-Like Model
IBM's Tailored Fit Pricing (TFP) replaces R4HA peak management with a predictable annual model. Your prior-year consumption is reviewed, an estimated growth increase is added, and your monthly bill becomes one-twelfth of that total — eliminating the monthly peak penalty entirely. TFP comes in two flavours: Enterprise Consumption (pay-per-use, averaged across the year) and Enterprise Capacity (a fixed fee for an agreed capacity band).
TFP trades peak-management effort for predictability, and it can be the right choice for organisations with growing or spiky workloads where soft-capping is operationally painful. But the baseline and growth assumptions are negotiated — accept an inflated baseline and you lock in overpayment for the term. The model should never be signed without benchmarking the proposed baseline against actual consumption history.
Container Pricing and Workload Isolation
Container Pricing (the mechanism underlying the Enterprise Consumption model) lets you isolate and separately price defined workloads — new applications, payments engines, or co-located workloads — with their own MSU baseline and entitlements, insulated from the rest of the estate's R4HA. This prevents a new workload from inflating the aggregate peak that prices everything else, and it builds in annual reconciliation to smooth seasonal variability. Used well, it lets you grow specific workloads without dragging up the cost of the whole environment.
| Pricing model | Billing basis | Best for |
|---|---|---|
| Traditional MLC | Rolling four-hour average MSU peak | Stable workloads you can soft-cap and schedule |
| zIIP offload | Specialty-engine cycles (no MLC charged) | Db2, Java and eligible analytics workloads |
| Tailored Fit Pricing | One-twelfth of prior-year usage plus growth | Growing or spiky workloads needing predictability |
| Container Pricing | Isolated workload MSU baseline | New or co-located workloads to ring-fence |
MLC Optimisation Levers
A disciplined MLC programme combines four moves: maximise zIIP eligibility to remove cycles from the priced engines; soft-cap LPARs to control the R4HA; schedule discretionary batch out of the peak window; and benchmark any TFP or Container Pricing proposal against real consumption before committing. Each is independent of negotiated discount, and together they routinely reshape a mainframe software bill that finance had assumed was fixed. The strategic framing sits in the IBM licensing and contract negotiation guide, and to model your own MLC position you can request a confidential briefing.
Negotiating the Full z Software Stack
Mainframe cost is rarely IBM alone. A typical z/OS stack also carries independent software vendors — BMC and Broadcom chief among them — whose products are often priced against the same capacity metrics, so an MLC reduction can lower ISV charges too. Negotiate the stack as a whole: an aggressive zIIP and capping programme that cuts your rolling four-hour average reduces both IBM MLC and any capacity-priced ISV licence in the same move, and that combined saving is the number to take to the table.
Reporting accuracy is its own lever. The Sub-Capacity Reporting Tool (SCRT) output drives the bill, so clean, validated reporting prevents you paying for phantom peaks created by misconfiguration. When negotiating, weigh one-time-charge products against recurring MLC for stable workloads, pursue growth and migration credits when moving workloads onto the platform, and consider a multi-year capacity or Tailored Fit Pricing commitment only after benchmarking the proposed baseline against real consumption — an inflated baseline locks in overpayment for the whole term. The independence to push on all of these at once is what separates a managed mainframe spend from one that rises with every capacity upgrade.
This guide is one of eleven in our IBM licensing cluster. To connect mainframe licensing to the rest of your IBM estate, read it with the IBM master guide, ELA negotiation, Passport Advantage, sub-capacity PVU counting, ILMT configuration, Db2 cost reduction, Cloud Paks licensing, watsonx pricing, Power Systems and AIX, and subscription migration.
One discipline underpins every mainframe saving: accurate, governed capacity reporting. The Sub-Capacity Reporting Tool (SCRT) output that IBM bills against is only as good as the LPAR and defined-capacity configuration behind it, and a single misconfigured partition can inflate the reported four-hour average for the whole machine. Treat SCRT generation and review as a monthly control with a named owner, reconcile it against your soft-cap settings, and challenge any month where the reported peak does not match expected workload. Many organisations discover, on close review, that they have been paying for capacity created by a reporting artefact rather than real demand, a correction that delivers savings without any change to the workloads themselves and without a single difficult conversation with IBM.
Where Mainframe Licensing Fits
Mainframe MLC is a world apart from IBM's distributed licensing: it is untouched by ILMT, separate from Passport Advantage RSVP mechanics, and distinct from the subscription shift affecting distributed and Power workloads. Yet many enterprises run both estates and negotiate them together for leverage. Read this with the IBM ELA negotiation guide, the IBM vendor hub, and the IBM Licensing Guide white paper.