MSU: Million Service Units, Explained.

MSU stands for Million Service Units. It is a measure of mainframe processing capacity that IBM assigns to every machine model and uses, together with many software publishers, to calculate software charges. The key thing a buyer has to internalize is that the MSU rating is set by IBM, per machine, and the bill is computed against MSU consumption rather than against the business value of the work. Two machines doing the same useful work can carry different MSU ratings, and the one rated higher costs more to license even if it delivers nothing extra.

Under classic Monthly License Charge pricing, what you are billed for is not total or average MSU. It is the single highest rolling four hour average of MSU consumption in the month, measured per LPAR and per product by IBM's SCRT tool, then priced through a graduated tier schedule. That one mechanic, peak rather than average, is why the same workload can produce wildly different bills depending on when it runs.

Software priced on a graduated MSU tier gets cheaper per MSU as volume rises, so the charge is the sum across the bands the peak passes through, not a flat rate times the MSU. Take an LPAR whose highest rolling four hour average for one MLC product lands at 250 MSU in the month. Using an illustrative tier schedule, the monthly charge for that product builds up like this:

Tier band (MSU)	MSU billed in band	Illustrative rate per MSU	Band charge
1 to 100	100	$45	$4,500
101 to 200	100	$32	$3,200
201 to 250	50	$24	$1,200
Total at 250 MSU peak	250	n/a	$8,900

Illustrative rates and bands for arithmetic only. Real MLC schedules are product specific and confidential to your contract.

Now the lesson buyers pay for. Suppose a single batch job, scheduled by habit into the busiest window, adds 30 MSU to that peak, lifting it from 250 to 280. Those 30 MSU bill in the next band, and the same logic applies in reverse when you remove them:

Scenario	Peak (MSU)	Monthly charge	Annual impact
Peak as measured	280	$9,620	n/a
Batch job rescheduled out of the window	250	$8,900	−$8,640
Same work, different clock	−30	−$720 / mo	−$8,640 / yr

One product, one LPAR. A real estate runs many products across many LPARs, so the effect multiplies.

The job did exactly the same work in both cases. It simply ran at a different time. That 30 MSU was avoidable, it was created by a scheduling accident rather than business demand, and it cost real money every month until someone measured the peak and moved it. Multiply that across a portfolio of MLC products and dozens of LPARs and the avoidable MSU on an unmeasured estate is rarely small.

Buyers use MIPS and MSU almost interchangeably in conversation, and contracts use both, which causes expensive confusion. They are not the same kind of number.

	MIPS	MSU
What it is	Informal performance measure	Formal billing unit set by IBM
Who sets it	Convention and benchmarks	IBM, per machine model
Used for	Sizing and capacity planning	Software pricing and charges
Fixed ratio?	No. The MIPS to MSU ratio varies by processor generation and model; newer machines often deliver more MIPS per MSU

Treat any single MSU to MIPS conversion as approximate and machine specific, never as a contract constant.

The practical danger is contract language that fixes a conversion. A clause that pegs your licensed capacity to a MIPS number, or assumes a constant MIPS per MSU ratio, can quietly inflate your bill when you refresh hardware to a machine with a different rating. That is one mechanism behind MIPS creep, where the bill grows on a hardware change while the workload stays flat.

Once you see the bill as a function of the peak, the cost drivers and the levers are the same list read in two directions.

This is why MSU is a lever and not just a line item. Across 500+ engagements and $180M+ of negotiated mainframe spend, the estates that measure their MSU peaks pay less than the estates that accept them, and the gap between the two is usually larger than anyone inside the estate had assumed.