Re: Coupling facility - Non Volatile performance
We've been doing parallel sysplex since 1995. I've never heard of any
performance implication. It's all about structure placement: some
exploiters insist on placing their structures in nonvolatile CFs. We've
run 'nonvolatile' for so long that I forget the gritty details, but I'm
pretty sure that in the olden days at least, JES2 was unhappy about a
volatile environment for the checkpoint structure (if used) .
So who actually decides if a CF is volatile or not? YOU do. It's a matter
of assertion, not hardware budget. On the HMC, select a CF LPAR and open
Operating System Messages. You can determine the current setting of this
option with the command
display mode
You will see 'MODDE is {NON}VOLATILE'
If it shows VOLATILE, issue the command
mode nonvolatile
Any application that queries CF volatility will now be told that the CF is
nonvolatile. In our case, we have a robust UPS with multiple utility feeds
(yes, we're a utility) and generator backup. We have never sprung for the
internal battery option, but we don't lose sleep over it. Note that MODE
setting applies to each CF LPAR, so you must perform these actions on all
CF LPARs on all CECs.
I suggest checking MODE via HMC as a good exercise, but OS 'DISPLAY CF'
will also tell you if you need to take action.
Like most CF options, MODE is retained across activations, e.g. POR.
However, any time you get a new CEC or undergo serious modifications to an
existing CEC, recheck and if necessary adjust the MODE. Same goes for
DYNDISP, topic for different discussion.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: "Vernooij, CP - SPLXM"
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 01/23/2013 11:54 PM
Subject:Re: Coupling facility - Non Volatile performance
Sent by:IBM Mainframe Discussion List
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:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of nitz-...@gmx.net
Sent: Thursday, January 24, 2013 07:28
To: IBM-MAIN@LISTSERV.UA.EDU
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
Re: Coupling facility - Non Volatile performance
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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of nitz-...@gmx.net Sent: Thursday, January 24, 2013 07:28 To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Coupling facility - Non Volatile performance
Thanks Roger We have very good UPS.. and have decided to make CF mode Non volatile.. Just read somewhere that non volatile CF has better performance than Volatile ..but there is no ROTs or any indicative relative perfomance figure or how to measure / monitor it.. Best Regards Munif. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Coupling facility - Non Volatile performance
On Wed, 23 Jan 2013 23:04:40 -0600, Munif Sadek wrote: > >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. > Munif, 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. Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Coupling facility - Non Volatile performance
Dear Listers, 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. regards Munif -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
