Using velocity goals for started tasks

Velocity goals are the most appropriate goal for started tasks and long running work. Instead of figuring out a specific velocity goal for your started tasks, you should divide your started tasks into a high, a medium, and a low importance service class, and define a velocity that suffices for each category.

You can also take advantage of the system supplied service classes for started tasks: SYSTEM and SYSSTC. Workload manager recognizes special system address spaces (like GRS, SMF, CATALOG, MASTER, RASP, XCFCAS, SMXC, CONSOLE, IOSAS, WLM), puts them into the SYSTEM service class, and treats them accordingly. Address spaces in the SYSSTC service class are kept at a very high dispatching priority.

Note: You can also assign address spaces to the SYSTEM and SYSSTC service classes as part of your work classification rules. See System-provided service classes.

For information about how to define service classes and associated classification rules for started tasks, see Using the system-supplied service classes.

Velocity is also appropriate for the “server” started tasks, that is, the address spaces that do work on behalf of a transaction manager or resource manager, such as CICS® AOR, or an IMS™ control region. Since the server address spaces are processing work that also has an assigned performance goal, the velocity goal that you assign to servers applies only during address space startup. Then workload management manages resources to meet the goals defined for the work the servers are processing, and not towards the goals defined for the servers.

If you have a version of a work manager such as CICS and IMS that does not support workload management, you cannot define a goal to the work manager's transactions, but you can define a velocity goal for its server address spaces.