Chapter 5 Key Takeaways: z/OS Workload Manager

The One-Sentence Summary

WLM dynamically allocates z/OS resources based on business goals — your COBOL code's runtime performance depends as much on WLM classification as on code quality.

Five Things to Remember

1. WLM is goal-based, not priority-based. You define what you want (response time, velocity) and WLM figures out how to achieve it. If your service class is meeting its goal, WLM will give excess resources to other work — this is by design.

2. Performance Index (PI) is your single most important metric. PI < 1.0 means WLM is providing adequate resources (look elsewhere for performance problems). PI > 1.0 means WLM is not meeting the goal (investigate importance levels, capacity, or classification).

3. Importance levels create tiers; goals create targets within tiers. Use importance (1–5) for coarse-grained priority. Use response time or velocity goals for fine-grained performance management. Never put everything at the same importance — it defeats WLM's purpose.

4. Classification rules determine your code's priority. A perfectly optimized COBOL program at importance 5 will run slower than mediocre code at importance 1. Ensure your production workloads are correctly classified.

5. Service policies enable time-based priority shifts. Use separate policies for daytime (online-heavy) and batch window (batch-heavy). Automate the switch. Test the policies before you need them.

Quick Reference: WLM Components

SERVICE DEFINITION
├── SERVICE CLASSES (containers for work with goals)
│   ├── Name (8 chars max)
│   ├── Importance Level (1=highest, 5=lowest)
│   └── Periods (1-8, each with goal type + value)
│       ├── Response Time (seconds, average)
│       ├── Velocity (0-100%, time using resources vs. waiting)
│       └── Discretionary (leftover resources only)
│
├── WORKLOADS (logical groupings for reporting)
│   └── Group related service classes by business function
│
├── CLASSIFICATION RULES (how work gets assigned)
│   ├── By Subsystem Type (CICS, DB2, JES, STC, TSO, OMVS)
│   ├── By Job/Transaction attributes
│   └── Evaluated top-down, first match wins
│
└── SERVICE POLICIES (named sets of goal overrides)
    ├── DAYTIME — online at high importance
    ├── BATCHWIN — batch critical path elevated
    └── MONTHEND — additional batch elevated

Quick Reference: Performance Index

PI = Actual Performance / Goal

PI < 1.0  →  BETTER than goal    → WLM is providing adequate resources
                                    → Look at application/DB2/I/O for issues
PI = 1.0  →  EXACTLY at goal     → Ideal state
PI > 1.0  →  MISSING goal        → Check importance, capacity, classification
PI > 2.0  →  SERIOUSLY missing   → Investigate immediately if importance 1-2
PI = N/A  →  Discretionary       → No goal to measure against

Quick Reference: Dispatching Priority Ranges

Ranges are approximate and dynamic — WLM adjusts within them based on PI.

Quick Reference: Diagnostic Flowchart

Job/Transaction Running Slowly
│
├─ Check PI
│  ├─ PI < 1.0 → NOT a WLM problem → Check code, DB2, I/O
│  └─ PI > 1.0 → Possible WLM issue → Continue
│
├─ Check Dispatching Priority
│  ├─ Priority in expected range → System may be capacity-constrained
│  └─ Priority too low → Check classification rules (misclassified?)
│
├─ Check for Higher-Priority Contention
│  ├─ Imp 1 work also missing goals → Capacity problem
│  └─ Imp 1 work meeting goals → Goals or importance may need adjustment
│
└─ Check Non-WLM Bottlenecks
   ├─ High I/O wait → Storage subsystem
   ├─ DB2 lock waits → Application design
   ├─ ENQ waits → Serialization
   └─ High CPU + PI < 1.0 → Application inefficiency

Common Mistakes to Avoid

Key Data Sources

Connection to Other Chapters