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.