Art, In my experience, GRS-Star with shared CP CFs is still significantly faster (at least one order of magnitude) than GRS Ring using XCF. Also, the purpose for the extra CF can be used to upgrade CF code without a Sysplex outage. I guess it's also remotely possible that a CF code fault could cause a CF failure, though I have yet to see this. I keep a second CF running for this purpose, though I don't currently have any active structures in it. Scott
>>> Arthur Gutowski <aguto...@ford.com> 12/7/2009 9:25 AM >>> I also don't see which LPAR's are part of the Sysplex, and which are not. Dynamic Dispatch with a CF LPAR is not so much a matter of utilization, but as Scott suggests, getting the CPU when the CF needs it. We have found that DynDisp dramatically increases ISGLOCK response times (at least one order of magnitude) - and we have characterized CF engines. I cannot imagine how much worse this would be if we had to share with MVS images, too. IMHO, if A and B are the only ones in the Sysplex, the parallel sysplex does not give you significant advantage in and of itself in this configuration, unless of course, you have it for pricing considerations. Yes, GRS Star (parallel sysplex required) does perform better than Ring, even in a two-system complex, but without dedicated CF engines, my gut tells me you are losing whatever ground Star gives you. If A, B, C and D are all in it together, then IMHO, seriously consider funding and characterizing an ICF CP. Also, if they are, and since you are on a single footprint, I do not see the advantage of two CF LPARs for a single complex. If an internal CF goes down, it's either because your Operators need to be more astute, or there is a serious hardware problem, which probably means the whole machine is down. When our European counterparts tried to implement Star a few years back, they found this out empirically, also notwithstanding the added CPU demand buried their already-taxed z990. FWIW, Art Gutowski Ford Motor Company On Fri, 4 Dec 2009 14:33:18 -0500, Scott Rowe <scott.r...@joann.com> wrote: >Certainly, SYSA can take unused cycles, they are distributed according to weights. What you haven't said is what mode your CFs are running in, so I will assume the are dynamically dispatched. The thing you need to be very careful about here is that the CF partitions can get the cycles they need when they need them. According to your calculations, your CF partitions are promised 100 and 36 MIPS respectively - but is that enough? I prefer to over- weight CFs that run on shared CPs, since it helps ensure that the CF has access to the CPU when it needs it. If there are many CF requests and not enough available cycles to service them you could get in trouble quickly. > >>>> John Mitchelle <john.mitche...@googlemail.com> 12/4/2009 11:57 AM >>> >Hi, > >I have 936 MIPS processor Z02-2096 z9BC > >I have 4 LPARS and 2 CF LPARs > >SYSA (Prod) > >SYSB (Dev) > >SYSC (Test) > >SYSD (Maint) > >SYCF1 > >SYCF2 > >Both CPU Engines are online across all LPAR's. > >Wts are in such a way that MIPS Allocation are > >650 for SYSA > >50 for SYSB > >50 for SYSC > >50 for SYSD > >100 MIPS for SYCF1 and > >36 MIPS for SYCF2 , > > >SYSA is UNCAPPED and SYSB, SYSC and SYSD are CAPPED. > >Recently we are having issues related to MIPS capacity. > >I am aware that in case SYSA needs more capacity then it can take from >SYSB,SYSC,SYSD if available. > >However, was wondering whether system will allow to take MIPS from >Coupling Facility LPAR's as well or not if available ? > >These are the structures in use for CF > >ISGLOCK >IXCXCF1 >IXCXCF2 > >Is there any advantage in getting rid of these coupling facility ? >Will that give us comfort ofhaving these additional MIPS ? ---------------------------------------------------------------------- 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
