① Journal · Cost Mechanics
IBM Z Capacity on Demand is some of the cheapest hardware capacity you will ever buy. The trap is what rides on top of it. Temporary engines move the rolling four hour average that your software is billed on, and the software bill the extra capacity carries is routinely many times the hardware charge. Here is how On/Off CoD, CBU, and CPE actually work, and the levers that keep the flexibility from turning into a renewal surprise.
The engines are cheap. The software they carry is not.
Capacity on Demand is one of the genuinely good ideas in the IBM Z (IBM zSystems) platform. You can light up extra processor capacity in minutes to cover a quarter close, a seasonal surge, or a failover, and turn it off when the event passes. The hardware charge for that temporary capacity is modest, which is exactly why operations teams reach for it without a second thought. The second thought is the one that matters to the budget, because on the mainframe the hardware is rarely the expensive part of adding capacity. The software is.
On sub-capacity software pricing, your monthly license charge follows the peak rolling four hour average of MSU consumption, product by product. When a temporary engine lets a workload run hotter, it can lift that peak, and on a monthly license charge model the higher peak sets the bill for the entire month even if the spike lasted an afternoon. That is the price tag. A CoD activation that cost very little in hardware terms can reset the software peak across a stack of products and show up as a permanent looking increase on the next true up. The flexibility is real, but it is priced on the software side, and the buyers who get hurt are the ones who treated CoD as a hardware decision. Read this alongside our z17 cycle piece and our MIPS to MSU conversion explainer.
On/Off CoD · CBU · CPE · what each is for and where the software cost lands
| Offering | Event it covers | Hardware charge | Software consequence to price first |
|---|---|---|---|
| On/Off CoD | Planned workload spikes: quarter close, seasonal peak, batch surge | Billed for what you activate, commonly on a 24 hour basis; prepay or postpay | Highest risk. The activation can lift the peak four hour average and reset monthly license charges across the stack for the whole month |
| CBU (Capacity Backup) | Disaster or outage recovery onto a surviving machine | Standby; typically no usage charge for a genuine recovery or test | Lower if confined to true recovery. Watch contract terms on how recovery capacity is treated for software during an extended failover |
| CPE (Capacity for Planned Event) | A one time planned event such as a data center move or migration | One time, fixed duration | Bounded by the event window. Scope the software peak the event will create and confirm it falls back when CPE ends |
The hardware columns are the small numbers. The right hand column is where a CoD decision actually costs money, and it is the column most activations are approved without reading.
Same activation, two pricing models, very different bills.
Under a traditional monthly license charge model the exposure is binary and unforgiving. The bill follows the peak four hour average, so a single hot interval driven by temporary capacity can set the charge for the whole month on every product running on that machine. A four hour spike and a four week spike can cost the same, which is why bursty CoD use under monthly license charge is so punishing and why buyers learn to cap, schedule, and watch the peak rather than the average.
Tailored Fit Pricing changes the shape. The Software Consumption Solution bills on MSUs actually consumed rather than a monthly peak, so a short temporary spike costs only the consumption it genuinely adds instead of resetting a month. For organizations that use CoD in real bursts, that can make consumption pricing materially cheaper, and it removes the manual capping gymnastics that monthly license charge forces. But consumption based pricing is not free flexibility. It still bills every extra MSU the temporary capacity burns, and the Enterprise Capacity Solution prices to the size of the physical environment, so a permanently larger installed footprint raises the baseline whether or not you activate. The lesson is the same one we apply to every metric transition: model your actual CoD pattern against both models before you assume one is cheaper. Our batch window tuning explainer and our reading your SCRT report guide turn that model into numbers you can take to the vendor.
Before any planned CoD activation, model the peak four hour average it will create and the monthly license charge that peak sets across every product on the machine. The hardware quote is the wrong number to approve against.
Approve the software bill, not the engine count.
If temporary capacity can run when other workloads are quiet, the activation may not lift the monthly peak at all. Timing the burst against the existing four hour average is often the difference between a free spike and a reset month.
When you burst can matter more than how much.
Recovery and planned event capacity are usually the cheaper offerings, but only if the contract treats their software the way you assume. Read how an extended failover or a long migration window is billed before you rely on it.
A recovery you have not priced is a surprise waiting.
If your real usage is bursty, that pattern is an argument for a consumption based model at the next renewal. Documented CoD behavior is leverage to move off a peak based charge that overcharges you for flexibility you use rarely.
Your usage shape is a negotiating position.
⑤ The discipline that pays
Capacity on demand is a software decision wearing a hardware price. Price the bill the capacity carries, before you activate.
Typical reduction negotiated on renewal spend
Mainframe spend negotiated on the buyer side
Engagements delivered since 2019
It can, and the increase usually dwarfs the hardware charge. On sub-capacity pricing the bill follows the peak rolling four hour average, so temporary capacity that lifts the peak sets the monthly license charge for the whole month across the stack. The engine is cheap; the software it carries is where the cost lands, which is why CoD should be priced against the software peak, not the engine count.
Three offerings for three events. On/Off CoD covers planned spikes and is billed for what you activate, commonly on a 24 hour basis. CBU is standby capacity to recover work during a disaster, typically with no usage charge for a genuine recovery. CPE covers a one time planned event such as a data center move. The software consequence differs by offering and should be priced before the event.
It changes the shape rather than removing it. The Software Consumption Solution bills on MSUs consumed, so a short spike costs only the consumption it adds instead of resetting a month, which can make bursty CoD use cheaper. But consumption pricing still bills the extra MSUs, and the Enterprise Capacity Solution prices to the installed footprint, so a larger machine raises the baseline.
Model the software peak before activating, schedule bursts away from the existing peak where possible, confirm CBU and CPE contract terms in advance, and use a documented bursty pattern as leverage for a consumption based model at renewal. See our IBM renewal advisory for how we price CoD exposure into a negotiation.
Related: what the z17 cycle means for software costs · batch window tuning to cut R4HA peaks · reading your SCRT report · IBM licensing hub
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →