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
[email protected]
From: "Vernooij, CP - SPLXM" <[email protected]>
To: [email protected],
Date: 01/23/2013 11:54 PM
Subject: Re: Coupling facility - Non Volatile performance
Sent by: IBM Mainframe Discussion List <[email protected]>
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
