① Explainer · Licensing concept
The one figure that tells you whether you are overpaying. Built right, it exposes the products dragging your bill up. Built wrong, as a single blended number, it hides exactly what you need to see. Here is how to build it and read it.
Cost per MSU is the only figure that lets you compare your bill against itself, across products, across years, and against your peers.
Cost per MSU is annual software spend divided by the MSU capacity or consumption that spend covers. It is the most useful normalizing figure in mainframe software, because MSU is the common denominator across machines, vendors, and contract vintages. A bill of a given size means nothing on its own. The same bill expressed per MSU, and tracked over time, tells you immediately whether your cost is growing with your capacity or running ahead of it.
The mistake almost everyone makes is to compute one blended cost per MSU for the whole estate. That single number averages a core operating system stack together with a handful of niche ISV utilities, and the average conceals the outliers, which are exactly the products where the money is. A defensible cost per MSU is built per product and per metric, then compared. The worked build-up below shows why the blended figure misleads and the per product view does not.
A small estate billed against 600 MSU. The blended figure looks unremarkable. The per product build-up shows one product sitting far above where it should. Figures are illustrative, normalized to a relative index where the peer midpoint equals 100.
| Product | Annual spend (index) | MSU covered | Cost per MSU index | Peer midpoint |
|---|---|---|---|---|
| Core MLC stack | 360 | 600 | 96 | 100 |
| Db2 for z/OS | 150 | 600 | 102 | 100 |
| ISV utility A | 48 | 600 | 88 | 100 |
| ISV utility B | 90 | 600 | 165 | 100 |
Blended across the estate the cost per MSU index is about 105, just above the midpoint, easy to wave through. Built up per product, ISV utility B stands at 165, well above its peer range, while everything else is fine. The blended number told you the estate was healthy. The per product number told you exactly which line to challenge at renewal. The index here is relative, not a published rate; the method is what transfers.
Cost per MSU rises for reasons that mostly have nothing to do with running more workload. It rises because the numerator grows on its own, or because the denominator shrinks underneath it. These seven drivers account for most of the movement we see, and naming the one that is moving your number is the first step to reversing it.
| Driver | Effect on the number | Where to look |
|---|---|---|
| Annual uplift and indexation | Raises spend with no capacity change | Indexation and CPI clauses in the contract |
| Tier crossings | Capacity growth pushes products into pricier tiers | Tier boundaries near your MSU level |
| Stranded licenses | Spend stays flat while covered capacity shrinks | Decommissioned or downsized machines |
| Bundle drift | Bundled products you no longer use inflate spend | Bundle composition versus actual usage |
| Metric transitions | A new metric resets the baseline upward | Recent moves between MLC metrics |
| Single version charging gaps | Running multiple versions raises the charge | Version currency across the estate |
| Capacity headroom | Paying full capacity where sub-capacity would apply | Full versus sub-capacity metric eligibility |
These are patterns commonly observed across estates. The specific drivers moving your number depend on your contracts, metrics, and machine configuration.
Cost per MSU is built on the MSU unit itself and the R4HA that produces it, and it moves with the drivers covered in MIPS creep and indexation clauses and CPI uplifts. Reading it well is also how you challenge the numbers in a renewal proposal. When the per product view exposes an outlier, that is the leverage, and the work on mainframe cost optimization and license negotiation turns it into a lower bill.
Audit notice or renewal under 18 months out? We mobilize within 48 hours. Want a per product cost per MSU model before your next renewal? Start here.
Cost per MSU is annual software spend divided by the MSU capacity or consumption that spend covers. It is the single most useful normalizing figure for mainframe software, because it lets you compare your bill against itself over time, across products, and against peers regardless of machine size. The catch is that a blended cost per MSU across an entire estate hides more than it reveals, which is why it must be built up by product and metric.
There is no single right number, because cost per MSU varies enormously by product type, metric, contract age, and estate size. A core MLC operating system stack carries a very different per MSU cost than a single ISV utility. The useful benchmark is internal and directional: is your per MSU cost rising faster than your capacity, are specific products far above their peer range, and is the trend moving the wrong way at renewal. Those signals matter more than any published absolute.
Commonly because of drivers that have nothing to do with new workload: annual uplift and indexation clauses, capacity growth pushing you into higher pricing tiers, stranded licenses on retired or shrunk capacity, bundle pricing that no longer matches your usage, and metric transitions that reset the baseline. Each raises the numerator or shrinks the denominator. Isolating which driver is moving your number is the first step to reversing it.
Build it per product, compare each product against its own history and against a defensible peer range, and identify the products where your per MSU cost is an outlier. Those outliers are where the leverage is. A vendor defending a renewal uplift on a product that already sits well above the peer range has a weak position. Bringing a clean, per product cost per MSU model to the table changes who is explaining what.