Sysplex between two hardware

Discussion:

(too old to reply)

Peter

2018-07-06 02:45:56 UTC

Hi

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 ?

Peter

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

p***@gmail.com

2018-07-06 04:33:39 UTC

Permalink

Yes, most definitely, it's common to have Sysplexes with LPARs on different CECs. Good idea if you need HA and your application supports it. You can even have the CECs at different sites, again if your application can tolerate the response time elongation (as will likely happen if the disk is at a different site from the CEC).

Another Peter

Post by Peter
Hi
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 ?
Peter
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

Vince Getgood

2018-07-06 08:19:15 UTC

Permalink

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Timothy Sipples

2018-07-06 12:39:31 UTC

Permalink

Post by Peter
We are looking up for a solution where we need a LPAR to have a hot

standby

Post by Peter
in other LPAR running in a different machine .
As we are trying to create a sysplex relationship between two LPARS

running

Post by Peter
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: ***@sg.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Bill Ogden

2018-07-06 13:23:42 UTC

Permalink

Date: Thu, 5 Jul 2018 09:48:03 -0500
TUPL DC A(TU1,TU2,TU3,TU4,TU5,TU6,TU7,TU8+X'80000000)

Thank you!

IBM-MAIN is magical. A minute AFTER I hit "send" for my message I saw
the error. If the magic could be improved to work a minute BEFORE
hitting "send" it would be even better.

Bill

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Ed Jaffe

2018-07-06 13:51:11 UTC

Permalink

A minute AFTER I hit "send" for my message I saw the error.

I do my best proofreading *after* I press the <Send> key...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Seymour J Metz

2018-07-06 14:34:50 UTC

Permalink

These two commands are quite different:

ERASE CMS EXEC
EXEC CMS ERASE

The fastest PA1 in the west.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Ed Jaffe <***@PHOENIXSOFTWARE.COM>
Sent: Friday, July 6, 2018 9:51 AM
To: IBM-***@listserv.ua.edu
Subject: Re: DYNALLOC

A minute AFTER I hit "send" for my message I saw the error.

I do my best proofreading *after* I press the <Send> key...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://secure-web.cisco.com/1k_Zs8z-_9uUfmqbgc7vpW3YAkqiWJQ1-dkwoiAwQx7LD3a0Coc4yPIG5ZXYEMOi00sSQ59hBTz4hNr3eRpaQHQlzE9RzxaivWpz35VJfMmdeVXdVeaVsMYbcZxXRb4gtsBdRfdjfwMsSeet4ArvKC5KMigrb56GIz7HVWoH7fC1m5T_jx103WaA9zuEAxkR_4dcSf5s9e1IlCSGOmc4jKs-jd4jNFiB_w7RYMjpDiANarD4NLHFCQz-lcoytFqn00QGpir1eeyFqvT5eZTAxvRpiwHTCNp2cR5MeRVTS3jvZgU1uI7MOgSwQuRarQUSi7Fr2-Up7ZwX7yviMTpQP2hp7DqNPJhq8I0t6O4uk2Jgb4jIQ-jkw_SaRP5DAiVznk4NOzUDUcGO3pJDxAZI6kcbj2kCOiTU1Aqnr-WqX1WJdnegdzfTPVwmCoqDhyJPb/https%3A%2F%2Fwww.phoenixsoftware.com%2F

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Peter Hunkeler

2018-07-10 18:41:53 UTC

Permalink

Post by Ed Jaffe

A minute AFTER I hit "send" for my message I saw the error.

I do my best proofreading *after* I press the <Send> key...

I'm excellent at finding my typos when I read my post after it is echoed back to me.

--
Peter Hunkeler

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Hobart Spitz

2018-07-10 19:08:03 UTC

Permalink

It beats the alternative. The more I proofread, the more improvements I
make and the longer my posts get. 8-D

OREXXMan
JCL is the buggy whip of 21st century computing. Stabilize it.
Put Pipelines in the z/OS base. Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

Post by Peter Hunkeler

Post by Ed Jaffe

A minute AFTER I hit "send" for my message I saw the error.

I do my best proofreading *after* I press the <Send> key...

I'm excellent at finding my typos when I read my post after it is echoed back to me.
--
Peter Hunkeler
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Elardus Engelbrecht

2018-07-06 14:00:58 UTC

Permalink

Post by Ed Jaffe

A minute AFTER I hit "send" for my message I saw the error.

I do my best proofreading *after* I press the <Send> key...

Or, AFTER you pressed that famous key "ENTER", you see you are making a career ending 6-letter-word mistake...

After you (and your boss) see horrible output in a job/screen/Syslog, then you wish you have PROOFREAD that intended command before running it...

Oh, BTW, I once send a somewhat naugthy dirty joke in a wrong WhatsApp group. Oooops...

I believe it is Friday today... ;-)

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Jesse 1 Robinson

