The system is designed to efficiently execute large numbers of processes simultaneously. However, each system incorporates a limited number of processors and a finite amount of main memory. On a heavily used system, all the processes in the mix are competing for the use of these system resources.
However, it may be that not all these processes are equally urgent from the user's point of view. The system provides the concept of priority to allow you to specify which processes should receive preference in the competition for system resources.
The primary effect of process priority occurs in cases where more than one process is ready to use a central processor. Each central processor executes only one process at a time, but divides its time among all the processes on the system. The system maintains a list, called the ready queue, of all processes that are waiting for a processor, arranged in priority order.
A processor continues executing a particular process until one of three things happens: the process reaches a natural stopping point (for example, because it is waiting for an I/O to complete), a higher-priority process appears in the ready queue, or the process exceeds its time slice and a process of equal priority is present in the ready queue. The processor then retrieves the higher-priority process from the ready queue and begins executing it.
The priority of a process is determined by several factors, only some of which can be controlled by the user. For example, some system software processes have a higher priority than can be assigned to an ordinary application process. For a complete overview of factors affecting process priority, refer to the System Administration Guide.
One aspect of priority that you can control, within certain limits, is the PRIORITY task attribute value. The PRIORITY task attribute has a range of values from 0 to 99, with the higher values indicating higher priority. The default value is 50. You can assign a PRIORITY value to a process anytime before initiation, either through task equations or assignments to a task variable. Once a process is initiated, any programmatic assignments to the PRIORITY task attribute change the task attribute value without affecting the actual priority at which the process executes. The new PRIORITY task attribute value is returned when the task attribute is read, and displayed in the output of various system commands.
The only way to effectively change the priority of an in-use process is with the PR (Priority) system command. This command changes the PRIORITY task attribute value and also causes the system to enforce the new priority value.
One point to bear in mind about this attribute is that its effects are absolute rather than proportional. That is to say, the system always gives the processor to the highest-priority process that is ready to use it. A PRIORITY value of 51 gives as much advantage over a PRIORITY of 50 as a PRIORITY value of 99 does. If the process with the PRIORITY of 51 is very processor-intensive, it could prevent the process with PRIORITY 50 from receiving any processor time at all. For this reason, you should be cautious about raising the PRIORITY value of a processor-intensive process.
On the other hand, it is sometimes helpful and appropriate to raise the priority of interactive processes. An interactive process is one that is largely driven by input from a user at a terminal. Such a process typically spends most of its time waiting for the user to enter commands. Once the user does enter a command, the user typically has to wait for a response before being able to accomplish any further useful work. If the processor usage of the process is small and occasional, you can improve response time by raising the priority with relatively little impact on overall system performance.
For information about how to determine whether a process is processor-intensive, refer to Understanding Processor Usage Accounting later in this section.
On native MCP systems, you can also control the processor rate for a process. The CPURATEBIAS task attribute determines the maximum processor rate for a process. If a process is ready to use a processor but is prevented from doing so as a result of the CPURATEBIAS task attribute value for that process, it is placed in queue known as the hold queue. You can use this attribute to prevent a processor-intensive task from starving other processes of processor time.
The system administrator can place some constraints on the values you are able to assign to the PRIORITY task attribute. For example, the administrator can assign a PRIORITY limit to a job queue. If you write a WFL job that is initiated from that job queue, the job cannot request a PRIORITY value higher than the job queue PRIORITY limit. Similarly, the system administrator can assign a value to the PRIORITY attribute of your usercode. CANDE and MARC read the PRIORITY attribute of your usercode when you log on. When you initiate a task from a CANDE or MARC session, CANDE and MARC do not allow you to assign the PRIORITY task attribute a value higher than your PRIORITY usercode attribute.
Aside from the PRIORITY task attribute, the major feature you can use to manipulate process priority is the MP <file title> + CONTROL form of the MP (Mark Program) system command. This option marks an object code file as a control program. Thereafter, whenever that program is initiated, it runs in the same priority category that message control systems (MCSs) do. This category gives higher priority than WFL jobs or application programs have, but lower priority than invisible independent runners.
An additional effect of control program status is that it prevents the system from scheduling a process (that is, delaying initiation of the process) when there is a shortage of available memory. If you mark too many programs with control program status, the result can be that system memory becomes overloaded, with a resulting adverse effect on system performance. Therefore, you should use caution in marking programs with control program status.
The system can place WFL compilations in a special priority category. These WFL compilations receive higher priority than all application programs, but lower priority than control programs, MCSs, and invisible independent runners. The high priority class is limited to a maximum of 20 seconds of processor time. After a WFL compilation has used 20 seconds of processor time, its priority bias is automatically removed, and the task is made visible.
The special priority is given to WFL compilations initiated from the ODT (such compilations are invisible while they are in the special priority category) and to WFL compilations initiated with the ALGOL ZIP and COBOL CALL SYSTEM WFL statements. The special priority is not given to compilations initiated with the DCALGOL CONTROLCARD statement.
The system also places WFL jobs in a special priority category. WFL jobs receive higher priority than all application programs, but lower priority than control programs, MCSs, and invisible independent runners.
The system uses the PRIORITY task attribute only when comparing processes that are in the same priority class. Thus, a WFL job running with a PRIORITY value of 1 still has a higher priority than an ordinary process with a PRIORITY of 99.
The system places WFL jobs in the high priority class because their only purpose, in most cases, is to initiate tasks; the sooner the job initiates each task, the sooner the system can evaluate the priority of each task on its own merits. However, it would not be possible to rewrite a typical application in WFL to take advantage of its priority. WFL is specialized for tasking functions and has no ability to read from or write to files.
The high priority class is limited to a maximum of 60 seconds of processor time. After a WFL job has used 60 seconds of processor time, its priority bias is automatically removed and the job competes for processor resources based on its visible priority value, in the same way most other tasks compete for processor resources. The priority bias is also removed if the priority of the job is adjusted.
Running a looping WFL job at priority 99 can still seriously impact system performance in the same way as any looping task running at priority 99 impacts the system performance. In general, the priority of a WFL job should be about the same as the priority of the tasks that it initiates.
Because the PRIORITY task attribute and control program assignments have a potential to affect overall system performance, you should generally consult with the administrator of your system before raising the priority of any particular process.
