Why tasks fail to get an initial dispatch

When a task is past the transaction class and MXT barriers, it can be attached to the dispatcher. It must then wait for its initial dispatch. If tasks are made to wait for a relatively long time for their first dispatch, you will probably notice the degradation in the performance of the system.

You can get evidence that tasks are waiting too long for a first dispatch from performance class monitoring. If you do find this to be the case, you need to investigate the reasons for the delay. To calculate the initial dispatch delay incurred by a task use the following fields from the performance-class monitoring record:

DSPDELAY = First dispatch delay
TCLDELAY = Transaction Class delay
MXTDELAY = MXT delay

Using the above names:

  Delay in dispatcher = DSPDELAY - (TCLDELAY + MXTDELAY)

If ‘Delay in Dispatcher’ is significantly greater than 0, the dispatcher could not dispatch the task immediately.

The factors that influence the length of time a task must wait before getting its first dispatch are:

Priorities of tasks

Normally, the priorities of tasks determine the order in which they are dispatched. Priorities can have any value in the range 1-255. If your task is getting a first dispatch (and, possibly, subsequent dispatches) too slowly, you might consider changing its priority to a higher value.

You have no control over the priorities of CICS system tasks.

One other factor affecting the priorities of tasks is the priority aging multiplier, PRTYAGE, that you code in the system initialization parameters. This determines the rate at which tasks in the system can have their priorities aged. Altering the value of PRTYAGE affects the rate at which tasks are dispatched, and you probably need to experiment to find the best value for your system.

Storage stress conditions are detailed in the storage manager statistics. CICS attempts to alleviate the situation by releasing programs with no current user, and by not attaching new tasks. If these actions fail to eliminate storage stress or if the SOS condition is caused by a suspended GETMAIN, one or both of these messages is sent to the console:

DFHSM0131 applid CICS is under stress (short on storage below 16MB)

DFHSM0133 applid CICS is under stress (short on storage above 16MB)

If you don't observe the SOS messages, you can find out how many times CICS has gone SOS from the storage manager statistics ('Times went short on storage'). You can also get this information from the storage manager domain DSA summary in a formatted system dump.

Note:
Release of the storage cushion is not the only cause of CICS going SOS. The condition is also raised if a task makes an unconditional request for storage greater than the storage cushion size when the system is approaching SOS. In such a case, the cushion is not released, but the task making the unconditional request is suspended and message DFHSM0131I or DFHSM0133I may be issued. CICS resumes the suspended tasks immediately if storage is made available by CICS releasing unused programs. The short-on-storage condition remains until all the previously suspended tasks have obtained the storage they requested.

Two other conditions are recognized by the dispatcher on the approach to SOS, namely ‘storage getting short’ and ‘storage critical’. The two conditions affect the chance of new tasks getting a first dispatch.

From the ‘storage getting short’ point, through ‘storage critical’ and right up to SOS, the priorities of new user tasks are reduced in proportion to the severity of the condition. However, this is not true if the PRTYAGE system initialization parameter is set to 0. At first, you are not likely to notice the effect, but as ‘storage critical’ is approached, new tasks might typically be delayed by up to a second before they are dispatched for the first time.

It is likely that ‘storage getting short’ and ‘storage critical’ occur many times for every occasion SOS is reached. If you want to see how often these points are reached, select level-2 tracing for the dispatcher domain and look out for trace point IDs DS 0038 (‘storage getting short’) and DS 0039 (‘storage critical’). Trace point DS 0040 shows that storage is OK.

A summary of the effects of ‘storage getting short’, ‘storage critical’, and SOS is given in Table 13.

Table 13. How storage conditions affect new tasks getting started
State of storage Effects on user tasks
Storage getting short Priority of new user tasks reduced a little
Storage critical Priority of new user tasks reduced considerably

Related concepts
CICS tracing
Task control
Related tasks
Interpreting storage manager statistics
Selecting tracing by component
Formatting system dumps
Related references
Storage manager statistics
CHANGE TASK
[[ Contents Previous Page | Next Page Index ]]