Paul, yesterday we did a SSL test. We have two overlapping cluster - one using SSL, the other one without SSL. We use to systems - one z/OS host and one AIX server - for the tests. Both systems are members of both clusters.
First we put the queues into the non-SSL cLuster. The messages were sent from a z/OS host to an AIX system and back via cluster queues. On AIX an application reads the messages, creates an answer and puts them to a respond queue. I could see (using your famous MO71 support pac ;-) ), that the message were transmitted via the non-SSL channel in both directions. Then we altered the queues and put them to the SSL cluster. From z/OS to AIX the messages were now sent via the SSL channel - fine. But on the way back, the messages were sent via the non-SSL channel :-(. Would you expect such a behaviour? We did no cluster refresh, but with MQMON I could verify, that the queues we use did really move from the non-SSL to the SSL cluster. Regards Hubert > -----Ursprüngliche Nachricht----- > Von: MQSeries List [SMTP:[EMAIL PROTECTED] im Auftrag > von Kleinmanns, Hubert (ext.) > Gesendet am: Montag, 25. Juli 2005 17:15 > An: [email protected] > Betreff: AW: AW: MQ Clustering question > > Paul, > > let me describe a possible scenario: > > 1. QMgr QM1 hosts two queues: Q.SECURE and Q.FAST. > > 2. Messages to Q.SECURE have to be send via a SSL channel. > > 3. Messages to Q.FAST have to be send via a non-SSL channel. > > 4. QM1 is a member of two clusters CL_SECURE and CL_FAST. > > 5. Cluster receiver on QM1 are named TO.QM1.SEC (defined for cluster > CL_SECURE) and TO.QM1.FAST (defined for cluster CL_FAST). > > 6. An application connected to another QMgr QM2 - which is member of both > clusters too - puts message, with high security impact to queue Q.SECURE > and > other messages, with high speed requirements to queues Q.FAST. > > In this scenario QM2 knows two different ways to QM1. Would messages to > queue Q.SECURE be sent over channel TO.QMGR1.SEC only or over both > channel? > How can I assure, that message to queue Q.SECURE are NOT send over the > insecure channel TO.QM1.FAST? > > Regards > Hubert > > > > > -----Ursprüngliche Nachricht----- > > Von: MQSeries List [SMTP:[EMAIL PROTECTED] im > Auftrag > > von Paul Clarke > > Gesendet am: Donnerstag, 21. Juli 2005 17:35 > > An: [email protected] > > Betreff: Re: AW: MQ Clustering question > > > > Hubert, > > > > Sorry for the delay - I've been on leave. > > > > I'm not sure what you want me to explain or in fact what your concern > is. > > Bear in mind that MQ does its routing in two stages. If the QM is not > > local > > all it cares about is how to get to the QM. If the QM is local then it > > routes to the individual queue. So, if you're targetting a remote QM > (via > > a > > remote queue if necessary) all MQ will concern itself with is "do I know > > how to get to this remote QM". We don't care what the target queue name > is > > and therefore don't need a cluster definition of it. This is the same > > principle temporary reply queues work and why you don't need a remote > > queue > > definition for each remote queue your sending messages to. Anyway, > > presumably you have a cluster queue manager telling MQ how to get to > your > > remote QM so off it goes. > > > > Clustering is still very useful to send messages to non-cluster queues > and > > just using it as a way to manage the channel definitions etc. > > > > Does this clarify at all ? > > > > Cheers, > > P. > > > > Paul G Clarke > > WebSphere Messaging Clients > > IBM Hursley > > > > > > > > MQSeries List <[email protected]> wrote on 14/07/2005 > > 13:46:30: > > > > > T.Rob, David, > > > > > > I do not know, who is right. I would expect a behaviour as David > > describes, > > > but I would be not very surprised, whe T.Rob is right. I am in doubt, > > > because MQ tries to find a way to the target QMgr. E. g. when you > define > > a > > > remote queue without having a local tranmission queue and "normal" > > sender > > / > > > receiver channel, but MQ "knows" a cluster channel to the target QMgr, > > the > > > message will be send using the cluster channel, although the remote > > queue > > as > > > well as the target queue are NOT in any cluster. > > > > > > Maybe we need a "real" expert (like Paul Clarke ;-) ) to clarify the > > > situation. > > > > > > Regards > > > Hubert > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: MQSeries List [SMTP:[EMAIL PROTECTED] im > > Auftrag > > > > von David C. Partridge > > > > Gesendet am: Donnerstag, 14. Juli 2005 14:32 > > > > An: [email protected] > > > > Betreff: Re: MQ Clustering question > > > > > > > > T. Rob said: > > > > > > > > >When you have overlapping clusters and two channels leading to the > > same > > > > instance of > > > > >a cluster queue, both channels are eligible to send the message. > > > > >This is true even if the channels are in different clusters and the > > > > cluster > > > > queue > > > > >exists in only one of them. > > > > > > > > No that shouldn't happen IMO - if a cluster queue is defined in only > > one > > > > cluster, then only the cluster channels for THAT cluster should be > > > > eligible > > > > to send messages to that queue. The APAR I was referring to in my > > > > earlier > > > > post related to the problem that it WAS behaving as you describe. > > > > > > > > I'm still trying to find out the relevant APAR number and platforms. > > > > > > > > David > > > > -----Original Message----- > > > > From: MQSeries List [mailto:[EMAIL PROTECTED] On > > Behalf > > > > Of > > > > Wyatt, T Rob > > > > Sent: 14 July 2005 13:22 > > > > To: [email protected] > > > > Subject: Re: MQ Clustering question > > > > > > > > Rao, > > > > > > > > Remember that clusters are really just namespaces. When you have > > > > overlapping clusters and two channels leading to the same instance > of > > a > > > > cluster queue, both channels are eligible to send the message. This > > is > > > > true > > > > even if the channels are in different clusters and the cluster queue > > > > exists > > > > in only one of them. You can set NETPRTY on the channels so one is > > > > favored > > > > over the other but that does not provide the QOS you want. > > > > > > > > I believe, and someone please correct me if I am wrong, that your > only > > > > option here is to create a workload exit or fall back to classic > > channels. > > > > If you use classic channels, they can coexist with the cluster, you > > just > > > > need to point the channels at QMgr aliases that are not known to the > > > > cluster. So if you want to send to cluster QMgr QM1 then you would > > define > > > > a > > > > QMgr alias on it like... > > > > > > > > DEF QR(QM1.QOS) RQMNAME('QM') RNAME(' ') CLUSTER(' ') CLUSNL(' ') > > > > > > > > On the sending side you need an XMitQ and channel to QM1.QOS. As > long > > as > > > > QM1.QOS is not known to the cluster, you can direct messages down > this > > > > channel. You can have as many of these as you need such that normal > > > > messages use the cluster channels and batch or large messages use > one > > of > > > > the > > > > QOS channels. > > > > > > > > Hope that helps so you don't have to tear down you cluster! > > > > > > > > -- T.Rob > > > > > > > > -----Original Message----- > > > > From: MQSeries List [mailto:[EMAIL PROTECTED] > > Behalf > > > > Of > > > > Rao Adiraju > > > > Sent: Thursday, July 14, 2005 4:31 AM > > > > To: [email protected] > > > > Subject: MQ Clustering question > > > > > > > > > > > > Fellas > > > > > > > > We have connected two queue managers - say QM1 and QM2 by putting > them > > in > > > > a > > > > cluster. We have a requirement to support Quality of Service (Qos) - > > in > > > > the > > > > sense we need three separate channels between them to support > online, > > > > batch, > > > > bulk data transfer. > > > > > > > > So the next suggestion came is - to define three clusters between > > these > > > > same > > > > two queue managers with each cluster having its own Cluster sender / > > > > Receiver channels to support this QOS. > > > > > > > > Here comes my question - in Cluster SENDER channel definitions I > > didn't > > > > see > > > > any option of specifying transmission queue name and what I have > seen > > is > > > > all > > > > three sender channels are polling on SYSEM.CLUSTER.TRANSMIT.QUEUE. > So > > even > > > > going to this length, am I stuck up with Single Transmission queue > ??? > > > > > > > > 1) Is there a way to tie up each Cluster Sender channel to a > specified > > > > transmission queue or not. > > > > > > > > 2) Is there any other way of implementing clusters so that the three > > QoS > > > > can > > > > be supported. > > > > > > > > My personal preference is to get rid of this clustering and use DQM > - > > with > > > > three different transmission queues, three Sender channels. > > > > > > > > Thanks in advance > > > > > > > > Cheers > > > > > > > > Rao > > > > > > > > ***************************************************** > > > > * Rao ADIRAJU * > > > > * Distributed Systems Consultants Pty. Ltd. * > > > > * GPO Box 1177, Canberra - ACT - 2601 * > > > > * AUSTRALIA * > > > > * Email: [EMAIL PROTECTED] * > > > > * [EMAIL PROTECTED] * > > > > * > > > > * Tel:+61-419-022-126 Fax:+61-262-900-200 * > > > > ***************************************************** > > > > > > > > Instructions for managing your mailing list subscription are > provided > > in > > > > the > > > > Listserv General Users Guide available at http://www.lsoft.com > > > > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > > > > > > Instructions for managing your mailing list subscription are > provided > > in > > > > the > > > > Listserv General Users Guide available at http://www.lsoft.com > > > > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > > > > > > Instructions for managing your mailing list subscription are > provided > > in > > > > the Listserv General Users Guide available at http://www.lsoft.com > > > > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > > > > Instructions for managing your mailing list subscription are provided > in > > > the Listserv General Users Guide available at http://www.lsoft.com > > > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > Instructions for managing your mailing list subscription are provided in > > the Listserv General Users Guide available at http://www.lsoft.com > > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
