| Author |
Message
|
| klamerus |
 Posted: Thu Jun 07, 2007 3:33 pm Post subject: Problem with remote clustered queues??? |
 |
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
We've run into an issue and don't know if we're trying to do something that isn't possible.
Here's the scenario.
We have 5 Windows servers in one MQ cluster. This is MQ 5.3 on Windows 2000.
One of these servers acts as the "entry" point into the system. Requests are sent to an "input" queue on this box (called the gateway).
4 of the 5 servers have a queue called the "work" queue.
A program running on the gateway server reformats the original message and puts it on the work queue, resulting in messages being distributed across the other 4 servers.
Other programs running on the 4 servers perform work reading from this work queue.
Most work comes to the "input" queue via a channel from a queue on one of our mainframe systems.
We just created a new application on a new mainframe. Since this is newer we were able to format the message as needed by the 4 work servers above so we wanted to have the channel from it's queue connect directly to the clustered work queues, but have found this doesn't work.
So, the question is can a channel send messages from one MQ queue to clustered queues? It appears it cannot.
If this isn't possible can we create a new queue on the gateway box for these new messages and somehow forward the messages sent to it (via the channel form the new mainframe queue) to our clustered queues?
We really dont' want to create a new program on the gateway server that simply pulls messages off of a queue in order to put them on our work distribution queues.
_________________
Careful with that VAX Eugene |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Jun 07, 2007 3:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
This is easy to do.
When sending a message to a cluster through a gateway from a qmgr outside the cluster you need a cluster alias:
On the gateway
| Code: |
| def qr(MY.CLUSTER.ALIAS) |
On the Mainframe
| Code: |
| def qr(MY.CLUSTER.ALIAS) RQMNAME(MY.CLUSTER.ALIAS) XMITQ(GATEWAYQMGR) |
Then send put your messages to
qmgr MY.CLUSTER.ALIAS and queue MY.WORK.QUEUE.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| klamerus |
| Posted: Thu Jun 07, 2007 4:24 pm Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
I'm not sure I'm describing this properly.
We have a set of 4 queues with the same name in our cluster. We can put messages on them from an application writing to that "clustered" queue, but we cannot connect a channel from a remote system queue to it. We can connect that channel from a remote system to a single queue that's on our system.
At least that's what we need to do. We need a queue on the mainframe so that we can do things with our Windows systems (reboot) and have the messages queue up.
We need for the messages coming over the channel to be distributed across the 4 queues on the Windows systems.
Will these commands achieve this?
_________________
Careful with that VAX Eugene |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jun 07, 2007 4:32 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
On the 4 worker QMs in the cluster, there is a clusterd q called WORKER.QUEUE.
On z/OS, remote q def like this:
Remote Q = WORKER.QUEUE
Remote Queue Name = WORKER.QUEUE
Remote QM Name = CLUSTERNAME
XMITQ = GatewayQM.XMITQ
On the Gateway, a qm alias q like this:
Remote Q = CLUSTERNAME
Remote Q Name = (blank)
Remote QM Name = (blank)
XMITQ = (blank)
The app on the mainframe will put messages to the remote q def on the mainframe.
That routes them into the XMITQ that goes to the Gateway QM.
The QM Alias on the Gateway QM will wipe out the destination QM assocciated with the message.
At that point the message is on the Gateway QM, in the cluster, looking for a queue and it doesn't ask for a particular QM.
The Gateway QM first checks to see if it has a q by that name, and since it doesn't, the Gateway QM will round robin the message to one of the 4 other QMs in the cluster that do have a q by that name.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| klamerus |
| Posted: Thu Jun 07, 2007 5:05 pm Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
What happens if there is a problem on the network for messages on the MF being put on it's queue?
One advantage to what we currently have with a MF queue and a channel is that the messages just sit until the channel is re-established.
It sounds like this requires access to the remote queue on the Windows systems or errors start to generate.
_________________
Careful with that VAX Eugene |
|
| Back to top |
|
|
| klamerus |
| Posted: Thu Jun 07, 2007 5:10 pm Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
I'm not sure what I just said is even English.
What happens if we have a network issue.
Right now, the messages just sit on the MF queue until the network is back. Then they flow over the channel.
We can also just stop this at will (for whatever reason).
This solution sounds like we lose that (yes/no)?
_________________
Careful with that VAX Eugene |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jun 07, 2007 5:13 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
No.
If the Gateway QM is N/A, the messages will safely pile up in the GatewayQM.XMITQ on the mainframe. The z/OS can still keep putting messages (until the XMITQ fills up).
Basic MQ; nothing to do with clustering.
If the Gateway QM is up but by some freak reason all 4 of the Worker QMs are down, the messages will pile up in the SYSTEM.CLUSTER.TRANSMIT.QUEUE on the Gateway QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| klamerus |
| Posted: Fri Jun 08, 2007 2:27 am Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
Well then it sounds to me like this is actually better.
We can have things queue in one of two areas: 1, on the MF; and 2, on the cluster (but not in the target queues).
Is there no longer a channel from the MF to the cluster then?
Also, if we currently do have a MF queue and a channel (which is what we've been trying to get to work, would there be a way to gracefully replace those?
_________________
Careful with that VAX Eugene |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jun 08, 2007 2:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| klamerus wrote: |
Well then it sounds to me like this is actually better.
We can have things queue in one of two areas: 1, on the MF; and 2, on the cluster (but not in the target queues).
Is there no longer a channel from the MF to the cluster then?
Also, if we currently do have a MF queue and a channel (which is what we've been trying to get to work, would there be a way to gracefully replace those? |
You'd still need a channel between MF to the gateway. But yes, messages would only accumulate in the 2 places you mention (or the target queues if the reading application goes down!  )
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
