Skip, I'd share your scepticism about 100+ km apart. I don't know of
anybody doing anything remotely stressful in CF terms over that distance.
All my customers who are doing e.g. Data Sharing over distance plan and
measure extremely carefully - and they're doing it over a very few tens of
km.
I've heard of something called something like a "fibre suitcase" for
measuring in test.
Could someone who has such a thing tell me its proper name and a little
more about it? Thanks!
I've actually blogged extensively about the RMF 74-4 latency number
(relatively new) - which I think is useful in checking distance and
hinting at routing. While not wanting to advertise the posts I think this
latency number is one people should check occasionally.
Cheers, Martin
Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM
+44-7802-245-584
email: martin_pac...@uk.ibm.com
Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
From: Skip Robinson <jo.skip.robin...@att.net>
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 22/12/2015 23:59
Subject: Re: Coupling Facility Structure Re-sizing
Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
I made a lame assumption based on 20 years of parallel sysplex. Our
sysplexes have always consisted of boxes a few meters apart. I have
(rather
unkindly) scoffed at suggestions that we build a single sysplex between
our
data centers 100+ KM apart. It's not as much about speed as about the
fallibility of network connections. The DWDM links that transport XRC
connections are wicked fast, but they hiccup occasionally for usually
unfathomable reasons. We can handle XRC suspend/resume, but having a
sysplex
go hard down in such circumstances is not acceptable. Maybe I'm behind the
times, but that 'conversation with the boss' I alluded to in a previous
post
looms large in my imagination.
.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, December 22, 2015 12:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Bulk] Re: [Bulk] Re: Coupling Facility Structure Re-sizing
One crucial parameter: at what distance are the CFs?
There must be a noticable difference between 5 usecs for an unduplexed
local
CF or a number of 150 usecs signals between CFs at 15 km distance.
Kees.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Martin Packer
Sent: 22 December, 2015 8:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Bulk] Re: Coupling Facility Structure Re-sizing
We're not going to BLANKET recommend System-Managed Duplexing for high-
volume, high stringency structures such as LOCK1. SCA has little
traffic.
But I've seen MANY customers (including the one I worked with yesterday
here
in Istanbul) that successfully use it. And I support their use of it.
Other customers:
1) Have a failure-isolated CF for such structures.
Or
2) Take the risk of doing neither.
I've seen all 3 architectures even in the past 6 months. And your local
IBMer is
normally willing to give their view, hopefully backed up by data and
people who
know what they're talking about. :-)
Cheers, Martin
Martin Packer,
zChampion, Principal Systems Investigator, Worldwide Cloud & Systems
Performance, IBM
+44-7802-245-584
email: martin_pac...@uk.ibm.com
Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
From: "Vernooij, CP (ITOPT1) - KLM" <kees.verno...@klm.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 22/12/2015 07:39
Subject: Re: [Bulk] Re: Coupling Facility Structure Re-sizing
Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
Of course 'it depends'.
At least on the distance between the CFs. Signals are delayed by 10
usec/km.
The number of signals traveling for SMCFSD have indeed been optimized
since
the beginning, but it still makes a difference if the CF's are 1 or 15
kms
apart. Our
latest researches from this year is that IBM still does not recommend
SMCFSD
for Lock and SCA.
What is your configuration? If a CEC fails, others DB2's in the group
should do
the recovery without delay. Did all your CECs and DB2s fail? Our
experience is
that a group-restart is very fast, at max. 2 - 3 minutes and that are
also
IBMs
figures.
Altogether, we still see advantages in not using SMCFSD for Lock and
SCA.
Why did you decide different?
Kees.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Skip Robinson
Sent: 21 December, 2015 20:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Bulk] Re: Coupling Facility Structure Re-sizing
I'm talking from experience. The two hours-long CEC failures we
had--most
recently in the fall of 2014--took down all CICS and DB2 applications as
well as
three ICFs on the box that failed. The secondary 'penalty' box stayed up
and kept
live copies of structures so that after hardware repair, all LPARs--host
and CF--
came up with no recovery needed. In particular, no DB2 log processing,
which is
the worst case for recovery.
As for processing overhead, that's why IBM delayed SMCFSD. We're as
concerned with performance as any shop. Millions of CICS/DB2
transactions
per
hour. For DASD mirroring, we went with XRC (async) rather than PPRC
(sync) for that reason. Today we see no visible delays from SMCFSD. This
is
predicated on having enough CF engines to do the job. As previously
stated,
beware of putting CF LPARs on hardware that's slower than the
exploiters.
Note
that CF, ZIIP, and IFL engines run at full rated speed even on a box
that's
'downsized' to run GP engines at less than maximum speed--to save
software
costs. That's why we're happy to put ICFs on otherwise slower penalty
boxes.
.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler The
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Vernooij, CP (ITOPT1) - KLM
Sent: Sunday, December 20, 2015 11:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Bulk] Re: Coupling Facility Structure Re-sizing
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:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Skip Robinson
Sent: 19 December, 2015 5:57
To: IBM-MAIN@LISTSERV.UA.EDU
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
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of phil yogendran
Sent: Friday, December 18, 2015 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
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
<jo.skip.robin...@att.net>
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
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com
-----Original Message-----
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of phil yogendran
Sent: Friday, December 18, 2015 07:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
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. <
robert.richa...@opm.gov> 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht
Sent: Friday, December 18, 2015 7:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
