| Author |
Message
|
| smdavies99 |
 Posted: Sat Dec 07, 2013 3:56 am Post subject: MQOutput Node DestintionList & Remote queues [solved?] |
 |
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
System Windows Server 2008 R2
WMQ 7.0.1.8
Broker 7.0.0.4
I have a flow that works fine when setting up the DestinationList to point to a local queue.
If I...
1) delete the local queue
2) create a new REMOTE queue with the same name as the local queue
3) Test the queue and verifying that the right queue is reached on the target qmgr with AMQSPUTC
When I start the flow I get an error
MQRC 2045 MQRC_OPTION_NOT_VALID_FOR_TYPE
I've looked in the Infocentre but so far I can't see anything saying that the queue has to be local.
If I use an MQOutputNode in a normal mode writing to remote queues is fine.
Any thoughts on the matter most welcome
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
Last edited by smdavies99 on Sat Dec 07, 2013 11:00 pm; edited 1 time in total |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sat Dec 07, 2013 3:05 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
How exactly are you setting up the Destination list?
I suppose there is indeed a default route from the broker's qmgr to the ultimate destination?
Don't remember setting it up as a remote queue, more as qmgr name (alias or cluster alias) and qname... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Dec 07, 2013 10:59 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
The flow was already using a destinationList to dynamically setup the queuename based upon the data in the message.
What I was trying to do works fine with statically defined queue names in the MQOutput Node.
i.e. you can change the queue definition from a LOCAL queue to a REMOTE Queue and everything works fine and dandy.
With a distributionList it seems that you can't do that at all. Changing the property on the node changes the way the output is sent.
In order to use a DestinationList where the target is a queue on a REMOTE QUEUE MANAGER you have to specify the QueueManagerName in the DestinationList as well. toy can't rely on the Queue Object at all.
Old Setup of DestinationList
| Code: |
SET OutputLocalEnvironment.Destination.MQ.DestinationData[1].queueName = 'MYOUTPUTQ';
|
Then is you change the queue from a local to a remote type you get the 2045 error.
New setup of DestinationList
| Code: |
SET OutputLocalEnvironment.Destination.MQ.DestinationData[1].queueName = 'MYOUTPUTQ';
SET OutputLocalEnvironment.Destination.MQ.DestinationData[1].queueManagerName = 'MYREMQMGR';
|
Is seems to me that this is either a defect or the restriction needs to be documented (not looked in the V8 or V9 Infocentres though...)
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Dec 08, 2013 8:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I guess the most common option one might specify that works on a local queue but is not applicable to a remote queue are the MQOO_INPUT** options.
Is the Destination List (incorrrectly?) trying to open the output queue with an MQOO_INPUT* option? If yes that explains why the method specifying the RemoteQM name works - you are actually opening the XMITQ, itself a local queue.
Try your local queue test again, but Get Inhibit the local queue. If the flow fails to open the queue to put a message that will show its for some reason trying to open the queue for input for some reason.
There are other possibilities, see here:
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.tro.doc/q041160_.htm
Maybe its using the SET or INQUIRE option when opening the queue, which is fine for a local queue or XMITQ, but yaks when its a remote q def?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Esa |
| Posted: Mon Dec 09, 2013 11:49 pm Post subject: Re: MQOutput Node DestintionList & Remote queues [solved |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Putting messages onto a remote queue with a destination list is a very, very common scenario.
I did some tests and everything worked as it should. I was not able to reproduce the problem. I checked the status of the transmission queue, and the flow engine process seems to open it with similar options regardless if you use destination list mode or queue name mode.
To be able to remove a queue you will have to stop the flow. That drops the queue from open handle cache, so it's not possible that the handle was left there with wrong options, either.
It would be absurd if you were required to define qmgrName in the destinationlist when putting to a remote queue. Although it's possible to make Message Broker to put messages directly to a transmission queue that way, I wouldn't recommend it because it would make routing messages over several hops more complicated than using a remote queue (you would need to define the remote queue on the hub qm).
| smdavies99 wrote: |
When I start the flow I get an error
MQRC 2045 MQRC_OPTION_NOT_VALID_FOR_TYPE
|
There may be something wrong with your flow or setup. Output queues are not opened when you start a flow, they are opened when you first need to put a message. Unless you had messages in the flows's input queue when you started it. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Dec 10, 2013 12:16 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I even restarted the system so there are no q handles lying around.
In Q mode, changing from a local to a remote Q works fine.
In D-List mode changing from a local to a remote Q does not work (on my setup and without a QMGR Name is the D-List).
I'm using the same channel objects (xmitq, channel) in both cases.
I've added the QMGR Name to the D-List and everything works fine.
Puzzled ? yes but I've used the work around and that's ok for now.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Dec 10, 2013 12:54 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| smdavies99 wrote: |
I've added the QMGR Name to the D-List and everything works fine. |
Did you try putting the local queue manager name in Destination list to indicate that you want to use the locally defined remote queue?
Logically that would mean the same thing as leaving the field empty. But resolving seemingly absurd situations requires seemingly absurd measures. |
|
| Back to top |
|
|
| Simbu |
| Posted: Tue Dec 10, 2013 2:00 am Post subject: |
|
|
Master
Joined: 17 Jun 2011
Posts: 289
Location: Tamil Nadu, India
|
| smdavies99 wrote: |
I even restarted the system so there are no q handles lying around.
In Q mode, changing from a local to a remote Q works fine.
In D-List mode changing from a local to a remote Q does not work (on my setup and without a QMGR Name is the D-List).
I'm using the same channel objects (xmitq, channel) in both cases.
I've added the QMGR Name to the D-List and everything works fine.
Puzzled ? yes but I've used the work around and that's ok for now. |
InfoCenter says...
| Quote: |
| If the queue is defined on a remote queue manager, the Queue Manager Name must be specified and it must match the transmission queue defined on the broker's local queue manager, for that remote queue manager. |
Not sure how come it worked in Q node without specifying QMGR. |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Dec 10, 2013 2:40 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Simbu wrote: |
InfoCenter says...
| Quote: |
| If the queue is defined on a remote queue manager, the Queue Manager Name must be specified and it must match the transmission queue defined on the broker's local queue manager, for that remote queue manager. |
Not sure how come it worked in Q node without specifying QMGR. |
It works if the queue is a remote queue defined on the local queue manager. |
|
| Back to top |
|
|
| Simbu |
| Posted: Tue Dec 10, 2013 2:59 am Post subject: |
|
|
Master
Joined: 17 Jun 2011
Posts: 289
Location: Tamil Nadu, India
|
| Esa wrote: |
| Simbu wrote: |
InfoCenter says...
| Quote: |
| If the queue is defined on a remote queue manager, the Queue Manager Name must be specified and it must match the transmission queue defined on the broker's local queue manager, for that remote queue manager. |
Not sure how come it worked in Q node without specifying QMGR. |
It works if the queue is a remote queue defined on the local queue manager. |
Thanks for the clarification. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Dec 10, 2013 3:17 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Simbu wrote: |
Not sure how come it worked in Q node without specifying QMGR. |
It works because the Remote Queue definition contains the Remote Queue Manager Name which happens to be the XMIT Queue name.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Dec 10, 2013 10:34 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| smdavies99 wrote: |
Puzzled ? yes but I've used the work around and that's ok for now. |
user trace? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Dec 10, 2013 11:42 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Esa wrote: |
user trace? |
As someone who only ever uses UserTrace that was the first thing I looked at. It does not give any more data.
As we have a workaround (add three lines of ESQL) I'm moving onto some different issues until we move the whole system from Broker 7 to IIB 9.0.0.2 whenever that is released.
Rest assured it is on the 'Gotcha' list for the migration effort.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
