| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| queue with trigger first and message at cics startup |
« View previous topic :: View next topic » |
| Author |
Message
|
| ipmqadm |
 Posted: Thu Sep 12, 2013 7:53 am Post subject: |
 |
|
Acolyte
Joined: 18 Apr 2007
Posts: 68
|
| PeterPotkay wrote: |
| zpat wrote: |
| PeterPotkay wrote: |
| zpat wrote: |
| If it does not read the queue until empty you would need to use trigger EVERY. |
With Trigger FIRST, every time the app closes the q and there are more messages on the q the app will be retriggered until the q is emptied one message at a time. |
Really? I always thought it was only when the queue depth went from 0 to 1.
| Quote: |
| FIRST. A trigger event occurs only when the number of messages on the application queue changes from zero to one. Use this type of trigger if you want a serving program to start when the first message arrives on a queue, continue until there are no more messages to process, then end. |
|
Really. 
| Quote: |
12. The only application serving a queue issues an MQCLOSE call, for a TriggerType of MQTT_FIRST or MQTT_DEPTH, and there is at least:
One (MQTT_FIRST), or TriggerDepth (MQTT_DEPTH)
messages on the queue of sufficient priority (condition 2), and conditions 6 through 10 are also satisfied.
This is to allow for a queue server that issues an MQGET call, finds the queue empty, and so ends; however, in the interval between the MQGET and the MQCLOSE calls, one or more messages arrive.
Note:
If the program serving the application queue does not retrieve all the messages, this can cause a closed loop. Each time that the program closes the queue, the queue manager creates another trigger message that causes the trigger monitor to start the server program again.
If the program serving the application queue backs out its get request (or if the program abends) before it closes the queue, the same happens. However, if the program closes the queue before backing out the get request, and the queue is otherwise empty, no trigger message is created.
To prevent such a loop occurring, use the BackoutCount field of MQMD to detect messages that are repeatedly backed out. For more information, see Messages that are backed out.
|
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzal.doc/fg13830_.htm
This feature and the benefits of Trigger Interval mean you should use Trigger On First almost always. Its a rare case where Depth or Every are the correct solution, although they are available for a reason.
Trigger On Group (trigger only when all the messages of a group are on the q), now THERE is a trigger type that could be more useful than Every in my opinion.  |
Peter, I just now saw this, from so long ago, while researching triggering issues. The 'trigger on group' is an excellent idea! Have IBM make that happen... But I'm thinking that if the application program uses the MQCMIT or SYNCPOINT correctly then the LUW could in fact implement the 'trigger on group'? |
|
| Back to top |
|
 |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
