Re: Chargeback reporting
Service units not only better reflect the work being done, but also gives us a better idea how that work could map to a different box. Considering that LSP is what derives service units, then I would say that you are incorrect. Service units are almost as meaningless as MIPS. (Yes, I know this is a late respomnse, but my BlackBerry was off the air for a while, and I am still catching up) __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at http://ca.toolbar.yahoo.com. -- 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
Re: Chargeback reporting
Agreed. Also, consider that the only Chargeback-related SMF data source providing service units is the SMF type 30 data for address space usage. Better to calculate and use a normalized (using a user-defined speed/conversion factor) CPU time metric, derived from the specific SMF / log data source. Scott Barry SBBWorks, Inc. -- 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
Re: Chargeback reporting
Agreed. Try including an extract from the post you're agreeing to. Or, at least the name. It makes this response easier to follow. Thanks. - Too busy driving to stop for gas! -- 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
Re: Chargeback reporting
Thomas Kern writes: There is a difference between the 'Intro to Chargeback' reports that lowly sysprogs might give to management as their first look at computer accounting and the high-powered What-If modeling done by capacity planning scientists trying to show the outcome of buying a zIIP this month and a zAAP next month and switching to that new z05 with accelerator J in six months. There is indeed, but unfortunately a lot of managers, especially by the time the data get circulated three degrees of separation and beyond, improperly interpret such data and act accordingly. So my caution was mostly to point out that it's critical that all such simple data get stamped inseparably with heavy but friendly disclaimers. Remember, they're not getting these data from any other systems. SMF is unique. I'm not suggesting burying the data, but the data consumers almost always need education. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [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
Re: Chargeback reporting
Thomas Kern writes: I would use CPU seconds rather than Service Units. Managers can understand that there are only 86400 CPU seconds per engine per day. If you can get the price paid for your z9, take 1/4 of that and divide by 365*86400 to get a price per CPU second. This would recover the cost of the z9 in 4 years. I've said this before, but just be very, very careful. What you're describing is a measure of the (medium-term) *average* (hardware?) cost per CPU-second. The average cost is very substantially different from the marginal cost of processing an additional CPU-second, which is much more nearly zero. Said another way, in capital investment economics marginal costs are almost always lower than average costs -- in mainframe economics much lower -- except perhaps at specific, individual price discontinuities (stair steps). For a price discontinuity example, if you're running a System z9 BC Model Z04, i.e. a machine with all CP capacity enabled, then the marginal cost of the next MIPS requires moving to an EC model and the associated upgrade expense. Nowadays mainframe computing arguably has fewer price discontinuities than distributed computing. Folks, it's super-critical managers understand this phenomenon. Otherwise you get all sorts of really weird and perverse behaviors.?) Honestly I don't think the average cost is particularly meaningful. Marginal costs are much more interesting and valuable. As a general rule, mainframe economics are characterized by decent (but steadily declining each year) initial fixed costs, low (and steadily declining each year) marginal costs, and progressively lower marginal costs as workload grows (the curve). There are some nuances for each major component of those costs (staff/services, hardware, software, and facilities/network), but that's the general rule by the time you add it all up. Your mileage may vary, but if that's not what you're experiencing it's worth investigating. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [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
Re: Chargeback reporting
There is a difference between the 'Intro to Chargeback' reports that lowly sysprogs might give to management as their first look at computer accounting and the high-powered What-If modeling done by capacity planning scientists trying to show the outcome of buying a zIIP this month and a zAAP next month and switching to that new z05 with accelerator J in six months. What is that sysprog going to be able to give his bosses and what requires a Capacity Planning Department stuffed with CompSci PhDs? Remember that guy was going to CODE it up himself. /Tom Kern On Thu, 5 Jun 2008 14:17:35 +0900, Timothy Sipples [EMAIL PROTECTED] wrote: I've said this before, but just be very, very careful. What you're describing is a measure of the (medium-term) *average* (hardware?) cost per CPU-second. The average cost is very substantially different from the marginal cost of processing an additional CPU-second, which is much more nearly zero. Said another way, in capital investment economics marginal costs are almost always lower than average costs -- in mainframe economics much lower -- except perhaps at specific, individual price discontinuities (stair steps). For a price discontinuity example, if you're running a System z9 BC Model Z04, i.e. a machine with all CP capacity enabled, then the marginal cost of the next MIPS requires moving to an EC model and the associated upgrade expense. Nowadays mainframe computing arguably has fewer price discontinuities than distributed computing. Folks, it's super-critical managers understand this phenomenon. Otherwise you get all sorts of really weird and perverse behaviors.?) Honestly I don't think the average cost is particularly meaningful. Marginal costs are much more interesting and valuable. As a general rule, mainframe economics are characterized by decent (but steadily declining each year) initial fixed costs, low (and steadily declining each year) marginal costs, and progressively lower marginal costs as workload grows (the curve). There are some nuances for each major component of those costs (staff/services, hardware, software, and facilities/network), but that's the general rule by the time you add it all up. Your mileage may vary, but if that's not what you're experiencing it's worth investigating. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [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
Re: Chargeback reporting
Different places adopt different philosophies. Having been the MVS chargeback administrator in the past, I can say that no method is perfect. My suggestion is to familiarize yourself with the research of those who have gone down this road before. A good place to start would be the Web site of the IT Financial Management Association http://www.itfma.com/. It would pay to own a copy of Chargeback and IT Cost Accounting, by Terry Quinlan, available at http://www.itfma.com/displaycommon.cfm?an=1subarticlenbr=10. db -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bri P Sent: Wednesday, June 04, 2008 6:48 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Chargeback reporting Hi all I want to send senior management a chargeback report each month - not actually to chargeback but to illustrate in pounds and pence what we're doing on the mainframe. Partly I hope to show that, overall, we're cost-effective per business transaction compared to some of the other processing platforms, etc.. and also to show the development people on a job-by-job basis what their big hitters are and identify targets for efficiency improvements etc (we're toying with the idea of signing up for sub-capacity licensing). Presumably I should use SMF type 30 records as a basis for this (rather than RMF records?) Would you use the values for CPU seconds, or those for service units? Regardless of which, do you take the totals of these, or just the CPU, SRB, etc? In arriving at a cost per CPU second or per Service Unit, What sort of financial inputs do people typically use? Our z9 was only purchased just over a year ago, so I assume the capital cost of that, written down over a period of years, should factor, plus the annual software costs and initial purchase prices, but also people costs..?? What about disk/storage usage, do you factor those in too? Sorry, probably a big topic, I know. If anyone's got any pointers to manuals or documentation on this sort of thing, I'd also appreciate it. Cheers! Brian - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- 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
Re: Chargeback reporting
I don't havean pointers to books or documentation but I can make a few suggestions. I would use CPU seconds rather than Service Units. Managers can understand that there are only 86400 CPU seconds per engine per day. If you can get the price paid for your z9, take 1/4 of that and divide by 365*86400 to get a price per CPU second. This would recover the cost of the z9 in 4 years. You can adjust this later depending on how quickly your management changes processors. You can do the same for DASD to get a residency price (pounds/pence per MB per day) but the scanning of your DASD and assigning ownership is usually more difficult than the CPU processing. For real chargeback, TAPE, Telecommunications, PRINT and backup/disaster_recovery processes should be factored into the bill but that is too much for any initial reports to management. Leave them out until your managers promote you to Head of Chargeback with a staff to do the detailed work. For your initial CPU reports, have two different reports ready, First for overall management, a report to show what groups use how much during some time period (consider being able to show usage on different days of the week). Second for the managers of the individual groups, a report to show who/what their top users are. /Tom Kern On Wed, 4 Jun 2008 11:47:55 +0100, Bri P [EMAIL PROTECTED] wrote: Hi all I want to send senior management a chargeback report each month - not actually to chargeback but to illustrate in pounds and pence what we're doing on the mainframe. Partly I hope to show that, overall, we're cost-effective per business transaction compared to some of the other processing platforms, etc.. and also to show the development people on a job-by-job basis what their big hitters are and identify targets for efficiency improvements etc (we're toying with the idea of signing up for sub-capacity licensing). Presumably I should use SMF type 30 records as a basis for this (rather than RMF records?) Would you use the values for CPU seconds, or those for service units? Regardless of which, do you take the totals of these, or just the CPU, SRB, etc? In arriving at a cost per CPU second or per Service Unit, What sort of financial inputs do people typically use? Our z9 was only purchased just over a year ago, so I assume the capital cost of that, written down over a period of years, should factor, plus the annual software costs and initial purchase prices, but also people costs..?? What about disk/storage usage, do you factor those in too? Sorry, probably a big topic, I know. If anyone's got any pointers to manuals or documentation on this sort of thing, I'd also appreciate it. Cheers! Brian -- 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
Re: Chargeback reporting
On Wed, 4 Jun 2008 07:19:26 -0500, Thomas Kern wrote: I would use CPU seconds rather than Service Units. Managers can understand that there are only 86400 CPU seconds per engine per day. If you can get the price paid for your z9, take 1/4 of that and divide by 365*86400 to get a price per CPU second. This would recover the cost of the z9 in 4 years. You can adjust this later depending on how quickly your management changes processors. You need to also divide by the number of processors in the box. Also consider that you can't bill for every CPU second. The system uses quite a bit. You might want to consider also the cost of environmentals such as floor space, power and cooling for the processor. Also the cost of the system software. Any application software is another story. -- Tom Marchant -- 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
Re: Chargeback reporting
That is a good approach, but IMHO CPU seconds are not a good metric for comparing upgrade options and paths. Service units not only better reflect the work being done, but also gives us a better idea how that work could map to a different box. Remember, the OP doesn't really want to charge for anything, but to somehow show the cost effectiveness of the solution. He can take the TCO of the shop, and divide by the SU capacity to set a base. Then prorate the costs using the SU consumption ratios of the applications. So, it costs us x to provide a maximum of a y level of service. Of that service, App1 consumes A%, App2 consumes B%, and so on. Note that we quickly move away from techospeak of CPU metrics to managementspeak of dollars/pounds and percentages. Hopefully our management can relate the applications to business units and then to each bottom line contribution. HTH and good luck. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Wednesday, June 04, 2008 7:19 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Chargeback reporting I don't havean pointers to books or documentation but I can make a few suggestions. I would use CPU seconds rather than Service Units. Managers can understand that there are only 86400 CPU seconds per engine per day. If you can get the price paid for your z9, take 1/4 of that and divide by 365*86400 to get a price per CPU second. This would recover the cost of the z9 in 4 years. You can adjust this later depending on how quickly your management changes processors. You can do the same for DASD to get a residency price (pounds/pence per MB per day) but the scanning of your DASD and assigning ownership is usually more difficult than the CPU processing. For real chargeback, TAPE, Telecommunications, PRINT and backup/disaster_recovery processes should be factored into the bill but that is too much for any initial reports to management. Leave them out until your managers promote you to Head of Chargeback with a staff to do the detailed work. For your initial CPU reports, have two different reports ready, First for overall management, a report to show what groups use how much during some time period (consider being able to show usage on different days of the week). Second for the managers of the individual groups, a report to show who/what their top users are. /Tom Kern On Wed, 4 Jun 2008 11:47:55 +0100, Bri P [EMAIL PROTECTED] wrote: Hi all I want to send senior management a chargeback report each month - not actually to chargeback but to illustrate in pounds and pence what we're doing on the mainframe. Partly I hope to show that, overall, we're cost-effective per business transaction compared to some of the other processing platforms, etc.. and also to show the development people on a job-by-job basis what their big hitters are and identify targets for efficiency improvements etc (we're toying with the idea of signing up for sub-capacity licensing). Presumably I should use SMF type 30 records as a basis for this (rather than RMF records?) Would you use the values for CPU seconds, or those for service units? Regardless of which, do you take the totals of these, or just the CPU, SRB, etc? In arriving at a cost per CPU second or per Service Unit, What sort of financial inputs do people typically use? Our z9 was only purchased just over a year ago, so I assume the capital cost of that, written down over a period of years, should factor, plus the annual software costs and initial purchase prices, but also people costs..?? What about disk/storage usage, do you factor those in too? Sorry, probably a big topic, I know. If anyone's got any pointers to manuals or documentation on this sort of thing, I'd also appreciate it. Cheers! Brian -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Re: Chargeback reporting
Agreed, Service Units are a better measure for full-fledged chargeback and capacity planning. They work very well with managers who already understand SUs. If your management is less than the IBM trained management, they might not understand Service Units at the beginning. The move from computer metrics to money metrics is an important one but it must not be sort of a hand wave. Managers need to understand WHAT they might have to pay for. When I first got told about Service Units alot of the systems programmers in the room did not get a clear handle on it and when I asked about Service Units for a VM customer, there were blank stares. We still did go with an accounting package for our MVS under VM that referenced Service Units, but I still had to use CPU seconds for the VM side of our workload. As an installation grows from chargeback introduction to full chargeback to capacity planning/modeling, Service Units are what are best. /Tom Kern On Wed, 4 Jun 2008 11:39:34 -0500, Hal Merritt [EMAIL PROTECTED] wrote: That is a good approach, but IMHO CPU seconds are not a good metric for comparing upgrade options and paths. Service units not only better reflect the work being done, but also gives us a better idea how that work could map to a different box. Remember, the OP doesn't really want to charge for anything, but to somehow show the cost effectiveness of the solution. He can take the TCO of the shop, and divide by the SU capacity to set a base. Then prorate the costs using the SU consumption ratios of the applications. So, it costs us x to provide a maximum of a y level of service. Of that service, App1 consumes A%, App2 consumes B%, and so on. Note that we quickly move away from techospeak of CPU metrics to managementspeak of dollars/pounds and percentages. Hopefully our management can relate the applications to business units and then to each bottom line contribution. HTH and good luck. -- 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
