Hmm. Good to know, kind of, that I'm not the only one with stuck 'running' channels, but for us it was distributed to mainframe. Never did get a proper resolution to it either :(
Regards Darren. ----- Original Message ----- From: "Potkay, Peter M (ISD, IT)" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, February 10, 2005 3:48 PM Subject: Re: Monitoring XMIT queues > "So if the depth is greater than 0, we check the channel health. ie is it > running, is it transmitting messages." > > But not always 100% true. We have occasionally had channels stuck in running > from the mainframe to distributed, and the XMITQ kept piling up. > > Also, the channel could be running, the messages could be moving, but at a > rate of 1 per minute, for whatever reason. > > I like QPASA's dequeue rate feature, which tells you how fast the messages > are being pulled off of the XMITQ. Who cares if the XMITQ is >0, if the > channel is pulling off the messages at a rate of several thousand per > minute? > > > > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf > Of Glen Larson > Sent: Thursday, February 10, 2005 10:42 AM > To: [email protected] > Subject: Re: Monitoring XMIT queues > > > Dave, > > We have several batch applications that dumps thousands of msgs on a xmitq. > We also have a process initiated by DB2 stored procedures, that are > triggered by database field updates. (the data is updated by both CICS and > WAS versions of the application) During peak hour these cause thousands of > transactions a minute, so the xmitq there almost always has msgs. > > So if the depth is greater than 0, we check the channel health. ie is it > running, is it transmitting messages. > > Before we page for channels that are not running we check for time of day, > since some of our nodes have nightly outages, and our mainframes have their > change windows in the wee hours of Sunday. > > But basically we started with the simple stuff like the msgs in the queue, > and built it the alerts as we tired of getting pages for non-problems > > glen larson > Zurich North America > > > > > > "Williams, Dave (Systems Management)" > <[EMAIL PROTECTED]>@LISTSERV.MEDUNIWIEN.AC.AT> on 02/10/2005 09:05:28 AM > > Please respond to MQSeries List <[email protected]> > > Sent by: MQSeries List <[email protected]> > > > To: [email protected] > cc: > > Subject: Monitoring XMIT queues > > > Hello... How are folks monitoring XMIT queues for page alerts? Seems to > me that if the depth of an XMIT queue was on the rise, but had > intermittent decreases there is no need to be paged - if however there > was an increase w/no decreases, that would be a problem and a page would > be warranted. A friend suggested we use ' Service Interval High' to key > off of, but I'm not sure what to code in Omegamon to do this. > > Ideas... Suggestions? > > Thanks, > > Dave W. > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > > > ******************* PLEASE NOTE ******************* > This E-Mail/telefax message and any documents accompanying this > transmission may contain privileged and/or confidential information and is > intended solely for the addressee(s) named above. If you are not the > intended addressee/recipient, you are hereby notified that any use of, > disclosure, copying, distribution, or reliance on the contents of this > E-Mail/telefax information is strictly prohibited and may result in legal > action against you. Please reply to the sender advising of the error in > transmission and immediately delete/destroy the message and any > accompanying documents. Thank you. > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > This communication, including attachments, is for the exclusive use of > addressee and may contain proprietary, confidential or privileged > information. If you are not the intended recipient, any use, copying, > disclosure, dissemination or distribution is strictly prohibited. If > you are not the intended recipient, please notify the sender > immediately by return email and delete this communication and destroy all copies. > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
