Re: Posting From [email protected] on Fri, 11 Sep 2009 20:50:31 +0200
> Well. I thought the rules are slightly different: it is enough to > run some product ONCE during reporting period (month) to pay for > that. More precisely: if you run ABC product on LPAR1 (only) and > LPAR1 highest usage is nnn MSU then you pay for product ABC as it > would consume nnn MSU on that LPAR. And it doesn't matter that you > ran the product only once, 3 days before the peak occured. (This is > what I heard from IBMer, however I consider him as an oracle. ) One of the differences between a product which does cut SMF89 records and one which does not is how sophisticated SCRT can be when determining the peak rolling 4-hour average (R4HA) utilization to assign to it. For products which do cut SMF89 records SCRT is able to "know" which hours it was running and which it was not, and thus is able to assign the peak R4HA for the LPAR(s) in which it is running when it was running there, and not choose the peak when the product was not running. A product which does not cut SMF89 records (a.k.a. a "NO89" product) will be assumed to be running in the identified LPAR(s) any time that z/OS is running there. So, for example, let's say that CICS normally runs in LPAR1, but it does not always run there. If LPAR1 peaked at 9am Monday 31 August at 300 MSUs but CICS was not running then, CICS would not be charged 300 MSUs. SCRT would look at the R4HA for LPAR1 throughout the month specifically for the hours when CICS was running, and pick that peak R4HA value. It might help to imagine drawing a graph of the R4HA of LPAR1 for the whole month. Then imagine taking an eraser and erasing the parts of the graph for the hours when CICS was not running (and not cutting SMF89 records). The high point of what was left of the graph is the peak R4HA for LPAR1 when CICS was running, and that is what SCRT will assess for the bill. Maybe CICS would end up being charged 295 instead of the 300 which would be charged for z/OS. For NO89 products the MSUs assigned for billing will simply be the peak R4HA for the month of the LPAR(s) identified by the user as where the product ran that month. This case matches the example described in the original post. I like to avoid the verbs "consumed" or "used" when describing SCRT and sub-capacity pricing because that actually is not what the measurement is based upon. Sub-capacity charges are based upon the LPAR utilization of the machine, not upon product usage. In the example above, CICS did not consume 295 MSUs. CICS is charged 295 MSUs because the peak R4HA of LPAR1 for the hours of the month when CICS was running happened to be 295 MSUs. Other things were probably running in LPAR1 at the same time CICS was during that hour, the R4HA value of 295 is not due solely to CICS. Especially because that 295 is a smoothed average including LPAR1 activity from the previous 3 hours, who knows, maybe CICS wasn't even running in LPAR1 in those previous 3 hours. I hope this helps as opposed to making it more confusing... -- David J. Chase, WW System z Software Sales -- -- IBM 18th Fl, 11 Madison Ave, NYC, NY 10010 -- -- 917-472-3346 - dchase at us.ibm.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
