Barbara, I would have expected you to mention option 3. as first option. Or do I really sense a careful positivism towards HCs from you in the last year ;-)?
I would add another option: set up you CFs and structures in such a way, that you can stand CF failures. Many applications can survive a CF failure by rebuilding the structure in the other CF, others can keep on working with duplexing, either user- or system-managed. The same applies to failure isolation. Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, January 24, 2013 07:28 To: [email protected] Subject: Re: Coupling facility - Non Volatile performance > >Due to IBM Health checker report we have to change mode of our Coupling facility to non Volatile.. CF is running in a partition on CPC, shared by 4 z/OS LPARs making it a sysplex. We are enabled for CICSPlex , DB2 Data sharing, RACF Database Sharing, SMSPlex, Catalog ECS etc etc.. > > > >Can someone point me in the right direction to measure performance gain (due to change of CF Mode) , if any. > > > >We are RMF, SAS/MXG and BMC Performance assurance (aka Visualiser, Best/1 ) site. > > > > A volatile coupling facility is one in which interruption of the power supply causes loss of the memory contents. You can make the coupling facility nonvolatile by adding to it an uninterruptible power supply or you can use a battery backup, which uses internal batteries to provide power during an outage. We are talking about the XCF_CF_STR_NONVOLATILE check, right? Before going to the expense of adding a battery or power supply (or - IIRC - just fake it by setting the appropriate switch for the CF somewhere in the HMC, which was possible in the past), read up carefully what the health check says: It doesn't just talk about non-volatility. In essence it talks about non-volatility *and* failure isolation. (Read up on both in 'setting up a sysplex'.) Making the CF non-volatile will NOT make the exception disappear as long as your CF runs on the same *hardware* as any of the z/OSs that use this CF. You have the following chances of making this exception disappear: 1. Make sure that no z/OS that uses the CF is on the same hardware as the CF (failure isolation) *and* provide the battery to that hardware (non-volatility). 2. Buy a standalone CF (failure isolation) with the appropriate battery (non-volatility). 3. Delete this health check and go on as before (just for completeness). >From the top of my head, structures that would like to have a non-volatile, failure-isolated CF are typically system logger structures. Assuming that you configured them correctly, they will already automatically be duplexing data written to the CF to staging data sets. Which will give you the result you need: In case of power failure to the hardware your z/OS runs on, there is a copy of the data still available somewhere (in this case, staging data sets). You will gain a small benefit in performance because with a failure isolated, non-volatile CF duplexing to staging data sets is no longer necessary for system logger. Not sure if other structures also request non-volatile, failure isolated CFs. Barbara Nitz ---------------------------------------------------------------------- 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
