external vs internal coupling facility
We have an external coupling facility that is only used about 2%. We have four LPARs on an 890 with 3 shared general purpose engines and one IFL for VM/Linux, so all engines accounted for. We have been requested to create a production coupling facility LPAR that will share the general purpose engines. It will replace the external CF, thus saving money in maintenance, etc. The plan is to give it a weight of 500 with a second 500 being split between the other LPARs. Dynamic dispatch will be set on for the CF LPAR. The other business LPARs have MSU soft capping enabled, if that matters. IBM documentation says do NOT set dynamic dispatch on with shared engines (even IFLs) for a production coupling facility. Has anyone else tried this and what was your success or failure in the attempt? Thanks. -- 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
Re: external vs internal coupling facility
>We have been requested to create a production coupling facility LPAR that will share the general purpose engines. It will replace the external CF, thus saving money in maintenance, etc. I wouldn't touch that environment with a 15-foot Ukranian! The first time productivity goes south because of poor response, time-out, etc., who is going to be blamed? BTDT! GTTS! DWTDIA! Let's all say this together: "Sharing CF's with anything is BAD!" PS: Response will probably go balistic within 10 seconds of a load hitting the environment. I hope you're saving enough to augnment your productivity hit! - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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
Re: external vs internal coupling facility
From: "Frank Leblanc" > > We have been requested to create a production coupling facility LPAR that > will share the general purpose engines. > It will replace the external CF, thus saving money in maintenance, etc. M - everyone's at the mercy of "bean counters". > Has anyone else tried this and what was your success or failure in the attempt? Works fine. Whether it's what you really want is another question. The z/Architecture machines basically handle things themselves, with requests being converted to async dynamically. Will play merry hell with CF response times: - Datasharing would be a no-no, but you know that already. - for the GRS Star numbers, you can probably just move the decimal point. Hopefully just once, maybe twice - I'll let you guess in which direction. Converting back to ring mode is another option - m. - some you couldn't care less about, like LOGREC. Make sure you have all your RMF data available for some comparisons after the fact. Won't help then, but may give you ammo for future fights. Shane ... -- 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
Re: external vs internal coupling facility
We also moved from standalone CF to ICF for financial reasons. But our management had the foresight to spring for some ICF engines in the process. They reasoned that enough money would be saved just on maintenance to justify the extra CPs. An additional saving for many shops is memory. Unused/unusable memory in a standalone CF can now be pooled with MVS memory. That is, external CFs need memory installed in whatever increments the hardware requires regardless of how much is needed for CF LPARs. We had to over-buy memory because if we ran out, only an upgrade could relieve the shortage. With ICF, memory can be allocated into or out of other LPARs in order to more precisely satisfy structure requirements without wasteful overkill. Adjustments can be made with nothing more disruptive than bouncing a couple of LPARs. In other words, try hard to sell the idea of at least one ICF CP--which can be shared among LPARs under favorable conditions. You will still save money by eliminating footprint(s) without tossing performance into a tar pit. . . JO.Skip Robinson Southern California Edison Company SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] IBM Mainframe Discussion List wrote on 02/17/2006 02:41:51 PM: > From: "Frank Leblanc" > > > > We have been requested to create a production coupling facility LPAR that > > will share the general purpose engines. > > It will replace the external CF, thus saving money in maintenance, etc. > > M - everyone's at the mercy of "bean counters". > > > Has anyone else tried this and what was your success or failure in the > attempt? > > Works fine. > Whether it's what you really want is another question. The z/Architecture > machines basically handle things themselves, with requests being converted > to async dynamically. > > Will play merry hell with CF response times: > - Datasharing would be a no-no, but you know that already. > - for the GRS Star numbers, you can probably just move the decimal point. > Hopefully just once, maybe twice - I'll let you guess in which direction. > Converting back to ring mode is another option - m. > - some you couldn't care less about, like LOGREC. > > Make sure you have all your RMF data available for some comparisons after > the fact. Won't help then, but may give you ammo for future fights. > > Shane ... -- 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
Re: external vs internal coupling facility
Is there any way you can wiggle an ICF into your configuration? For example, could you go to a 2xx model? Are you WLC (and thus could conceivably shift the Linux workload to the CPs)? Could you consolidate more Linux work and turn on an IFL or two in the second system to convert it, better funding its maintenance? Do you need the CF? Have you had a recent chat with your IBM SE^H^H IT Specialist? I'm not liking Plan A either. :-) - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- 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
Re: external vs internal coupling facility
Moving the CF from external to internal might introduce single points of failure which may lead to data loss. So, careful planning is due. Some apply only to multi system sysplex, some also to single system environments. Peter Hunkeler CREDIT SUISSE -- 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
Re: external vs internal coupling facility
We am running a similar configuration for our sandbox CF (internal CF LPAR sharing 3 CPs with 4 other LPARs). Not only that sync requests are converted to async by PR/SM, it's done without z/OS knowing about it. z/OS still thinks its a sync request, and RMF will report it as a sync request. So the sync requests will have high, misleading, response time. From my experience, in the milliseconds. Gil. On 2/18/06, ibm-main <[EMAIL PROTECTED]> wrote: > > > Works fine. > Whether it's what you really want is another question. The z/Architecture > machines basically handle things themselves, with requests being converted > to async dynamically. > -- 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
Re: external vs internal coupling facility
>Not only that sync requests are converted to async by PR/SM, it's done without z/OS knowing about it. IIRC, only the requests from the same physical CEC are converted. Those from another footprint stay synchronous. - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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
