| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CKTI and Trigger Type Every |
« View previous topic :: View next topic » |
| Author |
Message
|
| GEORGEY |
 Posted: Tue Jun 20, 2006 6:20 am Post subject: CKTI and Trigger Type Every |
 |
|
Newbie
Joined: 20 Jun 2006
Posts: 3
|
Hi,
If the trigger type is set up as Every, then when a message arrives on the queue and CKTI calls the defined transaction(xxxx), how does my transaction know which message to read from the Queue? The Msg Id isn't in the MQTM.
Does my transaction xxxx have to just take the first message on the queue using info from MQTM? If this is so, should I just change the Trigger type to First.
You can probably tell I am new to this subject. Our system will be handling thousands of MQ messages each day and I'm just trying to see the best way to process them.
Thanks in advance for any replies. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jun 20, 2006 7:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You are correct, the triggered transaction must take the 1st message off the queue. I'd also recommend using trigger FIRST and looping round the process until the queue is empty. Trigger EVERY is seldom a good idea, especially with large volumes of messages as you end up with large numbers of triggered transactions competing for resource.
There are any number of ways of detecting and dealing with the situation where messages are arriving faster than your application can read & process them. Use the search facility on this forum for some previous discussions on queue depth monitoring strategies.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| GEORGEY |
| Posted: Tue Jun 20, 2006 7:21 am Post subject: |
|
|
Newbie
Joined: 20 Jun 2006
Posts: 3
|
I think I was eventually coming to that conclusion. I'll check out that depth monitoring. Must say this is a very good forum.
Cheers. |
|
| Back to top |
|
|
| wschutz |
| Posted: Tue Jun 20, 2006 7:35 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
and...don't assume that they will be a message to process... there are many examples where your transaction will be triggerred but these is NO message to process...so allow for 2033 from the FIRST MQGET...and also, you should also wait on the first MQGET for a brief period of time (like 15 seconds) because it might be that the trigger message becomes available before the message that causes the trigger event....
_________________
-wayne |
|
| Back to top |
|
|
| GEORGEY |
| Posted: Tue Jun 20, 2006 7:37 am Post subject: |
|
|
Newbie
Joined: 20 Jun 2006
Posts: 3
|
The queue we are using will have messages from a front end system, with several different message types. For each of these message types we'd want to kick of a related cics transaction.
CKTI
¦
starts
¦
xxx1
¦
starts
¦
xxx3 or xxx4 or xxx5 etc depending on the message.
Any better way of doing it? I don't think we can use multiple queues. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 20, 2006 8:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
This kind of "gatekeeper" arrangement is certainly a valid way of doing it. People who know more about CICS transactions than I do will probably express this better, but ensure that xxx3, xxx4, xxx5 can roll the message back onto the queue or otherwise handle any errors that occur.
One way (but by no means the only way) is for xxx1 to read from the inbound queue, identify the message type, write the message to one of another queues (called xxx3, xxx4, xxx5, etc) depending on message type from which it is read off and processed by the appropriate transaction. Each queue has a backout defined, you get granularity in the depth monitoring and everyone's happy.
Apart from the next poster, who will suggest a much better and eligent solution 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
