Most mainframe cost programs start by trying to use fewer MIPS. That is the wrong target, because IBM has never invoiced anyone for MIPS. Under both of its current pricing models the billing unit is MSU, and what IBM does with your MSU depends entirely on which model you are on.
Under Advanced Workload License Charges (AWLC), you are billed on the highest rolling four-hour average your partitions reach in the month. One peak sets the bill. Which means you can run more work and pay less, provided the work lands in the right places.
This article is about the AWLC mechanism, because that is where reshaping the month changes the bill. If you are billed under Tailored Fit Pricing the levers are different, and AWLC vs TFP covers that decision.
MIPS, MSU and what IBM actually bills you for
MIPS (Million Instructions Per Second) is a speed rating. It tells you roughly how much work a processor can do, which makes it useful for sizing hardware and comparing machines. It appears nowhere on your invoice.
What appears on your invoice is MSU (Million Service Units), IBM’s unit of consumption. Under sub-capacity pricing, though, not your total MSU for the month: IBM charges sub-capacity products on the peak rolling four-hour average, or R4HA, reached by the logical partition (LPAR) that each product runs on (BMC). The R4HA is recalculated continuously: the system samples every five minutes, averages twelve of those samples into an hourly figure, and rolls that forward across a four-hour span (Planet Mainframe).
At the end of the month, the single highest value that average ever reached sets your Monthly License Charges (MLC) for every sub-capacity product on that partition. One four-hour stretch out of the whole month decides what you pay. You report it with the Sub-Capacity Reporting Tool (SCRT), a no-charge IBM tool that reads a month of SMF (System Management Facilities) data, types 70-1 and 89, and produces the report IBM bills from (IBM).
Which reframes the whole exercise. Two sites running identical annual workloads can pay very different amounts, because the one whose peaks collide pays more than the one whose peaks are spread. No work was deleted in either case.
The question stops being “how do we consume less” and becomes “what is standing in our peak window, and does it need to be there”.
Where the cost actually comes from
It helps to know which parts of the bill this work can reach before anyone spends effort on it.
Hardware is a capital decision made every few years, and maintenance follows the hardware. People are people. What MIPS optimization reaches is the software line: MLC on IBM sub-capacity products, plus whatever third-party licenses are pinned to the same capacity measures. On most sites that is the largest single controllable line, and it responds within a billing cycle rather than a budget cycle.
Worth being clear about that scope. Peak management moves the software line. It does not restructure a mainframe budget.
Workload placement, not workload deletion
The first MIPS optimization technique is also the least technical. Find out what runs during your peak window, then ask whether it has to.
Batch is the usual culprit. Reporting jobs, extracts, housekeeping, archive runs: work with no business deadline attached, scheduled at whatever hour somebody picked years ago and never revisited, now sitting on top of the online transaction peak. Moving it costs scheduling attention and nothing else.
Partition placement is the second lever. Charges are calculated per LPAR, so two workloads that peak together on one partition cost more than the same two workloads separated across partitions whose peaks fall at different times. The machine is the same and so is the total work. Only the bill changes.
Some workloads can move off the platform entirely and some genuinely cannot. Be careful with the analysis here, because the study that says “move this and save” often prices the compute and forgets the data gravity around it. Look at what a workload actually touches before assuming it travels.
Dynamic soft capping
Defined capacity lets you set a ceiling on an LPAR, and IBM invoices the lower of your R4HA peak or that defined capacity (Planet Mainframe). Which sounds like a solved problem. Set a limit, pay the limit.
In practice this is where sites get hurt. A static cap does not know what day it is. Set it low enough to save real money and sooner or later it sits in front of a workload that needed the capacity. Once the R4HA exceeds the limit the partition becomes eligible for capping, and work is delayed (Planet Mainframe). Month-end close, a market event, a recovery run after an incident: the moments when demand spikes tend to be the moments when delay is least acceptable. So the cap gets raised “temporarily”, nobody lowers it again, and the saving evaporates over a couple of quarters.
The alternative is to adjust capacity continuously against what is actually happening, protecting workloads that carry an SLA and holding back the ones that do not.
Worth knowing where this stops applying. Capping exists to hold down a billing peak, so under TFP, where there is no peak to hold down, capping for cost purposes has no target (AWLC vs TFP).
That is what Zetaly Automated Capacity (ZAC) does. It watches the R4HA in real time and reallocates capacity ahead of the billing-relevant peaks, throttling lower-priority work while mission-critical services keep their headroom. It manages the billing peak rather than consumption, which is a distinction worth insisting on: a site can consume more and still pay less once its R4HA is smoothed. Across 30+ enterprise deployments ZAC reduces MLC costs by 5 to 20% from startup. Orange, for example, uses ZAC to absorb the yearly increases in its software prices without any impact on performance (Zetaly). ZAC is installed on-premise and runs directly on your mainframe.
License terms and what is actually negotiable
Two things are worth checking before your next renewal.
The first is what you are licensed for against what you run. Product inventories drift over the years. Sites carry sub-capacity products nobody has opened in a long time, and each one is charged against the same R4HA peak as everything else on that partition. Taking an honest inventory is unglamorous work that frequently pays for itself.
The second is which pricing model you are on, because it decides which of the levers above are even available to you.
AWLC is the peak-based model everything above describes. TFP bills the other way, on total consumption across the year, which changes what is worth doing. If a switch is on the table, AWLC vs TFP covers the trade-offs and the timing.
Capacity planning
Peak management handles the month you are in. Capacity planning handles the year.
Most sites plan capacity by applying a growth percentage to last year’s totals, which is a reasonable way to size hardware and a poor way to predict cost. Cost follows peaks, and peaks follow business events: a product launch, a seasonal cycle, a migration, an acquisition. Planning against those tells you when the bill will move, with enough warning to act. Zetaly Resource Planning (ZRP) is built for that kind of forward view.
What to measure before you change anything
None of this can be judged without a baseline, and the baseline you need is not “our MIPS”.
You need the peak R4HA per LPAR per month across at least twelve months, the workloads running during those peaks, the distance between your peak and your typical load, and which sub-capacity products sit on each partition. That distance is the rough size of the opportunity. Zetaly Cost Control (ZCC) gives real-time visibility into it, though the twelve months of SCRT reports you have already filed will get you most of the way to a first answer.
It is worth doing this before committing to any approach. Mainframe MIPS optimization is not one technique applied everywhere: a site sitting a little above its average load has a different problem from one running far above it, and the two need different work.
FAQ
What is the difference between MIPS and MSU?
MIPS (Million Instructions Per Second) rates processor speed and is used for sizing hardware. MSU (Million Service Units) is IBM’s consumption unit and is what appears on your invoice. Sub-capacity software is charged on the peak rolling four-hour average of MSU consumption, per logical partition, per month.
What are the most effective MIPS optimization techniques?
Moving deadline-free batch work out of your peak window, separating workloads that peak together onto different partitions, and managing defined capacity dynamically rather than with a static limit. License inventory cleanup often pays for itself too. None of these reduce the work you do.
How do you reduce mainframe costs without reducing workload?
IBM bills sub-capacity products on your monthly peak rolling four-hour average, not on total consumption. Reshaping when work runs lowers that peak while the same volume still completes. Two sites with identical annual workloads can pay very different amounts depending on how their peaks fall.
What is MIPS on a mainframe?
MIPS stands for Million Instructions Per Second and rates how much work a processor can perform. It is a capacity measure, useful for comparing machines and sizing hardware. It does not appear on your IBM invoice, which is calculated from MSU consumption instead.
How much mainframe cost savings are realistic?
Zetaly Automated Capacity delivers a 5 to 20% reduction in Monthly License Charges from startup, across 30+ enterprise deployments. Orange uses it to absorb its yearly software price increases without any impact on performance. Where a site lands in that range depends mainly on how far its current peak sits above its typical load.
Does soft capping slow down my workloads?
A static cap can. When the rolling four-hour average exceeds a defined capacity limit, the partition becomes eligible for capping and work is delayed. Dynamic management avoids this by reallocating capacity in real time, protecting anything that carries an SLA.
