| Author |
Message
|
| murdeep |
 Posted: Tue Jun 02, 2009 7:37 am Post subject: runmqdlq converts payload when forwarding |
 |
|
Master
Joined: 03 Nov 2004
Posts: 211
|
Hi, running:
Name: WebSphere MQ
Version: 7.0.0.1
CMVC level: p700-001-081219
BuildType: IKAP - (Production)
We have the dlq handler setup to move messages off of the SDLQ via an ACTION(FWD) to staging queues for subsequent processing. What we have noticed is that when a message is forwarded the payload that follows the MQDLH is converted. This causes us issues when we replay the message off of the staging queue since the end point application expects the data in the original senders encoding and ccsid.
Is there anyway to stop the product shipped runmqdlq from doing this conversion so that when we replay it it is is the original encoding and ccsid? |
|
| Back to top |
|
 |
| sumit |
| Posted: Tue Jun 02, 2009 8:21 am Post subject: Re: runmqdlq converts payload when forwarding |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| murdeep wrote: |
| We have the dlq handler setup to move messages off of the SDLQ via an ACTION(FWD) to staging queues for subsequent processing. |
I know there could be ample reasons, but why are these messages going to DLQ as it's very clear from your post that you have a well defined destinationq for these messages? Is it because of q full or something else?
| murdeep wrote: |
| What we have noticed is that when a message is forwarded the payload that follows the MQDLH is converted. This causes us issues when we replay the message off of the staging queue since the end point application expects the data in the original senders encoding and ccsid. |
Are you sure that messages sitting in DLQ were fine and the problem occured when they were moved to different q?
Can you tell what's the exact changes it's doing in the message? CCSID is same accross the qmgr irrespective of qs.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| murdeep |
| Posted: Tue Jun 02, 2009 10:02 am Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
Messages on the SDLQ because the WMB flow threw an exception.
Message sitting on the SDLQ have MQDLH.Encoding 785 CCSID 37. Verified this by stopping dlq handler on SDLQ. When messages moved to broker exception queue the MQDLH.Encoding is 546 CCSID 437.
Broker flow expects message in EBCDIC, please no comments on this it is what it is. Broker flow now updated to check encoding but I think that is wrong. Personally I think runmqdlq shuld leave encoding abd ccsid alone and simply move the message unchanged. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jun 02, 2009 1:45 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| murdeep wrote: |
Messages on the SDLQ because the WMB flow threw an exception.
Message sitting on the SDLQ have MQDLH.Encoding 785 CCSID 37. Verified this by stopping dlq handler on SDLQ. When messages moved to broker exception queue the MQDLH.Encoding is 546 CCSID 437.
Broker flow expects message in EBCDIC, please no comments on this it is what it is. Broker flow now updated to check encoding but I think that is wrong. Personally I think runmqdlq shuld leave encoding abd ccsid alone and simply move the message unchanged. |
Firstly, I suggest you look at the source code for the supplied dead-letter queue handler and see what it does.
Secondly, dead-letter queues are there as undelivered message queues, not as some dump because an application spits its dummy (don't get me started about java...).
Thirdly, why not have the Broker put the messages directly to the exception queue? (I'm not a Broker developer, so this seems a good question from my point of view).
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Jun 02, 2009 2:22 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you define a Backout Requeue Queue and Backout Requeue Depth on the queue being read by MQInput, then the message will not get dumped to DLQ, but to the Backout Requeue Queue instead.
Without *any* change in code. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jun 02, 2009 3:10 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mqjeff wrote: |
If you define a Backout Requeue Queue and Backout Requeue Depth on the queue being read by MQInput, then the message will not get dumped to DLQ, but to the Backout Requeue Queue instead.
Without *any* change in code. |
Is that what I said, but in a roundabout sort of way?  or 
_________________
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: Tue Jun 02, 2009 3:36 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| payload that follows the MQDLH is converted |
In what way converted? From ASCII to HEX? From English to Spanish?
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Jun 02, 2009 8:07 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| exerk wrote: |
| mqjeff wrote: |
If you define a Backout Requeue Queue and Backout Requeue Depth on the queue being read by MQInput, then the message will not get dumped to DLQ, but to the Backout Requeue Queue instead.
Without *any* change in code. |
Is that what I said, but in a roundabout sort of way? or |
 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jun 02, 2009 8:18 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
| Backout Requeue Depth |
Did they change the Backout Threshold to Backout Requeue Depth in V7? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| AkankshA |
| Posted: Tue Jun 02, 2009 8:22 pm Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
I can see them as Backout Requeue Queue and Backout Threshold in V7 Explorer 
_________________
Cheers |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 03, 2009 1:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| mqjeff wrote: |
| Backout Requeue Depth |
Did they change the Backout Threshold to Backout Requeue Depth in V7? |
 |
|
| Back to top |
|
|
| aditya.aggarwal |
| Posted: Wed Jun 03, 2009 2:18 am Post subject: |
|
|
Master
Joined: 13 Jan 2009
Posts: 252
|
Murdeep Wrote:
| Quote: |
| Message sitting on the SDLQ have MQDLH.Encoding 785 CCSID 37. Verified this by stopping dlq handler on SDLQ. When messages moved to broker exception queue the MQDLH.Encoding is 546 CCSID 437[ |
Does the CCSID 37 is the CCSID value of the Sender queue manager or Broker queue manager? I think CCSID of your RCVR queue manager is 437?
Murdeep Wrote:
| Quote: |
| This causes us issues when we replay the message off of the staging queue since the end point application expects the data in the original senders encoding and ccsid. |
Are you using hard coded value for CCSID and encoding in the endpoint application code? If yes Why you need this?
Sumeet Wrote:
| Quote: |
| CCSID is same accross the qmgr irrespective of qs |
CCSID is not same across queue managers. When message will arrive in queue at Target System then it always contains the CCSID of the Last SDR queue manager in MQMD. Ofcourse This is true when CONVERT is Off on SDR channel.
Cheers,
Aditya |
|
| Back to top |
|
|
| sumit |
| Posted: Wed Jun 03, 2009 3:08 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| aditya.aggarwal wrote: |
| Sumeet Wrote: |
Wrong spelling...  (atleast not with names)
| aditya.aggarwal wrote: |
Sumeet Wrote:
| Quote: |
| CCSID is same accross the qmgr irrespective of qs |
CCSID is not same across queue managers. |
If you see the term in bold it says, 'the qmgr'. So, I am talking about 1 queue manager here but not queue managers. The point I'd like to put forward was, CCSID doesn't change with every q in a qmgr. If, there is a change in it's value when a msg is moved from one q to another by an app, then it looks to be a fault of app.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| murdeep |
| Posted: Wed Jun 03, 2009 6:31 am Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
Ok, some comments.
| Quote: |
| In what way converted? From ASCII to HEX? From English to Spanish? |
You're j/k right?
| Quote: |
If you define a Backout Requeue Queue and Backout Requeue Depth on the queue being read by MQInput, then the message will not get dumped to DLQ, but to the Backout Requeue Queue instead.
|
True, but I have 100's of flows and I'd prefer to manage one SDLQ then 100's of backout queues. If I use a single backout queue then I must be able to parse the messages that end up there to know where to replay them to which is not a good design since I'll need to imbed the parsing knowledge of 100's of message formats.
Also, runmqdlq works well in replaying messages back to the flow input when the root cause of the broker exception has been determined and resolved.
| Quote: |
| Does the CCSID 37 is the CCSID value of the Sender queue manager or Broker queue manager? I think CCSID of your RCVR queue manager is 437? |
Sending app is 785/37 (z/OS), broker is 546/437 (W2K). Like I said, as the message sits on the SDLQ the MQMD.Encoding/CCSIS that describes the DLQ message is 546/437. The MQDLH.Encoding/CCSID is 785/37. Which is correct. I would expect then that when the message is forwarded by runmqdlq that the MQMD.Encoding/CCSID would be 785/37 since this is the encoding/CCSID of the payload. But it gets converted by runmqdlq to 546/437. Note that the message payload format is MQSTR so it does indeed get converted, however the msg flow expects the message in z/OS encoding/CCSID which is the problem.
| Quote: |
| If, there is a change in it's value when a msg is moved from one q to another by an app, then it looks to be a fault of app. |
Correct, I suspect runmqdlq is doing a get with convert from the SDLQ which I think is something that should be controlled via the rules table. That is my question is this possible? Sometimes IBM doesn't doc all options I was wondering if this is something that I could control via some undoc'd option. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 03, 2009 6:51 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| murdeep wrote: |
| ...Correct, I suspect runmqdlq is doing a get with convert from the SDLQ which I think is something that should be controlled via the rules table. That is my question is this possible? Sometimes IBM doesn't doc all options I was wondering if this is something that I could control via some undoc'd option. |
| exerk wrote: |
| Firstly, I suggest you look at the source code for the supplied dead-letter queue handler and see what it does... |
_________________
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 |
|
|
|
|
