| Author |
Message
|
| ashu |
 Posted: Sun May 06, 2007 10:20 pm Post subject: FIRST trigger type. |
 |
|
Centurion
Joined: 11 Nov 2006
Posts: 132
|
Hello,
If the trigger type is FIRST, does it mean that the trigger is fired only for the very first message on the queue when it is created or for every first message whenever the queue is empty?
If the later is true then can we safely assume that trigger type FIRST is same as trigger type DEPTH with depth 1?
regards 
_________________
Ashu
"It is simple to be Happy but difficult to be Simple" |
|
| Back to top |
|
 |
| abhishekpreddy |
| Posted: Sun May 06, 2007 11:17 pm Post subject: |
|
|
Apprentice
Joined: 02 May 2007
Posts: 49
|
TRIGTYPE=FIRST
Is the default. When the number of messages on the triggered queue goes
from zero to one, the queue is triggered, the queue manager creates a trigger message and places it on the initiation queue, and the trigger monitor reads that message and starts the program.
TRIGTYPE=DEPTH
When the depth of the queue goes from one less than TRIGDPTH to equal to TRIGDPTH, the queue is triggered and the process continues as in
TRIGTYPE=FIRST.
Hope this explains your doubt , however for a TRIGTYPE of DEPTH, when the trigger conditions are satisfied on the
triggered queue, the queue manager creates a trigger message and disables triggering on that queue using the TriggerControl attribute. The triggered application must re-enable triggering itself by using the MQSET call.
Hope this Helps. |
|
| Back to top |
|
|
| ashu |
| Posted: Mon May 07, 2007 12:19 am Post subject: |
|
|
Centurion
Joined: 11 Nov 2006
Posts: 132
|
Agreed...so does that mean the only reason there is trigger type FIRST is because one need not re-enable triggering every time the trigger condition is met...cause otherwise trigger type DEPTH with depth=1 can suffice and we don't need trigger type FIRST at all... 
_________________
Ashu
"It is simple to be Happy but difficult to be Simple" |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Mon May 07, 2007 12:39 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi ashu,
TRIGTYPE=FIRST should trigger on every first message that arrives when the triggered application is not running....i think, these days i'm doubtful about everything 
You actually want to use this and not DEPTH...
Regards. |
|
| Back to top |
|
|
| atheek |
| Posted: Mon May 07, 2007 3:15 am Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
The trigger interval (TRIGINT) attribute of the queue manager comes into picture when TRIGTYPE is FIRST.
usage of TRIGINT as per IBM docs:
When the arrival of a message on a queue causes a trigger message to be put on the initiation queue, then any message that arrives on the same queue within the specified interval does not cause another trigger message to be put on the initiation queue.
The trigint is used to prevent unnecessary triggering of applications. If you use trigtype as depth then the qmgr turns off the trigering to prevent unwanted trigerring. But now the apllication needs to set it back to turn on triggering. This is not required if you are using trigtype(FIRST). |
|
| Back to top |
|
|
| ashu |
| Posted: Mon May 07, 2007 3:35 am Post subject: |
|
|
Centurion
Joined: 11 Nov 2006
Posts: 132
|
| atheek wrote: |
The trigger interval (TRIGINT) attribute of the queue manager comes into picture when TRIGTYPE is FIRST.
usage of TRIGINT as per IBM docs:
When the arrival of a message on a queue causes a trigger message to be put on the initiation queue, then any message that arrives on the same queue within the specified interval does not cause another trigger message to be put on the initiation queue.
The trigint is used to prevent unnecessary triggering of applications. If you use trigtype as depth then the qmgr turns off the trigering to prevent unwanted trigerring. But now the apllication needs to set it back to turn on triggering. This is not required if you are using trigtype(FIRST). |
 Marvellous! Thank you for the input ...my doubt is now cleared...
