① Licensing concept · Capping mechanics
A group capacity limit pools several LPARs under one shared MSU ceiling and holds the peak that every Monthly License Charge product is billed on. Set it right and you cut cost without touching the workload.
A shared ceiling over a group of LPARs. Slack pooled, not stranded.
A group capacity limit is a soft cap that z/OS Workload Manager, WLM, enforces together with PR/SM across a named group of logical partitions on the same machine. Rather than capping each LPAR on its own, WLM sums the consumption of every partition in the group and holds that total to a single MSU ceiling, managed against a rolling four hour average. Partitions in the group can borrow each other's unused headroom, so a quiet LPAR lends capacity to a busy one as long as the group total stays under the cap.
This matters for cost because of how IBM bills. Sub-capacity Monthly License Charge products are billed on the peak rolling four hour average MSU recorded in the month, the R4HA. Soft capping holds that peak down, and a group cap does it across a pool of partitions instead of stranding spare capacity inside individual ones. Defined capacity, the single LPAR version of the same mechanism, caps one partition; the group limit extends the idea to the whole group so the slack is shared, not wasted.
All three hold the rolling four hour average down to shape the billed peak. They differ in scope and in how efficiently they use spare capacity.
| Mechanism | Scope | Spare capacity behavior |
|---|---|---|
| Defined capacity | One LPAR, own MSU ceiling | Slack stays inside the partition, often stranded |
| Group capacity limit | A named group of LPARs, shared ceiling | Slack pooled and lent across the group |
| Hard cap (PR/SM weight cap) | One LPAR, absolute processor cap | No four hour averaging; throttles immediately |
Three LPARs that peak at different times. Capping each one individually strands headroom; one group cap shaves the billed peak without clipping real work. The rate per MSU is an illustrative placeholder R; actual rates are negotiated and not stated here.
| Measure | Three defined caps | One group cap |
|---|---|---|
| LPAR A ceiling (MSU) | 220 | n/a |
| LPAR B ceiling (MSU) | 180 | n/a |
| LPAR C ceiling (MSU) | 150 | n/a |
| Sum of individual ceilings | 550 | n/a |
| Group ceiling needed for same service | n/a | 430 |
| Peak MSU billed across MLC products | 550 × R | 430 × R |
Because the three partitions peak at different hours, their individual ceilings never fire at once, so 120 MSU of headroom sits idle inside the separate caps. A single group ceiling of 430 MSU carries the same workloads, because the pool lends capacity from quiet LPARs to busy ones. The billed peak drops 22 percent across every MLC product, with no workload moved and no service level missed. That is the case for group over defined capping.
When the rolling four hour average reaches the cap, WLM holds the line by throttling dispatchable work. A ceiling set below sustained demand delays lower priority workloads, so the cap has to sit above genuine demand, not at a target someone picked for the savings.
Only LPARs in the named group share the ceiling. Leave a busy partition out and its peak still bills in full; put an unpredictable one in and it can consume the pool. The grouping decides the savings as much as the number does.
Because capping works on a rolling four hour average, a brief spike does not immediately cap. That tolerance is useful, but it also means a sustained climb can ride for a while before WLM reacts, so the peak can still drift up if the cap is loose.
Caps are set in MSU, and MSU ratings shift across machine generations. A refresh can change what a given cap actually permits, so caps and any negotiated capacity protections need revisiting whenever the box changes.
Pool the slack, cap above demand, measure before you tighten.
Used well, a group capacity limit is one of the cleanest cost levers on the mainframe, because it lowers the billed peak without moving any workload. Start by measuring sustained demand per LPAR and the times each one peaks, then group partitions whose peaks fall at different hours so the pool actually lends capacity. Set the group ceiling above genuine demand, not at the savings target, and watch the rolling four hour average for throttling before you tighten further. Pair capping with scheduling so the two work together rather than fighting.
Capping shapes the peak that the capacity metric bills, so read MIPS and MSU explained for how that number is built and peak shaving for the scheduling side of the same problem. If you are weighing a move off MLC entirely, see Tailored Fit Pricing, which changes whether capping still pays. When the goal is to turn capping into measured savings, our mainframe cost optimization service models the caps against your SCRT data.
A soft cap WLM and PR/SM enforce across a named group of LPARs, holding their combined consumption to one shared MSU ceiling on a rolling four hour average. It extends defined capacity from a single partition to a pool.
Defined capacity caps one LPAR to its own ceiling; a group limit caps the total of several to one shared ceiling, so partitions borrow unused headroom. Group capping pools slack that defined caps strand.
Yes, deliberately used. It holds the rolling four hour average down, and the peak R4HA sets what every sub-capacity MLC product is billed. A cap just above demand shaves that peak across the whole stack.
If set below real demand, yes: WLM throttles work to hold the line. The discipline is to cap above sustained demand so only genuine spikes get clipped, which needs measurement rather than guesswork.