When Workload Manager Really Matters: Turning Business Priorities into System Performance
In many z/OS environments, Workload Manager (WLM) is treated as a given – configured, running, and largely left alone. But how often do you step back and ask: Is my WLM policy actually aligned with what the business needs today? This question becomes especially important when systems move from “everything is fine” to “everything is competing.”
WLM: Invisible When Things Work, Critical When They Don’t
When CPU resources are abundant, WLM doesn’t appear to do much. Every workload gets the resources it needs, regardless of priority. In these situations, even a poorly designed policy can seem adequate.
But this is misleading. The real test of WLM comes when resources are constrained. When CPU is fully utilized, WLM becomes the decision-maker, allocating resources based on predefined goals and importance levels. That’s when your policy either supports the business… or exposes its weaknesses.
From Business Priorities to IT Execution
WLM was designed with a clear purpose: to translate business priorities into IT behavior.
That sounds straightforward, but in practice, many environments evolve policies based on urgency rather than strategy.
A useful exercise is to create a clear overview of business workloads is to create a plan like the below:
| Importance | Behavior | Business workloads |
|---|---|---|
| 1 | Workloads that support importance 2. Workloads will not be held back during scarce resources. |
Database management Network |
| 2 | This category typically holds the online systems that has users waiting and provides customer service. Workloads are only held back if importance 1 is lacking resources. |
Interactive online work. Data requests from live distributed systems. Message queuing. |
| 3 | Daily work that impacts how customer services is provided. Batch workloads that are time dependent. Workload will be held back if resources are exhausted. |
Asynchronous online tasks. Smaller print outs. |
| 4 | Critical batch workloads. Large scale batches with risk of next day delays. | This would normally be the critical path batch flow. |
| 5 | Less time critical batch. | Normal batch flow. Ad hoc jobs |
| 6 | This importance is basically not important at all. Work under this importance will always be the first to suffer. |
Use it to fill up whitespace. Not classified workload should end up here. |
Service Classes: Powerful, but Easy to Overcomplicate
WLM organizes work into service classes, often with multiple periods and classification rules.
It’s tempting to build a detailed and granular setup to hold all possible workloads in more areas like Prod, Test and Dev. But complexity comes at a cost. Even a “simple” setup can quickly grow to 60+ service periods. At that point, it becomes difficult to maintain a clear understanding of priorities.
Common Pitfalls
A few recurring challenges seen in WLM environments:
- Too many service classes to manage effectively
- Default classes not monitored closely enough
- Policies that no longer reflect current business priorities
- Over-reliance on historical configurations
To keep your WLM policy effective
If there’s one message to take away, it’s this: WLM is not a “set and forget” system.
To keep it effective:
- Regularly review your WLM policy
- Validate that it aligns with current business priorities
- Ensure goals are realistic and measurable
- Simplify where possible
- Be prepared to redesign as workloads evolve
-
Mary SolomonVice President of ITBI Services -
Frank TidemandCapacity and Performance Consultant
