One thing we found out the hard way was that the software charge for IBM products, under soft cap setup, can really get skewed -- e.g. -- say the charge for WAS is MSU based and it is active (runs) all day -- also say ,on average, it uses 80 MSU -- you then look at your SCRT at the end of the month and see WAS is being charged at 100 MSU.. how on earth is that possible Well, in our case we found that during the batch process, the CPU got pegged at 100 MSU (once a month is all it takes). You know what, just because WAS was active at the time the batch process was chewing up CPU -- you wind up paying for the max use of CPU for WAS too. All it takes is one CPU spike in any given month (SCRT reporting window).
Soft capping works great as it allows me to meet my SLAs but keep that in mind when you plan MSU based license charge. Regards, Jasbir -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Walter Medenbach Sent: Wednesday, February 13, 2008 5:47 PM To: [email protected] Subject: Re: Soft Capping Nothing wrong with restricting capacity to save on licensing costs. We use a coupling facility LPAR with dynamic dispatch disabled to control the amount of CPU available to the other LPARs on the machine. The zOS LPARs are all uncapped to allow each LPAR to use any unused capacity. Walter Medenbach On Feb 9, 2008 5:23 AM, Kelman, Tom <[EMAIL PROTECTED]> wrote: > This has been cross posted to the MXG list. > > > > At the end of last year I was asked to determine what would be practical > soft caps for our LPARs. We are currently at z/OS v1.7 so we can't cap > at the CEC level yet. Of course, the reason for the cap was to keep > software costs down, especially for the OEM software. We have an > agreement with most of our vendors that we won't use more than 110 MSUs > out of our 138 MSU box. My direction was that we didn't want the total > MSU 4HRA to go about 110. So I split 110 between the three LPARs we > have as equitably as I could based on a years worth of analysis. This > split came to 90 MSUs for production, 19 MSUs for development, and 1 MSU > for the sysprog sandbox. We have just hit the cap on development and > they are screaming blood murder because there are some deadlines to meet > for a conversion. So they want to increase the cap on development. My > suggestions were to take some from production and give it to development > or to just increase development since the high 4HRA for the individual > LPARs never occur at the same time. > > > > Now, after that explanation, my question. Has anybody had to cap their > machine by LPAR like this? If so, do you insure that the individual > caps would add up to some sort of specified limit, or did you set them a > little higher realizing that they probably wouldn't hit the max all in > the same day? Of course taking the second route will leave open the > possibility of going over the CEC 4HRA that you want (in our case 110 > MSUs). I'd appreciate any ideas anyone has on determining these caps. > > > > Please don't say that you're not in favor of capping to keep software > costs down. Neither am I so you'd be preaching to the choir. However, > as we all know, after all the recommendations you do what your told to > do. > > > > Tom Kelman > > Commerce Bank of Kansas City > > (816) 760-7632 > > > > > > > ************************************************************************ ***** > If you wish to communicate securely with Commerce Bank and its > affiliates, you must log into your account under Online Services at > http://www.commercebank.com or use the Commerce Bank Secure > Email Message Center at https://securemail.commercebank.com > > NOTICE: This electronic mail message and any attached files are > confidential. The information is exclusively for the use of the > individual or entity intended as the recipient. If you are not > the intended recipient, any use, copying, printing, reviewing, > retention, disclosure, distribution or forwarding of the message > or any attached file is not authorized and is strictly prohibited. > If you have received this electronic mail message in error, please > advise the sender by reply electronic mail immediately and > permanently delete the original transmission, any attachments > and any copies of this message from your computer system. > > ************************************************************************ ***** > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- 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
