Neil, understand what you and Paul described. I now have to clarify, what the responding application really does. The scenario you describes shold only happen, when the applications use request / reply messages. In my case the applications use datagrams, so the responder has to address a queue. But I am not sure, whether the responding application sets the qmgr on the put commands. This would explain the behaviour I found.
Thanks a lot for all the input, I will check the applications (and then go for a three week vacation ;-) ). I will send the solution I found back to the list. Regards and many thanks. Hubert > -----Ursprüngliche Nachricht----- > Von: MQSeries List [SMTP:[EMAIL PROTECTED] im Auftrag > von Neil Casey > Gesendet am: Donnerstag, 28. Juli 2005 00:45 > An: [email protected] > Betreff: Re: AW: AW: AW: MQ Clustering question > > Hi Hubert, > > I think you have missed Pauls point slightly. > > Even though your ReplyToQ is a member of the cluster, that information is > not being used by MQ to route the response message. You can verify this if > you run a cluster workload exit which prints out the control blocks > showing > the routing information. > > If your client and server applications are normal, then the client will > not > populate the ReplyToQM, only the ReplyToQ. In this case, the Client app > queue manager will fill in its own name before sending the message. When > the server application responds, it will fill in both the QName and QMName > from the Request MQMD into the Response MQOD. This will cause MQ to route > via the QMgrName, not the queue name, and both clusters are eligible. > > In order to avoid this, Paul suggests that you could create a QMgrAlias on > your client app queue manager (called QM2_SECURE). The QMgrAlias needs to > be in the CL_SECURE cluster. Your secure client application then should > populate the ReplyToQ as it does now, but also put QM2_SECURE into the > ReplyToQM field. This stops the queue manager putting its own name in > there. > > When your server app builds in MQOD, it ends up with a QMgrName of > QM2_SECURE, which is then resolved to the QMgrAlias which only exists in > the secure cluster. This will force the responses to traverse the secure > cluster only. > > Regards, > > > > > Neil Casey > > > __________________________________________________________________________ > ________ > > > Senior Systems Programmer > Phone : +61 3 9886 2375 (x82375) > > > Middleware Services MQ Support > Mobile: +61 414 615 334 > > > Cross Platform & Transaction Services > Fax : +61 3 9886 2700 (x32700) > > > Southern Star Technology > Email : > > [EMAIL PROTECTED] > > > > > > > > This email is sent by or on behalf of the named sender identified above. > If > you do not wish to receive any email marketing material from this person > in > the future, please forward the contents of this email to > [EMAIL PROTECTED] with the word "unsubscribe" in the subject > box. If you do not forward the contents of this email with your > unsubscription then it may not be able to be implemented. If you wish to > unsubscribe from all central email marketing lists used by our business, > please forward the contents of this email to > [EMAIL PROTECTED] with the message "unsubscribe from all > central email marketing lists" in the subject box. If you do not forward > the contents of this email with your unsubscription then it may not be > able > to be implemented. > > > The information contained in this email communication may be confidential. > You should only disclose, re-transmit, copy, distribute, act in reliance > on > or commercialise the information if you are authorised to do so. Any views > expressed in this email communication are those of the individual sender, > except where the sender specifically states them to be the views of a > member of the National Australia Bank Group of companies. Any advice > contained in this e-mail has been prepared without taking into account > your > objectives, financial situation or needs. Before acting on any advice in > this e-mail, National Australia Bank Limited recommends that you consider > whether it is appropriate for your circumstances. If this e-mail contains > reference to any financial products, the National recommends you consider > the Product Disclosure Statement (PDS) or other disclosure document > before > making any decisions regarding any products. The National Australia Bank > Group of companies does not represent, warrant or guarantee that the > integrity of this communication has been maintained nor that the > communication is free of errors, virus or interference. > > > > > > > > > > > Hubert Kleinmanns > > <Hubert.Kleinmann > > [EMAIL PROTECTED] To > > COM> [email protected] > > Sent by: MQSeries cc > > List > > <[EMAIL PROTECTED] Subject > > V.MEDUNIWIEN.AC.A AW: AW: AW: MQ Clustering question > > T> > > > > > > 07/28/2005 02:30 > > AM > > > > > > Please respond to > > MQSeries List > > <[EMAIL PROTECTED] > > V.MEDUNIWIEN.AC.A > > T> > > > > > > > > > > Paul, > > essentially it does make sense to me. The cluster queue, which was used > for > the way back to host, is defined with DEFBIND(OPEN). So when the non-SSL > channel was the first in the load balancing mechanism of MQ, I understand > why all message went the same way. Next test the should go the SSL > channels > - hopefully. > > I have to check with our application guys, if they address a cluster queue > or a qmgr. > > What is about the APARs David mentioned? > > Regards > Hubert > > > > -----Ursprüngliche Nachricht----- > > Von: MQSeries List [SMTP:[EMAIL PROTECTED] > im Auftrag > > von Paul Clarke > > Gesendet am: Mittwoch, 27. Juli 2005 18:02 > > An: [email protected] > > Betreff: Re: AW: AW: MQ Clustering question > > > > Hubert, > > > > I was actually responding to your previous note when this one came in. I > > believe what you're seeing is tied in to what I said in my original > note. > > Remember that there are two distinct phases to queue resolution. Either > > the > > message is targeting a local queue definition (which includes cluster > > queues on remote boxes, remote queues etc) or it's targetting a remote > > queue manager in which case the queue name itself is somewhat irrelevant > > until we get there. > > > > So, in your previous note if I do a put MQPUT1(Qm="",Q="Q.SECURE") the > > Queue Manager will look for a local definition of Q.SECURE. It will find > > one defintion that belongs to cluster CL_SECURE, there is a single > channel > > for this cluster so the message will go the secure route to QM1. > > > > However, I could also put using MQPUT1(Qm="QM1",Q="Q.SECURE"). Now, we > are > > targetting a queue manager and we don't really care what the name of the > > queue is. So, the QM will look to see how many ways it has of sending a > > message to QM1 (not Q.SECURE). It finds two channels to QM1, TO.QM1.FAST > > and To.QM1.SECURE. It is pot-luck as to which one it will choose. > > Essentially it will round-robin. > > > > I suspect this latter case is what your seeing in your reply case. Most > > applications take the reply queue manager and reply queue name and open > > those for the response. In other words the reply is targetting the queue > > manager not a cluster queue that lives in a particular cluster. > > > > There are a couple of solutions to this problem. One is you could > > predefine > > a reply queue for your secure replies which lives in the secure cluster. > > Alternatively, you could define a queue manager alias, such as > QM2_SECURE, > > which lives in the secure cluster. You then set QM2_SECURE as the reply > to > > queue manager forcing QM1 to look for defintiions only in the secure > > cluster. > > > > Does this explain what you're seeing or have I messed up somewhere ? > > > > Cheers, > > P. > > > > Paul G Clarke > > WebSphere Messaging Clients > > IBM Hursley > > > > > > > > > > > > > > Hubert Kleinmanns > > > > <Hubert.Kleinmann > > > > [EMAIL PROTECTED] > To > > > > COM> > [email protected] > > > > Sent by: MQSeries > cc > > > > List > > > > <[EMAIL PROTECTED] > Subject > > > > V.MEDUNIWIEN.AC.A AW: AW: MQ Clustering question > > > > T> > > > > > > > > > > > > 27/07/2005 15:52 > > > > > > > > > > > > Please respond to > > > > MQSeries List > > > > > > > > > > > > > > > > > > > > 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 > > > > 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
