Let me try to fill in a couple of blanks. First, the conventional wisdom would be that recycling the qmgr clears it up because it forces an end to all UOW's, eliminating all uncommitted gets/puts. Second, client connections are more prone to some unexpected effects because the qmgr is not always intimately aware of the client's state. Suppose for example, a client does an MQGET under syncpoint and then abends before the commit. In that state you have a queue depth 1 greater than the number of messages that you can "see" on the queue. That situation remains until the qmgr recognizes the client is gone and rolls back the MQGET, which might be awhile. Finally, I agree with others that the absence of MQBEGINs is not a fair test of whether you are using syncpoints. The operative indicator is the use of syncpoint on the GMO/PMO parameter.
I notice from your display that 12 process have the queue open when it contains no messages. This suggests a lot of long-running tasks and makes me ever-more suspicious that one of them is misbehaving with respect to uncommitted gets/puts. My approach to diagnosis would be this. First, see what DISPLAY THREAD shows. If that doesn't reveal the culprit, then, terminate the 12 processes one-by-one and monitor the queue depth at each step. If the difference between available messages and qdepth changes, then that process is suspect. When all's-said-and-done if there are no open handles and there is still an inconsistency, then you can throw the uncommitted message theory out the window. Regards, Dennis -----Original Message----- From: Tony Boggis [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 3:54 PM To: [EMAIL PROTECTED] Subject: Re: Incorrect CURDEPTH displayed? Recycling the qm does generally clear it up, yes. For a while. I've seen this a few times lately. I don't know how a restart is clearing it. No client connections involved (why would that affect things?). All apps make direct connections (no channels involved). Granted that persistence is a message attrib. My error. Uncommitted gets? Hmmm. Granted that could be a possibility, but in our case, as I mentioned, we do not use syncpointing (but your point about using syncpointing is interesting). A grep on all source code finds not one instance of MQBEGIN. tonyB. > -------- Original Message -------- > Subject: Re: Incorrect CURDEPTH displayed? > From: "Miller, Dennis" <[EMAIL PROTECTED]> > Date: Wed, November 03, 2004 2:27 pm > To: [EMAIL PROTECTED] > > Does recycling the QMgr clear it up? > And, if so, how--by restoring the messages or by clearing the qdepth? > Are any applications using client connections? > > > You said> > The queues are set as non-persistent. > > >>Persistence is a property of a message, not a queue. Any queue can > hold persistent messages. > > > You said> > We do not use units-of-work (no Begin/End). > > >>My-oh-my. There's a fair chance that uncommitted gets are the > culprit. I have never heard a defensible argument for doing gets > outside of syncpoint. Problems like phantom messages and dropped > messages are an expected result. > > > Regards, > Dennis > > > -----Original Message----- > From: Tony Boggis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 03, 2004 12:45 PM > To: [EMAIL PROTECTED] > Subject: Incorrect CURDEPTH displayed? > > > I have a queue manager that is showing a current depth (non-zero) on > several application queues. However, when I browse the queues > (MQExplorer or amqsbcg) I get nothing. Also, when I browse the queues, > the count does not go down to zero (as I might expect if there were > expired messages). > > The queues are set as non-persistent. > We do not use units-of-work (no Begin/End). > We do not set expiry time on messages. > > Apart from this "ghost" depth, everything seems ok. I can get/put > messages as normal. I just can't seem to get curdepth to return to > zero. > > Suggestions? Am I missing something obvious? > > This is on Solaris 5.8 with WMQ 5.3, CSD08. > > tonyB. > > 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 > > 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 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 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
