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
