OK, so there are multiple MCAs (one for each dynamically created CLUSSNDR) all servicing the one S.C.T.Q, and they should be able to do their work independently, right?
I plan on testing this in my lab environment and posting the results when I yank the cables from the server to the SAN. I just wanted to get a feel from the list as to whether this was possible and worth testing. I'll see what other posts come about today and tomorrow (Morag??? :-)) and then test later in the week. -----Original Message----- From: Raabe, Stefan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 8:58 AM To: [EMAIL PROTECTED] Subject: AW: A double cluster to get 2 CLUSRCVR channels? Peter, a message destigned for a "remote" cluster queue gets a target queue assinged and a cluster channel to use and is then put to the SYSTEM.CLUSTER.TRANSMIT.QUEUE. I assume, that every mca gets only the messages that are assigned to its channel. On os/390, the correlid field holds the channel name and the S.C.T.Q is indexed by correlid, it is most likely that the mca does a get by correlid to pick up the proper messages. You share the S.C.T.Q queue between the cluster channels, so you share the storage, but i do not think that the P and NP messages will be mixed over the channels because the target queue is not known in the other cluster. Regards Stefan -----Ursprüngliche Nachricht----- Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 15. Juli 2003 14:29 An: [EMAIL PROTECTED] Betreff: Re: A double cluster to get 2 CLUSRCVR channels? I plan on separating the queues into the proper cluster. Queues that deal only with NP messages will be in CLUSTER1, and queues that deal with both P and NP messages will live in the other cluster. The goal being that WITHOUT replacing the standard cluster workload exit, NP messages destined for queues in CLUSTER1 will not be effected by channel problems in CLUSTER2. These channel "problems" could be large messages taking their time, or P messages holding up both P and NP messages while the P message waits to be logged on the receiving side. The only doubt I have is the fact that there is one common XMIT queue in this case (SYSTEM.CLUSTER.TRANSMIT.QUEUE) being serviced by 2 or more channels. ************** I got to think that one message at the head of the SYSTEM.CLUSTER.TRANSMIT.QUEUE that is held up for whatever reason would not impeded others behind it destined for other channels to other QMs in the same cluster or other channels in other overlapping clusters. ************** -----Original Message----- From: Neil Casey [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 12:30 AM To: [EMAIL PROTECTED] Subject: Re: A double cluster to get 2 CLUSRCVR channels? Hi Peter, you design pretty much pans out Ok. This is actually similar to the way we set up our clusters here. Our reasons for separating out the cluster channels are different (security rather than performance) but the result is the same. You might find that you need to use a cluster workload balancing exit to force the correct choice of cluster. If you are sending to a cluster queue (a request) and that queue is defined in only one of the clusters, then you will be fine. If you want to make the choice based not on the queue, but instead on the message size, then you will need to open your queues with bind(notfixed) and use the cluster workload exit to make the choice. If you are sending a response, based on the replyToQ and replyToQMgr fields, then either cluster is a valid choice, and the workload balancing algorithm gets to make the choice. The IBM default algorithm may not be able to make the choice that you want, in which case you will need to write or buy a workload balancing exit. This can also happen in an environment where the destination for a message is looked up in an external database (like LDAP) and the target queue manager and queue are both specified. Regards, Neil Casey. |---------+------------------------------> | | "Potkay, Peter M | | | (PLC, IT)" | | | <[EMAIL PROTECTED]| | | RTFORD.COM> | | | Sent by: MQSeries | | | List | | | <[EMAIL PROTECTED]| | | AC.AT> | | | | | | | | | 15/07/2003 13:09 | | | Please respond to | | | MQSeries List | | | | |---------+------------------------------> >--------------------------------------------------------------------------- -----------------------------------| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: A double cluster to get 2 CLUSRCVR channels? | >--------------------------------------------------------------------------- -----------------------------------| 3 QueueManagers (QMs) on 3 servers, QM1, QM2 and QMGateway. QM1 has a CLUSRCVR called TO.QM1.CLUSTER1 which is in CLUSTER1. It also has a CLUSRCVR called TO.QM1.CLUSTER2 which is in CLUSTER2. QM1 is a full repository for a cluster name list called CLUSTER1andCLUSTER2. QM2 has a CLUSRCVR called TO.QM2.CLUSTER1 which is in CLUSTER1. It also has a CLUSRCVR called TO.QM2.CLUSTER2 which is in CLUSTER2. QM2 is a full repository for a cluster name list called CLUSTER1andCLUSTER2. QMGateway has a CLUSRCVR called TO.QMGateway.CLUSTER1 which is in CLUSTER1. It also has a CLUSRCVR called TO.QMGateway.CLUSTER2 which is in CLUSTER2. The point of all this is so I can have 2 different dynamically created CLUSSNDR channels into each QM. I wish to do this for 2 reasons. First, CLUSTER1 will only have queues and applications that deal with messages greater than 50 MEG in size. CLUSTER2 will only deal with messages smaller than 500 bytes in size (numbers have been exaggerated to make the point). So I would like to insure that the 50MEG lunkers do not block the 500 byte peewees on the CLUSSNDRs as the big messages take their sweet time being sent across. Will my idea work? If I have 2 clusters, I should have 2 channels that should not interfere with each other, correct? I wonder if the fact that there is still only 1 SYSTEM.CLUSTER.TRANSMIT.QUEUE to be shared between the 2 CLUSSNDRs will invalidate this concept (i.e. a message taking its sweet time going down a CLUSSNDR in CLUSTER1 will prevent a little message sitting in the XMIT queue from going down a CLUSSNDR in CLUSTER2.)? Oh yeah, the second (and more important) reason I want to this is the whole concept of how a QM deals with persistent and non persistent messages when it relies on a SAN (remember that thread a little while back titled "How a MQSeries Hub does its thing with persistent / non-persi st m essages"). One of the things we agreed upon was that if both P and NP messages were being sent across a channel, and the receiving side of that channel had a SAN / hard drive outage all the message would start backing up on the sending side. The reason being was that even if the channel speed was FAST, P messages would still need to be logged and if the RCVR was waiting for resources to do that logging, it could not process NP messages either. A way around this is 2 channels. So if I have two CLUSSNDRs going to each QM, and make one of the clusters only NP messages, and the CLUSSNDRs/CLUSRCVRs are set to FAST, then I assume NP messages will not be blocked by P messages waiting to be logged during a SAN blip in the other cluster (but the same QMs). Unless of course the fact that all messages, big and small, persistent and non, queue up in the same SYSTEM.CLUSTER.TRANSMIT.QUEUE. Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
