I simply have to wade in here, having dealt with capacity planning since 1965. And, yes, we did CP back then.
Regarding SI versus MI, I think the question has been answered here. But the reason that IBM started publishing multi-image estimates is that the majority of customers run multiple LPARs, which carries some amount of overhead. The single-image estimates gave too optimistic a view of potential capacity. If you truly run a single image, then use the SI values. This thread has discussed two different parts of CP. The first part is non-negotiable and by far the hardest to handle - it's the estimate of the change in workload. That's an entire book on techniques, but the most important is talking to the customer about their plans. For example, does the claims department plan to add more reviewers because the load is expected to increase by 15%, or is the sales department adding remote offices. While it helps to predict growth based on the past, it's more important to understand the driving force behind the changes due to business requirements. Because CP is often added to the sysprog's duties, this part of CP is often neglected. The second part of CP is understanding the capacity of both the current and the potential new machines. I'm apparently one of the few in this thread who believe in MIPS. I do that because management believes in MIPS, and you have to give them what they want. It's the closest metric we have to understanding the capacity of different machines. Just be sure that you realize there is no such thing as a value of MIPS for a machine; there are values of MIPS for different kinds of workloads. If you run 60% CICS and 40% batch, you might need to come up with a combined MIPS that is 60% CICS MIPS and 40% batch MIPS. (I've simplified this for this discussion; the workloads aren't that well defined any more.) IBM spends a lot of time running benchmarks and attempting to show customers what they might expect when moving to a new machine. Part of that information is published in the LSPRs (Large Systems Performance Reference - https://www-304.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprindex?OpenDocument). The results of the benchmarks are shown in both the LSPRs and zPCR. But zPCR has additional information that isn't published, such as the impact of additional LPARs. For both tools, however, you need to understand the makeup of your own workloads, because they may not match IBM's benchmark workloads. I strongly believe that you cannot do a proper job of capacity planning without using zPCR, and for the new processors you should be collecting the 113 SMF records to better understand the storage access of your workloads. Most of the knowledge from the benchmarks has been put into zPCR. And it's the ONLY tool I know of that will give you a reasonable estimate of what to expect. The results can be shown in any manner you want such as MIPS or relative change. Most people use MIPS because it's something they and their management can relate. Even though we publish MIPS in our CPU Charts, we suggest that people use them to find possible candidates for the capacity they might need (which zPCR doesn't do). But then we tell them to use those potential machines with zPCR to see how each machine will handle the workloads. Even then, the capacity might be wrong, but if you've run zPCR first, then IBM will help you find the combination that works. Just remember that zPCR is an estimate. You still need to confirm that you received the capacity you expected. You don't want to run into the situation where you need another upgrade the next week. While some sites use a standard set of jobs that they run on a new machine, I've always thought that you should look at all the stable jobs, not just a select group. That's why in 1987, I started using a technique described by Joe Majors that finds stable job steps or transactions using CPU per I/O and compare them before and after the migration. (Now here's where I'll probably get into trouble with the moderator...) That technique is the basis of our software product, BoxScore, which does that comparison. The results from our BoxScore customers shows that zPCR results are really excellent on average, but there are some workloads that don't seem to be represented in IBM's benchmarks. Those are the workloads that bite you. Best regards, Cheryl ====================== Cheryl Watson Watson & Walker, Inc. www.watsonwalker.com 941-266-6609 ====================== On Nov 23, 2010, at 5:16 PM, Ted MacNEIL wrote: > That may be all well and good in your environment, but there are many in > management at many shops who want capacity boiled down to a simple number. I never said I've been blessed with management more enlightened than that. The one number is still an issue. > If you say that it is more complicated then that, then they will just use it > as yet another reason to get rid of the mainframe. If you have not had the > pleasure of working with this "new wave" of IT management you are lucky. I've tried to be accurate. Spending cash on nebulous ratings is a great way to risk the business and spend on abitrary ratings. It scares me that software decisions are based on crap evaluations. - Ted MacNEIL [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
