① Explainer · Licensing concept
Most shops treat the Workload Manager as a performance tuning tool. On a sub-capacity estate it is also the lever that sets your software bill, because it is the mechanism that caps the R4HA. Here is the mechanics, worked, with the policy levers that move the number.
The Workload Manager decides which work runs when capacity is tight. That same decision decides your bill.
The z/OS Workload Manager, WLM, enforces the defined capacity and group capacity limits that cap the rolling four hour average. Because sub-capacity software is billed on the peak R4HA, the WLM policy that holds that average under a chosen MSU ceiling is, in practice, the control that sets the bill. WLM is normally framed as a performance tool, and it is, but on a sub-capacity estate it is also the primary software cost control, because it is the component that actually does the capping.
This is the lever most buyers underuse, because cost and performance live in different teams. The systems group owns the WLM policy and tunes it for service. The sourcing team owns the contract and negotiates the price. The MSU peak sits between them, set by the policy, billed by the contract, and managed by neither as a cost. Bringing the two together, treating the WLM policy as a cost instrument as well as a performance one, is where real savings live. The worked example shows the capping mechanic.
One LPAR, an overnight batch window, eight hourly MSU readings. The uncapped R4HA peaks at 543 MSU. A defined capacity limit set at 480 MSU, enforced by WLM, holds the four hour average at the cap during the surge. The billed peak falls accordingly.
| Hour | Demand MSU | Uncapped R4HA | Capped R4HA (limit 480) |
|---|---|---|---|
| 02:00 | 800 | n/a | n/a |
| 03:00 | 820 | 507.5 | 480.0 |
| 04:00 | 300 | 532.5 | 480.0 |
| 05:00 | 250 | 542.5 | 480.0 |
| 06:00 | 240 | 402.5 | 402.5 |
| 07:00 | 230 | 255.0 | 255.0 |
Uncapped, the billed peak is 543 MSU. With WLM holding the defined capacity at 480, the four hour average cannot exceed the limit during the surge, so the billed peak drops to 480, a 63 MSU reduction that repeats every month the policy holds. The cost is a managed delay to discretionary work during the cap. This is a simplified illustration; real capping operates at finer intervals and depends on your policy and machine.
A WLM policy tuned for cost is not a single switch. It is four levers set together so that the constraint lands on work that can absorb it and never on the work that cannot. Set well, the bill falls with little service impact. Set carelessly, it trades critical service for savings, which is why this is a design problem, not a configuration toggle.
| Lever | What it controls | The risk to manage |
|---|---|---|
| Defined capacity | The MSU ceiling on a single LPAR's R4HA | A cap set too low delays critical work |
| Group capacity | A shared MSU ceiling across a group of LPARs | One LPAR can starve another for headroom |
| Importance levels | Which work yields first when capped | Misranked work yields at the wrong moment |
| Service class goals | The targets WLM protects under constraint | Loose goals let cost rise, tight goals fight the cap |
WLM behavior depends on your z/OS level, machine, and policy. These are common levers and patterns, not guarantees for any one configuration. Capping should be modeled against service goals before it is deployed.
WLM is the engine behind the group capacity limits and the peak shaving tactics that move the R4HA, and the figure it controls is reported by SCRT. Used alongside zIIP offload, it is central to MSU consumption optimization. Turning policy into a lower, defensible MSU peak is the work on MSU optimization and mainframe cost optimization.
Audit notice or renewal under 18 months out? We mobilize within 48 hours. Want your WLM policy read as a cost instrument, not just a performance one? Start here.
The z/OS Workload Manager (WLM) enforces the defined capacity and group capacity limits that cap the rolling four hour average. Because sub-capacity software is billed on the peak R4HA, the WLM policy that holds that average under a chosen MSU ceiling directly sets the bill. WLM is normally thought of as a performance tool, but on a sub-capacity estate it is also the primary software cost control, because it is the mechanism that does the capping.
Soft capping is using a defined capacity or group capacity limit, enforced by WLM, to hold the rolling four hour average under a set MSU value. When the four hour average approaches the limit, WLM constrains dispatching so the average does not exceed it. The instantaneous machine can still run faster, but the billed peak is held down. It is soft because it caps the average, not the hardware, so short bursts above the limit are tolerated as long as the average stays under.
It can, if the cap is set too low or the policy is built without care, because constraining dispatching to hold the average can delay work during a genuine peak. The art is setting the cap and the importance levels so that discretionary and low priority work absorbs the constraint while critical online and batch are protected. A well built WLM policy lowers cost with little or no impact on the workloads that matter. A careless one trades service for savings, which is why policy design is the whole job.
No. Capping helps where a controllable peak drives the bill, typically batch heavy or bursty LPARs. It is the wrong tool where the workload is latency sensitive and already near its service limit, or where the LPAR contributes little to the billed peak. The right answer is per LPAR: model the contribution each LPAR makes to the aggregated peak, then cap selectively. Blanket capping every LPAR usually costs more in service than it saves in MSU.