I agree that capping a shared (Production) CF could be dangerous, and I have a 
hard time imagining a configuration where I would consider such a thing.

>>> Joel Wolpert <j...@perfconsultant.com> 08/08/09 12:36 PM >>>
I agree that ones has to make intelligent decisions based upon their 
environment. I do not endorse capping a shared CF, but if you do not have 
the available CPU capacity to dedicated a full CP it might work. However, 
you have to be careful or else you can kill production.

----- Original Message ----- 
From: "Scott Rowe" <scott.r...@joann.com>
Newsgroups: bit.listserv.ibm-main
To: <IBM-MAIN@bama.ua.edu>
Sent: Saturday, August 08, 2009 11:44 AM
Subject: Re: DASD: to share or not to share


>I do not cap my CF LPARs, except that they are limited to only 1 CP.  I 
>define a weight such that they are guaranteed a full CP, yet they never use 
>a full CP, since they are using dynamic dispatching.  This configuration is 
>not going to hang my production LPAR, and I believe it is silly to suggest 
>such a thing.
>
> Would I get better CF response time if I had dedicated CPUs for the CFs 
> (ICF or CP)?  Yes, of course.  Would I try to do DB2 data sharing in this 
> configuration?  No, of course not.  One has to make informed intelligent 
> decisions in this business, isn't that our job?
>
>>>> "Gibney, Dave" <gib...@wsu.edu> 08/08/09 3:27 AM >>>
>
> Does not "cap it CF LPAR" ask for or equal "hang production LPAR(s)"
> waiting for CF response?
>
>
> CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
> confidential and privileged information intended only for the addressee. 
> If you are not the intended recipient, please be advised that you have 
> received this material in error and that any forwarding, copying, 
> printing, distribution, use or disclosure of the material is strictly 
> prohibited.  If you have received this material in error, please (i) do 
> not read it, (ii) reply to the sender that you received the message in 
> error, and (iii) erase or destroy the material. Emails are not secure and 
> can be intercepted, amended, lost or destroyed, or contain viruses. You 
> are deemed to have accepted these risks if you communicate with us by 
> email. Thank you.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to