Bottleneck analysis as a methodology focuses on CPU usage. Removing bottlenecks enables threads to use more CPU per unit of time and complete faster. The individual execution states in the CPU usage group describe how much CPU the threads use and where (for example, CPU used in DL/I versus CPU used in the application program itself). All of these states are executing states—they are only experienced by threads actually running in the control region.
Note: Because of their importance, Bottleneck Analysis always displays the CPU Usage execution states, even when you use a label field character to restrict the display to a certain class of execution groups. See the OMEGAMON II for DBCTL Bottleneck Analysis Reference Manual for more information.
You can use the Using CPU states to infer activity which Bottleneck Analysis cannot measure directly. For example, a shift away from Using CPU toward Database I/O, in the absence of increased I/O contention, indicates that the databases being accessed may require reorganization. An abrupt, massive increase in Using CPU indicates a possible CPU hardware problem. For example, the cache buffer or the TLB may have gone out of service, and the message issued by the machine check handler may have gone unnoticed or been misunderstood.
Using CPU in APPL
The collector includes a thread in the Using CPU in APPL state when it finds the thread is actually executing instructions on a CPU. The program had no DL/I function in progress, so the collector ascribes its use of the CPU to application processing.
In a normal IMS system, this number will be small, even tiny, compared to the other execution states. However, this is one of the most important statistics you can watch because:
Almost every tuning trick increases this number (and decreases the total of the other execution states by the same amount). Indeed, a thread executing 100% in this state is not degraded at all in the Bottleneck Analysis sense of the term unless it is looping.
Almost every performance problem decreases this number (and increases the total of the other execution states by the same amount). For example, if I/O contention slows down an application’s access to a database, its execution profile shifts towards Database I/O and away from this execution state.