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