| Author |
Message
|
| bernard_fay |
 Posted: Tue Jul 24, 2012 5:24 am Post subject: sending messages without using remote queue definition |
 |
|
Apprentice
Joined: 24 Jul 2012
Posts: 30
|
Hello all,
First, I am new to MQ and pushed to deliver solutions with this very interesting piece of software but also very complex. So please be indulgent if my question seems obvious or anything else.
We have two queue managers (QM). From the first one, using a XMITQ we wish to send messages to queues on the second QM. So far the only way I know to do this is with a remote queue definition on the first QM.
My question is: Is there a way to send messages to queues on the second QM without the need of remote queue definition?
In other words, we would like clients to connect to the first QM which will be a kind of passthru to send messages to the second QM.
Thanks,
Bernard |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Tue Jul 24, 2012 5:32 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
A QRemote definition is exactly for the purpose of moving a message to an xmitq, and down the network to another qmgr.
Why your aversion to QRemote defs?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 24, 2012 5:39 am Post subject: Re: sending messages without using remote queue definition |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bernard_fay wrote: |
| My question is: Is there a way to send messages to queues on the second QM without the need of remote queue definition? |
Yes there is. As my worthy associate says, why would you want to? You're moving knowledge of the WMQ set up & topology out of the WMQ layer and into the application. At best, this is going to make it very hard to alter your topology without changing and retesting the applications.
If you're certain you want to paint yourself into this particular corner, research how WMQ resolves object names. Even if you decide not to, it's still worth getting to grips with name resolution.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 24, 2012 5:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There is a school of thought that says that applications should never know the real names of real MQ objects - qlocals or qmgrs.
Everything should be addressed using aliases of some kind or another.
There are some good solid reasons for doing so. But it takes planning and solid administration skills and tooling. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jul 24, 2012 5:50 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The MQOPEN API call can specify the name of a remote queue manager and the queue name on that qm. (also works on MQPUT1).
This will result in the xmit queue for that remote queue manager being opened directly without any remote queue definition being needed.
This assumes there is a xmit queue with the name of the remote queue manager defined. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 24, 2012 5:53 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Since you are a newbie to WMQ, I'll first suggest that you get some training on the basics of the product.
Applications MQCONNect to a queue manager; and this qmgr becomes the 'local qmgr' for all subsequent MQI calls, like puts and gets.
Applications get messages from, and put messages to real local queues (QLocal) on the local qmgr. Administrators tell the app coder a name for the queue, but this name need not be the absolute name of the queue. Rather, it could be a QAlias (another name for the queue), or a QRemote. A QRemote tells the qmgr that the message is destined for another qmgr down the network.
Messages destined for another qmgr down the network must be put to a special kind of local queue called a transmission queue. When the app issues the MQPUT call, the qmgr creates an additional header (XQH) that provides routing information for the message channel agents that move the message across the network. The app message and the XQH are put to the transmission queue. Applications are unaware that the queue is a transmission queue. Applications do not create the XQH, and are unaware of its existence. This is all transparent to the application.
The explicit purpose of a QRemote definition is to give the app a name for the queue - not THE name of a queue. This abstraction allows for administrators to move the 'target' queue to another qmgr without the putting application having to be changed in any way.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 24, 2012 5:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
The MQOPEN API call can specify the name of a remote queue manager and the queue name on that qm. (also works on MQPUT1).
This will result in the xmit queue for that remote queue manager being opened directly without any remote queue definition being needed.
This assumes there is a xmit queue with the name of the remote queue manager defined. |
It's sort of more accurate, although more confusing, to say that the message will be put on the queue that has a matching name, with an xmit header.
Whether or not the channel that reads that xmit queue leads to a queue manager with that name is irrelevant to the process. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 24, 2012 5:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Again, let's go back to the question of 'why?'.
What are you trying to accomplish by not having a qremote? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 24, 2012 6:00 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Another method of avoiding the explicit need for a QRemote definition is to define the queue as part of a CLUSTER.
I'm going to guess that this is prep for certification, or a computer science class assignment, or some such.
Interesting intellectual exercise, but hopefully not a requirement in the real world.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 24, 2012 6:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
Another method of avoiding the explicit need for a QRemote definition is to define the queue as part of a CLUSTER.
I'm going to guess that this is prep for certification, or a computer science class assignment, or some such.
Interesting intellectual exercise, but hopefully not a requirement in the real world. |
I disagree, based on "pushed to deliver solutions". |
|
| Back to top |
|
|
| bernard_fay |
| Posted: Tue Jul 24, 2012 6:06 am Post subject: |
|
|
Apprentice
Joined: 24 Jul 2012
Posts: 30
|
Thanks for your replies everyone.
This is not class assignment or certification prep. It's real world and I try to learn as fast as I can. There is thousands of queues on the target QM. We would like to avoid to define each one of them on the source QM.
Thanks again. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 24, 2012 6:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
| bruce2359 wrote: |
Another method of avoiding the explicit need for a QRemote definition is to define the queue as part of a CLUSTER.
I'm going to guess that this is prep for certification, or a computer science class assignment, or some such.
Interesting intellectual exercise, but hopefully not a requirement in the real world. |
I disagree, based on "pushed to deliver solutions". |
I'm waiting to read the rationale for the requirement for no QRemote defs, and the dark place from which it came.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 24, 2012 6:11 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| bernard_fay wrote: |
Thanks for your replies everyone.
This is not class assignment or certification prep. It's real world and I try to learn as fast as I can. There is thousands of queues on the target QM. We would like to avoid to define each one of them on the source QM.
Thanks again. |
Research WMQ Clusters. Make the real local queues members of a cluster. Cluster software will broadcast the existence of the queues to other qmgrs that are part of the cluster. Voila! - no QRemote definitions.
Get WMQ training.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 24, 2012 6:20 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| bernard_fay wrote: |
Thanks for your replies everyone.
This is not class assignment or certification prep. It's real world and I try to learn as fast as I can. There is thousands of queues on the target QM. We would like to avoid to define each one of them on the source QM.
Thanks again. |
Research WMQ Clusters. Make the real local queues members of a cluster. Cluster software will broadcast the existence of the queues to other qmgrs that are part of the cluster. Voila! - no QRemote definitions. |
Or, better, just use a qmgr alias. As described by zpat.
| bruce2359 wrote: |
| Get WMQ training. |
 |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 24, 2012 6:26 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
| bruce2359 wrote: |
| bernard_fay wrote: |
Thanks for your replies everyone.
This is not class assignment or certification prep. It's real world and I try to learn as fast as I can. There is thousands of queues on the target QM. We would like to avoid to define each one of them on the source QM.
Thanks again. |
Research WMQ Clusters. Make the real local queues members of a cluster. Cluster software will broadcast the existence of the queues to other qmgrs that are part of the cluster. Voila! - no QRemote definitions. |
Or, better, just use a qmgr alias. As described by zpat.
| bruce2359 wrote: |
| Get WMQ training. |
|
A qmgr alias is a QRemote definition.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
