Maybe it's illusory, but that is in David Raften document.
Obviously it's cheaper to have 2 CPCs than 3, but it is also cheaper to have 1 CPC than 2. The white paper clearly describes some structures as demanding duplexing or third CPC with failure-isolated CF.

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2018-07-11 o 01:15, Jesse 1 Robinson pisze:
It's easy to diss a solution as 'budget' when it saves someone *else* money. 
The notion that a third CEC for standalone CF is substantially better than ICF 
is illusory. If you truly believe that one extra CEC is necessary, then you 
really need two extra CECs for CF because there are times when you have to take 
one of them down. Maybe for repair, maybe for upgrade. So you still need a 
backup.

OTOH, 'logical standalone'--interesting term--with an ICF in each z/OS CEC is a 
sufficient solution. We've run this way for years and survived two separate 
hard-down CEC failures with zero recovery agony. My recommendation is to run 
two CECs, one substantial box to run application hosts, and a minimal 'penalty 
box' just for ICFs plus a few high-cost products that bill significantly less 
on a small CEC. With proper structure duplexing, you have extraordinary 
redundancy at a reasonable cost.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, July 10, 2018 3:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Sysplex between two hardware

W dniu 2018-07-10 o 06:56, Timothy Sipples pisze:
I should also respond to this part:

Radoslaw Skorupka wrote:
...for availability reasons one should avoid having CF and z/OS LPAR
on the same hardware, which means....
That's not phrased as IBM would phase it, and it's not correct as written.

Even when there's some merit in physically separating the CF, the
physical separation need only be between that CF and the particular
z/OS Parallel Sysplex it serves. Having other z/OS LPARs, even LPARs
that are participating in other Parallel Sysplexes, on the same
machine as the CF is consistent with IBM's recommendations here.

David Raften has published a whitepaper (updated in May, 2018) that
explains the various CF configuration options. The direct link to the
current edition is here:

https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw01971usen/zsw01971u
sen-.pdf
[...]

I quickly browsed the document and found confirmation what I learned several 
years ago.
That means:
Yes, you need either standalone CF (*see note) or CF structure duplexing! This 
is required for *some* structures, but ...it is. David Rften call it structures 
which /require failure independence/.

Note: Standalone CF should be understood here as LOGICAL stand alone CF.
IBM-MIAN do not allo pictures, so I'll try to describe it:
SYSPLEX PROD:
z/OS 1 in CPC A, z/OS 2 in CPC B, and CF2 in CPC B or A. And CF1 in CPC C.
Three CPCs.
However CPC C may be used for other purpose, i.e. for test LPARs.
Anything but z/OS image belonging to the sysplex PROD.

There is also two-CPC configuration
z/OS 1 + CF1 in CPC A, z/OS 2 + CF2 in CPC B and *some structures are duplexed*.
What I heard unofficially from IBM-ers is such configuration is "budget"
read: when you cannot afford good one.
And the link between CFs should be really local (short).


Note2: it is also possible to build a configuration without dedicated
(logical stand alone) CF and without duplexing. Your choice.
However it is NOT resistant to all possible (single) failures. Yes, it
is still better than parallel sysplex with single CF, but still
vulnerable to some failures.



======================================================================


       --
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

Reply via email to