Do the messages you're counting always traverse a channel?
If any are put locally then you'll miss them with the channel status technique. You'll likely miss some anyway, especially if you have clients, depending how often you check and how long the channels live. Plus you need to determine if you're looking at new or pre-existing channel instances to determine how to increment your values.
Using a channel message exit you shouldn't miss any messages traversing non-client channels but it is a bit on the complex side. You can count client messages using send/rcv exit(s) but that's a bit more complicated. I've used those methods and they do work well though.
If all you need to do is count messages, i.e. don't need a byte count, then the ResetQueueStatistics PCF command is generally the ticket. It's very easy to do using perl, and not difficult in java, etc. If you do need a byte count and don't mind writing exits you might take a look at capturing relevant information from MQPUT[1]/MQGET calls in an API exit.
Buying something works too.
HTH, Marty
van Zyl, Andre wrote:
Thanks for all the ideas. I think that the best would be to purchase some lightweight WMQ monitoring tool, else if 100% accuracy is not an issue, one can simply look at channel / queue stats figures at regular intervals to compile the required information as required.
Andre
-----Original Message----- *From:* Adiraju, Rao [mailto:[EMAIL PROTECTED] *Sent:* 02 March 2004 11:03 *To:* [EMAIL PROTECTED] *Subject:* Re: MQ Message statistics
One simple option I can think off, is gathering the statistics from "Channel Status". Channel status will give you the number of messages and number of bytes transmitted.
In absence of monitoring tools, I suggest to run a query every night to take a snap shot of channel status and analyse the figures from there (either through a script or program). I do know that channel sequence number gets reset after reaching it's maximum defined on the channel definition and you have to factor this in counting the messages. However, I am not sure how big are the other fields and when do they get reset - you have to give a go at them and see (unless somebody add some info from this forum). The fields of interest are:
LSTSEQNO, BYTSSENT, BYTSRCVD, BUFSSENT, BUFSRCVD (and of course buffer size if you need).
Let us know, how it goes.
Cheers
Rao
------------------------------------------------------------------------ *From:* van Zyl, Andre [mailto:[EMAIL PROTECTED] *Sent:* 2 March 2004 10:19 PM *To:* [EMAIL PROTECTED] *Subject:* MQ Message statistics *Importance:* High
My client has requested that I give them statistics on MQSeries messages ( volumes etc) on a monthly basis. There is no MQ monitoring / admin software installed other than the standard MQ.
We have a hub and spoke architecture, and all mq messages currently flow through the central windows 2000 server and use circular logging. No clustering or MQclients are involved at this stage. On the hub we have WMQI flows for message transformation and distribution purposes.
I would like to find out what the most optimal way would be to gather statistics on message volumes passing through our central HUB server. The 2 options I am considering at the moment is to either use channel exits or to actually modify the message flows to add another destination for each message flow. This additional queue will trigger a program which will collect stats for monthly reporting.
Any advice will be much appreciated!
(WMQI version 2.1 and WMQ version 5.3)
Andre van Zyl
*=========================================================================*
*Disclaimer *
*This message may contain information which is private, privileged or confidential and is intended solely for the use of the individual or entity named in the message. If you are not the intended recipient of this message, please notify the sender thereof and destroy / delete the message. Neither the sender nor Sappi Limited (including its subsidiaries and associated companies) shall incur any liability resulting directly or indirectly from accessing any of the attached files which may contain a virus or the like.*
*Director Names*
* A list of Sappi companies and the names of their directors can be retrieved from http://www.sappi.com/home.asp?pid=644* *=========================================================================*
This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you.
*=========================================================================*
*Disclaimer *
*This message may contain information which is private, privileged or confidential and is intended solely for the use of the individual or entity named in the message. If you are not the intended recipient of this message, please notify the sender thereof and destroy / delete the message. Neither the sender nor Sappi Limited (including its subsidiaries and associated companies) shall incur any liability resulting directly or indirectly from accessing any of the attached files which may contain a virus or the like.*
*Director Names*
* A list of Sappi companies and the names of their directors can be retrieved from http://www.sappi.com/home.asp?pid=644*
*=========================================================================*
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
