Your last statement is far too general in my opinion. SMCFSD is not free: besides memory, which indeed is cheap these days, it will cost performance, like PPRC does. So one must always make the decision about having high availability or high performance. Even without SMCFSD, Structure availability is very high. And in the rare event of a CF failure (when was you last one?) each exploiter of CF Structures should be able to recover from that failure. In my experience they all do, except MQ. If you have a CF failure, the structures are recovered within seconds or minutes. If you can't bear the recovery delay, you can use Duplexing. Besides that, if you have a CF failure, what other problems do you have? Do you still need the zero recovery delay then?
Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Skip Robinson Sent: 19 December, 2015 5:57 To: [email protected] Subject: Re: Coupling Facility Structure Re-sizing Wow, I feel so ancient. In the History of the World Part II, there are two kinds of duplexing. The late comer is System Managed Duplexing, which is provided by z/OS - XCF - XES. The exploiter does not need to participate in SMD (my acronym); he just reaps the benefits. But SMD for customer use was delayed for quite a while because IBM could not get it working. (More history.) Meanwhile DB2 could not wait for SMD and developed their own duplexing mechanism. Hence DB2/IRLM does not need/use SMD. I forgot that when I mentioned DB2 recovery. So I recommend that DUPLEX be specified for all other structures that need SMD. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of phil yogendran Sent: Friday, December 18, 2015 12:19 PM To: [email protected] Subject: [Bulk] Re: Coupling Facility Structure Re-sizing The increases recommended by the CF Sizer is marginal. Our structures in production are generously sized and we have lots of storage in the new CFs so that's not a concern. I will however lookout for messages as suggested. Most of our structures are duplexed. Some like the structure for the IRLM lock are not. I have a note to investigate the product specific doc to understand this better. I also need to check on the performance of CF links as we're going to ICB links now. Thanks for the info. On Fri, Dec 18, 2015 at 12:42 PM, Skip Robinson <[email protected]> wrote: > In case you're curious, the parameters 'missing' from your old > definitions were added over the years since the advent of coupling > facility. The new parameters all have defaults such that they do not > actually require specification, but using them may give you better > control over structure sizes. Some additional points: > > -- At any time, the CF Sizer makes recommendations based on the latest > hardware with the latest microcode. Newer hardware or newer microcode > typically requires larger structures to accomplish the same work even > with no changes to the exploiters. > > -- In my experience, CF Sizer makes very generous recommendations. > Memory is cheaper now than ever, but watch out for gratuitous over allocation. > Especially on an external CF, you might be constrained. > > -- Several structures require that you input data to CF Sizer on how > busy you expect the structure to be. For most, this has less to do > with the number of sysplex members than the amount of data the > structure has to handle. This is seldom easy to determine. Make your > best SWAG and monitor the results. > > -- The worst case is when a structure is too small for the exploiter > to initialize. I have not seen this for some time; maybe the big > exploiters have been (re)designed to come up regardless. But watch for > messages indicating that a structure needed more than the specified > minimum size at the outset. > > -- A parameter you did not ask about is DUPLEX. Even if you have only > one box for CF use, I recommend two CF LPARs on that box with > duplexing for relevant structures. Better of course would be two > boxes. The best thing about sysplex is its ability to survive > disruptions. Over the years we have had two CEC failures. In both > cases, the second CF allowed all applications to resume with zero data > recovery efforts. Note that some structures do not require duplexing, notably > GRS. If a host dies, so do all of its enqueues. > > > . > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > [email protected] > [email protected] > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of phil yogendran > Sent: Friday, December 18, 2015 07:39 AM > To: [email protected] > Subject: [Bulk] Re: Coupling Facility Structure Re-sizing > > Thank you all for your replies. I will take your suggestions into > consideration going forward. We are in the process of upgrading from > z10 - > > z12 -> z13 over the next few months. The CF upgrade is a part of > > this > project. The CFs are going from 2097/E10 and 2098/E12 to 2817/M15. > > I expect to see better structure response with these changes and will > be surprised to see anything otherwise. Will keep you posted. Thanks again. > > On Fri, Dec 18, 2015 at 8:16 AM, Richards, Robert B. < > [email protected]> wrote: > > > The archives probably have it, but simply put and if IIRC, there was > > an old 9674 being used with z990s. Waiting on CF structure response > > was horrific as compared to the speed of the z990 processor response. > > > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:[email protected]] On Behalf Of Elardus Engelbrecht > > Sent: Friday, December 18, 2015 7:55 AM > > To: [email protected] > > Subject: Re: Coupling Facility Structure Re-sizing > > > > Richards, Robert B. wrote: > > > > >The last thing you want is for your CFs to be slower than the CPs. > > >BTDTGTS > > > > Ouch. Could you be kind to tell us about it? Are there any manuals > > stating that trouble? Any configuration changes to avoid? Or is it > > about the sizes or quantity of LPARs involved? > > > > TIA! > > > > Groete / Greetings > > Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
