| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Backout Queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| sami.stormrage |
 Posted: Fri Mar 13, 2009 10:32 am Post subject: Just some additional question relevent to this(z/os) |
 |
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
I have an application that gets triggered and under transactional control writes to a DB, but if the DB is busy, the messages are reinstated onto the Queue, starting a vicious cycle even with Trigger First. Eventually causing the application to abend.
Now there are 3 possiblities here
1) Ask the CICS programmer to read the message from the Queue (since its a reply message, or does CICS support reading message from a queue  )
2) Send it to backout Queue and after that is there are method to put it back onto the Q after a delay? if this is possible do I need a job to run and reprocess the message  or is there a sample program that I can use 
( how is a message backedout onto a local Q, looked at by the Qmgr? is it as a new message or is there something I can do with; other than editing Qmgr Trigger Interval which is set at 6000 ms. )
3) Or make the application ignore additional Trigger messages generated.
And how can that be done? 
Regards
Sami
_________________
*forgetting everything  * |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Mar 13, 2009 10:40 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
1) it depends if the CICS application has MQ calls in it (CICS app is MQ-aware); or is the MQ message passed via the MQ-CICS bridge to a CICS application program COMMAREA (CICS app is MQ-unaware).
2) where the message is eventually "backed out" is under you application control. MQBACK puts it back into the same queue with backout count incremented by 1. The next MQGET of the backed out message will have the backout count set up by 1. At this point, your app can decide what to do with the backed-out message (like move it some other queue, or wait 30 seconds and try to prcocess it again, whatever...). The qmgr does nothing to make this happen.
3) Applications do not use trigger messages; rather, it's the trigger monitor application that MQGETs trigger messages.
I'd be focusing on the DB delays.
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
