Soft Capping and Defined Capacity, Explained.

Soft capping is the use of a defined capacity limit, enforced by z/OS Workload Management together with PR/SM, to hold an LPAR's billable MSU consumption at or below a set figure. It works against the rolling four hour average, the same window that sub-capacity Monthly License Charge software is billed on, which is exactly why it is a cost lever and not merely a throttle.

Defined capacity is the MSU number you set on a single LPAR. Group capacity applies the same mechanic to a group of LPARs on one machine, summing their four hour averages against one shared limit. Both differ from hard capping, which limits actual processor access by weight or logical processor count regardless of demand. Soft capping allows short bursts above the line as long as the four hour average stays controlled, so it protects responsiveness while still holding the peak that sets the bill.

An uncapped LPAR lets its four hour average climb wherever the busiest window takes it. Because the sub-capacity bill tracks that peak per product, the busiest four hours of the month set the charge for the whole month. A defined capacity limit pulls the billed peak down to the line you choose. Take an LPAR whose uncapped peak reaches 480 MSU but whose work could be held at 400 with no material service impact.

State	Billable peak	What the cap does
Uncapped	480 MSU	Peak set by the busiest window
Defined capacity at 400	400 MSU	Four hour average held at the line
Billable MSU removed	80 MSU	Across every sub-capacity product on the LPAR

Illustrative MSU figures. The cap reduces the billed peak for every sub-capacity product running on that LPAR, so the effect compounds across the stack.

The 80 MSU removed is not 80 MSU of lost work. It is 80 MSU of peak that the work did not actually need to run at, recovered by holding the four hour average flat through the busy window and letting the workload smooth across it. Because every sub-capacity product on the LPAR is billed against the same controlled peak, one well placed limit moves the charge for the whole stack at once. Multiply across LPARs and products and a disciplined capping policy is frequently the largest single line of avoidable spend on an unmanaged estate.

Capping is not one switch. There are four modes and they trade cost control against responsiveness differently. Choosing the wrong one either leaves money on the table or starves the work.

Mode	What it limits	Best for
Hard cap (PR/SM)	Actual processor access by weight	Absolute ceilings, test partitions
Defined capacity (soft)	Single LPAR 4 hour average vs MSU	Per LPAR cost control with burst headroom
Group capacity (soft)	Group of LPARs, summed 4 hour averages	Sharing a ceiling across related LPARs
Absolute capping	Caps to the MSU limit regardless of 4HRA	Firm ceilings where 4HRA enforcement is too loose

Soft modes enforce only while the long term four hour average is at or above the limit, which is what preserves short burst capacity.

The art is matching the mode to the workload. A predictable batch LPAR tolerates a tight defined capacity limit. A latency sensitive online LPAR needs burst headroom and may prefer group capacity so a quiet sibling lends it room. Absolute capping suits cases where the four hour average enforcement is too permissive and a firmer ceiling is required. The point of the matrix is that a single sitewide capping rule is almost always wrong: it overcharges the steady workloads and strangles the spiky ones. The optimization is per LPAR.

Across 500+ engagements and $180M+ of negotiated mainframe spend, the estates that treat capping as a continuous tuning discipline pay materially less than those that set a limit once and forget it, or worse, run uncapped because nobody owns the peak. Defined capacity is the most direct lever on a sub-capacity bill. It just has to be set with data, not with caution.