| Author |
Message
|
| moez |
 Posted: Thu Oct 13, 2005 4:13 am Post subject: Triggering with First vesus Every option |
 |
|
Newbie
Joined: 13 Oct 2005
Posts: 4
|
I'm a mainframe, CICS programmer and we are implementing our first MQ application - so, I'm about as green as you get.... Hopefully my question isn't too basic. I've tried to review previous posts for an answer, but have not had luck finding just what I'm looking for.
My application will be triggered when transactions from a client hit a queue. In my mind, I wanted to set this up the same way that I have every other CICS transaction that we have - basically, one message, one transaction. So, in our current environment, it is not uncommon to see many many ATM transactions all executing at the same time, for example.
With this in mind, I set up the queue to trigger with trigger type = Every. My program then opens, gets and closes the queue, processes the transaction, put1's the output message and ends. I thought that this would most closely parallel our current processing with all of our other applications.
Yesterday, when we began testing, I turned on new "every" triggering options and tried to let it rip (we already had 5 messages on the trigger queue)..... nothing happened. Finally, after I cleared the existing messages, all new messages began triggering my transaction successfully.
So.... that got me wondering whether or not my design was appropriate for the way MQ works. Specifically, if the system were to come down and back up again with messages on the queue. Would those messages be "stranded" with my current logic? Or should I instead change the option to FIRST and just loop through the queue each time that I process a transaction?
I'm just looking for any thoughts or ideas from people who have lived through all of this before. Any thoughts will be appreciated.
Thanks,
Moez |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Oct 13, 2005 4:16 am Post subject: Re: Triggering with First vesus Every option |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| moez wrote: |
| Or should I instead change the option to FIRST and just loop through the queue each time that I process a transaction? |
Yes.
Trigger EVERY is not guaranteed to trigger for every message. It likely should have triggered for your case, but it's hard to tell why it didn't from your post.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Oct 13, 2005 4:30 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
And to follow on with Jeff's comment:
When you design triggered applications, you should always do these things;
1. never asume only 1 message, always loop until you get a 2033
2. never asume any messages, always be able to handle a 2033 on the first get
(1) follows from your experience and Jeff's comments, (2) follows from (1).
_________________
-wayne |
|
| Back to top |
|
|
| moez |
| Posted: Thu Oct 13, 2005 4:51 am Post subject: |
|
|
Newbie
Joined: 13 Oct 2005
Posts: 4
|
Wayne and Jeff,
Thanks for your responses - the looping definitely makes sense to me and I'll implement that right away. I'm confused however, why using the FIRST option on the trigger is preferable to using EVERY.
If, as Jeff mentioned, that EVERY doesn't guarantee a trigger event, wouldn't my loop alone take care of this situation? Also, wouldn't I be in the same boat (with transactions being stranded on the queue) if the system were to go down and come back up with transactions on the queue and my trigger option was set to FIRST?
Thanks,
Moez |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 13, 2005 4:56 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Oct 13, 2005 4:59 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Triggering is both simple and complex ......
Many prefer FIRST. If you use EVERY, and suddenly 10,000 messages arrive on your queue, the qmgr will generate 10,000 trigger messages, which can swamp any system if the trigger monitor tries to start 10,000 programs. However, if you feel assured that a much smaller number of messages will arrive at any given time, then EVERY allows you to have an easy way for running multiple instances of your program to give faster turn-around time.
| Quote: |
| Also, wouldn't I be in the same boat (with transactions being stranded on the queue) if the system were to go down and come back up with transactions on the queue and my trigger option was set to FIRST? |
No, with FIRST, the queue manager will generate a trigger message when the system "comes up' (technically, when the trigger monitor opens the initiation queue).
_________________
-wayne |
|
| Back to top |
|
|
| moez |
| Posted: Thu Oct 13, 2005 5:08 am Post subject: |
|
|
Newbie
Joined: 13 Oct 2005
Posts: 4
|
Wow. Thanks to both of you.
Wayne, I have noticed that most of the posts that I've read are always proposing the use of FIRST over EVERY. In my case, this should be a very low volume application (at least for my lifetime) and having multiple programs running concurrently is the same way that we process everything else anyway.... And, maybe it's easier for my small brain to understand.
Thank you for the great link, Jeff. It is VERY helpful. Next time, I'll be able to RTFM more completly before posting.
Thanks again!
Moez |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Oct 13, 2005 5:48 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
just let me add that with trigger "first" you are not allowed to leave messages in the queue when you close the queue (when the last process that has the queue open for input closes the queue).
in that case, mqseries will create another trigger messages because the queue is not empty (and trigger first will never occur again).
This means, that an abending cics transaction that leaves (backouts) the message back to the queue again will be triggered again, abend again, backout again, trigger again, abend again, ....... will loop this way.
so it is important with trigger first to check the backoutcount of the message and perform proper action if required prior to process the message.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Oct 13, 2005 5:58 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Good point about poisoned messages, I should have mentioned that 
| Quote: |
| just let me add that with trigger "first" you are not allowed to leave messages in the queue when you close the queue |
"not allowed to leave" perhaps should say "you technically can leave messages there, but you should design the system to avoid it, but if you do, MQ handles it anyways" 
_________________
-wayne |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Oct 13, 2005 6:05 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
thats what i ment, but i did not pick up the right words (my english sucks) . thanks for correcting.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Oct 13, 2005 6:07 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| having multiple programs running concurrently is the same way that we process everything else anyway |
And if you want this, then the most efficient way is to write a small program, that is triggered on First, to act as a "traffic cop" and spawn off the rewuired processes. That way you can keep control of how many concurrent programs are running when you get a flood of messages at once.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| moez |
| Posted: Thu Oct 13, 2005 6:16 am Post subject: |
|
|
Newbie
Joined: 13 Oct 2005
Posts: 4
|
Eddie,
What you described with your "traffic cop" is essentially the way that I've set up my process.
The initial program gets kicked off with a transaction on the queue. This then kicks off any of a number of CICS processes (depending on the incoming message) and waits for it to finish. If I don't get a response back from the CICS process in 30 seconds, the traffic cop sends a timeout error.
It was because of this flow that I opted against using the FIRST option. That is, if the kicked off CICS transaction goes of to lala land for a while, then every transaction behind it could potentially be held up by 30 seconds. On the other hand, using EVERY, then every transaction can be processed without regard to the previous ones on the queue.
This, plus the facts that this is a low volume application and that multiple, concurrent executions of the program are OK all led me to believe that EVERY was my best alternative.
Does that logic make sense? |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Oct 13, 2005 7:46 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
I was suggesting that the "traffic cop" launches independent versions of the application. In CICS terminology (if I remember correctly), a START, not a LINK. That way the processes run concurrently, not sequentially.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 13, 2005 3:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| We run with trigger EVERY but have the transaction TCLASSED in CICS. Thus we limit the number of transactions allowed to run concurrently and avoid swamping the system.... Enjoy |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Oct 13, 2005 5:22 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
well...of course...but we still have to be careful about long ICE chains.....
_________________
-wayne |
|
| Back to top |
|
|
|
|