Thanks to all for their valuable time and all the inputs.
Regards,
_________________
Ashu
"It is simple to be Happy but difficult to be Simple" |
|
| Back to top |
|
|
| ashu |
| Posted: Mon May 07, 2007 4:14 am Post subject: |
|
|
Centurion
Joined: 11 Nov 2006
Posts: 132
|
Then again.... 
| Quote: |
| If you use trigtype as depth then the qmgr turns off the trigering to prevent unwanted trigerring. |
what does it mean by Unwanted Triggering?
Also if the trigtype is EVERY does that mean for every message on the queue a trigger message is put on the init Q? cause since in the case of trigtype FIRST the triggered application always makes the Queue empty there by making the trigtype act like EVERY....
Is that confusing... 
Forgive my innocence
Regards,
_________________
Ashu
"It is simple to be Happy but difficult to be Simple" |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon May 07, 2007 4:23 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Suppose you write a program that reads each message off of the queue, until it gets a 2033.
Then you configure this program to be triggered, and you set trigger=EVERY.
And then ten messages are put on the queue.
The queue manager will put ten messages on the initiation queue.
The trigger monitor will try to start your program ten times.
Each program will try and read all ten messages from the queue. If, for example, you've coded your program to open the queue for exclusive input - then only one program will get messages. Every other program will then throw errors, presumable. This will cause the trigger monitor to dump the initiation message on the DLQ.
EXCEPT, that trigger=every is not 100% guaranteed to produce one initiation message for each message on the queue. There are some cases where it will decide to "optomize" things, and produce less than 10.
The recommended practice for quite a long time has been to use TRIGTYPE=FIRST. This is because it's the option that works the best and fits the best into MQ design patterns.
Just think about TRIGTYPE as controlling, somewhat, which conditions cause INITIATION messages to be put on the initation queue. Do not think, at all, about how the program that is triggered acts.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| ashu |
| Posted: Mon May 07, 2007 8:08 pm Post subject: |
|
|
Centurion
Joined: 11 Nov 2006
Posts: 132
|
Thank You Jeff !
Regards,
_________________
Ashu
"It is simple to be Happy but difficult to be Simple" |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 08, 2007 6:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Jeff correct me if I'm wrong here:
My understanding is with Trigtype(first) and all the usual stuff for triggering the trigint will come to play in the following situation:
The queue is not empty. The queue is not serviced. A new message hits the queue.
If that message is in the interval (last trigger msg + trigint) there is no trigger message generated.
If the new message is outside the interval (last trigger msg + trigint) a new trigger message is generated.
If there is no new message hitting the queue and the interval is greater than trigint since the last trigger message there is no trigger message generated.
The generation of a new trigger message is dependent on the event: a message is put to the queue + evaluation of trigint
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed May 09, 2007 1:52 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No, I think trigint only comes into play for purposes of generating a trigger message if the queue is not empty.
But I haven't read through the page of trigger conditions in a while....
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 09, 2007 3:43 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
No, I think trigint only comes into play for purposes of generating a trigger message if the queue is not empty.
But I haven't read through the page of trigger conditions in a while.... |
The premise was the queue was not empty... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed May 09, 2007 3:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Man, I read that wrong...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 10, 2007 11:24 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
Jeff correct me if I'm wrong here:
My understanding is with Trigtype(first) and all the usual stuff for triggering the trigint will come to play in the following situation:
The queue is not empty. The queue is not serviced. A new message hits the queue.
If that message is in the interval (last trigger msg + trigint) there is no trigger message generated.
If the new message is outside the interval (last trigger msg + trigint) a new trigger message is generated.
If there is no new message hitting the queue and the interval is greater than trigint since the last trigger message there is no trigger message generated.
The generation of a new trigger message is dependent on the event: a message is put to the queue + evaluation of trigint
|
Correct.
EXCEPT on z/OS at MQ 6.0. On the mainframe, once trigger interval passes a trigger message will be generated if the q depth is > 0 and the IPROCS is 0. A new message does not need to arrive. This is not yet documented in the manuals. We had a discussion about this on the list serve last year.
On distributed systems, it works as you described.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| atheek |
| Posted: Thu May 10, 2007 8:44 pm Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
This is my understanding of how trigtype(first) works. Can anybody confirm the same:
1. Situation: qdepth =0 and iprocs = 0
Event: New Message comes
Result: New trigger message generated (Irrespective of whether
triginterval has expired or not)
2. Situation: qdepth =0 and iprocs > 0 (queue is serviced)
Event: New Message comes
Result: No trigger message generated (Irrespective of whether triginterval has expired or not)
3. Situation: qdepth =>0 and iprocs = 0 (queue is not serviced)
Event: Trigger Interval expires
Result: No trigger message generated ( Except in Mainframes as suggested by Peter)
4. Situation: qdepth =>0 and iprocs = 0 (queue is not serviced)
Event: Trigger Interval expires & New Message comes
Result: New trigger message generated |
|
| Back to top |
|
|
|
|
