| Author |
Message
|
| villarin |
 Posted: Thu May 26, 2005 10:02 am Post subject: Put on XMITQ |
 |
|
Newbie
Joined: 26 May 2005
Posts: 1
|
Hello friends,
OS: Windows 2003.
Language: C#.Net
Version: WMQ 5.3
I had an old MQ Series scheme (classic) where I did put a message directly on a Queue Remote passing on a Transmission Queue, etc., I did not have problems with it. Then we had changes with the systems politics using MQ, and we want to eliminate the remote queue and we have to do put a message directly on a trasmission queue.
I wanted to do it in a normal way like when I had the remote queue but the message goes to DLQ, the question is: What additional parameters do I need to add or modify on the message to send him using transmission queue directly?.
Txn for help me. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu May 26, 2005 10:10 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can not and should not ever write directly to an xmit queue.
If your policy says you can't have remote queue definitions, then a) it's insane, b) you need to look into default transmission queues or clustering.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 26, 2005 6:16 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Or specify the queue name and the destination QM name on the MQOPEN / MQPUT1 call. If there is an XMITQ by the name of the destination QM, the message will be placed there. Or you can create a QM Alias as well that has the same name as the destination QM, that will catch the messages and put it to the named XMITQ in the QMAlias.
No remote queues, huh? Maybe there are just talking about replies, and enforcing replying apps to use the Reply2Queue and Reply2QM from the request message.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| FFSparky |
| Posted: Sat May 28, 2005 9:34 am Post subject: |
|
|
Novice
Joined: 23 Dec 2003
Posts: 16
Location: Des Moines, Iowa
|
I agree with the prior two responses.
Used properly, remote and alias queues provide you as an administrator a significant amount of flexability and control.
If this is a set policy, perhaps you should consider going to having just one queue manager  |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Sun May 29, 2005 11:37 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
The best way to go is what Peter said, use the xmitq as qmgr name or use a qmgr alias.
But you can write directly to the xmitq if you like, you have to provide all headers (mqxqh with embedded md and md) and the proper values.
We do use this to send a message to a remote queuemanager that is addressed to ourselves (target queuemanager is the xmitq of the remote queuemanager that points to us). This is some kind of a monitoring function, and saves some (a lot of) remoteq definitions at our end.
Anyway, i used this to speed up this monitoring function (the old version involved change of remoteq etc. but thats another story), but i would not recommend to use this for any application stuff.
For distributed queueing, use remote queues!
_________________
Regards, Butcher |
|
| Back to top |
|
|
| ping master |
| Posted: Mon Dec 18, 2006 12:02 pm Post subject: |
|
|
Centurion
Joined: 20 Sep 2002
Posts: 116
Location: USA
|
| Although writing directly to transmission queues is definitely possible and it is mostly frowned upon. It basically puts all the responsibilty on the application itself to build the proper XQH header etc which can get a little tricky itself. This is all taken care of by WMQ if you put to the remote Qdef. I have seen where there could be 10,000 clients (env not clustered) that receive distribution from a server and they did not want to create 10,000 separate queues/channels objects for each client to distribute, but are in the works to determin a better way than still placing messages directly onto an xmitQ. |
|
| Back to top |
|
|
| tleichen |
| Posted: Mon Dec 18, 2006 1:01 pm Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
I don't know the specifics of your "policies", but the fact that you can even use the word "queue" in a policy would imply someone is directing something against the product itself. What if you did not have MQSeries? What would you use to communicate between systems (i.e., FTP, etc.)? Queues do not even exist in those products. I would ask the policy maker(s) what their real agenda is and why they are trying to go against the grain of the software product that your company bought and paid for. Is this a new person wanting to make his own changes by forcing MQSeries not to perform right, so he can bring in some product that he used at a prior company? Believe me, I've seen this kind of thing before. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
|
|
