Finding the bottleneck

Four potential bottlenecks can be identified for user tasks, and three for CICS® system tasks.

About this task

The bottlenecks are as follows:

  • Attach to transaction manager (user tasks only)
  • Attach to dispatcher (user tasks and system tasks)
  • Initial dispatch (user tasks and system tasks)
  • Dispatch, suspend and resume cycle (user tasks and system tasks)

Procedure

  1. Determine which bottleneck is causing your performance problem.
    Each bottleneck is affected by a different set of system parameters and you might find that adjusting the parameters solves the problem.
  2. If performance is particularly poor for any of the tasks in your system, you might be able to capture useful information about them with the command CEMT INQ TASK.
    However, tasks usually run more quickly than you can inquire on them, even though there might be a performance problem. You can use performance class monitoring or tracing to get the information you require.

What to do next

Based on your situation, find out the next troubleshooting action.

A task has not been attached to the transaction manager

If a task has not been attached to the transaction manager, you cannot get any information about its status online. CEMT INQ TASK returns a response indicating that the task is not known. If the task has not already run and ended, this response means that it has not been attached to the transaction manager.

Guidance about finding out why tasks take a long time to get an initial attach to the transaction manager is given in Why tasks fail to get attached to the transaction manager.

A task has not been attached to the dispatcher

If a task has been attached to the transaction manager but has not yet been attached to the dispatcher, CEMT INQ TASK shows it to be ‘SUSPENDED’ on a resource type of MXT or TCLASS. These are the only valid reasons why a user task, having been attached to the transaction manager, would not be attached to the dispatcher.

If CEMT INQ TASK returns anything other than this, the task is not waiting to be attached to the dispatcher. However, consider whether the MXT limit might be causing the performance problem, even though individual tasks are not being held up long enough for you to use CEMT INQ TASK on them. In such a case, use monitoring and tracing to find just how long tasks are waiting to be attached to the dispatcher.

Guidance about finding whether the MXT limit is to blame for the performance problem is given in MXT summary.

A task is taking a long time to get an initial dispatch

A task can be attached to the dispatcher, but then take a long time to get an initial dispatch. In such a case, CEMT INQ TASK returns a status of ‘Dispatchable’ for the task. If you keep getting this response and the task fails to do anything, it is likely that the task you are inquiring on is not getting its first dispatch.

The delay might be too short for you to use CEMT INQ TASK in this way, but still long enough to cause a performance problem. In such a case, use tracing or performance class monitoring for the task, either of which would tell you how long the task had to wait for an initial attachment to the dispatcher.

If you think your performance problem could be due to tasks taking a long time to get a first dispatch, read Why tasks fail to get an initial dispatch.

Tasks are getting attached and dispatched
If performance is poor and tasks are getting attached and dispatched, the problem lies with the dispatch, suspend and resume cycle. Tasks run, but the overall performance is poor. If you are able to show that tasks are getting attached and then dispatched, read Why tasks take a long time to complete.