Alan,
after the redbook the team and I have been involved in many projects to
distribute workloads across distance.
The main issue is the secondary effect of distance, which depends on how
your applications are written. In my experience this is mainly related
to data access and serialization. I have large customers happily running
at 30+ km distance, and others who gave up at 5 km because of their
applications' locking rates, which makes their applications very
sensitive to distance.
A review of your current transactions' response times by component could
tell you if there are serious inhibitors, but in most cases these only
show up when going over distance. That's why we always recommend testing
as there is no accurate way to predict the impact of distance on
response times.
Attention must be paid to batch processing, which benefits less from
caching mechanisms provided by middleware. Is your batch window
constrained? Do you plan to run batch across sites or locally in the
site which will host primary DASD and CFs? Batch can be a more sensitive
workload than online.
Finally, and I try to address this before starting any technological
discussion: What are you trying to achieve by going over distance? Most
customers I worked with equate multi-site parallel sysplex with even
workload distribution to non stop operation. This may be or may not be
true, and depending on your actual needs a slightly different
configuration might do with less performance impact.
Asynchronous CF locking is the major enhancement in the area of
performance over distance. It was made available ealry last year,
requires DB2 v12, z/OS Version 2 Release 2 + APAR OA47796 and CFCC lvl
21 with Service Level 02.16 or later.
Hope this helps,
mario
On 01/03/2018 07:17 AM, AlanWatthey , GMAIL wrote:
I have had a strange request from management as to how far apart we can move
our production systems. I know there are limitations on how far the (in
this case) two systems (and two coupling facilities) can be apart and I've
dug up an old IBM Redbook on the issue where they did tests with a sysplex
at 0, 20, 40, 60 and 80 kms apart. Physical limitations (eg. FICON) don't
seem to be an issue. We are a CICS and DB2 shop so the manual certainly
addressed issues that we might see but it is dated 2008 so has anything
changed since then? CICS and DB2 have moved on a long way in that time.
I was thinking of saying up to 10km but this is really a finger in the air
value. Maybe it's only 5 and maybe its 20 or 30. Can we just throw CPU and
memory at it as I would think we would have a lot more transactions running
at the same time with some (but not all apparently) having extra delays
incurred? The transaction increases suggested in that manual are
milleseconds and these days (with all the distributed systems involved) the
users are happy to get 10 second response times. Admitted this can involve
many, many transactions behind the scenes from the application servers to
populate their crowded browser screens. Gone are the days of data-entry
pools and sub-second responses.
What I was wondering is there anyone out there with real life experience on
this kind of activity. How far apart do people run their sysplex systems?
What gotchas sprang up to relieve them of their sanity? Any pointers would
be gratefully appreciated.
Regards,
Alan Watthey
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of IBM-MAIN automatic digest system
Sent: 03 January 2018 8:00 am
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM-MAIN Digest - 1 Jan 2018 to 2 Jan 2018 (#2018-2)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
