1. SHARE in Boston Presentation
2. The Charge Back Normalization Myth
1. SHARE in Boston Presentation
SHARE in Boston was my best SHARE week ever! On Monday morning during the general meeting and keynote, I received two awards – The President’s Award (which came as a big surprise and a great honor) and a Best User Session award for my presentation last February. And then, on Thursday, I received a pin and award for 35 years of volunteering at SHARE. It doesn’t seem like that long ago! I had a beam on my face all week long.
The learning experience was wonderful, of course, with all of the details on z/OS 2.1 and more information on the zBC12, as well as the zEC12 enhancements. Obviously, our paid Tuning Letter subscribers will hear a lot about this in the coming newsletters. On Friday, I gave the second presentation in my series of ‘Exploiting z/OS – Results from the SHARE Survey’. You can find this presentation and the first part (that received the Best Session award) at no charge on our website under ‘Presentations’ – www.watsonwalker.com/presentations.html. One of the topics I discussed in my session has to do with user experiences who have recently moved to new processors. See the next item.
2. The Charge Back Normalization Myth
zPCR
I believe that running IBM’s Processor Capacity Reference, zPCR, tool is one of the most important steps you can take before making any processor upgrade. This is a no-charge PC tool to predict the expected MIPS after a change in hardware or configuration. (See www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS1381.) If you’re a Tuning Letter subscriber, you know that I trust and believe in zPCR’s capacity estimates. zPCR uses the same Large Systems Performance Reference (LSPR) ratios that we use for our CPU Chart. (See www.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprindex?OpenDocument.)
Speed is the capacity of a single CP, while capacity refers to all of the CPs. Speed generally determines the amount of billable CPU time that a workload will take. As an example, you might be going from a 1000 MIPS 5-way to a 1000 MIPS 2-way. The capacity remains the same, but the speed of each CPU changes from 200 MIPS to 500 MIPS. The new processor is 2.5 times faster, so will take less billable CPU time.
In most chargeback situations, the charges are based on either service units or a site-determined normalized CPU factor. Of course service units are simply IBM’s normalization based on their average LSPR benchmarks. This means that if your workload doesn’t match the average LSPR workload that your service units per second will not be appropriate for your workload. This is one more example where service units may not give you the results you’re looking for.
How do people come up with a normalization factor? It varies. Some sites use the LSPR ratios, others use our CPU Chart, while others have their own set of benchmark jobs. (The last technique is usually the least reliable.) But many sites today, because of encouragement from IBM and from us, use the ratios provided by zPCR. zPCR, for example, might tell you that the speed of the new machine will give you a 10% reduction in CPU time. So you might add a 10% factor into your chargeback algorithm. This has worked for several years, but in the last few years, it’s fallen apart. I’d like to explain what I think it happening. (Usually I reserve these longer articles for our newsletter subscribers, but this is so important that I’d like everyone to hear about it.)
What Has Changed?
We’ve been receiving emails from customers who are getting more speed and, therefore, more capacity out of their new machines than zPCR predicted. During the SHARE conference, several people indicated that they were seeing the same thing. Workloads that had not changed were using fewer service units after a processor upgrade. This is a major problem when a site charges back on CPU time or service units. Some outsourcers are being caught with lower revenue after spending thousands of dollars to upgrade their machines.
It’s important to note that zPCR is designed to estimate the speed and capacity of machines that have no bottlenecks. That implies that the original configuration and the new configuration have no paging, and there are no major I/O delays.
A site normally upgrades when the system is starting to get constrained. And most upgrades these days include much more than just the processor. A processor upgrade might also include more memory, changing from ESCON to FICON channels, upgrading a storage controller with more cache and facilities, changing the speed of the coupling facilities, adding or changing the zIIPs and zAAPs, changing the use of HiperDispatch, or using other new hardware facilities such as zFlash. The site is normally moving from a constrained system to an unconstrained system. (This seemed to be true of most of the installations that indicated their processors were faster or had more capacity.) Each of these upgrades could reduce the CPU time used by a workload that otherwise did not change.
The result of these multiple changes is that the CPU time is lower than predicted by zPCR, and the use of a chargeback normalization factor based on zPCR will result in lower charges. The customer of an outsourcing company will be thrilled, but the outsourcer will see reduced revenue. It’s actually a disincentive for outsourcers to use newer technology.
But it’s not always that way. There are technology and configuration changes that actually cause the CPU usage of workloads to increase. If you add an LPAR, or add a new function such as zAware, there could be increased bills to the customer.
The fact is that any type of change to hardware, software, or configuration can result in a change to billable CPU time. zPCR will give you an estimate of how it expects the CPU speed to change, but it doesn’t know what else has changed.
What’s the Solution?
If you’re billing (or receiving invoices) based on CPU time or service units, you need to determine the actual change in normalization factor for your billing methodology. We created our BoxScore software product several years ago to provide this normalization factor. Many of our customers, including outsourcers, use BoxScore both to provide the normalization factor for billing, and also to identify the changes in the configuration which have affected the results. These changes include changes in memory, number of LPARs, weight, number of CPs in each LPAR, CPU utilization, software release, HiperDispatch, and other factors.
Having the information come from an independent third-party provides a high degree of confidence in both the outsourcers and their customers. When you look at the BoxScore results, one of the things you’ll notice is that not all jobs or transactions see the same amount of change in CPU time from a change to the configuration. But BoxScore will be able to tell you the exact change for each unit of work. Instead of dealing with customer outrage after they see an increased bill because of a change you made, you can identify immediately the impact of every change. Instead of losing revenue because you bought new equipment, you can show your customers what they gained. I am always happy to help you analyze your results if you have questions.
You really shouldn’t be without this valuable tool! The cost is only $11,900 for the first year, with a nominal annual maintenance fee thereafter. For more information, including sample reports, please see our website at www.watsonwalker.com/boxscore.html. You can also contact me directly by email or on my cell phone – 941-266-6609 (Florida time).
Stay Tuned!