ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » MQOPEN error on a queue monitor CURDEPTH XMITQ

Post new topic  Reply to topic Goto page Previous  1, 2
 MQOPEN error on a queue monitor CURDEPTH XMITQ « View previous topic :: View next topic » 
Author Message
fjb_saper
PostPosted: Wed Oct 19, 2022 12:15 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
hughson
PostPosted: Wed Oct 19, 2022 12:24 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Thu Oct 20, 2022 5:14 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
Oroshi
PostPosted: Tue Oct 25, 2022 1:46 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Tue Oct 25, 2022 4:38 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
gbaddeley
PostPosted: Tue Oct 25, 2022 3:28 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
bruce2359
PostPosted: Wed Oct 26, 2022 6:57 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
Oroshi
PostPosted: Thu Nov 03, 2022 12:20 am    Post subject: Reply with quote

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
View user's profile Send private message
Andyh
PostPosted: Thu Nov 03, 2022 1:37 am    Post subject: Reply with quote

Master

Joined: 29 Jul 2010
Posts: 237

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
View user's profile Send private message
Andyh
PostPosted: Thu Nov 03, 2022 3:15 am    Post subject: Reply with quote

Master

Joined: 29 Jul 2010
Posts: 237

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
View user's profile Send private message
bruce2359
PostPosted: Thu Nov 03, 2022 3:46 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
bruce2359
PostPosted: Thu Nov 03, 2022 3:14 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » General IBM MQ Support » MQOPEN error on a queue monitor CURDEPTH XMITQ
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.