| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| 'Over Triggering' Issue under CICS |
« View previous topic :: View next topic » |
| Author |
Message
|
| lenburt |
 Posted: Wed Mar 04, 2009 11:26 am Post subject: 'Over Triggering' Issue under CICS |
 |
|
Novice
Joined: 24 Sep 2004
Posts: 15
|
This seems simple, but i have a case where after being started by a trigger message, opening the input queue, then performing some CICS commands which result in a fatal error (which i handle) i continue to be triggered once my first task ends. There is only a single message on the queue (which i would like to leave there in this case).
When i handle the error, i write to a CICS TDQ, and then return to CICS. Immediately, another task is started so i am in an infinite loop.
The only solution i can think of is to programmaticaly disable triggering but i think that is drastic.
Is there a simple explanation i am missing?
len |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Mar 04, 2009 11:31 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
This is working as designed.
WMQ assumes that if there is a message in a triggered queue AND no consuming application is MQGETting the message, that it is time to trigger the application.
If you or your application decide to leave the message in the queue, you or your application should turn triggering off.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| lenburt |
| Posted: Wed Mar 04, 2009 11:44 am Post subject: |
|
|
Novice
Joined: 24 Sep 2004
Posts: 15
|
| Ok, that was one option we were considering, but it seems like MQ did its job and started the process which made a conscious decision to leave the message on the queue. It seems like overkill for the trigger initiator to assume otherwise but i can live with disabling trigger to let operations deal with the issue. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 04, 2009 11:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It makes more sense to back the message out to the BackoutRetryQueue, and leave triggering alone.
Then new messages will not get stuck behind the bad message.
Only if the fatal error indicates a problem with a resource required to process *all* messages (db2 subsystem down for example) should your app disable triggering to quiesce itself. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 04, 2009 11:55 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| to let operations deal with the issue. |
I'm with Jeff on this one. This is an application issue. The application decided to leave the unprocessed message in the triggered queue. There are other choices.
If the application decides that it (the application) is somehow fatally flawed, it should disable triggering so no other instance of itself is launched.
If the application decides that this particular message is flawed, it should move the message to a special-handling queue - the backout requeue quename attribute of the triggered queue.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| 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
|
|
|
|
