| Author |
Message
|
| mikiu |
 Posted: Mon Jan 17, 2011 10:21 pm Post subject: MQINQ |
 |
|
Acolyte
Joined: 23 Jul 2002
Posts: 61
Location: toronto
|
Can any of yous lerned and helpful gentlefolks tell me IF and How I could run an MQINQ on remote queues?
After I use only options MQOO_FAIL_IF_QUIESCING and MQOO_INQUIRE in a successful MQOPEN, all my local queues come back nicely from the MQINQ call, with the actual verified Queue Depth value but all my remote queues get me a 2068 reason (cannot understand the Messages and Codes manual re 2068, no matter how often I read it).
I have a count of ONE in selectors and in the integer attribute count and only have the MQIA_CURRENT_Q_DEPTH in the selectors. Code should work fine IMO, but I am missing something: for the life of me I couldn't figure what.
Much obliged for a quick reply.
Miki |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Mon Jan 17, 2011 10:38 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
if you do MQINQ on a "local definition of a remote queue" you can only inquire the attributes of that queue object, and not the attributes of targetqueue and targetqueuemanager the remote queue is pointing to. so as a "local definition of a remote queue" has no curdepth attribute, you get reason code 2068.
if you want to know the curdepth of the targetqueue on the targetqueuemanager, you have to connect to targetqueuemanager and issue an inquire on the targetqueue. but keep in mind there is a xmitq inbetween that could also hold messages.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| mikiu |
| Posted: Mon Jan 17, 2011 10:54 pm Post subject: |
|
|
Acolyte
Joined: 23 Jul 2002
Posts: 61
Location: toronto
|
Thank you kind Sir ...
this is more or less what I thought ... and alas, I cannot connect to the target queue manager because under CICS, only she conects and she wants her own z/OS queue managers and, even if I could stop and start a different connection, I'd screw everybody I share the CICS region with ... so I will sit and figure out something clever that will get me aroudn this thing.
best regards,
Miki |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Jan 18, 2011 12:55 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
maybe we can be of help if you let us know what you are trying to achieve
_________________
Regards, Butcher |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jan 18, 2011 3:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There's no reason to MQINQ on Queue Depth.
EVER. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 18, 2011 5:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mikiu wrote: |
| I will sit and figure out something clever that will get me aroudn this thing. |
What thing? There's no good reason for an application to inquire on the depth of any queue, unless you're reinventing the wheel and trying to write your own monitoring system for WMQ.
And as you've mentioned z/OS & CICS, whatever you're using to monitor those will almost certainly have the capability to monitor WMQ as well.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jan 18, 2011 5:20 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| mikiu wrote: |
| I will sit and figure out something clever that will get me aroudn this thing. |
What thing? There's no good reason for an application to inquire on the depth of any queue, unless you're reinventing the wheel and trying to write your own monitoring system for WMQ. |
EVEN THEN you should use PCF and not MQINQ. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 18, 2011 5:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Vitor wrote: |
| mikiu wrote: |
| I will sit and figure out something clever that will get me aroudn this thing. |
What thing? There's no good reason for an application to inquire on the depth of any queue, unless you're reinventing the wheel and trying to write your own monitoring system for WMQ. |
EVEN THEN you should use PCF and not MQINQ. |
Point taken. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fatherjack |
| Posted: Tue Jan 18, 2011 5:35 am Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| Vitor wrote: |
| unless you're reinventing the wheel and trying to write your own monitoring system for WMQ. |
But given this post and the numerous other similar ones we've seen over the years it would appear that is what lots of people out there are doing.
So, what are you guys doing when you MQINQ on queue depths?
Are you writing your own monitoring? If so, why?
Or are you doing something else? Custom trigger monitors maybe?
Or just an academic training exercise?
Or something else?
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jan 18, 2011 5:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fatherjack wrote: |
So, what are you guys doing when you MQINQ on queue depths?
Are you writing your own monitoring? If so, |
Use PCF messaging.
| fatherjack wrote: |
| Or are you doing something else? Custom trigger monitors maybe? |
Use Event Messages and set QDEPTHHI/QDEPTHLO
| fatherjack wrote: |
| Or just an academic training exercise? |
Use PCF Messaging.
| fatherjack wrote: |
| Or something else? |
Don't use MQINQ. |
|
| Back to top |
|
|
| fatherjack |
| Posted: Tue Jan 18, 2011 5:49 am Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| mqjeff wrote: |
| fatherjack wrote: |
So, what are you guys doing when you MQINQ on queue depths?
Are you writing your own monitoring? If so, |
Use PCF messaging.
| fatherjack wrote: |
| Or are you doing something else? Custom trigger monitors maybe? |
Use Event Messages and set QDEPTHHI/QDEPTHLO
| fatherjack wrote: |
| Or just an academic training exercise? |
Use PCF Messaging.
| fatherjack wrote: |
| Or something else? |
Don't use MQINQ. |
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| mikiu |
| Posted: Wed Jan 19, 2011 6:26 am Post subject: |
|
|
Acolyte
Joined: 23 Jul 2002
Posts: 61
Location: toronto
|
Hello MQWiseMen,
I appreciate your input and willingness to help ... I see now that the right approach is to give you background, not just shriek for help on one isolated, out of the context topic ... so here goes app. description:
1 - Code on AIX puts a message on a request queue (with expiry time)
2 - the program then issues a get with a wait for corelid/msgid
3 - message starts CICS transaction (using trigger type first) transaction issues a get msg.
4 - after processing CICS transaction puts a message on a request queue to an external partner (with expiry time)
5 - CICS transaction issues a get with a wait for corelid/msg id
6 - external partner usually replies in a couple of seconds ... the get at #6 is satisfied
7 - CICS transaction puts a message on a reply queue (with expiry time) for the AIX task, issues necessary syncpoints and loops back to do another get in case there are more messages on the AIX request queue.
8 - get at #2 is satisfied and the individual iteration closes
We see an increased queue depth on the AIX request queue due to the single threading caused by the trigger type first - this only slows us down and we can probably live with it ... but the real issue is that, at higher transaction rates 2 - 3 / minute we experience 2018 errors on the puts at #4 and #7 ... and I wanted to capture queue depth using the MQINQ to figure when this happens and how it is related to the 2018.
I am certain that you will havce ideas and you will share them with us.
Please be assured of our appreciation and gratitude for the time you took to help.
regards,
Miki |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 19, 2011 6:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mikiu wrote: |
and I wanted to capture queue depth using the MQINQ to figure when this happens and how it is related to the 2018.
|
Most WMQ monitoring tools do this. Whatever you have on z/OS doing monitoring almost certainly has WMQ capability. Use this to monitor the depth of the queue in question.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Jan 19, 2011 7:15 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| at higher transaction rates 2 - 3 / minute we experience 2018 errors on the puts at #4 and #7 |
| Quote: |
| 2018 - The connection handle Hconn is not valid |
From your data flow description puts #4 and #7 are the puts done by CICS. Strange you get a connection handle problem in CICS, as CICS is connected to MQ, there is no "own" connection handle for the application.
If you MQCONN in CICS, you get the handle supplied from CICS (or from the CICS conneciton), and i am not sure if you can specify something in the HCONN field in CICS environment here that MQ does not like.
Maybe check if you modify the content of the HCONN somewhere in your program, especially when you are "busy" (e.g. when code is executed twice) or have special conditions like "timeouts" (e.g. answer not received during wait time). Also check if you are linked with the proper stub (a hint from the RC description)
So far i can not see any relation between a 2018 and queue depth except an (logical) application error.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Jan 19, 2011 4:18 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| mikiu wrote: |
...
We see an increased queue depth on the AIX request queue due to the single threading caused by the trigger type first - this only slows us down and we can probably live with it ... but the real issue is that, at higher transaction rates 2 - 3 / minute we experience 2018 errors on the puts at #4 and #7 ... and I wanted to capture queue depth using the MQINQ to figure when this happens and how it is related to the 2018.
I am certain that you will havce ideas and you will share them with us.
Please be assured of our appreciation and gratitude for the time you took to help. |
Miki, the 2018 reason codes are almost certainly due to an application programming issue. A program is attempting to put a message to a MQ queue when it has not established a valid connection to a MQ queue manager. You are unlikely to find a bug in MQ that relates this to queue depth, but you never know 
_________________
Glenn |
|
| Back to top |
|
|
|
|
