| Author |
Message
|
| Pringle |
 Posted: Mon Nov 12, 2012 2:57 am Post subject: "Twice-removed" queue |
 |
|
Novice
Joined: 12 Nov 2012
Posts: 15
|
Hi there,
A user of our software is having trouble connecting to a remote queue which is itself defined as a remote queue to another queue manager. Are there any special settings that need to be set to make this possible when connecting from a client using the .net API?
Here is the code that we are using to open the connection:
| Code: |
Hashtable props = new Hashtable();
if (!string.IsNullOrEmpty(_sslKeyStorePath))
{
props.Add(MQC.SSL_CERT_STORE_PROPERTY, _sslKeyStorePath);
props.Add(MQC.SSL_CIPHER_SPEC_PROPERTY, _sslCipherType);
}
props.Add(MQC.CHANNEL_PROPERTY, _channel);
props.Add(MQC.HOST_NAME_PROPERTY, _machineName);
props.Add(MQC.PORT_PROPERTY, _port);
mQM = new MQQueueManager(_queueManager, props);
if (write)
{
mQ = mQM.AccessQueue(_queueName, MQC.MQOO_OUTPUT | MQC.MQOO_FAIL_IF_QUIESCING | MQC.MQOO_SET_ALL_CONTEXT);
}
else
{
mQ = mQM.AccessQueue(_queueName, MQC.MQOO_INPUT_AS_Q_DEF | MQC.MQOO_FAIL_IF_QUIESCING | MQC.MQOO_BROWSE | MQC.MQOO_INQUIRE);
}
|
Please only respond if you have anything useful to add, no "rtfm" comments please. Links to specific parts of the documentation that might help would be appreciated though.
Anyone leaving rtfm comments will come down with a terrible cold within a fortnight!
Any help would be massively appreciated!! |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Nov 12, 2012 4:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
Exactly what problem are you having?
_________________
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 |
|
|
| Pringle |
| Posted: Mon Nov 12, 2012 5:17 am Post subject: |
|
|
Novice
Joined: 12 Nov 2012
Posts: 15
|
| Sorry I forgot to mention, the error returned is MQRC_OPTION_NOT_VALID_FOR_TYPE. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 12, 2012 7:33 am Post subject: Re: "Twice-removed" queue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Pringle wrote: |
| Anyone leaving rtfm comments will come down with a terrible cold within a fortnight! |
You'll find the error clearly documented in the InfoCenter.
(I just wanted to call your bluff).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Nov 12, 2012 7:34 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| Pringle wrote: |
| Sorry I forgot to mention, the error returned is MQRC_OPTION_NOT_VALID_FOR_TYPE. |
So do not connect in input mode. You cannot read any messages from that queue. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 12, 2012 7:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Pringle wrote: |
| Sorry I forgot to mention, the error returned is MQRC_OPTION_NOT_VALID_FOR_TYPE. |
The error's fairly clear and is explained here.
(Do I now get a cold in a week?)
In summary, the code's trying to use an option that doesn't apply to a remote queue; typically browse or inquire. This may be from the interface layer rather than user written code. Check the object definitions.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Pringle |
| Posted: Tue Nov 13, 2012 8:22 am Post subject: |
|
|
Novice
Joined: 12 Nov 2012
Posts: 15
|
Thanks for the advice given so far. However I have built a new version of the software having removed the input and inquire options, but the client is still reporting failure. I am calling AccessQueue with the following option now:
| Code: |
mQ = mQM.AccessQueue(mQueueData.QueueName, MQC.MQOO_FAIL_IF_QUIESCING);
|
Based upon that link you provided, and the fact I am now only setting the above option, is it most likely down to the following paragraph:
| Quote: |
This reason code can also occur on the MQOPEN call when the object being opened is of type MQOT_NAMELIST, MQOT_PROCESS, or MQOT_Q_MGR, but the ObjectQMgrName field in MQOD is neither blank nor the name of the local queue manager.
|
I don't have access to the queue myself, what is the easiest way to establish in code whether the object being opened is of type MQOT_NAMELIST, MQOT_PROCESS, or MQOT_Q_MGR? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Nov 13, 2012 8:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You need to make sure that they have *not* set any value in your _queueManager field and then make sure that they *have* set the *correct* value in your _queueName field. |
|
| Back to top |
|
|
| Pringle |
| Posted: Wed Nov 14, 2012 1:45 am Post subject: |
|
|
Novice
Joined: 12 Nov 2012
Posts: 15
|
I have tried this latest piece of advice, but to no avail. They are now seeing the following error code when leaving the queue manager field blank: MQC.MQRC_Q_MGR_NAME_ERROR
Are there some other properties I also need to set, and/or is there a special syntax for the *correct* queue name when not naming a queue manager? |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Nov 14, 2012 4:00 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
You are opening a remote queue for INPUT or BROWSE (as well as for OUTPUT).
It won't work!!!
Irrelevant where the remote queue points to, or how many hops.
However it is possible to avoid the double remote queue definitions by specifying the final QM as the remote queue manager name, and the intermediate QM as the XMIT queue name (in the first remote queue def). |
|
| Back to top |
|
|
| Pringle |
| Posted: Wed Nov 14, 2012 4:19 am Post subject: |
|
|
Novice
Joined: 12 Nov 2012
Posts: 15
|
I am now opening the remote queue using MQC.MQOO_FAIL_IF_QUIESCING only. Then I followed the advice to leave the queue manager name blank, which didn't work.
I will try to get them to type in the final queue manager name rather than the intermediate one...however how do I set the XMIT queue name in code? It doesn't seem to be a property of the MQC enumeration when setting the properties on the queue manager. I was hoping to see a nice XMIT_QM_NAME_PROPERTY alongside HOST_NAME_PROPERTY etc. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Nov 14, 2012 4:28 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Set only a queue name in the code (from an external config source of course),
Set the remote QM name and XMIT queue name in the remote queue definition (the name of which is the queue name used above.). |
|
| Back to top |
|
|
| Pringle |
| Posted: Wed Nov 14, 2012 5:40 am Post subject: |
|
|
Novice
Joined: 12 Nov 2012
Posts: 15
|
The only properties we are currently exposing in the UI for client configuration are:
Channel name
Host name
Port
Queue name
Queue manager name
So should all the above be blank except queue name? How will the WebSphere client know what machine to connect to?
The client has sent me a screenshot of their remote queue definition. On it I can see a property called Transmission Queue, which I take it is the XMIT property you are referring to. They have set the value of this property to the same as the Remote QMgr Name property. Is that correct, as you seem to imply it should be queue name not the queue manager name?
If I do still need to set the host name, does that need to be the host name of the intermediate remote queue or the final target queue? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Nov 14, 2012 5:51 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| Pringle wrote: |
I am now opening the remote queue using MQC.MQOO_FAIL_IF_QUIESCING only. Then I followed the advice to leave the queue manager name blank, which didn't work.
I will try to get them to type in the final queue manager name rather than the intermediate one...however how do I set the XMIT queue name in code? It doesn't seem to be a property of the MQC enumeration when setting the properties on the queue manager. I was hoping to see a nice XMIT_QM_NAME_PROPERTY alongside HOST_NAME_PROPERTY etc. |
You need to also open the queue for output....
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Pringle |
| Posted: Wed Nov 14, 2012 6:05 am Post subject: |
|
|
Novice
Joined: 12 Nov 2012
Posts: 15
|
With the queue manager name blank though? The code is failing before the call to AccessQueue; it's failing on instantiation of the MQQueueManager object. So therefore I can only try what you have suggested if we do pass in the queue manager name.
I will recompile a new version and get the client to try this with a queue manager name set, but this seems to conflict with other bits of advice given. |
|
| Back to top |
|
|
|
|
