Response time analysis scenario leveraging CICS Transaction metrics in combination with WLM service class performance index data to identify the cause of missing WLM goal during a specific time interval.
More CICS Transactions Videos
- CICS Timing Metrics – Overview
- Transaction Response Time Analysis
- Timing Analysis by High-Level Components
- Response Time Analysis Scenario 1 Values Differing by System ID
- Integrating WLM Performance Index and CICS Transaction Analysis
- CICS Web Services Metrics
- Overview of Non-timing Transaction Metrics
All right. One other thing from looking at the response time data we’re going to see later, but there is a workload manager service class where almost all the transactions do better than the goal of 90% under 325 milliseconds, except for around 7:00 PM. So this is an interesting situation here. Let’s go ahead and filter this by the transaction response time, filter this particular view, and I only want to look at the transactions that are greater than or equal to 325 milliseconds.
So, when we do that, we find out that there are basically three transactions, three of the high volume transactions that exceed that as their response time pretty frequently. And I just moused over them, and I’ve got a note here in my notes for that.
Okay. So now let’s go ahead and look at the transaction volume and we still got that filter in place. So this is only those transactions that are averaging exceeding 325 milliseconds. So let’s go ahead and make that a timeline chart. And when we do that, we see we have a very high volume of one of those transactions. That’s a very long running transaction that spiked at that particular time when that WLM service class goal is being missed. So let’s go ahead and I’m going to remove the filter here, and then I’m going to zero in on that time interval. Basically, the interval before the inter and the interval immediately after those three intervals and look at the transaction volume specifically during that time period. And then, since we’re looking at the mix of transactions, we want to see that as a pie chart. So when we do that, we see that that particular transaction is almost 10% of the total mix during that time. So, it’s tough to make a 90% goal when the volume of a very long-running transaction represents 10% of the total transaction. So here again, the transaction timing data sheds light on what’s happening in the system.
So the 72 data in addition to CPU consumption by service class, which can also be of interest that also captures, the WLM performance index PI, which reflects the degree to which a service class is meeting its goal. So here in this environment, we see that there are different goal types for the work going on with CICS, often production CICS regions, or in service classes with execution velocity goals, and then production high volume transactions are often found in service classes with percentile goals. And we see both types of service classes here.
So, first let’s look at the velocity goal, look at that by service class or just a single service class. And we drill in and so for that service class, the velocity goal is 72. And usually, the velocity is above that which means you’ve got a performance index of less than one, but during a few of these intervals here, the velocity dipped below 72 and thus the performance index was greater than one. Let’s go ahead and capture that in our dashboard.
All right. So, in WLM for velocity goal service classes also reports on the using and delay samples. So we’ll look at that here. And usually when looking at those samples, using CPU and delay CPU are of the most interest. All right, now let’s look at the percentile goal, and there are two service classes, but almost all the transactions in this environment execute in this second service class. So let’s focus in on that. We can see that for most of the day, it far exceeds the performance index, but there are some time intervals around seven o’clock where it does not.
So, let’s examine that in a little more detail again, look at the CICS by service class, and we’ll look at that service class by the percentile distributions, which is how a workload manager manages the performance index for service classes with a percentile goal. So we can see that this service class has a goal of 90%, less than 325 milliseconds. And for most of the day more than, you know, 90 plus percent of the transactions are finishing not only in that number but in less than half of that number. So, you know, 160 or less milliseconds, but for a few intervals around that seven o’clock hour, it’s falling below 90%. And thus the performance index is above one. So those are the intervals that we saw earlier, where the volume of long-running DWWS transaction surge to become almost 10% of the overall mix. So tough to make a 90% goal when you’ve got a very long-running transaction that makes up almost 10% of
your mix. So that’s a good example of how the systems workload manager data and the CICS transaction response time data can really compliment each other and fill in and tell the story of what’s going on.
Speak to a Technical Expert Today
Whether you are conducting product research, need support on a project, are experiencing downtime, or want to learn more about how IntelliMagic can support your business, our experts are here to help.
You May Also Be Interested In:
CICS Web Services Metrics
Introduction to Web Services insights available from CICS Transaction data that can facilitate collaboration between infrastructure and application teams.
Overview of Non-timing Transaction Metrics
Overview of several types of non-timing transaction metrics captured in CICS Transaction data.
Response Time Analysis Scenario 1 Values Differing by System ID
CICS response time analysis scenario where insights into the causes of variances across z/OS systems can be quickly derived from isolating the components driving the differences.