| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| [SOLVED]Messages to EXEXMLINPUTQ |
View previous topic :: View next topic |
| Author |
Message
|
| CHF |
 Posted: Mon Apr 19, 2004 1:15 pm Post subject: [SOLVED]Messages to EXEXMLINPUTQ |
 |
|
Master
Joined: 16 Dec 2003
Posts: 297
|
Hi,
When we put messages to EXEXMLINPUTQ, Is there any relationship or link between RTMessageRetryLimit and Backout count?
Thanks
CHF 
Last edited by CHF on Mon Apr 19, 2004 1:45 pm; edited 1 time in total |
|
| Back to top |
|
 |
| vennela |
| Posted: Mon Apr 19, 2004 1:22 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
This is from the manual:
| Quote: |
This is a count of the number of times the message has been previously returned
by the MQGET call as part of a unit of work, and subsequently backed out. It is
provided as an aid to the application in detecting processing errors that are based
on message content. The count excludes MQGET calls that specified any of the
MQGMO_BROWSE_* options.
The accuracy of this count is affected by the HardenGetBackout queue attribute; see
“Chapter 39. Attributes for queues” on page 433.
On OS/390, a value of 255 means that the message has been backed out 255 or
more times; the value returned is never greater than 255.
On VSE/ESA, this is a reserved field.
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. |
I have seen that the XML message being retired by workflow for 5 times before discarding it. But what perplexes me is why do you want to specify a wrong queue name and bring the exec server down. |
|
| Back to top |
|
|
| CHF |
| Posted: Mon Apr 19, 2004 1:45 pm Post subject: |
|
|
Master
Joined: 16 Dec 2003
Posts: 297
|
Vennela,
Thanks for the reply.
| Quote: |
| why do you want to specify a wrong queue name and bring the exec server down. |
I am specifying a bad Reply2Q and purposefully bringing down the EXE server, because I would like to know how WF behaves in such scenarios. We are doing this because once after moving to production, we dont want to face severe problems with such unknown scenarios that can bring Execution Server down.
Once again thanks for your time
CHF  |
|
| 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
|
|
|
|
