① Licensing concept · Capacity metrics
MIPS does not actually count instructions, and you rarely pay on the number you watch. One MSU is roughly 8.5 MIPS, the bill runs off a peak, and that gap is where mainframe software cost is won or lost.
A rating, not a count. And not the number on your bill.
MIPS stands for millions of instructions per second, but on the mainframe it is not a literal instruction count. It is a relative capacity rating derived from IBM benchmark tables, used to size machines, plan upgrades, and scale software pricing. MSU, million service units, is IBM's licensing unit for the same capacity. The two are different scales of one measurement: as a rough planning rule, one MSU is approximately 8.5 MIPS, though the exact ratio shifts by machine generation and model.
The detail that decides your bill is which number, and which moment, the vendor charges. For IBM sub-capacity Monthly License Charge products, the charge is based on the rolling four hour average, the R4HA, and specifically the highest R4HA recorded during the month. You do not pay on average consumption. You pay on the peak. Broadcom (CA) and most third party publishers price their mainframe products on MSU or MIPS too, so the same capacity figure drives software cost across the whole estate, not just IBM's own stack.
Using the common planning rule of 1 MSU ≈ 8.5 MIPS. Use this to read the scale, not to size a contract: the real ratio depends on machine model and is published in IBM capacity tables.
| Installed capacity (MIPS) | Approx. MSU | Typical estate |
|---|---|---|
| 500 | ~59 | Small production LPAR or test estate |
| 1,500 | ~176 | Mid size single site shop |
| 3,500 | ~412 | Large enterprise, multiple LPARs |
| 8,000 | ~941 | Major bank or insurer, multi site |
| 15,000 | ~1,765 | Top tier estate, several machines |
Two estates with identical average consumption pay very differently, because IBM MLC bills the monthly peak R4HA, not the average. The per MSU figure below is an illustrative placeholder to show the mechanics; actual rates are product specific and negotiated, and are not stated here.
| Measure | Estate A · flat | Estate B · peaky |
|---|---|---|
| Average MSU across the month | 300 | 300 |
| Highest rolling four hour average | 340 | 520 |
| MSU actually billed (the peak) | 340 | 520 |
| Billed at an illustrative rate R per MSU | 340 × R | 520 × R |
| Cost difference, same average work | base | +53% |
Estate B does the same total work as Estate A but concentrates it into a sharp peak, so it pays 53 percent more on every MLC product for that month. Flattening the peak by 180 MSU, through scheduling, capping, or zIIP offload, removes that premium without removing any work. This is why peak management, not the headline rate, is usually the largest cost lever on the mainframe.
Because capacity based products track machine MIPS or MSU, a refresh to a larger box can lift software entitlements even when workload is flat. Without a negotiated cap, the renewal resets to the new capacity, which is one of the most common sources of an uplift.
A disaster recovery test, a quarter end batch, or a migration can spike the R4HA and set the billed MSU for the month. Uncontrolled peaks quietly inflate every MLC product at once.
In capacity priced bundles, idle products are billed on the same MSU as the ones you use. Thirty to fifty percent of a bundle can be shelfware still drawing cost from the capacity metric.
Operations teams watch average utilization; finance pays on the peak. The gap between the two is invisible until the invoice, which is exactly where buyer side measurement earns its keep.
Lower the peak, offload the engine, retire the shelfware.
Four levers move a MIPS or MSU based bill. Lower the rolling four hour peak by scheduling non urgent work away from the busy window and capping where appropriate. Offload eligible work to zIIP specialty engines so it does not count against general purpose MSU, the approach products like Syncsort ZPSaver use directly. Retire unused products from capacity priced bundles so you stop paying the capacity rate on shelfware. And negotiate caps so the next hardware refresh does not silently reset the baseline. The largest savings almost always come from the peak and the bundle, not from shaving the headline rate.
This metric drives pricing across the estate, so see how it plays out on specific products: CA Dispatch licensing, Syncsort MFX licensing, and Enterprise COBOL licensing. For the model that tries to move past the peak, read Tailored Fit Pricing, and for capping mechanics see group capacity limits. When it is time to act on the number, our mainframe cost optimization service turns these levers into a plan.
MIPS is a relative capacity rating from IBM benchmark tables; MSU is IBM's licensing unit for the same capacity. As a rough rule, 1 MSU is about 8.5 MIPS, varying by machine model. Vendors price in either; both describe the same capacity.
For IBM sub-capacity MLC products, on the peak: the highest rolling four hour average MSU in the month, not the average. One busy window can set the figure every MLC product is billed on.
It is a stable, widely understood relative capacity unit that maps cleanly to machine models and to MSU. It survives because it is convenient for pricing, not because it precisely counts instructions.
Lower the four hour peak through scheduling and capping, offload eligible work to zIIP, retire unused products from capacity bundles, and negotiate caps against hardware refresh. The peak and the bundle usually beat the rate.