2018-07-06 16:23:06 UTC

Permalink

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
***@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples
Sent: Friday, July 06, 2018 5:39 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Sysplex between two hardware

Post by Peter
We are looking up for a solution where we need a LPAR to have a hot

standby

Post by Peter
in other LPAR running in a different machine .
As we are trying to create a sysplex relationship between two LPARS

running

Post by Peter
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: ***@sg.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

R.S.

2018-07-09 10:46:59 UTC

Permalink

Post by Jesse 1 Robinson
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: ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Vernooij, Kees - KLM , ITOPT1

2018-07-09 11:26:32 UTC

Permalink

Post by Jesse 1 Robinson
-----Original Message-----
Behalf Of R.S.
Sent: 09 July, 2018 12:47
Subject: Re: Sysplex between two hardware

Post by Jesse 1 Robinson
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.

Post by Jesse 1 Robinson
-- If you want a full-function parallel sysplex, you would need to

create an internal coupling facility LPAR (ICF) in each CEC.

Post by Jesse 1 Robinson
-- 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

R.S.

2018-07-09 12:26:37 UTC

Permalink

Post by Vernooij, Kees - KLM , ITOPT1

Post by Jesse 1 Robinson
-----Original Message-----
Behalf Of R.S.
Sent: 09 July, 2018 12:47
Subject: Re: Sysplex between two hardware

Post by Jesse 1 Robinson
We all have lots of questions about your goals here, but the short

Post by Jesse 1 Robinson
-- If you want a full-function parallel sysplex, you would need to

create an internal coupling facility LPAR (ICF) in each CEC.

Post by Jesse 1 Robinson
-- 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

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: ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Vernooij, Kees - KLM , ITOPT1

2018-07-09 12:47:32 UTC

Permalink

Post by Jesse 1 Robinson
-----Original Message-----
Behalf Of R.S.
Sent: 09 July, 2018 14:26
Subject: Re: Sysplex between two hardware

Post by Vernooij, Kees - KLM , ITOPT1

Post by Jesse 1 Robinson
-----Original Message-----

Post by Vernooij, Kees - KLM , ITOPT1

Post by Jesse 1 Robinson
Behalf Of R.S.
Sent: 09 July, 2018 12:47
Subject: Re: Sysplex between two hardware

Post by Jesse 1 Robinson
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

Post by Vernooij, Kees - KLM , ITOPT1

Post by Jesse 1 Robinson
data. Turning such a configuration into a sysplex may require some
additional hardware, but not a lot.

Post by Jesse 1 Robinson
-- If you want a full-function parallel sysplex, you would need to

create an internal coupling facility LPAR (ICF) in each CEC.

Post by Jesse 1 Robinson
-- 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

Post by Vernooij, Kees - KLM , ITOPT1

Post by Jesse 1 Robinson
sysplex.
For production parallel sysplex it is good idea to have standalone

CF.

Post by Vernooij, Kees - KLM , ITOPT1

Post by Jesse 1 Robinson
--
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.

Post by Vernooij, Kees - KLM , ITOPT1
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
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Mark A. Brooks

2018-07-09 13:41:23 UTC

Permalink

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

R.S.

2018-07-09 14:20:43 UTC

