Author |
Message
|
awatson72 |
Posted: Thu Jun 01, 2006 10:48 am Post subject: MQ Explorer SVRCONN channel status |
|
|
Acolyte
Joined: 14 Apr 2004 Posts: 69 Location: Freeport, Maine
|
Using MQ Explorer (v6), I view the status of a SVRCONN channel, and it has columns for "messages" and "channel substate" among others. It would seem that these are not accurate. I have only oneapplication connected to the channel that I know has sent one message and stopped, there are nine channels showing up on status. Each channel shows a large number of messages, and increasing. Channel substate shows some in Receiving and some in MQ Get.
Can anyone shed some light on this? I know the tool isn't perfect, maybe this is a case of it reporting completely bogus information?
Thanks. _________________ Andrew Watson
L.L. Bean, Inc. |
|
Back to top |
|
 |
vennela |
Posted: Thu Jun 01, 2006 11:01 am Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
Quote: |
I know the tool isn't perfect, maybe this is a case of it reporting completely bogus information? |
I doubt if it.
Did you apply the service pack?
How many times did your app run?
What does the mqsc command show if you issue
Code: |
dis chs(*) chltype(svrconn) |
|
|
Back to top |
|
 |
awatson72 |
Posted: Thu Jun 01, 2006 11:30 am Post subject: |
|
|
Acolyte
Joined: 14 Apr 2004 Posts: 69 Location: Freeport, Maine
|
To answer your questions:
I applied Refresh Pack 1.
Displaying channel status with runmqsc doesn't get into enough detail to show "messages" like the GUI tool, but the information about channel substate correlates to the GUI. _________________ Andrew Watson
L.L. Bean, Inc. |
|
Back to top |
|
 |
vennela |
Posted: Thu Jun 01, 2006 11:31 am Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
Try either one of the following
Code: |
dis chs(*) all
dis chs(*) chltype(svrconn) msgs |
|
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Jun 01, 2006 5:30 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
"Messages" on a SVRCONN channel are not actual MQ messages. Issue an MQGET from a client over a SVRCONN channel that returns no MQ message (2033). The "messages" count on that channel will go up by 2. The first "message" is the MQGET request. The 2nd is the results of the MQGET.
Most (every?) MQ API call generates 2 "messages". I only tested it with the puts and gets a year or so ago. I *think* all the API calls do this. Easy enough for you to test. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Carl Bloy |
Posted: Fri Jun 02, 2006 12:40 am Post subject: |
|
|
Acolyte
Joined: 16 Dec 2003 Posts: 69 Location: England
|
Check the connection name of the SVRCONN channels, are they the same?
Also check the last message date/time.
My guess is that most of these 9 channels are no longer in use, maybe from a previous application not closing correctly? _________________ Regards
Carl |
|
Back to top |
|
 |
awatson72 |
Posted: Fri Jun 02, 2006 5:21 am Post subject: |
|
|
Acolyte
Joined: 14 Apr 2004 Posts: 69 Location: Freeport, Maine
|
Carl, I ensured that this channel is used by only one application, the connection name is the same.
Interestingly, now that I've let it sit overnight, I've noticed that 3 of the 9 channels have been accumulating "messages" and are now up to roughly 26,000 each. Those 3 are in MQ Get, the others are Receiving. I'm quite sure that this behavior is because this channel is used by a WAS MQ Connection Factory, (MDB). Also, keepalives are turned on. Do keepalives issue an MQ API call? Does anyone know if Queue Connection Factories cause activity on the channel, even if they aren't doing any work?
Thanks. _________________ Andrew Watson
L.L. Bean, Inc. |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Jun 02, 2006 5:33 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
MDBs will continually browse the queue looking for messages that match what the application wants. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
awatson72 |
Posted: Fri Jun 02, 2006 5:52 am Post subject: |
|
|
Acolyte
Joined: 14 Apr 2004 Posts: 69 Location: Freeport, Maine
|
That makes sense.
Do you happen to know if the browse frequency is configurable? Just curious more than anything...
I don't see any obvious way to control that at the Listener Port, or QCF in WAS... _________________ Andrew Watson
L.L. Bean, Inc. |
|
Back to top |
|
 |
vennela |
Posted: Fri Jun 02, 2006 6:36 am Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
I am pretty sure that it is configurable |
|
Back to top |
|
 |
zpat |
Posted: Thu Jul 01, 2021 1:58 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
We have a single JMS application reading a single queue.
Even when the queue is empty (and nothing is arriving) - the message count on the srvconn channel (CHSTATUS) being used increases at a rate of about 60 per second.
I presume these are all failed MQGETs?
Does JMS use selectors?
They claim to have set the JMS receive timeout to 30 seconds.
How can I prove this is actually resulting in MQGMO_WAIT being used correctly?
Linux MQ v8 client - z/OS MQ v9 QM
As so often with z/OS we don't get the new features so there is no application activity trace option on the QM. _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
tczielke |
Posted: Thu Jul 01, 2021 5:34 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010 Posts: 941 Location: Illinois, USA
|
z/OS does have an MQ API trace. It is not as user friendly as the Application Activity Trace, but you can see some of the API calls and control blocks (e.g. GMO) in this trace. The MH06 supportpac has a Java mqtrcfrmt.jar that can decode the control blocks, too. _________________ Working with MQ since 2010. |
|
Back to top |
|
 |
zpat |
Posted: Thu Jul 01, 2021 12:00 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Will a trace taken on the MQ client platform be of any use, if I send it to the IBM support centre?
(tracing on z/OS MQ really is most unfriendly to use and has to be sent as a dump to IBM). _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
gbaddeley |
Posted: Thu Jul 01, 2021 3:58 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
zpat wrote: |
We have a single JMS application reading a single queue.
Even when the queue is empty (and nothing is arriving) - the message count on the srvconn channel (CHSTATUS) being used increases at a rate of about 60 per second. |
https://developer.ibm.com/components/ibm-mq/articles/mq-best-practices/
Are you setting the consumer receive wait time to a low value?
The recommendation is to not set it, so that the app does an indefinite blocked wait for new messages. _________________ Glenn |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Jul 01, 2021 5:13 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
I recall from posts here and Vienna that JMS required MQINQ, so yes to JMS using selectors. _________________ 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 |
|
 |
|