Hello Allan,
Thanks for this clarification.
Regards
------------------------------------------------------------------------
*De :* Allan Staller [mailto:[email protected]]
*Envoyé :* lundi 24 juin 2024 à 13:52
*Pour :* [email protected]
*Objet :* GRS in MONOPLEX without physical CTCs ?
Classification: Confidential
IMO, no.
The various images will not attempt to communicate with each other in Monoplex
mode.
The CTC's should be defined and then run GRS in RING mode.
As I previously posted, the more systems to be communicated with in the longer
GRS will take to respond.
This escalates very rapidly.
CF or CF engine is not required.
HTH,
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
MANCINI Frédéric (80)
Sent: Friday, June 21, 2024 8:45 AM
To: [email protected]
Subject: Re: GRS in MONOPLEX without physical CTCs ?
[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don’t click links or open attachments as it may be a Phishing email,
which can steal your Information and compromise your Computer.]
Actually, we do share a few DASD devices between our lpars.
Thanks to all the replies, I understand better now what we must do in order to
implement a fully functional GRS without buying an external coupling facility.
I understand that we can leave our lpars in MONOPLEX mode and use GRS managed
CTCs, possibly on a ring architecture in order to minimize the hardware
connections.
Using virtual CTCs without interconnecting the MONOPLEX lpars doesn't seem to
make sense for resource serialization.
Am I right ?
------------------------------------------------------------------------
*De :* Tom Marchant [mailto:[email protected]]
*Envoyé :* vendredi 21 juin 2024 à 15:30 *Pour :* [email protected]
*Objet :* GRS in MONOPLEX without physical CTCs ?
The OP hasn't said whether or not any DASD is shared.
If there is a need to share PDSE, it is only supported within a
Sysplex. MIM is not sufficient
--
Tom Marchant
On Fri, 21 Jun 2024 13:49:29 +0200, Radoslaw Skorupka <[email protected]>
wrote:
To complement:
Parallel Sysplex - a CF is required, which mean sysplex links
(emulated, free - for PS within single CPC). GRS is STAR mode is
possible and strongly suggested. (GRSplex is required, the mode is suggested).
Base Sysplex - CTC links required. In the old days also sysplex timer.
Now it can be sysplex link to provide time synchronization for STP
(Server Time Protocol). The GRS is mandatory and it's configuration
is RING, which is not the best from performance point of view. For
base sysplex within single CPC there are no STP-only links, but CTC
over FICON is required. Note: the FICON can be shared, that means
used for other purposes.
Monoplex. GRSplex is still possible (unless something changed) and it
is RING topology with drawbacks mentioned above. Of course multiple
monoplex LPARs may share DASD without GRSplex, but again it is not
seamless - at least PDSE sharing is almost impossible.
...and there is CA-MIM family of products. :-)
--
Radoslaw Skorupka
Lodz, Poland
W dniu 21.06.2024 o 08:41, Brian Westerman pisze:
You can just use extra FICON interfaces as FCTC's. IBM refers to that method
as a baby sysplex. It allows you to have GRS in ring mode. TO have star mode
you need CF's.
If you have multiple LPARs and you share dasd, then you need either CF's
(expensive) or Ficon CTCs (pretty cheap). The setup is very simple. CF's are
much faster but ficon CTC's easily handle 3,4 or 5 lpars without any issues at
all.
Brian
--------------------------------------------------------------------
-- For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO
IBM-MAIN
---------------------------------------------------------------------
- For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO
IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] 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 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,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
