① Guide · Cost optimization
On the mainframe the software bill, not the hardware, is the larger and more durable cost of capacity. A plan built on box economics alone understates the true cost of every MSU. This is the buyer side method that puts license cost into the capacity decision where it belongs.
Hardware is bought once. Software is paid every month it runs.
Capacity planning on distributed platforms is a hardware exercise. On the mainframe it is mostly a licensing one. Monthly license charges for the IBM stack, z/OS, CICS, Db2 for z/OS, IMS, MQ, and many ISV products scale with capacity, commonly with the rolling four hour average under sub-capacity. The result is that adding capacity adds a recurring software cost that, over the life of the box, routinely dwarfs the hardware it runs on. A capacity plan that prices only the machine is planning half the bill and usually the smaller half.
The buyer side fix is to carry a software cost line in every capacity decision, modeled on the metric that actually drives the charge. That turns capacity planning into a cost lever rather than a cost surprise, and it connects directly to sub-capacity licensing and to MSU optimization, where the same peaks are managed down.
Illustrative comparison of three ways to meet the same demand · directional only
| Capacity choice | Hardware effect | Software cost driver | Net license impact |
|---|---|---|---|
| Add capacity, run peak unchanged | More installed MSU | Higher rolling four hour average peak | Highest; the recurring bill rises with the peak |
| Add capacity, cap or shift the peak | More installed MSU, managed R4HA | Peak held by soft capping and batch timing | Capacity gained with little license increase |
| Offload eligible work to specialty engines | zIIP or IFL capacity added | Specialty engine work outside the MLC metric | Lower; eligible cycles leave the charged peak |
| Hardware refresh to a newer generation | More capacity per MSU | Transition terms plus reset baselines | Negotiable; a planned moment to reset the bill |
The same demand met four ways produces four very different software bills. The variable that moves the recurring cost is the charged peak, not the installed capacity, which is exactly what a hardware only plan misses.
Build the plan on the metric that drives the charge, the rolling four hour average for sub-capacity products, rather than on installed capacity. The peak is the bill, so the plan has to forecast the peak, not the size of the machine.
Forecast the peak, because the peak is the cost.
Soft capping, batch rescheduling, and workload placement can meet demand without lifting the charged peak. Often the cheapest capacity is the peak you avoid, and that move belongs in the plan before any hardware is ordered.
The cheapest MSU is the peak you do not create.
Eligible work moved to zIIP and IFL engines runs outside the general purpose MLC metric, lowering the charged peak while adding real capacity. Planning specialty engine offload is one of the most direct ways to add headroom without adding license cost.
Offloaded cycles leave the charged peak.
A generation refresh such as the IBM z17 delivers more capacity per MSU and can carry transition terms, but it also moves consumption patterns. Use the refresh as a planned moment to reset baselines and negotiate price protection rather than let a capacity jump quietly inflate the recurring bill.
A refresh is a negotiation, not just an upgrade.
④ The discipline
A capacity plan without the software line is half a plan. On the frame, the license is the larger half.
Typical reduction negotiated on renewal spend
Mainframe spend negotiated on the buyer side
Engagements delivered since 2019
Because on the mainframe the software bill is commonly the larger and more durable cost of adding capacity. MLC charges scale with capacity, typically with the rolling four hour average, so a plan built on hardware economics alone understates the true cost. A plan without the software line is planning the smaller half.
Under sub-capacity the charge follows the rolling four hour average peak, not installed capacity. So how and when you run work matters as much as how much capacity you own. Capping or shifting the peak and offloading to specialty engines lowers the bill without removing capacity.
It can, both ways. A newer generation like the z17 gives more capacity per MSU and may carry transition terms, but consumption patterns shift too. Treat the refresh as a planned license event to reset baselines and secure price protection. See our price holds guide.
Directly. The peaks you model in capacity planning are the same ones managed in MSU optimization and contested at renewal. A capacity plan that carries the software cost is the evidence base for both. See our cost optimization service.
Related: sub-capacity vs full capacity · specialty engines explained · securing price holds across refreshes · MSU optimization service
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →