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
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
Re: [Maybe Spam] Trigger
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
Re: [Maybe Spam] Trigger
I see. I don't think you need to do anything to restart the trigger mechanism because you haven't done anything to disable it (at least nothing that you mentioned). I still don't quite understand the point of put-disabling the triggered queue, but that's not really the issue. Put-disabling a triggered queue will certainly stop the flow of messages, but I'm not aware that it does anything to affect the triggering mechanism, itself. You claim that your triggered program will process the queue until it gets a 2033. That's exactly what it should do. But then you say there's a chance the triggered app does not get the 2033 return code. Why is that? (Of course, there's always that possibility, I just don't see how it relates to pur-disabling the triggered queue). And what does the program do then? If it keeps trying for a 2033, then you don't need to re-trigger it. If it quits, then it will just retrigger immediately (aka poison message loop) when there are messages on the queue. Sounds to me like maybe you need to rethink the error-handling in the triggered application. Regards, Dennis -Original Message- From: Dawson, John [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 11:11 AM To: [EMAIL PROTECTED] 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