When a ready task is dispatched, it becomes a running task. It is unlikely to complete without being suspended at least once, and it is likely to go through the ‘READY - RUNNING - SUSPENDED’ cycle several times during its lifetime in the dispatcher.
The longer the task spends in the non-running state, either ‘ready’ or ‘suspended’, the greater your perception of performance degradation. In extreme cases, the task might spend so long in the non-running state that it is apparently waiting indefinitely. It is not likely to remain ‘ready’ indefinitely without running, but it could spend so long suspended that you would probably classify the problem as a wait.
The purpose of this section is to deal not with waiting tasks, but instead with tasks that complete more slowly than they should.
Here are some factors that can affect how long tasks take to complete:
Each of these factors is considered in turn.
The most obvious factor affecting the time taken for a task to complete is system loading. For more information, see CICS® Performance Guide. Note in particular that there is a critical loading beyond which performance is degraded severely for only a small increase in transaction throughput.
The time-out interval is the length of time a task can wait on a resource before it is removed from the suspended state. A transaction that times out is normally abended.
Any task in the system can use resources and not allow other tasks to use them. Normally, a task with a large time-out interval is likely to hold on to resources longer than a task with a short time-out interval. Such a task has a greater chance of preventing other tasks from running. It follows that task time-out intervals should be chosen with care, to optimize the use of resources by all the tasks that need them.
CICS uses QSAM to write data to extrapartition transient data destinations, and QSAM uses the MVS™ RESERVE mechanism. If the destination happens to be a DASD volume, any other CICS regions trying to access data sets on the same volume are held up until the TD WRITE is complete.
Other system programs also use the MVS RESERVE mechanism to gain exclusive control of DASD volumes, making the data sets on those volumes inaccessible to other regions.
If you notice in particular that tasks making many file accesses take a long time to complete, check the distribution of the data sets between DASD volumes to see if volume locking could be the cause of the problem.