I'm assuming two things here.
1) your program re-enables puts. And no enabling puts on a triggered queue
does not cause a trigger message.
2) your application (whether or not it receives a 2033) is going to close
the queue and end, therefore requiring a trigger if there was data on the
queue. Here there is good news. One of the events that will can cause a
trigger on first queue to generate a trigger message, is the last
application with an open for input issuing a close while the depth is
greater than 0.
I hope that the applications that send messages to this queue are prepared
to handle either the 2051 errors or the messages landing on a dead queue
while you have this queue put inhibited. I've got to admit I don't see a
reason why to set up triggered queues and then interfere with the ability
to use them. I must be missing something like what would cause you to 'at
times' decide to put inhibit the queue.
Rick
|---------+--------------------------------------->
| | "Dawson, John" |
| | <[EMAIL PROTECTED]> |
| | |
| | Sent by: MQSeries List |
| | <[EMAIL PROTECTED]> |
| | |
| | |
| | |
| | Monday February 9, 2004 01:10 PM |
| | Please respond to MQSeries List |
| | |
|---------+--------------------------------------->
>----------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: [Maybe Spam] Trigger
|
>----------------------------------------------------------------------------------------------------|
Dennis,
There is a trigger queue receiving messages. The queue is trigger on
first. The logic of the triggered program is that once triggered, it will
process all the messages until receiving a return code of 2033.
At times after getting the application message, there will be a need to
prevent any additional messages from being 'put' to the queue. So, the
triggered program will 'put' disable the queue. When it does the 'put'
disabled, there's a chance that the program did not receive the 2033 return
code and messages are remaining on the queue.
My question is, if there are messages that remained on the queue while
the
queue was 'put' disabled, will those messages that remain on the queue
cause
the trigger mechanism to restart. Or, will the trigger need to be turned
off
and then turned backed on to restart the trigger mechanism, once the queue
has been 'put' enabled?
Thanks,
John Dawson
-----Original Message-----
From: Miller, Dennis [mailto:[EMAIL PROTECTED]
Sent: Monday, February 09, 2004 12:49 PM
To: [EMAIL PROTECTED]
Subject: Re: [Maybe Spam] Trigger
John,
Unfortunately, I cannot follow your question. Maybe I just don't
understand what 'puts' is. If a queue is put-disabled, then no more
messages can be queued there. If a program loops until 2033, then that
means all queued messages have been removed. So what do you mean by
"because of this, messages will remain on the queue".
Also, it's not that common to put-disable a triggered queue. Sort of
defeats the purpose of queuing. Please better explain what you are
trying to accomplish.
-----Original Message-----
From: Dawson, John [mailto:[EMAIL PROTECTED]
Sent: Monday, February 09, 2004 7:21 AM
To: [EMAIL PROTECTED]
Subject: [Maybe Spam] Trigger
Hey Folks,
I have a triggered queue, triggering on first. The 'puts' for the
queue is disabled because the program, acting upon a message, has to
stop the processing, inside the loop that is getting messages until a
return code of 2033. Because of this, messages will remain on the queue.
When the 'puts' on the queue is re-enabled, will the remaining
messages on the queue force the trigger to start again or will it take a
new message arriving on the queue to start the triggering.
What if the triggering is turned off and then on at the same time as
the 'puts' are re-enabled?
Thanks everyone,
John Dawson
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
