z/OS UNIX System Services Planning
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Prioritizing kernel work on your system

z/OS UNIX System Services Planning
GA32-0884-00

Goal mode is a workload manager (WLM) mode for prioritizing kernel work in your system. The nice() and setpriority() functions use definitions in BPXPRMxx for goals. These definitions are optional, but if they are not specified, the nice() and setpriority() functions do not change the performance level. The following are some reasons for enabling nice() and setpriority() functions:
  • If you are running applications that require the ability to control the priority of different processes, you must define appropriate priority levels for the application to use. This is typically done for real-time systems that are dedicated to running a single application.
  • If you have enabled the batch, at, and cron shell functions, you need to define priority groups or goals that are appropriate for running batch jobs as in a UNIX system.

For more information, see Controlling dispatching priorities.

Installations that run in goal mode can take the following steps to customize service policies in their WLM definition:

  • Define a workload for kernel work.
  • Define service classes for kernel work:
    • Define a service class for forked child processes. You should specify a number of performance periods. Performance periods for short-running work can be given response-time goals or percentage response-time goals. Performance periods for long-running work should be given velocity goals.
    • Define a service class for startup processes, which are forked by the initialization process, BPXOINIT. This service class should be given a velocity goal that is higher than that of other forked child processes.
  • Define classification rules:
    • By default, put forked child processes (subsystem type OMVS) into the service class defined for forked child processes.
    • Put the kernel (with TRXNAME=OMVS) into a high-priority Started Task (subsystem type STC) service class. Another option is to keep the OMVS started procedure in the default started class category, which generally has high priority.
    • Put the initialization process BPXOINIT (with TRXNAME=BPXOINIT) into a high-priority Started Task (subsystem type STC) service class. Another option is to keep the BPXOINIT started procedure in the default started class category, which generally has high priority.
    • Startup processes that are forked by the initialization process, BPXOINIT, fall under SUBSYS=OMVS. These processes are identified by USERID=OMVSKERN. Put them in a separate service class.
    • Other forked child processes (under subsystem type OMVS) can be assigned to different service classes based on USERID, ACCTINFO, or TRXNAME.
    • Put the DFSMS buffer manager SYSBMAS (with TRXNAME=SYSBMAS) into a high-priority Started Task (subsystem type STC) service class. Another option is to allow the SYSBMAS started procedure to remain in the default started class category which generally has high priority.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014