① Journal · Cost optimization
Software cost on the mainframe tracks consumption, and consumption is more movable than most buyers assume. Some MSU levers pay off in a single billing month. Others need a full year of clean data to land. Knowing which is which decides what you can realistically achieve before the quote.
The number on the renewal quote is a function of MSU consumption. Lower the consumption that drives it and you change the quote before you ever negotiate it.
Most monthly license charges on z/OS are driven by the rolling four hour average (R4HA): the highest four hour average MSU figure in the month sets the bill for the products in that LPAR group. That mechanic is the reason optimization works. You are not trying to reduce total work; you are trying to reduce the single measured peak that pricing keys off. A workload that runs flat all month and a workload that spikes once can carry very different bills for identical total throughput. The lever set below sorts by how fast it moves that peak. For the underlying mechanic see the rolling four hour average explained, and for the offload angle, zIIP engines and software cost offload.
| Lever | What it does | Time to payoff |
|---|---|---|
| Defined capacity tuning | Caps an LPAR group so a peak cannot drive the R4HA above a set MSU line | Fast · effective next billing month |
| Soft capping review | Confirms group capacity limits are set where they should be, not stale | Fast · within a billing cycle |
| Peak window reshaping | Moves deferrable batch out of the four hour interval that sets the peak | Fast to medium · weeks once scheduled |
| zIIP offload | Shifts eligible work to zIIP engines that do not count toward the charged MSU peak | Medium · weeks to months depending on workload |
| Product placement | Moves an expensive product off an LPAR where its peak is set by unrelated work | Medium · a planning cycle |
| Code and SQL tuning | Reduces the CPU behind the peak in hot transactions and queries | Slow · months of engineering |
| Metric or model transition | Moves a product to a cheaper metric or the estate to consumption pricing | Slow · needs a clean baseline year |
Mechanics described reflect z/OS sub-capacity charging as commonly observed; product eligibility for zIIP offload and capping behavior vary by workload and release. Your SCRT data and configuration govern actual results.
The practical split: in the final months before a renewal, focus on the top of the table. Defined capacity tuning, a soft capping review, and reshaping the peak window can move the measured R4HA inside a billing cycle or two, which means they can change the consumption picture the vendor prices against before the quote is finalized. The bottom of the table, code tuning and metric transitions, is real money but it is next renewal money: it needs a year of clean data to prove and to defend. The mistake we see is buyers reaching for the slow levers under time pressure and getting neither the saving nor a defensible baseline. Match the lever to the clock. For the planning horizon behind that, see why renewal preparation starts at 18 months.
Renewal under 18 months out and consumption still unoptimized? We mobilize within 48 hours to find the levers that move in time. Start with mainframe cost optimization.
Every issue of the journal, plus renewal benchmarks we do not publish on the site. No vendor sharing, ever.
More from the journal: IBM Tailored Fit Pricing adoption, when a 60 percent uplift lands, and why renewal preparation starts at 18 months. Explainers: the rolling four hour average and zIIP engines and software cost offload. Service: mainframe cost optimization.