Permalink

Post by Mark A. Brooks
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

Vernooij, Kees - KLM , ITOPT1

2018-07-09 15:08:23 UTC

Permalink

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.

Post by Jesse 1 Robinson
-----Original Message-----
Behalf Of Allan Staller
Sent: 09 July, 2018 16:33
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-----
Behalf Of R.S.
Sent: Monday, July 9, 2018 9:20 AM
Subject: Re: Sysplex between two hardware

Post by Mark A. Brooks
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.

Post by Mark A. Brooks
--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.pl&da
ta=02%7C01%7Callan.staller%40HCL.COM%7C10622a536f78423874c708d5e5a72f4d%
7C189de737c93a4f5a8b686f4ca9941912%7C0%7C1%7C636667428590770229&sdat
a=eg%2FISBQY4%2BT0T%2BRPr%2FPulpGdLql5wRKMACmRqT4VxsQ%3D&reserved=0,
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,
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
--------------------------------------------------------------
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
prohibited. If you have received this email in error please delete it
and notify the sender immediately. Before opening any email and/or
attachments, please check them for viruses and other defects.
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
--------------------------------------------------------------
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

********************************************************
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Jesse 1 Robinson

2018-07-09 16:07:17 UTC

Permalink

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
***@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOPT1) - KLM
Sent: Monday, July 09, 2018 8:08 AM
To: IBM-***@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.

Post by Jesse 1 Robinson
-----Original Message-----
On Behalf Of Allan Staller
Sent: 09 July, 2018 16:33
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-----
On Behalf Of R.S.
Sent: Monday, July 9, 2018 9:20 AM
Subject: Re: Sysplex between two hardware

Post by Mark A. Brooks
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.

Post by Mark A. Brooks
--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

Vernooij, Kees - KLM , ITOPT1

2018-07-10 06:23:59 UTC

Permalink

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.

Post by Jesse 1 Robinson
-----Original Message-----
Behalf Of Jesse 1 Robinson
Sent: 09 July, 2018 18:07
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
-----Original Message-----
Behalf Of Vernooij, Kees (ITOPT1) - KLM
Sent: Monday, July 09, 2018 8:08 AM
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.

Post by Mark A. Brooks
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.

Post by Mark A. Brooks
--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,

Peter

2018-07-10 06:40:43 UTC

Permalink

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

Post by Vernooij, Kees - KLM , ITOPT1
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.

Post by Mark A. Brooks
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.

Post by Mark A. Brooks
--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,

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

Peter Hunkeler

2018-07-10 06:02:46 UTC

Permalink

Peter,You've been asking for help here. I consider it very impolite that you don't answer peoples inquiries for details.
--
Peter Hunkeler

Von: Peter <***@GMAIL.COM> An: IBM-***@LISTSERV.UA.EDU Betreff: Sysplex between two hardware Datum: 06.07.18, 04:45

Hi

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 ?

Peter

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Peter

2018-07-10 06:19:28 UTC

Permalink

I apologise as I was on personal leave and I will be back on Monday.

I honestly appreciate all the replies and query for which I can
collectively chose and research

Thanks again

Post by Vince Getgood
Peter,
You've been asking for help here. I consider it very impolite that you
don't answer peoples inquiries for details.
--
Peter Hunkeler
*Betreff: * Sysplex between two hardware
*Datum: * 06.07.18, 04:45
Hi
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 ?
Peter
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

Ravi Gaur

2018-07-10 07:58:18 UTC

Permalink

This post might be inappropriate. Click to display it.

Martin Packer

2018-07-10 08:03:48 UTC

Permalink

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

Post by Ravi Gaur
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,

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Ravi Gaur

2018-07-10 08:35:24 UTC

Permalink

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Martin Packer

2018-07-10 08:48:05 UTC

Permalink

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: ***@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 <***@GMAIL.COM>
To: IBM-***@LISTSERV.UA.EDU
Date: 10/07/2018 09:35
Subject: Re: Sysplex between two hardware
Sent by: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU>

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 ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN