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