| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQI: query queue type when using clustering |
« View previous topic :: View next topic » |
| Author |
Message
|
| Simon Kitching |
 Posted: Thu Apr 29, 2004 12:08 am Post subject: MQI: query queue type when using clustering |
 |
|
Newbie
Joined: 28 Apr 2004
Posts: 2
Location: New Zealand
|
Hi,
Using the "c" MQI interface (not MQAI or PCF), I want to determine whether a particular queue is a local queue.
The MQINQ call works very nicely as long as clustering is not involved; using the selector MQIA_Q_TYPE returns MQQT_LOCAL for local queues.
Unfortunately for all objects that are clustered, you get back MQQT_CLUSTER instead. Ok, so one should just use MQINQ again with MQAI_CLUSTER_Q_TYPE and check for MQCQT_LOCAL_Q, right? Nope, that just gives reason code 2067, "MQRC_SELECTOR_ERROR".
So does anyone have an idea how to get past this roadblock? Given an object that MQINQ tells you is some sort of clustered object, how can you know whether it is a local queue, a remote qdef, an alias, etc?
I'm using MQ 5.3.0 (CSD03) on Linux and AIX.
Thanks in advance,
Simon |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Thu Apr 29, 2004 12:10 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
don't know the answer to that one, but why do you want to know this???
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Apr 29, 2004 8:11 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
I had exact the same problem.
Here is what I did:
| Code: |
- MQINQ with only MQOO_INQUIRE + MQOO_FAIL_IF_QUIESCING options
- Get queue type
- If queue type equals 'Cluster' then
- MQINQ with MQOO_INQUIRE + MQOO_BROWSE + MQOO_FAIL_IF_QUIESCING options
- Save queue type
- else
- Save queue type |
That took a while to figure out but it does work. 
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 29, 2004 12:39 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The reason why Roger's solution works is explained in the App Prog Ref Manual, in the Usage Notes section (#4)of the MQINQ call.
| Quote: |
If the object being inquired is a cluster queue, the attributes that can be inquired depend on how the queue is opened:
If the cluster queue is opened for inquire plus one or more of input, browse, or set, there must be a local instance of the cluster queue in order for the open to succeed. In this case the attributes that can be inquired are those valid for local queues.
If the cluster queue is opened for inquire alone, or inquire and output, only the attributes listed below can be inquired; the QType attribute has the value MQQT_CLUSTER in this case:
MQCA_Q_DESC
MQCA_Q_NAME
MQIA_DEF_BIND
MQIA_DEF_PERSISTENCE
MQIA_DEF_PRIORITY
MQIA_INHIBIT_PUT
MQIA_Q_TYPE
If the cluster queue is opened with no fixed binding (that is, MQOO_BIND_NOT_FIXED specified on the MQOPEN call, or MQOO_BIND_AS_Q_DEF specified when the DefBind attribute has the value MQBND_BIND_NOT_FIXED), successive MQINQ calls for the queue may inquire different instances of the cluster queue, although usually all of the instances have the same attribute values.
For more information about cluster queues, refer to the WebSphere MQ Queue Manager Clusters book.
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Simon Kitching |
| Posted: Thu Apr 29, 2004 3:08 pm Post subject: Thanks |
|
|
Newbie
Joined: 28 Apr 2004
Posts: 2
Location: New Zealand
|
Thanks very much for all the replies.
Roger/Peter: your answers make all clear.
An alternative answer actually occurred to me in the shower this morning: just try to perform an inquiry that is only valid for local queues, and see if an error is reported.
Michael: the purpose of this is to implement a simple MQ monitoring tool. I have created a small application which detects all local queues on a specific (local) qmgr, and then checks that the top message on each queue is no older than X seconds. This is then integrated with the Nagios monitoring tool so that we get an alert if any queue is not being processed in a timely manner. We didn't want to use MQ's "instrumentation events" for various reasons. And this tool has been working fine - until we went to clustering. With this info, I hope to have working again very soon! |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Apr 30, 2004 1:53 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
