| Author |
Message
|
| dipanjan26 |
 Posted: Thu May 12, 2011 1:51 am Post subject: Need info on BACKOUTCOUNT |
 |
|
Newbie
Joined: 13 Apr 2011
Posts: 7
|
| what is the syntax of retreving the BACKOUTCOUNT of MQ |
|
| Back to top |
|
 |
| shashikanth_in |
| Posted: Thu May 12, 2011 2:55 am Post subject: |
|
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
| Have you looked at documentation of MQINQ API? BackoutThreshold attribute of queue. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu May 12, 2011 3:17 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
backoutthreshold of a qlocal definition is one thing, backoutcount of a message another thing. although they can be used together to perform actions on a message that was already backed out and is now reprocessed.
for Backoutthreshhould shashikanth_in already gave the answer.
for the backoutcount - this one is part of the MD, so you have to get or browse the message to know its value.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| dipanjan26 |
| Posted: Thu May 12, 2011 4:18 am Post subject: |
|
|
Newbie
Joined: 13 Apr 2011
Posts: 7
|
| I will elaborate my requirement. I have a CICS application that reads records from a local queue and updates files. Now we have set the unit of work to 100 records. I am concerned that when an abend occurs within the unit of work say at processing the 50th record all the 50 record updates will be rolled back on all resources and these records reinstated in the queue. Now how will I identify the problematic record and separate it out from the input queue. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu May 12, 2011 4:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Well, one option is indeed to examine the BackoutCount on the MQMD of the message you are processing. If that is non-zero, you know the message has been backed out at least once.
Another option is to simply set the BOTHRESH to a low enough value that messages don't get retried? |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu May 12, 2011 6:12 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
well, yes, all true, but he wants to know which message in his batch was the bad one.
so the answer is (hopefully) the last one in a row of messages with the same backoutcount <> 0 (or something similiar).
the other solution is to commit every message processed. then you know what has a backoutcount has failed. but thats of course less performant.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu May 12, 2011 6:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Presumably the last record written to the file is also the last message that was successfully processed... |
|
| Back to top |
|
|
| dipanjan26 |
| Posted: Fri May 13, 2011 3:20 am Post subject: |
|
|
Newbie
Joined: 13 Apr 2011
Posts: 7
|
This will be applicable if I am doing a add but if its an update,then? Beside adding a record to a KSDS will be based on the key which may not be the last record in the file.
The other thing is bringing down the unit of work to one record and we are testing with that option and has some performance trade off.What is a MARK-SKIP-BACKOUT, can that be an option? |
|
| Back to top |
|
|
|
|
