To avoid misunderstandings: n*z/OS + m*CF = Parallel Syplex, and
n=1...32, m=1...16.
I don't know what "most people" interpret, and without some sociological
survey. My survey told me that no one of my family members, neighbours
or local shop seller do understand parallel sysplex as you described. ;-)
Back to technical issues - single z/OS connected to single CF *IS*
parallel sysplex. 5*z/OS + 2*CF is probably better configuration,
especially when the logical images (LPARs) are wisely spread across
several CPCs. Wisely means there no SPOFs, i.e. we should NOT place both
CFs on single CPC.
Regarding VSAM RLS - it is good and very useful for applications that
use VSAM. I migrated (to DB2 table) last VSAM file 10+ years ago and
really do not need RLS. Of course YMMV.
BTW: IMHO properly configured and tuned single-image parallel sysplex
is ~70% of work for monoplex->parallel sysplex migration. Connecting
another z/OS images is (almost) just matter of HCD and repeating
configurations steps. My €0.02
Regards
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2018-07-12 o 08:37, Timothy Sipples pisze:
Radoslaw Skorupka wrote:
RLS require Parallel Sysplex, but not everyone need it.
We should be more precise and careful, to avoid any misunderstandings. VSAM
RLS requires:
* At least one z/OS instance (let's go with exactly one in this example);
* A Coupling Facility (CF)(*), which can even be on the same physical
machine.
And that's it! You do NOT *need* two z/OS LPARs to support VSAM RLS (and
Transactional VSAM). You need two basic ingredients: z/OS (one works) and a
Coupling Facility (one works). For Transactional VSAM you also need the
z/OS DFSMStvs software license.
This IBM redbook ("VSAM Demystified") illustrates VSAM RLS in a z/OS
Monoplex in Section 5.1.4:
http://www.redbooks.ibm.com/redbooks/pdfs/sg246105.pdf
Possible formal definitions aside, most people interpret "Parallel Sysplex"
as including two or more z/OS instances, at least in normal operations. But
no, even during normal operations you only *need* one suitably configured
z/OS instance for VSAM RLS and Transactional VSAM, to be clear. There might
be other reasons to have more than one z/OS instance, but you don't need a
second z/OS instance to run these two highly useful VSAM technologies.
In this example, you, your colleagues, and management might decide,
perfectly sensibly and rationally, that a particular set of CICS
applications (let's suppose) and the services they provide are well suited
to a z/OS Monoplex. You've agreed that they can tolerate the planned
outages required for such tasks as z/OS release upgrades in that LPAR
(perhaps scheduled in conjunction with a DR rehearsal), that the unplanned
outage characteristics (which are still quite excellent, as long as the
site is available) are good enough to meet the business requirements, and
that VSAM RLS and Transactional VSAM technologies are required to make sure
that the applications are providing excellent concurrent online and batch
services, to avoid planned online outages to run batch jobs. If these
parameters meet your needs, great, you're all set. There's a wonderful,
value-packed configuration for you called a z/OS Monoplex with VSAM RLS and
Transactional VSAM. If you change your mind, and management wants a
different service level, no problem! Gracefully shift to a Parallel Sysplex
with two z/OS LPARs on one machine, as one example. Or to any of the many
other configuration options available, as/when they make sense to deliver
on particular end-to-end business service needs.
The white paper clearly describes some structures as demanding
duplexing or third CPC with failure-isolated CF.
Yes, but David Raften is only describing the technical attributes there.
He's not necessarily describing business service outcomes, which require
more analysis. A particular technical result may or may not matter in terms
of delivering on particular end-to-end business service goals. "It
depends."
(*) Which is not quite the same as saying you need a CF *engine*. The CFCC
can run on a general purpose engine, and occasionally that makes sense.
--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: sipp...@sg.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.
======================================================================
--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is
intended solely for business use of the addressee. This e-mail may only be
received by the addressee and may not be disclosed to any third parties. If you
are not the intended addressee of this e-mail or the employee authorized to
forward it to the addressee, be advised that any dissemination, copying,
distribution or any other similar activity is legally prohibited and may be
punishable. If you received this e-mail by mistake please advise the sender
immediately by using the reply facility in your e-mail software and delete
permanently this e-mail including any copies of it either printed or saved to
hard drive.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców
KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
