> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Joel Wolpert > Sent: Friday, August 07, 2009 12:17 PM > To: [email protected] > Subject: Re: DASD: to share or not to share > > You can configure it so that it is not always polling, and therefore not > soaking up the CPU. In addition, you can set up an lpar weight and cap the
Does not "cap it CF LPAR" ask for or equal "hang production LPAR(s)" waiting for CF response? > ICF lpar. This will also prevent the ICF from consuming more of the CEC > than > you want. All of this being said: I would not recommend that you share a > CF > with the production lpars. If someone changes the config of the CF you > might > end up with a performance problem. > > ----- Original Message ----- > From: "Gibney, Dave" <[email protected]> > Newsgroups: bit.listserv.ibm-main > To: <[email protected]> > Sent: Friday, August 07, 2009 2:12 PM > Subject: Re: DASD: to share or not to share > > > >> -----Original Message----- > >> From: IBM Mainframe Discussion List [mailto:[email protected]] On > >> Behalf Of Scott Rowe > >> Sent: Friday, August 07, 2009 8:51 AM > >> To: [email protected] > >> Subject: Re: DASD: to share or not to share > >> > >> Heck, I just use a CF partition running on my shared CP. As long as > > you > > > > I've heard lots of scary stories about sharing CPs for CF. I understood > > the CF code was basically a non-terminating loop. > > > > I've even heard of folks using a CF lpar as a MSU soaker to keep z/OS > > MSU's down for SCRT purposes. > > > > I certainly don't want any hang of my production system because I shared > > with a CF. > > > > > >> are only doing GRS, and maybe HSM CRQm etc, there is no problem. My > > two > >> CF partitions combined average about 0.2% of my CPUs. It may not be > > as > >> fast as dedicated CPs, but it is still faster than GRS ring. > >> > >> >>> "Gibney, Dave" <[email protected]> 08/06/09 5:23 PM >>> > >> When ICF's are free, maybe we'll consider it :) I share resvols and > >> other volumes with software load and other read only type operational > >> data between some or all of our 4 LPARs with no appreciable impact. > >> > >> Dave Gibney > >> Information Technology Services > >> Washington State University > >> > >> > >> > -----Original Message----- > >> > From: IBM Mainframe Discussion List [mailto:[email protected]] On > >> > Behalf Of Chase, John > >> > Sent: Thursday, August 06, 2009 12:32 PM > >> > To: [email protected] > >> > Subject: Re: DASD: to share or not to share > >> > > >> > > -----Original Message----- > >> > > From: IBM Mainframe Discussion List On Behalf Of McKown, John > >> > > > >> > > [ snip ] > >> > > > >> > > A basic SYSPLEX (what we are running) does not require a Coupling > >> > Facility (CF). With a CF, you have a > >> > > Parallel Sysplex, which has some better facilities. If you only > > have > >> > an single CEC (box), then you > >> > > don't need a Sysplex Timer, either. And, if you're on a single > > box, > >> > you could get an CFL speciality > >> > > engine and run a single CF in a separate LPAR. In this case, there > >> is > >> > no cabling required - it used > >> > > "pseudo cabling" via the PR/SM hipervisor. Much like hipersockets. > >> > > >> > You must be wishing really hard for an IFL. :-) > >> > > >> > The "Integrated Coupling Facility" engine is an "ICF" (more overload > >> > for > >> > ICF). > >> > > >> > -jc- > >> > > >> > > > ---------------------------------------------------------------------- > >> > 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 > >> > >> > >> > >> 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 [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 ---------------------------------------------------------------------- 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
