| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQMD-BACKOUTCOUNT not incrementing for poison message |
« View previous topic :: View next topic » |
| Author |
Message
|
| AnjuKizh |
 Posted: Fri Jul 28, 2017 4:25 am Post subject: MQMD-BACKOUTCOUNT not incrementing for poison message |
 |
|
Newbie
Joined: 28 Jul 2017
Posts: 3
|
Hi All,
I'm reading message from queue in my CICS transaction. I have put a poison message(size greater than buffer size) to the queue. And when the MQGET fails (Reason code: 2080), I want the message to be moved to the back out queue defined. In my application program, I'm checking the MQMD-BACKOUTCOUNT and when it reaches BOTHRESH, I'm putting the message to Back out queue and do a CICS SYNCPOINT call. Until MQMD-BACKOUTCOUNT reaches the Threshold, I'm doing CICS SYNCPOINT ROLLBACK and do the MQGET again.
My issue is MQMD-BACKOUTCOUNT is not incrementing. It is always zero, ever after issuing MQGET call again on same poison message. Hence loops the transaction.
Below given are the MQGMO options I'm using for MQGET call.
MOVE MQMI-NONE TO MQMD-MSGID OF MQM-MESSAGE-DESCRIPTOR.
MOVE MQCI-NONE TO MQMD-CORRELID OF MQM-MESSAGE-DESCRIPTOR.
COMPUTE MQGMO-OPTIONS = MQGMO-CONVERT
+ MQGMO-WAIT
+ MQGMO-SYNCPOINT
+ MQGMO-FAIL-IF-QUIESCING.
Backout queue definition:
Queue name . . . . . . . . : XXXXX.XXXXX.XXXX.LOCAL
Disposition . . . . . . . . : QMGR XXXX
Backout Reporting
Backout threshold . . . : 3 0 - 999999999
Harden backout counter . : Y Y=Yes, N=No
Backout requeue name . . : XXXXX.XXXXX.XXXX.BO
Retention interval . . . . : 999999999 0 - 999999999 hours
Monitoring . . . . . . . . : Q Q=Qmgr, L=Low, M=Medium, H=High, O=Off
Accounting . . . . . . . . : Q E=Enabled, D=Disabled, Q=Qmgr
Creation time . . . . . . . : 2017-05-22 17.58.21
Last alteration time . . . : 2017-07-17 12.12.38
Can you please advise on what needs to be done.
Thanks in advance!
Anju. |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Jul 28, 2017 8:18 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Consider this: If the message size is bigger than the buffer size, and you have not specified ACCEPT_TRUNCATED_MESSAGE, will the message actually have been logically removed from the queue and subsequently rolled back, or not removed at all?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 28, 2017 8:24 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9486
Location: US: west coast, almost. Otherwise, enroute.
|
Or, restated:
Your MQGET call failed - it did not deliver a message to your message buffer. As a result, you cannot roll it back, and you cannot move it to the backout-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 |
|
|
| exerk |
| Posted: Fri Jul 28, 2017 8:40 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
Or, restated:
Your MQGET call failed - it did not deliver a message to your message buffer. As a result, you cannot roll it back, and you cannot move it to the backout-queue. |
Aw..., you gave the 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 28, 2017 8:43 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9486
Location: US: west coast, almost. Otherwise, enroute.
|
| exerk wrote: |
| bruce2359 wrote: |
Or, restated:
Your MQGET call failed - it did not deliver a message to your message buffer. As a result, you cannot roll it back, and you cannot move it to the backout-queue. |
Aw..., you gave the |
I was overwhelmed with sympathy at that moment. It won't happen again. 
_________________
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 |
|
|
| AnjuKizh |
| Posted: Fri Jul 28, 2017 8:48 am Post subject: |
|
|
Newbie
Joined: 28 Jul 2017
Posts: 3
|
Thank you for your response. But here in my case, even if reason code is 2080(MQRC_TRUNCATED_MSG_FAILED), I'm getting the truncated message in message buffer and I'm able to put it to Back out queue.
So did you mean like, only if the MQGET is successful(MQCC_OK), we will be able to rollback?
Thanks!
Anju |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jul 28, 2017 8:53 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| AnjuKizh wrote: |
| ...in my case, even if reason code is 2080(MQRC_TRUNCATED_MSG_FAILED), I'm getting the truncated message in message buffer and I'm able to put it to Back out queue... |
From the Knowledge Centre:
| Quote: |
| On an MQGET call, the message length was too large to fit into the supplied buffer. The MQGMO_ACCEPT_TRUNCATED_MSG option was not specified, so the message has not been removed from the queue. |
So you must be accepting the message in truncated form.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| AnjuKizh |
| Posted: Fri Jul 28, 2017 9:02 am Post subject: |
|
|
Newbie
Joined: 28 Jul 2017
Posts: 3
|
| exerk wrote: |
| AnjuKizh wrote: |
| ...in my case, even if reason code is 2080(MQRC_TRUNCATED_MSG_FAILED), I'm getting the truncated message in message buffer and I'm able to put it to Back out queue... |
From the Knowledge Centre:
| Quote: |
| On an MQGET call, the message length was too large to fit into the supplied buffer. The MQGMO_ACCEPT_TRUNCATED_MSG option was not specified, so the message has not been removed from the queue. |
So you must be accepting the message in truncated form. |
Okay. So do we have any option to remove a bad message from the queue, through application program when MQGET fails for other reasons than message size? In this case, I understand I can include MQGMO_ACCEPT_TRUNCATED_MSG option and make it to be removed.
Thanks,
Anju. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jul 28, 2017 9:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can set the buffer to be the max size = 1024768.
The memory used will only be the size of the actual message data.
You can then do whatever you need to figure out that the message is too big, and back it out.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 28, 2017 9:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9486
Location: US: west coast, almost. Otherwise, enroute.
|
Developers should look at MQCC in addition to MQRC to determine if a call succeeded or not.
_________________
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
|
|
|
|
