| Author |
Message
|
| newbieone |
 Posted: Wed Sep 20, 2006 9:28 am Post subject: MQMD-BACKOUTCOUNT |
 |
|
Newbie
Joined: 20 Sep 2006
Posts: 4
|
I would like to evaluate the feasibility of verifiying the MQMD-BACKOUTCOUNT to stop triggering of a queue if needed. The problem is the message becomes useless via the batch process once incrementals are done.
Can anyone comment on some best practices to utilizing this feature  |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Sep 20, 2006 1:38 pm Post subject: |
|
|
Guest
|
From the MQ Application Programming Reference manual:
BackoutCount (MQLONG) This is a count of the number of times that the message has been previously returned by the MQGET call as part of a unit of work, and subsequently backed out.
It helps the application to detect processing errors that are based on message content.
The count excludes MQGET calls that specify any of the MQGMO_BROWSE_* options.
The accuracy of this count is affected by the HardenGetBackout queue attribute; see Chapter 42, “Attributes for queues,” on page 437.
On z/OS, a value of 255 means that the message has been backed out 255 or more times; the value returned is never greater than 255. This is an output field for the MQGET call. It is ignored for the MQPUT and MQPUT1 calls. The initial value of this field is 0.
--------------------------------------------------------------
What this means is that an MQ Backout will return the message to the queue and increment the backout count in the MD. Application program that next gets the 'poisen' message will need to look at this field to see if the message has been previously backed out; and skip it, or process it differently, or ...
To your specific question: the application could backout the message, then set trigger attribute for the queue to NOTRIGGER. Of course, no more triggering means that no more instances of the getting application would be launched; and other messages arriving in the queue would not be processed. |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Sep 20, 2006 1:50 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
A best practice is to compare MQMD-BACKOUTCOUNT against BOTHRESH of the queue. If its greater, then place the message onto BOQNAME specified on the queue.
If course, your admin needs to ensure these values get set on the queue. I've recommended a fallback of using the value 3 if BOTHRESH=0 and the system dlq if BOQNAME isn't specified.
_________________
-wayne |
|
| Back to top |
|
|
| newbieone |
| Posted: Thu Sep 21, 2006 4:34 am Post subject: |
|
|
Newbie
Joined: 20 Sep 2006
Posts: 4
|
Thanks for the replies. Helps my brain think
The problem I have with checking backout count of 3 (with no BOQNAME....) is the following
Program executes = oc7
Message remains in queue and retriggers mq process.
By the time the backount has reached =N the process has been triggered 'x' number of times. (Trick is the process is attached to a mainframe scheduling application which is pulling in dependant schedules based upon the triggering of the mq process)
OC7 is hard abend non program detected. Trigger can be turned off through following JCL step of return code based but was hoping for a cleaner option without major program redesign.  |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Sep 21, 2006 5:26 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Sorry...I don't get it. First, I assume you mean 0c7 (Data Exception) ,, which I presume you are getting while processing the message you read from the queue ....
Why can't your FIRST check backoutcount BEFORE doing any processing? The 0c7 abend will cuase backoutcount to increment...
_________________
-wayne |
|
| Back to top |
|
|
| newbieone |
| Posted: Thu Sep 21, 2006 5:46 am Post subject: |
|
|
Newbie
Joined: 20 Sep 2006
Posts: 4
|
Yes your correct - dataexecption on the message and this batch mq
Situation is ----
Process is triggered
mqget checks backout count = 0 good to proceed than OC7
Backout count increments to 1
Process is triggered again -
Backout count = 1 can stop trigger here if > 0.
Problem is two processes have been triggered pulling in identical batch schedules to execute.
Only want one schedule. Need trigger off after first failure. Not sure if it is possible with checking backoutcount in this fashion.  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Sep 21, 2006 6:06 am Post subject: |
|
|
Guest
|
Now you have two application program issues, not one. Acutally, you have one application architecture issue: what to do with bad messages (backed out messages); and two: the s0c7 (bad decimal data).
The first issue is the backed out message, the backout count, the backout requeue queuename. As discussed in these posts (and at length in the MQ Application Programming Guide, the application needs to anticipate 'what if this message is defective/meaningless (like a timecard message arrives in an inventory queue).'
The second is the s0c7: bad decimal data. Every programming language has a facility for testing data fields; so the programmer failed to check the field before processing the data.
Both issues end up as application programming.
As a side-note: s0c7 = lazy programmer. |
|
| Back to top |
|
|
| newbieone |
| Posted: Thu Sep 21, 2006 6:29 am Post subject: |
|
|
Newbie
Joined: 20 Sep 2006
Posts: 4
|
Agreed. OC7 is easily fixed. The other is certainly a design feature of the process.
For future process designs and protentially maintanence of exsiting, I sure the backoutcount will become our standard.
Thanks for your insight. |
|
| Back to top |
|
|
| giuly020277 |
| Posted: Thu Mar 26, 2009 8:00 am Post subject: |
|
|
Centurion
Joined: 07 Aug 2007
Posts: 146
Location: Florence,Italy
|
| wschutz wrote: |
A best practice is to compare MQMD-BACKOUTCOUNT against BOTHRESH of the queue. If its greater, then place the message onto BOQNAME specified on the queue.
If course, your admin needs to ensure these values get set on the queue. I've recommended a fallback of using the value 3 if BOTHRESH=0 and the system dlq if BOQNAME isn't specified. |
Sorry...just a question... Programmer have to compare MQMD-BACKOUTCOUNT with BOTHRESH like :
IF MQMD-BACKOUTCOUNT > BOTHRESH
THEN ..... and so on?
how programmer have to specify my local's queue parameters (bothresh and boqname)? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 26, 2009 8:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| giuly020277 wrote: |
IF MQMD-BACKOUTCOUNT > BOTHRESH
THEN ..... and so on?
how programmer have to specify my local's queue parameters (bothresh and boqname)? |
1) Just like I said here
2) Please don't reopen 2 year old posts! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
