| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQOPEN error on a queue monitor CURDEPTH XMITQ |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjb_saper |
 Posted: Wed Oct 19, 2022 12:15 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You approach is plain WRONG.
Transmission queues are opened by the channel, by default in exclusive mode.
You do no monitor transmission queues by opening them and doing an INQ on them.
This is why you do have PCF commands. The way you monitor queues, is by issuing the correct PCF command and evaluating its return messages.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| hughson |
| Posted: Wed Oct 19, 2022 12:24 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| Oroshi wrote: |
Well, I want to monitor it, simply.
That's what I want to do.
Under AS400, we don't really know a way to make a simple script to trigger and monitor like we could, let's say, on a linux.
On a linux, a simple runmqsc < echo "dis ql(Queue)" |grep CURDEPTH would suffice, even if there is probably more efficient ways to do so, but you get the idea.
I want to monitor and get every 5 min the queue depth, and sent it to a file for example.
Then I can check the file and configure the triggers and alerting on our monitoring too. What I need is only the CURDEPTH. |
You still didn't say why. What will you do with the data you collect? What will change about your MQ setup based on these collected CURDEPTH numbers.
If on linux running an MQSC script would suffice, why not do that on IBM i too?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 20, 2022 5:14 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I'll guess that the OP is looking for a way to monitor a sender/receiver channel state. Most of the common monitoring tools already do this. Transmission queue CURDEPTH increasing can indicate channel issues.
I'd suggest the OP read Alternative ways of administering IBM MQ for IBM i https://www.ibm.com/docs/en/ibm-mq/8.0?topic=SSFKSJ_8.0.0/com.ibm.mq.adm.doc/q021670_.htm
_________________
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 |
|
|
| Oroshi |
| Posted: Tue Oct 25, 2022 1:46 am Post subject: |
|
|
Newbie
Joined: 05 Oct 2022
Posts: 9
|
Hello,
Lot of answers since last time, so I'll try to clarify some points.
We use solarwinds, for monitoring, using ODBC + sql queries.
About using a script, it's still bash on linux that I use, not only mqcli. When I try to do it on AS400, it doesn't work. So that's why I'm looking for something else. (I tend to use a lot of | in my scripts, and on AS400 I never got it to work)
And it's not about channels: we have a host that is linked to multiple others (pretty much like a switch or hub).
These host he's linked to are often restarted, that's why we don't want to monitor channels, since it would simply trigger often for a normal situation.
What we want is queue depth because of that.
Having a down channel is no issue, but if we start to get 1000+ messages in a sending queue, this means that something's wrong.
Hope this does clarify the situation, and the need.
And if you have a working script that can give a queue depth, I'd be glad to have it, and some explanation to understand a bit better how it works on AS400.
Thanks again for your time everyone |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 25, 2022 4:38 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Oroshi wrote: |
| And it's not about channels: we have a host that is linked to multiple others (pretty much like a switch or hub). |
As you are monitoring a transmission queue, then it is precisely about channels. Display your SENDER/SERVER channel definition that refers to the transmission queue.
IBM MQ channels connect queue managers together. Hub-and-spoke is a common topology.
SENDER/SERVER channel ends extract messages from transmission queues, and transmit the messages to partner RECEIVER/REQUESTER channels at the other end of the channel.
_________________
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 |
|
|
| gbaddeley |
| Posted: Tue Oct 25, 2022 3:28 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
It is OK to get the current depth of a transmission queue, by opening the queue for inquiry (MQOO_INQUIRE), and then using MQINQ with integer attribute MQIA_CURRENT_Q_DEPTH (or the equivalent object property name in OO language environments).
Typical monitoring would take a sample at 5 minute intervals.
If its anything other than zero for a significant period of time, there may be a volume or performance issue.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 26, 2022 6:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| gbaddeley wrote: |
It is OK to get the current depth of a transmission queue, by opening the queue for inquiry (MQOO_INQUIRE), and then using MQINQ with integer attribute MQIA_CURRENT_Q_DEPTH (or the equivalent object property name in OO language environments).
Typical monitoring would take a sample at 5 minute intervals.
If its anything other than zero for a significant period of time, there may be a volume or performance issue. |
Queue-manager stopped at remote end would result in the SENDER-RECEIVER channel at the sender end going into RETRY, then failing, resulting in xmitq depth increasing at sending end.
_________________
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 |
|
|
| Oroshi |
| Posted: Thu Nov 03, 2022 12:20 am Post subject: |
|
|
Newbie
Joined: 05 Oct 2022
Posts: 9
|
Hi again,
As I said, we have the fact that it's common that we stop/have channels into retrying.
But I think I know where you want to go, you want to monitor if a channel is down for, let's say, 4 polls on a 5 min interval.
That would work great for an alert, thing is, and I may have lacked precision on it, we want it to be reported in an easy-access table, that we can order and show.
Why we want to do this?
Because we do, each day, a quick checkup, and we'd like to optimize the process to eventually make it available for anyone, even if that person doesn't know the tools or have access. So that anyone can now in our team (we regroup 5 features) if there is an issue with a precise queue manager or not.
But, if you confirm me that this is plain impossible, or will get us into serious run problem, then maybe find something to display consecutives wrong polls on one precise channel can do the trick, but that will be the last resort. |
|
| Back to top |
|
|
| Andyh |
| Posted: Thu Nov 03, 2022 1:37 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
| Why aren't you simply inquiring on the channel status, via the command server? That way you could monitor both the channel state, the XMITQ depth, and whether the channel is actually moving messages. |
|
| Back to top |
|
|
| Andyh |
| Posted: Thu Nov 03, 2022 3:15 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
For example, query generic channel status with some sort of a " where XMITQ EQ" qualifier and then check that one of those channels is in the expected state and actually moving messages.
Similarly, if you really want to only monitor the XMITQ then why not again use the command server and have access to the full set of QSTATUS data rather than the subset visible to MQINQ ?
QDepth is visible as a queue attribute, and thus to MQINQ, but in general QSTATUS (for example last get time) isn't visible to MQINQ. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 03, 2022 3:46 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
This wheel has already been invented. There are a variety of monitoring tools currently in existence, from a variety of vendors, including IBMs Tivoli suite.
_________________
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 |
|
|
| bruce2359 |
| Posted: Thu Nov 03, 2022 3:14 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
A built-in feature of IBM MQ is events. Queue depth events might be a solution to your being alerted to a transmission queue depth increasing to a specified limit or becoming full. Read https://www.ibm.com/docs/en/ibm-mq/8.0?topic=events-enabling-queue-depth.
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
