Re: Incorrect CURDEPTH displayed?

[Markus Sonderegger]

> A grep on all source code finds not one instance of MQBEGIN.

An MQBEGIN marks the beginning of a global unit of work. where  another resource like  a database is involved an the QM is doing the resource coordination.

A local unit of work is requested when doing an MQGET, MQPUT, or MQPUT1 with the syncpoint option.
It is then either commited with MQCMIT or rolled back using MQBACK.

Therefore you should search in the code for MQCMIT.

Regards
Markus
------------------------------------------------------------------
Dr. Markus Sonderegger, IKI
Bank Julius Baer & Co. Ltd.
Hohlstrasse 602, CH-8010 Zurich, Switzerland
Telephone +41 58 887 7281, Fax +41 58 887 4475
www.juliusbaer.com
------------------------------------------------------------------

MQSeries List <[EMAIL PROTECTED]> wrote on 04.11.2004 00:53:49:

> 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


*****Disclaimer*****
This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the Julius Baer Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the Julius Baer Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.juliusbaer.com/maildisclaimer