Home / Licensing / Capacity on Demand and Software Cost Impact
① Explainer · Metric and concept
Capacity on Demand turns on extra hardware MSU in minutes. The software bill does not follow the hardware, it follows the peak rolling four hour average. Confuse the two and a temporary boost becomes a charge you keep paying. Here is where the gap opens.
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →Capacity on Demand (CoD) is a family of IBM Z features that activate additional processor or memory capacity without a physical hardware change. The temporary form, On/Off Capacity on Demand, is the one that matters most for cost: it lets you turn on extra MSU for a defined window, commonly for quarter end, seasonal peaks, a migration, or a disaster recovery test, then turn it back off. Related capabilities include Capacity Backup for recovery scenarios and permanent capacity upgrades activated through the same machinery.
The trap is the mental model. CoD is a hardware lever. Mainframe software, under sub-capacity Monthly License Charge, is not priced on installed hardware capacity. It is priced on the peak rolling four hour average MSU your workload actually drives. So the question is never "did we turn on more capacity", it is "did the work running on that capacity lift the peak that prices our software", and the answer is not automatic.
Directional only, to show the mechanic. A site runs a normal monthly peak rolling four hour average of 800 MSU on a priced product. For three days it activates On/Off CoD to handle a quarter end close. Three scenarios, same hardware event, very different software outcomes.
| Scenario | Hardware MSU added | Peak R4HA driven | Software month repriced? |
|---|---|---|---|
| Burst runs in the peak window, uncapped | +400 | 1,150 | Yes, to 1,150 |
| Burst scheduled outside the peak window | +400 | 820 | Barely |
| Burst runs but LPAR soft capped | +400 | 850 | Held near the cap |
Illustrative MSU only, not pricing. The hardware event is identical in all three rows.
The lesson is that the cost of a CoD event is decided by scheduling and capping, not by the activation itself. Run the burst straight through the existing peak window with no cap and you reprice the whole month at the higher rolling four hour average. Move it out of the window, or hold a defined capacity soft cap on the priced LPARs, and the same hardware boost barely touches the software bill. And note the tail: depending on the reporting window and which products sit on annual or full capacity bases, the effect of a single event can carry beyond the month it happened in.
Three failure modes recur. First, the unmodeled DR test: a recovery exercise that activates capacity at the recovery site without confirming the disaster recovery licensing provisions, turning a rehearsal into a charge. Second, the uncapped peak: a finance close or batch reprocessing run that lands in the existing peak window and silently resets the month for every priced product sharing that LPAR group. Third, the forgotten tail: a one off event that lifts an annual or full capacity basis into the next billing period, so the cost outlives the boost. None of these show up on the hardware activation record, which is why they get missed.
Plan the software side before you activate. Confirm which products are sub-capacity and which are full capacity, because the cost behavior is completely different. Cap the priced LPARs with defined capacity so the rolling four hour average is held below a ceiling you chose even while raw hardware capacity is up. Schedule burst work outside the established peak window using the same discipline as ordinary peak shaving. For recurring seasonal capacity, weigh whether Tailored Fit Pricing, which prices an annual baseline rather than a monthly peak, changes the math in your favor. The broader toolkit is on our MSU consumption optimization page.
Capacity on Demand is a set of IBM Z features that let you activate additional processor or memory capacity temporarily or permanently without a hardware change. On/Off Capacity on Demand, the temporary option, is commonly used for predictable spikes such as quarter end, seasonal peaks, or disaster recovery. The hardware capacity turns on in minutes, but the software cost consequence follows separately.
It can. Under sub-capacity MLC, the software bill is driven by the peak rolling four hour average MSU, not by how much hardware capacity is installed. If a CoD event drives real workload up during the peak window, the rolling four hour average rises and reprices the month. If the extra capacity is activated but the workload does not lift the peak, the software charge for sub-capacity products may not change.
A single On/Off CoD event that occurs in one month can affect that month's sub-capacity billing through the recorded peak, and the timing of the reporting window matters. For products on annual or full capacity bases the effect can carry into a later billing period. The practical rule is that a temporary hardware boost is not always a temporary software cost, so model the billing tail before activating.
Cap where you can: set defined capacity soft caps so the rolling four hour average for priced products is held below a chosen ceiling even while raw hardware capacity is up. Schedule the burst work outside the existing peak window where possible. Confirm which products are sub-capacity and which are full capacity before the event, and confirm the disaster recovery provisions if the CoD is for a DR test rather than production growth.
Related metrics: the rolling four hour average, Monthly License Charge, and DR licensing rules. Where these products live: z/OS licensing. Put it to work: IBM cost optimization.