Guide · metrics and contracts

Three numbers that should agree. They rarely do.

MIPS measures the box. MSU bills the software. Your contract entitles a capacity. Over years of upgrades and renewals these three drift apart, and the gap surfaces as an audit finding or an inflated renewal. Reconcile them first, on your terms, with your own validated figures.

Operations thinks in MIPS. The invoice bills in MSU. The contract entitles a tier.

MIPS, millions of instructions per second, is the number engineers reach for when they size a box or compare capacity. MSU, millions of service units, is the normalized unit IBM uses to bill software, derived from the processor model and reported through the Sub-Capacity Reporting Tool (SCRT) for the rolling 4 hour average MSU peak. The two are related, and vendors publish approximate MIPS to MSU ratios, but those ratios move across machine generations, so a MIPS figure from one machine does not translate cleanly onto the MSU rating of another.

That mismatch is where reconciliation lives. What your team measures in MIPS, what SCRT bills in MSU, and what each contract entitles you to in capacity should describe the same estate. After years of hardware refreshes, LPAR moves, and renewals nobody cross checked, they describe three different estates. The vendor reconciles the gap for you at exactly the moment it costs the most: an audit that finds you above a contracted tier, or a renewal priced off a peak you never needed to run.

MIPS, MSU, and the contract, side by side

MSU consumption levers →
Dimension MIPS (measured) MSU (billed) Contract (entitled)
What it describes Raw processor throughput. Normalized software billing unit. Capacity you are permitted to run.
Where it comes from Capacity tables, informal sizing. SCRT, R4HA peak per LPAR. Signed schedules per product.
Stability across upgrades Ratio shifts each machine generation. Re-rated on the new model. Fixed until renegotiated.
Who relies on it Capacity planners, operations. IBM MLC and many sub-capacity products. Procurement, the auditor.
The risk it creates A MIPS band drifts up on refresh. An unshaped peak inflates the bill. Consumption exceeds the entitled tier.

Ratios and reporting behavior described as commonly observed under current IBM and third party terms. The exact metric that governs each product lives in its own schedule, which is why reconciliation is per product, not per estate.

How we reconcile, on your side

№ 01

Map every product to its own metric

Each product is tagged with the metric in its contract: MSU, a MIPS band, named capacity, or a tier. Estates that assume one number governs everything miss the products that quietly bill on a different basis, and those are usually the ones that drift.

The metric that bills is the only one that matters.

№ 02

Validate the SCRT and R4HA position

The billed MSU peak is checked independently, LPAR by LPAR, against what is actually running. Soft capping, defined capacity, and reporting choices all move the number, and a peak nobody shaped is a peak the vendor prices off.

Validate the peak before it becomes the baseline.

№ 03

Compare measured against entitled

Measured consumption is laid against contracted capacity, product by product, to surface both exposures: where you run above your entitlement and risk an audit finding, and where you pay for capacity you never use.

Two gaps, opposite directions, both cost money.

№ 04

Close the gap before the vendor does

Right size the entitlement, shape the peak, and correct any band that drifted on a refresh, then take the validated position into the renewal or the audit response. Your numbers set the terms instead of the vendor's.

Reconcile first, and you own the conversation.

What changes with us in the room

The vendor reconciles the gap when it pays them. We reconcile it first, when it pays you.

20to35%

Typical renewal reduction

500+

Engagements delivered since 2019

$180M+

Mainframe spend negotiated on the buyer side

Frequently asked questions

Q1

What is the difference between MIPS and MSU?

MIPS measures raw processor throughput and is useful for sizing the box. MSU is IBM's normalized software billing unit, derived from the processor model and reported through SCRT for the R4HA peak. Vendors publish approximate ratios, but those shift across machine generations, so a MIPS figure from one box does not map cleanly onto the MSU rating of another.

Q2

Why reconcile against contracts?

Because measured MIPS, billed MSU, and contracted capacity should describe one estate and usually describe three. The drift surfaces as a vendor audit that finds you over a tier, or a renewal priced off an inflated peak. Reconciling first means you arrive with your own validated numbers rather than the vendor's.

Q3

Can a vendor bill us on MIPS instead of MSU?

Some non-IBM publishers priced on MIPS bands or processor capacity rather than IBM MSU, and some legacy schedules still reference MIPS. The risk is a band tied to an old machine rating that moves you up a tier on a refresh even when the workload did not grow. Reconciliation maps every product to the metric in its own contract.

Q4

When should we do this?

Before a renewal opens and well before any audit notice lands, ideally on a standing basis. A reconciled position is leverage at renewal and a defense in an audit, but only if it is validated before the vendor sets the clock. Done after the notice, you are reacting to their numbers instead of presenting yours.

Related: MSU consumption optimization · Defending your SCRT position · Building your software inventory · IBM licensing hub · cost optimization service

Audit notice or renewal under 18 months out? We mobilize within 48 hours.

Get expert help

Measured, billed, entitled, all different? We make the three agree.

Get expert help