Mainframe MSU and MIPS licensing: how to cut the peak IBM bills you on.

IBM bills mainframe software on MSU, measured at the month's highest rolling four hour average, while MIPS only sizes hardware. In our reviews, cutting that peak before you negotiate was the largest saving available and the least pursued.

What is the difference between MSU and MIPS in mainframe licensing?

MSU is the unit IBM bills mainframe software on, and MIPS is the unit capacity planners use to size hardware. MSU stands for Million Service Units per hour, MIPS for Million Instructions Per Second. The two track each other, but only MSU appears on the invoice.

For Monthly License Charge (MLC) products such as z/OS, CICS, Db2, IMS and MQ under sub capacity pricing, IBM bills each product on the month's highest rolling four hour average (R4HA) of MSU, measured on the LPARs where it runs. Convert any MIPS figure in a capacity plan to MSU, and place it in time, before you price it.

Why does the peak matter more than total usage?

The bill is set by the single highest four hour window in the month. A batch run that lands on top of the online day can set the price for all 30 days, and the quiet hours do nothing to lower it.

When the peak falls 10 percent, the charge falls for every product billed on it at once. Every method later on this page works through that number.

How does sub capacity pricing cut licensed MSU?

Sub capacity pricing charges each product on the combined R4HA of the LPARs it runs in, instead of the machine's full rated capacity. For environments running multiple LPARs with staggered peaks, that cuts licensed MSU by 30 to 60 percent.

Say a machine rated at 2,000 MSU runs online work in LPAR A, overnight batch in B and a test system in C. The table shows each LPAR's R4HA in three windows of one day.

A product running in all three LPARs is billed on 1,100 MSU, 45 percent below full capacity. A product installed only in LPAR C is billed on 250 MSU, so keeping products out of LPARs that do not need them saves money too.

What reporting keeps sub capacity pricing in place?

Sub capacity pricing lasts only while your reporting runs without gaps, and most mainframe environments have two reporting chains. On z/OS, the Sub Capacity Reporting Tool (SCRT) turns SMF records into a monthly report per machine. For PVU priced IBM software on Linux on IBM Z and on distributed servers, the IBM License Metric Tool (ILMT) does the job.

• SCRT timing. Each report covers the 2nd of one month through the 1st of the next, and must reach IBM by close of business on the 9th day. IBM's rule for a missing report is one month of full capacity charges for that machine.
• ILMT deployment. ILMT must be deployed and reporting continuously, and new sub capacity customers have 90 days from their first eligible deployment to put it in place.
• Retention. Keep two years of reports, because that is the history an auditor will ask you to verify.

What routine keeps the reporting chain intact?

1. Daily health check. Confirm the agent is reporting on every monitored LPAR and write the result down.
2. Monthly SCRT submission. File by the 9th of the following month without exceptions, since sub capacity billing depends on it.
3. Quarterly reconciliation. Compare the ILMT inventory with your Passport Advantage contract data, so you catch drift before IBM does.
4. Annual data quality review. Have an independent third party validate the ILMT record, since that record is what an audit will read.
5. Incident runbook. Keep a written response for any outage past 24 hours. The logged uptime becomes the audit trail.

Why do most mainframe audit findings start with reporting gaps?

In our reviews, most audit findings traced to ILMT gaps rather than to software that was under licensed. An auditor cannot give you sub capacity credit for a period with no data, so a gap is treated as full capacity.

Preventing this costs little. Give each chain a named owner and a named backup, and have the backup check the log whenever the owner is away.

Which methods reduce mainframe MSU, and in what order?

Run the operational methods first and the contractual ones second. Operational work lowers the peak every MLC product bills on, and contractual discounts then apply to that smaller number, so the two multiply.

How do workload shift, zIIP offload and capping lower the peak?

• Workload shift. Move batch jobs, reorgs and reporting runs out of the online peak window, starting with jobs that sit in the peak hour of recent SCRT reports.
• zIIP offload. IBM does not impose software charges on zIIP capacity, so eligible Java and Db2 distributed work moved there leaves the general purpose peak. Current machines have no separate zAAP engines; that work runs on zIIPs.
• Decommissioning. Retire subsystems and regions that still start every morning but serve no one.
• Defined capacity. Set an MSU limit per LPAR, or a Group Capacity Limit across several, in the Hardware Management Console image profile. Workload Manager soft caps the partition at that limit, so test it against a month end run.

Where do Tailored Fit Pricing, the ELA and bundling fit?

These three change the price per MSU. Tailored Fit Pricing charges annual consumption against a committed baseline, which suits predictable growth and can penalize a shrinking workload. The ELA and bundling set the rate on whatever baseline you bring, so all three give more once it has come down.

Why we would not start with the per MSU discount

The usual advice is to push IBM hard on rate first, because price feels like the quickest win. We disagree. A discount on an unmanaged peak discounts the waste with the real demand and locks the inflated MSU figure into the next term. Cut the peak first, then negotiate rate on the lower number.

The hypothetical example below uses a flat $1,200 per MSU per month for readability. Real MLC prices fall by volume tier, so removing top MSUs saves somewhat less in dollars.

