The priorities for jobs that run in batch environments should normally
be lower than priorities for jobs in interactive environments. Also, the time
slice should be small enough so that a looping program does not dominate processor
time and an activity level.
You may want the priority for the system operator's jobs to be higher
than priorities of other jobs so that the system operator can effectively
respond to system needs.
If you use QCTL as the controlling subsystem, the operator is automatically
running at a higher priority after signing on at the console. This is because
QCTL routes the console job using the QCTL class, which specifies a higher
priority.
Another way that you can set up your system so that the operator
can run at a higher priority would be to do the following:
- Add a routing entry to the subsystem with unique routing data and
specify the QSYS/QCTL class.
- Create a new job description for the operator, specifying the same
unique routing data that you used in the routing entry.
- Change the operator's user profile to specify the new job description.
- Now when the operator signs on to that subsystem, the job will
route using the QCTL class, which specifies a higher priority than the class
used by normal interactive jobs.
The job run priority is the highest priority at which any thread
in the job may run. Each thread may have it's own thread priority that is
lower than the job priority. The Change Job (CHGJOB) command
will change only the job priority. The Change Job (QWTCHGJB) API can be used
to change either the job priority or a thread priority.