Prioritization is a method of giving specific tasks preference in being dispatched.
Priority is specified by terminal in:
The overall priority is determined by summing the priorities in all three definitions for any given task, with the maximum priority being 255.
TERMPRIORITY+PRIORITY+OPPRTY <= 255
The value of the PRTYAGE system initialization parameter also influences the dispatching order; for example, PRTYAGE=1000 causes the task’s priority to increase by 1 every 1000ms it spends on the ready queue.
With CICS®, the dispatching priority of a task is reassessed each time it becomes ready for dispatch, based on clock time as well as defined priority.
A task of priority n+1 that has just become ready for dispatch is usually dispatched ahead of a task of priority n, but only if PRTYAGE milliseconds have not elapsed since the latter last became ready for dispatch.
Thus, a low priority task may be overtaken by many higher priority tasks in a busy system, but eventually arrives at the top of the ready queue for a single dispatch.
The lower the value of PRTYAGE, the sooner this occurs.
Prioritization is useful for browsing tasks, and tasks that use a lot of processor time. Input/Output bound tasks can take the required amount of CPU, and move on to the next read/write wait. CPU-intensive tasks take higher priority over the less intensive tasks.
Prioritization can be implemented in all CICS systems. It is more important in a high-activity system than in a low-activity system. With careful priority selection, an improvement in overall throughput and response time may be possible.
Prioritization can minimize resource usage of certain resource-bound transactions.
Prioritization increases the response time for lower-priority tasks, and can distort the regulating effects of MXT and the MAXACTIVE attribute of the transaction class definition.
Priorities do not affect the order of servicing terminal input messages and, therefore, the time they wait to be attached to the transaction manager.
Because prioritization is determined in three sets of definitions (terminal, transaction, and operator), it can be a time-consuming process for you to track many transactions within a system.
CICS prioritization is not interrupt-driven as is the case with operating system prioritization, but simply determines the position on a ready queue. This means that, after a task is given control of the processor, the task does not relinquish that control until it issues a CICS command that calls the CICS dispatcher. After the dispatch of a processor-bound task, CICS can be tied up for long periods if CICS requests are infrequent. For that reason, prioritization should be implemented only if MXT and the MAXACTIVE attribute of the transaction class definition adjustments have proved to be insufficient.
Use prioritization sparingly, if at all, and only after you have already adjusted task levels using MXT and the MAXACTIVE attribute of the transaction class definition.
It is probably best to set all tasks to the same priority, and then prioritize some transactions either higher or lower on an exception basis, and according to the specific constraints within a system.
Do not prioritize against slow tasks unless you can accept the longer task life and greater dispatch overhead; these tasks are slow, in any case, and give up control each time they have to wait for I/O.
Use small priority values and differences. Concentrate on transaction priority. Give priority to control operator tasks rather than the person, or at least to the control operator’s signon ID rather than to a specific physical terminal (the control operator may move around).
Consider for high priority a task that uses large resources. However, the effects of this on the overall system need careful monitoring to ensure that loading a large transaction of this type does not lock out other transactions.
Also consider for high priority those transactions that cause enqueues to system resources, thus locking out other transactions. As a result, these can process quickly and then release resources. Examples of these are:
Lower priority should be considered for tasks that:
PRTYAGE should usually be left to its default value, unless certain transactions get stuck behind higher priority transactions during very busy periods.
You specify the priority of a transaction in the CEDA TRANSACTION definition with the PRIORITY attribute. You specify the priority for a terminal in the CEDA terminal definition with the TERMPRIORITY attribute. You specify the priority for an operator with the OPPRTY operand in the user segment of the external security manager (ESM).
PRTYAGE is a system initialization parameter.
There is no direct measurement of transaction priority. Indirect measurement can be made from: