Hi Dennis,

Your original question was:

> > >Please tell me why  there
> > > is mention of MQTT_DEPTH in #11 and how it is
> > > any  different from conditions 1-10 in their own
> > >right.

I just made an humble attempt to  point out the
difference between #3 (which is in  1-10)  and #11.

Now the question is the difference between #11 and
#12. I know what you mean and share your sentiments
about the mention of MQTT_DEPTH in #11.

> > My understanding of #11 is:  This is to address
> >the  situation where the triggered app did not
>> consume all  of the messages before closing the
>> queue...

I should have said "This is to address the  situation
where the triggered app did not consume all  of the
messages before TERMINATING (not closing)..." And add
that "the queue was not opened at all before the
termination of the app...". Although this would have
clarified the difference (to some including myself,
NOT to you Dennis as you already know it;))    between
#3, 11 and 12 for MQTT_FIRST, it still would not
explain the inclusion of MQTT_DEPTH in #11.

Maybe, IBM guys can shed some light on this?

Best regards,

Ruzi


--- "Miller, Dennis" <[EMAIL PROTECTED]> wrote:
> Wouldn't condition #12 take precedence?
>
> > -----Original Message-----
> > From: Ruzi R [SMTP:[EMAIL PROTECTED]
> > Sent: Tuesday, March 04, 2003 7:47 PM
> > To:   [EMAIL PROTECTED]
> > Subject:           Re: Triggerinterval firing when
> queue is still open
> >
> > My understanding of #11 is:  This is to address
> the
> > situation where the triggered app did not consume
> all
> > of the messages before closing the queue So, in
> the
> > case of a trig type DEPTH queue: If the
> triggerdepth
> > was, say 10, and the app started GETtting messages
> but
> > terminated while there were still, say, 12 more
> > suitable messages on the queue (so the queue has
> now "
> > > triggerdepth" messages). The arrival of the
> first
> > suitable message on this queue would cause the
> trigger
> > message to be generated. This is different from #3
> > where the num of suitable messages must be "
> > triggerdepth minus 1".
> >
> > Best regards,
> >
> > Ruzi
> >
> >
> > --- "Miller, Dennis" <[EMAIL PROTECTED]> wrote:
> > > I've never understood #11 and defer to the
> > > discussion about "Special case of trigger type
> > > FIRST", a few pages later. Please tell me why
> there
> > > is mention of MQTT_DEPTH in #11 and how it is
> any
> > > different from conditions 1-10 in their own
> right.
> > >
> > > You can infer from the claim that "trigint=0
> behaves
> > > like trigtype every" that there is no
> requirement
> > > for IPPROCS=0. You may want to make your trigger
> > > interval >= to your waitinterval. (Yes, I know
> it's
> > > a qmgr-wide parameter).
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Tim Clarke [SMTP:[EMAIL PROTECTED]
> > > > Sent: Monday, March 03, 2003 5:48 PM
> > > > To:   [EMAIL PROTECTED]
> > > > Subject:           Triggerinterval firing when
> > > queue is still open
> > > >
> > > > I am have a queue with trigger FIRST and an
> > > application
> > > > that is doing a GET with a WAITINTERVAL of 5
> > > minutes.
> > > >
> > > > The application is staying running for hours
> > > keeping the
> > > > queue open, but the TRIGGERINTERVAL is still
> > > generating
> > > > extra trigger messages.
> > > >
> > > > My understanding from the Appl. Prog. Guide
> > > (Chapter 14)
> > > > in "Conditions for a trigger event" point 11
> is
> > > that
> > > > for a trigger message to be generated by the
> > > TRIGGERINTERVAL
> > > > conditions 2-10 (excl. 3) must be satisfied
> and
> > > condition 4
> > > > is that the queue must have an OpenInputCount
> of
> > > 0.
> > > >
> > > > So, if the application still has the queue
> open,
> > > why are
> > > > these extra trigger messages being generated ?
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
*********************************************************************************
> > > > This email contains information confidential
> to
> > > AAMI Limited.  If you are  not the intended
> > > recipient, you must not disclose or use the
> > > information in it.  If you have received this
> email
> > > by error, please notify us immediately by return
> > > email, and delete this email and any attached
> > > documents.
> > > > AAMI Limited is not responsible for any
> changes
> > > made to a document other than those made by AAMI
> > > Limited or for the effect of the changes on the
> > > document meaning.
> > > >
> > >
> >
>
**********************************************************************************
> > > >
> > > > 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

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

Reply via email to