Discount alone saves $108,000 a month. Reduction followed by the same discount saves $259,980 a month, a gap of $151,980, or $1,823,760 a year. The renewal also carries 451 MSU into the next term instead of 600.

What have we seen in recent IBM Z cost reviews?

Across roughly 20 to 30 IBM Z mainframe cost reviews I worked on between 2024 and 2025, MSU and MIPS reduction was the largest single saving available and the least pursued.

• Unmanaged spend. Soft capping and Tailored Fit Pricing sat unconfigured on environments that qualified for both, leaving 10 to 25 percent of MSU spend unmanaged.
• Schedules left alone. Workload was rarely shifted off peak, even though cuts of 8 to 18 percent were sitting in the batch schedule.
• Broken reporting chains. Parts of environments defaulted to full machine capacity because the sub capacity reporting chain broke. We found the same failure at every size.
• Scale. Our $71 million mainframe optimization case ran the same sequence at financial institution scale.

The cause was organizational. Schedulers, systems engineers and procurement each held part of the answer and rarely shared a baseline, so the peak had no owner.

Negotiating price on an unmanaged peak discounts the waste and carries it into the baseline for the next term.

How should you run an IBM mainframe ELA renewal?

Run it as a seven step sequence that starts with your own data and ends at IBM's quarter end. It is the largest single negotiation for any mainframe customer, and the MSU number agreed there sets the baseline for three to five years. Our ELA analysis covers the agreement itself.

1. Baseline consumption. Build the peak by product and by LPAR from two years of SCRT data.
2. Audit the operational options. Find the workload shifts and zIIP candidates first, so the reduction is yours before IBM discounts anything.
3. Score the bundle. Separate the products that carry weight from those you pay for and do not use.
4. Benchmark rates. Pull independent MSU rate benchmarks by product family.
5. Open the alternative. Model distributed migration for the workloads that could credibly move.
6. Cap the uplift. Fix annual increases at 0 to 3 percent in the contract.
7. Time the close. Aim for an IBM quarter end: March, June, September or December.

The pricing model decides which meter you negotiate against: WLC or VWLC for most z/OS environments, Tailored Fit Pricing for predictable growth. See our mainframe CIO advisory for the wider portfolio.

Our worked renewal case closed 31 percent below IBM's opening proposal. Fourteen points came from a 12 month program that reset ILMT discipline and shifted workload. The other 17 came from contractual terms applied to the reduced base, with the close timed to IBM's quarter end.

What will the IBM account team say, and how should you answer?

• "Tailored Fit Pricing removes the need to manage capping." Ask IBM to model it against your capped R4HA on the same SCRT history, and compare their baseline year with a low year.
• "Your consumption is growing, so the baseline has to reflect it." Show the SCRT history after the workload shift and use the managed peak as the baseline.
• "Add these products and the overall discount improves." Score each product on actual use first. A discount on software you will not run still costs money.
• "This price is only available until the end of the quarter." Accept the deadline if your baseline, benchmarks and redlines are already complete, since you planned for that quarter end months ago. If they are not, the next quarter end is three months away.

Which contract terms should you ask for?

• A defined baseline. Name the 24 months of SCRT data and the per product values it rests on.
• An uplift cap. Write the annual cap into the agreement, using the uplift cap clause language we recommend.
• Price holds. Hold per MSU rates for products you may add, per our price hold guidance.
• Reduction rights. Lower MSU entitlement or drop products when workloads leave. See reduction rights.
• A cure period for reporting gaps. Ask that a late SCRT report or ILMT gap can be corrected before full capacity charges apply.
• Audit limits. Set notice periods and scope with the audit clause redlines.

What should happen at 12, 6, 3 and 1 months before renewal?

How do you check your own MSU position?

Pull your last 24 months of SCRT reports, then use RMF, the HMC and ILMT to explain what drove each peak, and match all of it to your MLC invoices. Do this before any call with the account team.

• SCRT reports. They show the MSU value per product per machine and the hour the peak fell. Line those hours up against the batch schedule.
• RMF partition data. The RMF Partition Data Report shows which LPAR drives the peak.
• HMC image profiles. These hold the capacity limits actually in force, which can differ from the plan.
• ILMT audit snapshots. They show the PVU position and any periods with missing data.
• MLC invoices. Match each month against the SCRT submission and flag any month billed at full capacity.

Which mistakes cost the most?

• Negotiating rate before cutting the peak. The discount lands on capacity you did not need.
• Leaving the ILMT or SCRT job without an owner. One missed month on one machine can erase a year of capping savings.
• Setting caps once and never revisiting them. Too low slows batch and online work; too high saves nothing.
• Letting application teams move jobs unchecked. One batch job moved into the afternoon can raise the monthly peak.

What to do next

1. This week. Confirm ILMT health daily and log it; the log is your audit evidence.
2. This month. Baseline the R4HA peaks from two years of SCRT data, by product and LPAR.
3. Next quarter. Shift workload out of the peak window before anything else.
4. Before the renewal window. Configure defined capacity and evaluate Tailored Fit Pricing on the same data.
5. At renewal. Run the seven step ELA sequence against the reduced baseline.
6. If you want support. Our IBM practice can run the baseline, the reduction program and the negotiation with you.

Frequently asked questions