① Journal · Cost optimization
Sub-capacity software bills on the rolling four hour average peak. Soft capping is the buyer side lever that holds that peak down without starving the online day. Three patterns that work, and the window each one is aimed at.
The bill is the peak. Soft capping owns the peak.
Sub-capacity software on z/OS is billed on the rolling four hour average, the R4HA, which the system recalculates continuously from MSU consumption. The monthly license charge tracks the highest R4HA each product reaches during the reporting month. Soft capping is the mechanism that lets you choose that peak rather than discover it. Using the Workload Manager with a defined or group capacity limit, the LPAR or LPAR group is held at a chosen MSU ceiling measured against the four hour average, so the number SCRT reports for billing is the one you set.
The crucial point is that soft capping works on the average, not on instantaneous capacity. The system can still burst above the cap for short periods; only the four hour average is held at or below the limit. That is what separates it from hard capping and from a crude performance throttle. Aimed at the right window it cuts the bill and the online day never notices. Aimed at the wrong one it hurts service for no saving. Read this with our sub-capacity vs full capacity explainer and our MSU optimization service.
Illustrative R4HA peak before and after a cap aimed at the deferrable window · units are MSU
| Window | Uncapped R4HA peak | Capped R4HA peak | What changed |
|---|---|---|---|
| Online morning | 620 | 620 | Left untouched; the online day keeps its capacity |
| Midday batch overlap | 710 | 640 | Deferrable batch held below the cap during the costly window |
| Evening batch | 540 | 540 | Off peak, no cap needed |
| Billed monthly peak | 710 | 640 | The number SCRT reports falls by 70 MSU |
Illustrative figures only, not a quote or a benchmark. The mechanism is the point: because the bill follows the single highest R4HA peak, shaving only the peak window lowers the charge while every other hour runs exactly as before.
A group capacity limit sets one pooled MSU ceiling across several LPARs on the same machine and lets the Workload Manager balance demand among them. It suits estates where partitions peak at different times, so the pool absorbs the swings while the total billed average stays under one managed cap.
One pooled ceiling, demand balanced beneath it.
A defined capacity cap holds a single LPAR at a chosen MSU limit on its own R4HA. It suits a contained workload with a clear, self made peak, a test or development partition or a discrete application, where capping one partition removes the peak without touching anything that shares the machine.
Cap the partition that makes its own peak.
Where the peak is a predictable batch surge, the cap is applied only during the window that sets the bill and relaxed the rest of the day. The deferrable work is held back across the costly four hours and runs freely afterward, so the billed peak falls while total work completes on time.
Hold the window that prices the month.
Most large estates combine all three: a group cap for the shared machine, defined caps on the partitions that misbehave, and time based capping over the batch peak. The skill is reading which window sets the bill before deciding which cap to place.
④ The principle behind all three
You are not billed for the capacity you own. You are billed for the peak you let happen. Soft capping is how you choose the peak instead of discovering it.
Typical reduction negotiated on renewal spend
Mainframe spend negotiated on the buyer side
Engagements delivered since 2019
The Workload Manager plus a defined or group capacity limit holding an LPAR or LPAR group at a chosen MSU ceiling measured against the rolling four hour average. Short bursts above the cap are allowed; only the four hour average is held down, which is the number the software bills on.
Not when aimed correctly. It constrains the four hour average, not instantaneous capacity, so the system still bursts when needed. Placed on the deferrable peak window it cuts the bill while the online day keeps its capacity. Placed wrongly it hurts service for no saving.
Group capacity for partitions that peak at different times, defined capacity for a contained LPAR with its own peak, and time based capping for a predictable batch surge. Most large estates combine all three after reading which window sets the bill.
A lower peak is a lower baseline, and a lower baseline is what you want anchoring any renewal or Tailored Fit commitment. Cap first, then sign. See our MSU optimization service.
Related: the hidden cost of MIPS creep · sub-capacity vs full capacity · capacity planning with software cost · MSU optimization service
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →