Introduction to the Mainframe Workload Manager
The Mainframe's Ultimate Traffic Controller
Mainframes are trusted for their performance, security, and reliability. They process tens of thousands of transactions per second, around the clock. However, not all work is equally important — some are more urgent, and need to be handled as such. That's where the Workload Manager (WLM) comes in.
WLM acts as an orchestrator, directing the flow of operations on the mainframe so that everything works as it should, when it should.
New to mainframes? Read the foundational overview at ibm.biz/refer-zxp ↗ (select "Zubair Idris Aweda" as referrer) before continuing.
What is WLM?
Mainframe Workload Manager (WLM) is a core component of IBM z/OS. Its job is to automatically manage system resources — CPU, memory, I/O, networking — based on business priorities, not raw technical metrics.
Think of WLM as an air traffic controller: it must keep everything moving smoothly, stop lower-priority traffic for more urgent work, and clear the runway entirely for the equivalent of an ambulance — a critical banking transaction.
Why WLM Exists
In older systems, administrators manually assigned static priorities to jobs — fine until workload changed. WLM solves this by:
Dynamically shifts resources every few milliseconds as workloads fluctuate, ensuring consistent service levels even during peak usage.
Ensures each workload meets its Service Level Objective — the measurable performance target assigned by the business.
Keeps the entire system stable by preventing any single workload from monopolising resources at others' expense.
Manages resources to meet specific business objectives (e.g. a banking transaction finishes in under 1 second), not just arbitrary metrics.
Two Operating Modes
WLM manages everything automatically based on defined business goals. Modern, dynamic, and requires no manual tuning.
Legacy mode. Similar to old-school static priority systems — less flexible, maintained for backward compatibility.
Most mainframes today run in Goal Mode.
How WLM Works
WLM follows a continuous four-step cycle — defining categories, setting targets, measuring reality, and adjusting in response. Click each step below to explore it.
WLM Decision Flow Process
Click any step to expand details
- Online banking transactions → High Priority
- Batch report generation → Medium Priority
- Background data cleanup → Low Priority
- Each class carries performance goals
- Response time goal — "Complete in under 0.5s"
- Execution velocity — % of max possible speed (for batch)
- Discretionary — runs only when resources are free
- CPU allocation per class
- Request completion speed
- Delays (I/O, CPU, memory)
- Whether goals are being met or missed
- Increase dispatching priority
- Give more CPU to critical work
- Delay lower-priority workloads
- Move address spaces to faster processors
- Balance workload across multiple LPARs
WLM Priority Simulator
Adjust importance levels and performance goals for the different tasks below. Watch how WLM re-ranks and re-allocates CPU resources in real time.
Live WLM Workload Simulator
Drag sliders to change importance & goal pressure → WLM auto-prioritises
Key Concepts in WLM
These are the building blocks you'll encounter when working with WLM. Each links to official IBM documentation for deeper reading.
A specific, measurable performance target within z/OS WLM. Ensures critical apps get the resources they need based on business goals.
A group of related workloads (transactions, batch jobs, etc.) managed together under shared performance goals.
IBM Docs: Service Classes ↗Business priority ranking from 1 (critical) to 5 (lowest). Controls execution order and resource allocation.
IBM Docs: Importance Levels ↗Expected/target outcomes: average response time, percentage of completions within a window, or execution velocity for batch.
IBM Docs: Performance Goals ↗A group or item of work for which z/OS WLM reports performance data — used for monitoring and analysis.
Used to limit or guarantee resources for a workload group. Prevents a single workload from consuming all capacity.
IBM Docs: Resource Groups ↗Specifies conditions under which a job can run — e.g., software licenses, hardware, or system state requirements.
IBM Docs: Scheduling Envs ↗The entire rulebook WLM uses — the complete set of service classes, goals, importance levels, and resource rules.
Technologies WLM Interacts With
WLM doesn't operate in isolation — it orchestrates tightly with multiple z/OS components to ensure business priorities are met across the entire system.
Decides which unit of work gets CPU time. WLM dynamically adjusts dispatching priorities — if a critical workload misses its target, WLM signals the dispatcher to grant it more CPU, while lower-priority work waits.
WLM works across multiple z/OS systems to balance workloads at the enterprise level — ensuring no single system is overwhelmed while others are idle. Critical for high-availability installations.
WLM integrates tightly with enterprise middleware subsystems to manage transactions, database requests, and application threads by service class — protecting high-priority online transactions even under heavy load.
Some workloads span multiple address spaces (e.g., a web request triggering a DB query). Enclaves let WLM track and manage this as a single logical unit, applying consistent performance goals end-to-end.
WLM determines when eligible workloads can be redirected to IBM Z specialty processors, improving system efficiency and reducing software licensing costs without impacting critical workloads. See interactive demo ↓
zIIP CPU Offloading
The zIIP (z Integrated Information Processor) is a specialty engine that handles specific workload types at a lower software licensing cost. WLM automatically routes eligible work — Java, XML, DB2 utilities, encryption — off the general-purpose CPU and onto the zIIP.
Use the scenario buttons below to see how CPU load shifts between the general-purpose (GP) processor and the zIIP under different conditions.
CPU Offload Visualiser
Select a workload scenario to see how WLM distributes work
Real-World Examples
Here's how WLM behaves across three common production scenarios.
Users expect instant responses — any delay degrades trust and business outcomes.
✓ Boost CPU dispatching priority
✓ Preempt batch job CPU allocation
✓ Spread workload across available LPARs
✓ Flag goal miss and reassess every millisecond
No strict response time requirement — must complete by morning but not at the expense of anything online.
✓ Runs with moderate velocity target
✓ Throttled back if online transactions spike
✓ Resumed when online load drops overnight
✓ No human intervention required
If the system is busy, WLM holds it back. When idle, it runs at full speed. Critical workloads are always protected.
✓ Suspended during peak hours automatically
✓ Resumes the moment spare capacity appears
✓ Races through overnight when system is idle
✓ Zero impact on all higher-priority workloads
Summary
WLM is one of the key reasons mainframes can run diverse workloads reliably at scale. By translating business priorities into system behaviour, it ensures critical applications perform consistently — even under heavy load.
It does this automatically, continuously, and without human intervention: defining work categories, setting measurable goals, monitoring every millisecond, and dynamically reallocating resources to meet those goals.
This article was co-authored with Salaudeen Zainab Moyinoluwa.