Service classes, goals and classification
A service class pairs a goal with an importance. The goal can be a response time, an execution velocity or discretionary. Classification rules decide which class each piece of work lands in.
Three kinds of goal
| Goal | Means | Typical work |
|---|---|---|
| Response time | Finish within a time, as an average or as a percentage (for example 95% within 0.5 seconds) | CICS and IMS transactions, DB2 distributed requests, TSO |
| Execution velocity | How often work is running when it wants to run, from 1 to 99 | Batch, started tasks, long-running work |
| Discretionary | No goal; uses spare capacity | Low-priority batch, tests |
Execution velocity
Velocity measures how much a unit of work is delayed. WLM samples it repeatedly: each time it is either using a resource (processor or I/O) or delayed waiting for one. Velocity = using samples / (using + delay samples) x 100. A velocity of 50 means the work gets resources about half the times it wants them.
Periods
A class can have several periods. Work starts in period 1 and moves to the next after consuming a set amount of service. This lets short work finish fast while long-running work, which would otherwise hog the system, drops to an easier goal.
Service class TSOUSER Workload ONLINE Period 1 Duration 400 Imp 2 Response time 90% within 0.5 sec Period 2 Imp 4 Execution velocity 20
Classification rules
Rules are grouped by subsystem type, for example JES for batch, STC for started tasks, CICS, IMS, DDF for DB2 distributed work and TSO. Within each, qualifiers such as job name, user ID, transaction name or job class select the service class. The first matching rule wins, so order matters.
| Subsystem | Qualifier | Value | Service class |
|---|---|---|---|
| JES | Job name | PAY* | BATCRIT |
| JES | Job class | T | BATTEST |
| CICS | Transaction | AUTH | CICSHI |
| STC | Task name | DB2P* | STCHI |
| JES | (default) | BATLOW |
Performance index
The performance index (PI) shows whether a class is meeting its goal. PI below 1 means it is doing better than the goal; PI equal to 1 means exactly meeting it; PI above 1 means missing it. WLM watches the PI of every period and acts on the most important ones that are above 1.
Common mistakes
A goal the hardware cannot meet keeps the PI above 1 forever, and WLM keeps taking resources from other work trying to fix it.
Work that matches no rule falls to the default class for its subsystem. New job names that do not follow the naming convention can end up in a low class without anyone noticing.
Velocity is relative to the environment. After a hardware change, velocity goals usually need review.
What you will see at work
- When a new application goes live, someone must add classification rules for its jobs and transactions; it is easy to forget.
- Performance reviews use PI by service class over time to spot goals that are routinely missed.
- Naming standards for jobs and transactions exist partly so that WLM rules can classify them reliably.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.