Re: Sysplex between two hardware
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,
Re: Sysplex between two hardware
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
Re: Sysplex between two hardware
Yes, that's true. Fortunately ICF as other specialty engines always run at full speed. That's also reason why one should not use older machines for CF. BTW: Third CPC need not be very expensive. I'm neither IBM sales guy, nor "standalone CF evnagelist", but when you buy two CPCs with CP engines you pay for MIPS then for the frame. In such deal, adding another CPC with zero MIPS can be quite inexpensive when compared to "regular" CPC. And regarding level of redundancy: it's obvious when you use spare wheel you don't have spare. It's the same with CF. AFAIK you can have up to 16 CFs in a sysplex, but usually we protect against SINGLE failure, not coordinated series of failures. That's why we carry only one spare wheel in a car (typically). Regards -- Radoslaw Skorupka Lodz, Poland W dniu 2018-07-11 o 11:34, Richards, Robert B. pisze: Just make sure that if you have a standalone CPC with CFs for that purpose that its engines are as fast as your other CPCs engines. I got into a performance problem 15 years ago when a 9674 was kept around longer that it should have been. You are only as fast as your slowest . Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Wednesday, July 11, 2018 5:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex between two hardware 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. == -- 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 025237, 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
Re: Sysplex between two hardware
Just make sure that if you have a standalone CPC with CFs for that purpose that its engines are as fast as your other CPCs engines. I got into a performance problem 15 years ago when a 9674 was kept around longer that it should have been. You are only as fast as your slowest . Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Wednesday, July 11, 2018 5:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex between two hardware 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
Re: Sysplex between two hardware
W dniu 2018-07-11 o 09:41, Timothy Sipples pisze: J.O.Skip Robinson wrote: It's easy to diss a solution as 'budget' when it saves someone *else* money. I quite agree. As it happens, I'm quite fond of the single machine z/OS Parallel Sysplex configuration that David also describes. I wish more installations without Parallel Sysplex would adopt it in order to reduce or eliminate most planned and unplanned outages (for the part of their business services relying on IBM Z resources). The single machine z/OS Parallel Sysplex is a terrific value and quite easy to implement. For some odd reason there's a misconception that if you want to upgrade from PLEXCFG=XCFLOCAL or PLEXCFG=MONOPLEX that you must add another machine. No, that's not correct. Moreover, you can run terrifically useful z/OS features such as VSAM RLS and Transactional VSAM even in a PLEXCFG=MONOPLEX mode with one z/OS LPAR (or one z/OS guest in z/VM). That's another popular misconception. Within z/OS Parallel Sysplex configurations you get to decide which subsystems and applications to protect, and how. As one example, you might decide to implement MQ shared queues but otherwise not do much else. Messages can then still be received and queued for processing, even when the only instance of a particular application (or whole LPAR) is offline for maintenance or some other purpose. If "Yes, I've got your message, and I'll get to it soon" is good enough to meet the business requirements between 3:00 a.m. and 4:00 a.m. every third Sunday of the month, or whatever, FINE! There are all kinds of really interesting configuration choices available to cater to particular business service objectives, and it's wonderful to have the flexibility. It's important to have some basic familiarity with these various options if you have a role in advising on configurations. Timothy, It's 90% off-topic, but 99% right. The missing 1% is about XCFLOCAL and MONOPLEX mess. What misconception do you mean? Monoplex does not require (does not use) CF at all. It is not the same thing as single-image parallel sysplex, which require CF. Failure isolation is another issue. RLS require Parallel Sysplex, but not everyone need it. Regards -- Radoslaw Skorupka Lodz, Poland == -- 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 025237, 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
Re: Sysplex between two hardware
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 simila
Re: Sysplex between two hardware
J.O.Skip Robinson wrote: >It's easy to diss a solution as 'budget' when it saves >someone *else* money. I quite agree. As it happens, I'm quite fond of the single machine z/OS Parallel Sysplex configuration that David also describes. I wish more installations without Parallel Sysplex would adopt it in order to reduce or eliminate most planned and unplanned outages (for the part of their business services relying on IBM Z resources). The single machine z/OS Parallel Sysplex is a terrific value and quite easy to implement. For some odd reason there's a misconception that if you want to upgrade from PLEXCFG=XCFLOCAL or PLEXCFG=MONOPLEX that you must add another machine. No, that's not correct. Moreover, you can run terrifically useful z/OS features such as VSAM RLS and Transactional VSAM even in a PLEXCFG=MONOPLEX mode with one z/OS LPAR (or one z/OS guest in z/VM). That's another popular misconception. Within z/OS Parallel Sysplex configurations you get to decide which subsystems and applications to protect, and how. As one example, you might decide to implement MQ shared queues but otherwise not do much else. Messages can then still be received and queued for processing, even when the only instance of a particular application (or whole LPAR) is offline for maintenance or some other purpose. If "Yes, I've got your message, and I'll get to it soon" is good enough to meet the business requirements between 3:00 a.m. and 4:00 a.m. every third Sunday of the month, or whatever, FINE! There are all kinds of really interesting configuration choices available to cater to particular business service objectives, and it's wonderful to have the flexibility. It's important to have some basic familiarity with these various options if you have a role in advising on configurations. 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
Re: Sysplex between two hardware
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. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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/zsw01971usen-.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. -- Radoslaw Skorupka Lodz, Poland == -- 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 025237, 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
Re: Sysplex between two hardware
Thanks. I wasn't, in that post, intending to talk about Duplexing performance. Merely how I know about deactivated LPARs from RMF SMF - in case anybody wondered. (In recent engagements I've used the deactivated LPARs' names and locations to drive brief discussions on Availability setup etc.) It's possible you'll like this one, though I don't think it helps you with Performance all that much: https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/coupling_facility_duplexing_reporting_warm_over?lang=en And it's (almost) time I wrote about Async CF Duplexing - which might possibly be helpful to you. Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Ravi Gaur To: IBM-MAIN@LISTSERV.UA.EDU Date: 10/07/2018 09:35 Subject: Re: Sysplex between two hardware Sent by:IBM Mainframe Discussion List Martin, thanks I time to time read your blogs very useful however one you pasted for the deactivated lpar's doesn't have much on the performance side ...anyway yes we have LOCK1 duplex...here's an example from our dev partitions. STRNAME: Dxxx_LOCK1 STATUS: REASON SPECIFIED WITH REBUILD START: POLICY-INITIATED DUPLEXING REBUILD METHOD: SYSTEM-MANAGED AUTO VERSION: D290AFB4 34496191 PHASE: DUPLEX ESTABLISHED EVENT MANAGEMENT: MESSAGE-BASED TYPE: LOCK POLICY INFORMATION: POLICY SIZE: 310 M POLICY INITSIZE: 256 M POLICY MINSIZE : 256 M FULLTHRESHOLD : 80 ALLOWAUTOALT : YES REBUILD PERCENT: 1 DUPLEX : ENABLED ALLOWREALLOCATE: YES PREFERENCE LIST: CxxECC1 CxxECC1 -- 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
Re: Sysplex between two hardware
Martin, thanks I time to time read your blogs very useful however one you pasted for the deactivated lpar's doesn't have much on the performance side ...anyway yes we have LOCK1 duplex...here's an example from our dev partitions. STRNAME: Dxxx_LOCK1 STATUS: REASON SPECIFIED WITH REBUILD START: POLICY-INITIATED DUPLEXING REBUILD METHOD: SYSTEM-MANAGED AUTO VERSION: D290AFB4 34496191 PHASE: DUPLEX ESTABLISHED EVENT MANAGEMENT: MESSAGE-BASED TYPE: LOCK POLICY INFORMATION: POLICY SIZE: 310 M POLICY INITSIZE: 256 M POLICY MINSIZE : 256 M FULLTHRESHOLD : 80 ALLOWAUTOALT : YES REBUILD PERCENT: 1 DUPLEX : ENABLED ALLOWREALLOCATE: YES PREFERENCE LIST: CxxECC1 CxxECC1 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
A common pattern (and I often see the inactive LPARs in RMF* SMF) but tell me: Do you duplex DB2 LOCK1? And how is that working out performancewise? * I wrote about how to do this in https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/lpars_what_s_in_a_name?lang=en in 2014. Cheers, Martin Sent from my iPad > On 10 Jul 2018, at 08:58, Ravi Gaur wrote: > > We took an approach where for each plex we had CF defined on two cec's as > that make sense : > > 1. Systems defined in the plex are defined on both CEC ...i.e. Say we have > plex of 4 systems (SYS1,SYS2,SYS3,SYS4), each with 2 systems on one CEC1(SYS1 > & SYS2 Active(Normal running) the rest 2 in Inactive state on CEC1 (SYS3 & > SYS4) , similar definition goes other way which is CEC2(SYS3 & SYS4 > Active(normal running) & rest 2 in inactive state on CEC2(SYS1 & SYS2) > This provide resiliency in terms of whole CEC Going down ...Now both have CF > Definition for the Plex on both CEC which provide resiliency for the CF as > well with Structures defined in duplex mode ...This we have been running for > years and provide us various benefits example say we are applying or doing > microcode upgrade or for various other reason require structures to move > around ...those all features can be exploited when we have structures defined > in the duplex mode with hardware split over two separate physical box > So simple rule and policy and commonsense work here > > -- > 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
Re: Sysplex between two hardware
We took an approach where for each plex we had CF defined on two cec's as that make sense : 1. Systems defined in the plex are defined on both CEC ...i.e. Say we have plex of 4 systems (SYS1,SYS2,SYS3,SYS4), each with 2 systems on one CEC1(SYS1 & SYS2 Active(Normal running) the rest 2 in Inactive state on CEC1 (SYS3 & SYS4) , similar definition goes other way which is CEC2(SYS3 & SYS4 Active(normal running) & rest 2 in inactive state on CEC2(SYS1 & SYS2) This provide resiliency in terms of whole CEC Going down ...Now both have CF Definition for the Plex on both CEC which provide resiliency for the CF as well with Structures defined in duplex mode ...This we have been running for years and provide us various benefits example say we are applying or doing microcode upgrade or for various other reason require structures to move around ...those all features can be exploited when we have structures defined in the duplex mode with hardware split over two separate physical box So simple rule and policy and commonsense work here -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
Dear All I am receiving lot of great responses and I should be back on Mondays. Apologise for not responding. Peter On Tue 10 Jul, 2018, 10:24 AM Vernooij, Kees (ITOPT1) - KLM, < kees.verno...@klm.com> wrote: > Well, we don't disagree much, except that that in case of a CF failure, we > decided take the (few seconds) structure recovery delays and not have the > duplexing overhead. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Jesse 1 Robinson > > Sent: 09 July, 2018 18:07 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Sysplex between two hardware > > > > I stand by my original reply. All you need is an ICF LPAR in each CEC > > and physical links to connect the CECs, together with full CF structure > > duplexing. We have run this way for decades. Suffered two (!) CEC > > failures over the years. After repairing the failed CEC, we resumed > > normal operation with *no* recovery actions needed because all sensitive > > structures were duplexed in the non-failing CEC. > > > > Our standalone CFs went away with the 9674. > > > > . > > . > > 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 Vernooij, Kees (ITOPT1) - KLM > > Sent: Monday, July 09, 2018 8:08 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: Sysplex between two hardware > > > > That was my point: you don't miss a thing. > > You are fully redundant with CFs in each CPC. > > And since the latest MQ update, all applications are capable of > > recovering their structures, so recovery is guaranteed in case of a CF > > failure. > > > > Kees. > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > > On Behalf Of Allan Staller > > > Sent: 09 July, 2018 16:33 > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Sysplex between two hardware > > > > > > That configuration is perfectly valid. You are merely missing some(but > > > not all) redundancy and recovery options. > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > > On Behalf Of R.S. > > > Sent: Monday, July 9, 2018 9:20 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Sysplex between two hardware > > > > > > W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze: > > > > The essence of the matter is to ensure that the selected > > > > configuration > > > meets the availability objectives of the business services supported > > > by the sysplex. One must consider the service restoration objectives > > > for the business services in light of the potential failures that can > > > occur for a potential choice of configuration. There are many > > > possibilities and different installations will of course make > > > different choices based on their own business objectives. Choices of > > > standalone CF, or structure duplexing, and the like are really all > > > talking about different ways of solving the "failure isolation" issue > > > (wherein we might be concerned about the time to restore the business > > > service if we simultaneously lose the data in the CF along with the > > > system that produced that data). Each choice has its own advantages > > > and disadvantages; choose the one that's right for you. > > > > --Mark Brooks > > > > --z/OS Sysplex Development > > > > > > > > > > However "option c", that means we don't have standalone CF and we do > > > not duplex CF structures is not proper one, is it? > > > > > > Regards > > > -- > > > Radoslaw Skorupka > > > Lodz, Poland > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > For information, services and offers, please visit our web site: > http://www.klm.com. T
Re: Sysplex between two hardware
Well, we don't disagree much, except that that in case of a CF failure, we decided take the (few seconds) structure recovery delays and not have the duplexing overhead. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jesse 1 Robinson > Sent: 09 July, 2018 18:07 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sysplex between two hardware > > I stand by my original reply. All you need is an ICF LPAR in each CEC > and physical links to connect the CECs, together with full CF structure > duplexing. We have run this way for decades. Suffered two (!) CEC > failures over the years. After repairing the failed CEC, we resumed > normal operation with *no* recovery actions needed because all sensitive > structures were duplexed in the non-failing CEC. > > Our standalone CFs went away with the 9674. > > . > . > 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 Vernooij, Kees (ITOPT1) - KLM > Sent: Monday, July 09, 2018 8:08 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Sysplex between two hardware > > That was my point: you don't miss a thing. > You are fully redundant with CFs in each CPC. > And since the latest MQ update, all applications are capable of > recovering their structures, so recovery is guaranteed in case of a CF > failure. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Allan Staller > > Sent: 09 July, 2018 16:33 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Sysplex between two hardware > > > > That configuration is perfectly valid. You are merely missing some(but > > not all) redundancy and recovery options. > > > > -Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of R.S. > > Sent: Monday, July 9, 2018 9:20 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Sysplex between two hardware > > > > W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze: > > > The essence of the matter is to ensure that the selected > > > configuration > > meets the availability objectives of the business services supported > > by the sysplex. One must consider the service restoration objectives > > for the business services in light of the potential failures that can > > occur for a potential choice of configuration. There are many > > possibilities and different installations will of course make > > different choices based on their own business objectives. Choices of > > standalone CF, or structure duplexing, and the like are really all > > talking about different ways of solving the "failure isolation" issue > > (wherein we might be concerned about the time to restore the business > > service if we simultaneously lose the data in the CF along with the > > system that produced that data). Each choice has its own advantages > > and disadvantages; choose the one that's right for you. > > > --Mark Brooks > > > --z/OS Sysplex Development > > > > > > > However "option c", that means we don't have standalone CF and we do > > not duplex CF structures is not proper one, is it? > > > > Regards > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
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/zsw01971usen-.pdf If you're reading this post substantially later than July, 2018, then please check first to see whether there's yet another updated edition. David discusses what I just described, the "Logical Stand-Alone CF" configuration, starting on page 9 of that whitepaper. Just because something has merit doesn't automatically mean it has merit for the next available increment of resources (budget, effort, etc.) I always try to approach business risk reduction holistically, in end-to-end business service terms starting with the most critical business services. If adopting a stand-alone CF configuration is the highest, next best use of available resources within that end-to-end service context, great. And isn't it wonderful how much flexibility you have with these technologies, to craft (and re-craft) the most appropriate configurations for the desired business outcomes? 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
Re: Sysplex between two hardware
I stand by my original reply. All you need is an ICF LPAR in each CEC and physical links to connect the CECs, together with full CF structure duplexing. We have run this way for decades. Suffered two (!) CEC failures over the years. After repairing the failed CEC, we resumed normal operation with *no* recovery actions needed because all sensitive structures were duplexed in the non-failing CEC. Our standalone CFs went away with the 9674. . . 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 Vernooij, Kees (ITOPT1) - KLM Sent: Monday, July 09, 2018 8:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Sysplex between two hardware That was my point: you don't miss a thing. You are fully redundant with CFs in each CPC. And since the latest MQ update, all applications are capable of recovering their structures, so recovery is guaranteed in case of a CF failure. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Allan Staller > Sent: 09 July, 2018 16:33 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sysplex between two hardware > > That configuration is perfectly valid. You are merely missing some(but > not all) redundancy and recovery options. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of R.S. > Sent: Monday, July 9, 2018 9:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sysplex between two hardware > > W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze: > > The essence of the matter is to ensure that the selected > > configuration > meets the availability objectives of the business services supported > by the sysplex. One must consider the service restoration objectives > for the business services in light of the potential failures that can > occur for a potential choice of configuration. There are many > possibilities and different installations will of course make > different choices based on their own business objectives. Choices of > standalone CF, or structure duplexing, and the like are really all > talking about different ways of solving the "failure isolation" issue > (wherein we might be concerned about the time to restore the business > service if we simultaneously lose the data in the CF along with the > system that produced that data). Each choice has its own advantages > and disadvantages; choose the one that's right for you. > > --Mark Brooks > > --z/OS Sysplex Development > > > > However "option c", that means we don't have standalone CF and we do > not duplex CF structures is not proper one, is it? > > Regards > -- > Radoslaw Skorupka > Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
That was my point: you don't miss a thing. You are fully redundant with CFs in each CPC. And since the latest MQ update, all applications are capable of recovering their structures, so recovery is guaranteed in case of a CF failure. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Allan Staller > Sent: 09 July, 2018 16:33 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sysplex between two hardware > > That configuration is perfectly valid. You are merely missing some(but > not all) redundancy and recovery options. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of R.S. > Sent: Monday, July 9, 2018 9:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sysplex between two hardware > > W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze: > > The essence of the matter is to ensure that the selected configuration > meets the availability objectives of the business services supported by > the sysplex. One must consider the service restoration objectives for > the business services in light of the potential failures that can occur > for a potential choice of configuration. There are many possibilities > and different installations will of course make different choices based > on their own business objectives. Choices of standalone CF, or > structure duplexing, and the like are really all talking about different > ways of solving the "failure isolation" issue (wherein we might be > concerned about the time to restore the business service if we > simultaneously lose the data in the CF along with the system that > produced that data). Each choice has its own advantages and > disadvantages; choose the one that's right for you. > > --Mark Brooks > > --z/OS Sysplex Development > > > > However "option c", that means we don't have standalone CF and we do not > duplex CF structures is not proper one, is it? > > Regards > -- > Radoslaw Skorupka > Lodz, Poland > > > > > == > > > -- > 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, > https://apac01.safelinks.protection.outlook.com/?url=www.mBank.plda > ta=02%7C01%7Callan.staller%40HCL.COM%7C10622a536f78423874c708d5e5a72f4d% > 7C189de737c93a4f5a8b686f4ca9941912%7C0%7C1%7C636667428590770229sdat > a=eg%2FISBQY4%2BT0T%2BRPr%2FPulpGdLql5wRKMACmRqT4VxsQ%3Dreserved=0, > e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział > Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS > 025237, 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 > ::DISCLAIMER:: > > > > ---
Re: Sysplex between two hardware
That configuration is perfectly valid. You are merely missing some(but not all) redundancy and recovery options. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, July 9, 2018 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex between two hardware W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze: > The essence of the matter is to ensure that the selected configuration meets > the availability objectives of the business services supported by the > sysplex. One must consider the service restoration objectives for the > business services in light of the potential failures that can occur for a > potential choice of configuration. There are many possibilities and > different installations will of course make different choices based on their > own business objectives. Choices of standalone CF, or structure duplexing, > and the like are really all talking about different ways of solving the > "failure isolation" issue (wherein we might be concerned about the time to > restore the business service if we simultaneously lose the data in the CF > along with the system that produced that data). Each choice has its own > advantages and disadvantages; choose the one that's right for you. > --Mark Brooks > --z/OS Sysplex Development > However "option c", that means we don't have standalone CF and we do not duplex CF structures is not proper one, is it? Regards -- Radoslaw Skorupka Lodz, Poland == -- 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, https://apac01.safelinks.protection.outlook.com/?url=www.mBank.pldata=02%7C01%7Callan.staller%40HCL.COM%7C10622a536f78423874c708d5e5a72f4d%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C1%7C636667428590770229sdata=eg%2FISBQY4%2BT0T%2BRPr%2FPulpGdLql5wRKMACmRqT4VxsQ%3Dreserved=0, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, 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 ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized re
Re: Sysplex between two hardware
W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze: The essence of the matter is to ensure that the selected configuration meets the availability objectives of the business services supported by the sysplex. One must consider the service restoration objectives for the business services in light of the potential failures that can occur for a potential choice of configuration. There are many possibilities and different installations will of course make different choices based on their own business objectives. Choices of standalone CF, or structure duplexing, and the like are really all talking about different ways of solving the "failure isolation" issue (wherein we might be concerned about the time to restore the business service if we simultaneously lose the data in the CF along with the system that produced that data). Each choice has its own advantages and disadvantages; choose the one that's right for you. --Mark Brooks --z/OS Sysplex Development However "option c", that means we don't have standalone CF and we do not duplex CF structures is not proper one, is it? Regards -- Radoslaw Skorupka Lodz, Poland == -- 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 025237, 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
Re: Sysplex between two hardware
The essence of the matter is to ensure that the selected configuration meets the availability objectives of the business services supported by the sysplex. One must consider the service restoration objectives for the business services in light of the potential failures that can occur for a potential choice of configuration. There are many possibilities and different installations will of course make different choices based on their own business objectives. Choices of standalone CF, or structure duplexing, and the like are really all talking about different ways of solving the "failure isolation" issue (wherein we might be concerned about the time to restore the business service if we simultaneously lose the data in the CF along with the system that produced that data). Each choice has its own advantages and disadvantages; choose the one that's right for you. --Mark Brooks --z/OS Sysplex Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of R.S. > Sent: 09 July, 2018 14:26 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sysplex between two hardware > > W dniu 2018-07-09 o 13:12, Vernooij, Kees (ITOPT1) - KLM pisze: > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > >> Behalf Of R.S. > >> Sent: 09 July, 2018 12:47 > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Sysplex between two hardware > >> > >> W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze: > >>> We all have lots of questions about your goals here, but the short > >> answer to your question is Yes, sysplex is the answer. I assume that > >> your two boxes are already connected in some way as to share access > to > >> data. Turning such a configuration into a sysplex may require some > >> additional hardware, but not a lot. > >>> -- If you want a full-function parallel sysplex, you would need to > >> create an internal coupling facility LPAR (ICF) in each CEC. > >>> -- You would need CF links to connect each ICF to the opposite CEC. > >>> > >>> -- I think you would also need server timing protocol (STP) to keep > >> clocks in synch; I have not tried running without STP. > >> > >> STP (or earlier sysplex timer) is mandatory for sysplex, even for > basic > >> sysplex. > >> For production parallel sysplex it is good idea to have standalone > CF. > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > >> > >> > > In this case: yes, but to be precise: not if you run a sysplex on 1 > box. The required 'common time source' can then be the time of that > machine. > > I thought the recommendation of a standalone CF was not current > anymore. > > Well, I was suggested by the topic - "two different hardware". > Regarding CF and availability - for availability reasons one should > avoid having CF and z/OS LPAR on the same hardware, which means: > a) at least 3 CPCs (of course CF-only box is much cheaper) > b) use CF structures replication which gives some performance penalty, > especially for non-local distances. > > Regards > -- > Radoslaw Skorupka > Lodz, Poland > I disagree with the statement " avoid having CF and z/OS LPAR on the same hardware" Avoiding SPOFs can well be done by z/OS LPARs on both CPCs and 2 CFs on each CPC. The need for " CF structures replication", I suppose you mean System-Managed CF Structure Duplexing, is not evident to me either. Since the last upgrade of MQ, every structure owner is perfectly able to recover its structures into another CF after a CF failure. I don't see much benefit in it, but I see the disadvantages you mention. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
STP (or earlier sysplex timer) is mandatory for sysplex, even for basic sysplex. For production parallel sysplex it is good idea to have standalone CF. Not if entire sysplex is in one box. If that is the case, SYSPLEX time is not needed. As long as all participants use the same time source, all will be well. The issue requiring an ETR is synchronization/tolerization for XCF. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, July 9, 2018 5:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex between two hardware W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze: > We all have lots of questions about your goals here, but the short answer to > your question is Yes, sysplex is the answer. I assume that your two boxes are > already connected in some way as to share access to data. Turning such a > configuration into a sysplex may require some additional hardware, but not a > lot. > > -- If you want a full-function parallel sysplex, you would need to create an > internal coupling facility LPAR (ICF) in each CEC. > > -- You would need CF links to connect each ICF to the opposite CEC. > > -- I think you would also need server timing protocol (STP) to keep clocks in > synch; I have not tried running without STP. STP (or earlier sysplex timer) is mandatory for sysplex, even for basic sysplex. For production parallel sysplex it is good idea to have standalone CF. -- Radoslaw Skorupka Lodz, Poland == -- 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, https://apac01.safelinks.protection.outlook.com/?url=www.mBank.pldata=02%7C01%7Callan.staller%40HCL.COM%7Ca337fe0b86b840b524f408d5e58954cd%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C1%7C636667300404700814sdata=pf0btoRfi3YbUVX3SPfjI0C%2B%2FTvkSY8yfb8TZDefjXg%3Dreserved=0, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, 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 ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohi
Re: Sysplex between two hardware
W dniu 2018-07-09 o 13:12, Vernooij, Kees (ITOPT1) - KLM pisze: -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: 09 July, 2018 12:47 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex between two hardware W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze: We all have lots of questions about your goals here, but the short answer to your question is Yes, sysplex is the answer. I assume that your two boxes are already connected in some way as to share access to data. Turning such a configuration into a sysplex may require some additional hardware, but not a lot. -- If you want a full-function parallel sysplex, you would need to create an internal coupling facility LPAR (ICF) in each CEC. -- You would need CF links to connect each ICF to the opposite CEC. -- I think you would also need server timing protocol (STP) to keep clocks in synch; I have not tried running without STP. STP (or earlier sysplex timer) is mandatory for sysplex, even for basic sysplex. For production parallel sysplex it is good idea to have standalone CF. -- Radoslaw Skorupka Lodz, Poland In this case: yes, but to be precise: not if you run a sysplex on 1 box. The required 'common time source' can then be the time of that machine. I thought the recommendation of a standalone CF was not current anymore. Well, I was suggested by the topic - "two different hardware". Regarding CF and availability - for availability reasons one should avoid having CF and z/OS LPAR on the same hardware, which means: a) at least 3 CPCs (of course CF-only box is much cheaper) b) use CF structures replication which gives some performance penalty, especially for non-local distances. Regards -- Radoslaw Skorupka Lodz, Poland == -- 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 025237, 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
Re: Sysplex between two hardware
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of R.S. > Sent: 09 July, 2018 12:47 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sysplex between two hardware > > W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze: > > We all have lots of questions about your goals here, but the short > answer to your question is Yes, sysplex is the answer. I assume that > your two boxes are already connected in some way as to share access to > data. Turning such a configuration into a sysplex may require some > additional hardware, but not a lot. > > > > -- If you want a full-function parallel sysplex, you would need to > create an internal coupling facility LPAR (ICF) in each CEC. > > > > -- You would need CF links to connect each ICF to the opposite CEC. > > > > -- I think you would also need server timing protocol (STP) to keep > clocks in synch; I have not tried running without STP. > > STP (or earlier sysplex timer) is mandatory for sysplex, even for basic > sysplex. > For production parallel sysplex it is good idea to have standalone CF. > > -- > Radoslaw Skorupka > Lodz, Poland > > In this case: yes, but to be precise: not if you run a sysplex on 1 box. The required 'common time source' can then be the time of that machine. I thought the recommendation of a standalone CF was not current anymore. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze: We all have lots of questions about your goals here, but the short answer to your question is Yes, sysplex is the answer. I assume that your two boxes are already connected in some way as to share access to data. Turning such a configuration into a sysplex may require some additional hardware, but not a lot. -- If you want a full-function parallel sysplex, you would need to create an internal coupling facility LPAR (ICF) in each CEC. -- You would need CF links to connect each ICF to the opposite CEC. -- I think you would also need server timing protocol (STP) to keep clocks in synch; I have not tried running without STP. STP (or earlier sysplex timer) is mandatory for sysplex, even for basic sysplex. For production parallel sysplex it is good idea to have standalone CF. -- Radoslaw Skorupka Lodz, Poland == -- 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 025237, 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
Re: Sysplex between two hardware
We all have lots of questions about your goals here, but the short answer to your question is Yes, sysplex is the answer. I assume that your two boxes are already connected in some way as to share access to data. Turning such a configuration into a sysplex may require some additional hardware, but not a lot. -- If you want a full-function parallel sysplex, you would need to create an internal coupling facility LPAR (ICF) in each CEC. -- You would need CF links to connect each ICF to the opposite CEC. -- I think you would also need server timing protocol (STP) to keep clocks in synch; I have not tried running without STP. . . 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 Timothy Sipples Sent: Friday, July 06, 2018 5:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Sysplex between two hardware Peter wrote: >We are looking up for a solution where we need a LPAR to have a hot standby >in other LPAR running in a different machine . >As we are trying to create a sysplex relationship between two LPARS running >in a different machines . >Apology for my ignorance and is it possible ? Yes, it's certainly possible and common. Here are a couple questions: 1. How far apart (in fiber distance) are these two physical machines? 2. What workload types would you like to configure across the two LPARs? Examples: MQ, Db2, CICS, IMS TM, IMS DB, WebSphere Application Server? 3. What goal(s) are you trying to accomplish? Are you trying to improve service levels, for example? Or perhaps trying to move workloads from one machine to another while minimizing (or eliminating) an outage? Something else? 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
Re: Sysplex between two hardware
Peter wrote: >We are looking up for a solution where we need a LPAR to have a hot standby >in other LPAR running in a different machine . >As we are trying to create a sysplex relationship between two LPARS running >in a different machines . >Apology for my ignorance and is it possible ? Yes, it's certainly possible and common. Here are a couple questions: 1. How far apart (in fiber distance) are these two physical machines? 2. What workload types would you like to configure across the two LPARs? Examples: MQ, Db2, CICS, IMS TM, IMS DB, WebSphere Application Server? 3. What goal(s) are you trying to accomplish? Are you trying to improve service levels, for example? Or perhaps trying to move workloads from one machine to another while minimizing (or eliminating) an outage? Something else? 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
Re: Sysplex between two hardware
Peter, What is your question exactly? If you MEAN a "hot standby" - which I understand to mean a system that is IPL'd but not being used, but could take on workload from a currently active and used system, I'd say that's not a SYSPLEX, that's a disaster recovery scenario. If you are trying to connect two ACTIVE and USED LPARS on different machines, that may or may not share worload, then that could be a SHAMPLEX, a SYSPLEX, possibly a parallel SYSPLEX or even a GLOBALLY DISPERSED PARALLEL SYSPLEX. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
