There are many reasons for tuning your mainframe applications. Surely the most important reason is to provide faster access to your end users. The quicker an application responds, the happier the people that use it will be. But a close second is likely to be cost reduction.
Unfortunately, tuning to achieve cost savings is frequently undertaken without a good understanding of just how mainframe costs are calculated. Or at least the major contributor to those costs, which is your monthly software bill. So, instead of focusing on tuning programs that run in workloads that contribute to the peak rolling four-hour average (R4HA), tuning efforts are applied to programs that consume the most resources. And sure, tuning those programs is a good idea, but it might not really provide you much, if any, cost savings.
Focusing on Monthly Peaks
Recall from my earlier post that IBM MLC software is billed monthly based on the peak R4HA utilization for the month. For example, if you run Db2 for z/OS in one LPAR and that LPAR reaches a peak R4HA utilization of 120 MSUs on the last Friday of the month at 2:05 AM, then your monthly charge for Db2 would be based on 120 MSUs being used.
It is important to understand that the R4HA is for the entire LPAR and not just Db2, so tuning anything that runs within the four-hour span around 2:05 AM on the last Friday of the month can possibly provide cost savings.
It is also essential to understand that there will likely be multiple peaks for you to tune. Each LPAR and combination of LPARs with MLC products running in them can have a different peak R4HA for the month.
To find the peak utilization times that you should focus on to tune for cost savings, consult the SCRT report, which is produced each month and delivered to IBM to calculate your software bill. The P5 section of the SCRT report will break down the products that contribute to your bill, the LPARs where they run, the peak R4HA utilization for the month, and the date and time that peak occurred.
Consider the following example SCRT report:
Here we see several peaks at different date/time combinations. Tuning for any of the following peaks makes sense if you are looking to reduce costs:
• 03 Oct 2012 – 14:00 : workload running on LPAR2 and LPAR3
• 04 Oct 2012 – 10:00 : workload running on LPAR2
• 06 Oct 2012 – 11:00 : workload running on any of the three LPARs
• 09 Oct 2012 – 15:00 : workload running on LPAR1 and LPAR3
It doesn’t matter what the programs running during these peak timeframes are doing, just that it runs around that peak time and on the specified LPARs. You do not have to focus on the absolute peak time; remember, it is a four-hour rolling average. So, anything running at the peak hour and the trailing 4 hours is fair game for tuning to reduce cost for each of your peaks.
Tuning Peak Workload
Given the timeframes from the SCRT report, you can now utilize your capacity planning tools and performance monitors to determine the programs that were running within the four-hour timeframe of the peak. Once you have identified programs to focus on, you can take any number of standard tuning tactics to reduce their CPU consumption, such as:
• Improving the algorithms to improve data access and processing
• Caching data to reduce the CPU overhead of I/O
• Tuning SQL for Db2 programs to improve access paths
• Redirecting workload to zIIPs by using distributed SQL, parallel queries, or other approved methods of running SQL on zIIPs
• Converting COBOL programs to Java to make them eligible to run on zIIPs
These and other methods to reduce CPU usage can work to reduce the MSU consumption during your monthly R4HA peaks.
Whacking Moles
Most of us remember the arcade game whack-a-mole, wherein you are given a mallet and instructed to hit the moles that appear out of the many holes on the game board. Hit one mole, and another pops up that needs to be taken care of. Tuning the mainframe workload for cost savings can have a similar effect. Performance can be a never-ending game of whack-a-mole as you work to reduce your monthly software bill consistently.
Consider the scenario we just walked through. We identified four (4) peaks to tune. Assume that we found appropriate programs that ran during those timeframes that we could tune. What happens to our next monthly bill?
Well, the next SCRT report will identify the next highest peak(s) for your combination of products and LPARs being used. And you likely will have a different set of peak times to attack with tuning efforts. But will you have saved any money?
It all depends on the workload you run. You may have saved a significant amount or not much at all. For example, assume that by tuning the workload that ran during the 06 Oct 2012 – 11:00 peak (all three LPARs), we reduced the MSUs consumed in that timeframe from 98 to 88. Did we save 10 MSUs on our bill? Probably not. Why?
The SCRT identifies the next peak, which may be at a completely different date/time. So perhaps on the next day (or the next hour), you consumed 97 MSUs across those three LPARs. So, you saved one (1) MSU by whacking that first mole, but another one has popped up!
Of course, it all depends on your shop and the workloads you run. If the peak for the combination of all three LPARs continues to be at the same date/time, then you may have indeed saved 10 MSUs. But it is expected that the next peak will be close to the last one, so you must keep whacking those moles to reduce your bill iteratively.
The Bottom Line
Of course, every little bit helps. Even a one (1) MSU reduction can have an impact as it is against a recurring monthly bill. And eliminating one peak identifies the next peak to tune. I guess the bottom line is this: keep on whacking those moles!
© 2022 Craig S. Mullins
Find Out More
Learn more about zIIP.