Introduction to CICS Timing Metrics and Analysis

Concepts that enable you to optimize the value you can derive from the nearly 100 timing metrics captured in the CICS Transaction data are introduced in this video.

More CICS Transactions Videos

1. CICS Timing Metrics – Overview
2. Transaction Response Time Analysis
3. Timing Analysis by High-Level Components
4. Response Time Analysis Scenario 1 Values Differing by System ID
5. Integrating WLM Performance Index and CICS Transaction Analysis
6. CICS Web Services Metrics
7. Overview of Non-timing Transaction Metrics

Video Transcript

Let’s go ahead and look at CICS Transaction data, the 110 subtype one. And, again, as we mentioned, that captures almost 400 discrete fields for each transaction, and of those approximately 100 of those fields represent timing buckets.

So, let’s begin our learning journey there. Now, unfortunately, all those timing buckets can be grouped into high-level categories to help facilitate the analysis. So at the highest level, total response time is equal to dispatch time plus suspend time. So, dispatch time, as the name implies, is the time a task is dispatched on a CICS TCB. So, you can think of that as the time CICS thinks the task is executing, and then that dispatch time can be further subdivided into two components. One is CPU time, the time the task is actually executing on the CPU, and then Wait time, the time that the CPU’s been taken away from the task or the region by zOS and CICS is not aware of that.

And so the CPU and weight breakdown enable calculation of a CPU to dispatch ratio. And that quantifies the extent to which z/OS is giving a CICS region access to the CPU when it has dispatchable work and we will come across that ratio later. The other top-level component is Suspend Time and that’s the time a task is not dispatched by CICS and thus is waiting. And the majority of the CICS timing buckets are components of suspend time. They break out the timings for each of the many reasons that a task can be waiting. So as this formula suggests a task is either dispatched or it’s suspended. So before that suspend time, it’s made up of these categories: Wait for First dispatch includes any waiting before the first dispatch, and that can include delays for Max task and T class limits, you know, which we’ve already talked about.

Most of the suspend time components are classified into either the I/O wait time, and that’s about 15 buckets or the other wait time, and that’s about 30 buckets. And then finally, any remaining suspend time that’s not captured in a discrete bucket as classified as uncaptured wait time. I want to say a word about the resource manager interface times. There are many of those buckets and significant portions of transactional lapse times can occur in the interfaces with resource managers like Db2, IMS, MQ and TCP, and CICS captures these times in multiple RMI elapsed time and suspend time buckets. And there’s an overall RMI suspend time field, and that’s a component of total suspend time. But there are other suspend time fields that can be incremented at the same time that that RMI suspend time is also being accumulated, and so that explains why the RMI suspend time is not a discreet component in the suspend time formula above.