| Author |
Message
|
| murdeep |
 Posted: Wed Jun 03, 2009 8:00 am Post subject: |
 |
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| Vitor wrote: |
| [To answer your point directly, the sending MCA doing a convert by default would require the sending machine to have all the possible conversion tables in it's OS for each possible target. The assumption is that the receiving OS will know how to translate into it's code page in more cases than the sending one will. Remember how many possible translations there are across all the platforms & languages WMQ supports. |
Has to anyways since the MQMD must be converted in all cases between platforms so your point is moot. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Jun 03, 2009 9:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| murdeep wrote: |
| Has to anyways since the MQMD must be converted in all cases between platforms so your point is moot. |
It's converted by the receiver (where the fields are converted)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| murdeep |
| Posted: Wed Jun 03, 2009 12:15 pm Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| Vitor wrote: |
| murdeep wrote: |
| Has to anyways since the MQMD must be converted in all cases between platforms so your point is moot. |
It's converted by the receiver (where the fields are converted) |
Qmgr can be both sender or receiver so it needs the ccsid conv tables regardless if the sender channel or receiver channel makes good.
Anyways, looking at compiling the product shipped amqsdlq to provide an option to convert. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 03, 2009 1:14 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| murdeep wrote: |
| Anyways, looking at compiling the product shipped amqsdlq to provide an option to convert. |
It's a miracle the rest of us manage with the supplied one so well.
I'm sure you'll find this a simple and effective solution to your situation.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| murdeep |
| Posted: Wed Jun 03, 2009 2:23 pm Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| Vitor wrote: |
| murdeep wrote: |
| Anyways, looking at compiling the product shipped amqsdlq to provide an option to convert. |
It's a miracle the rest of us manage with the supplied one so well.
|
WTF? Do you think there could be any chance that some BS politics may be playing into the fact that I have to go down this road? Many places I've been have used vanilla runmqdlq with no problems. Just so happens this one has some history that requires some unique processing requirements. Save the snide comments please. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 03, 2009 4:04 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
Ok, some comments.
Quote:
In what way converted? From ASCII to HEX? From English to Spanish?
You're j/k right? |
No, I was serious. It seems that you tossed the first sarcasm.
Moving along...
We're trying to understand the symptoms you see to identify the underlying problem.
Was the original message created on a different platform from the platform that hosts the dlq where the message ended up (moved across a network or a client bindings app)? If so, then the consuming application would/should have driven the conversion process in its MQGET (or equivalent).
If the msg arrived form a different platform (different CCSID), and if the creating app loaded the application payload with binaries, but set the MQMD_FORMAT field to string, then the first consumer would drive the conversion.
I've seen this before - in a banking app where field delimiters and other odd characters were interspersed with user data that both the creating and consuming app 'knew' how to encode/decode. Both apps depended on conversion NOT taking place. Tricky app coding led them to the identical symptom, namely: msg ended up in dlq, was converted when FWDed.
If the msg was created on the same platform (CCSID), then no conversion will take place - unless the creating app force-fed a CCSID into the MQMD; thus confusing the dlh into driving conversion.
This is as complicated as it appears.
More details about the creating and consuming app would help.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Wed Jun 03, 2009 5:30 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| murdeep wrote: |
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.
|
"however the msg flow expects the message in z/OS encoding/CCSID"
What if you change the sending app to leave the MQMD_Format field blank? Nothing will be able to convert the message, including the DLQ handler. But you are saying your receiving app expects the message unconverted, even when being handed the message directly by the QM via the regular queue, so this won't be a problem?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 03, 2009 6:11 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
Out of curiosity, what was the ReasonCode in the DLH? Why was the message in the DLQ?
_________________
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 |
|
|
| murdeep |
| Posted: Wed Jun 03, 2009 8:02 pm Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| bruce2359 wrote: |
| Out of curiosity, what was the ReasonCode in the DLH? Why was the message in the DLQ? |
65536 - its a broker exception. In this case a network issue caused a d/b to be unavailable to the flow and the message was backed out and eventually moved to SDLQ where the runmqdlq moved it to a broker exception queue.
Typically these messages are simply replayed when the root cause is resolved. |
|
| Back to top |
|
|
| murdeep |
| Posted: Wed Jun 03, 2009 8:09 pm Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| PeterPotkay wrote: |
| murdeep wrote: |
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.
|
"however the msg flow expects the message in z/OS encoding/CCSID"
What if you change the sending app to leave the MQMD_Format field blank? Nothing will be able to convert the message, including the DLQ handler. But you are saying your receiving app expects the message unconverted, even when being handed the message directly by the QM via the regular queue, so this won't be a problem? |
Unfortunately the broker expects it in EBCDIC but the end point app expects it in ASCII so the message format must be set to MQSTR.
The reason why the broker expects it in EBCDIC is because the flow was written to insert EBCDIC characters to delimit records sent from a z/OS via a file to msg adapter to ensure the end point app can process each record by looking for a LF character. Ideally I'd like to change the flow to do a get with convert and insert an ASCII LF but the flow is not under my authority to change so that isn't going to happen. This is the politics I mentioned before. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 03, 2009 8:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
Remind the politicians in question that MQ and the broker are meant to decouple or loosely couple applications that were before tightly coupled.
Concretely this means that the MF should no longer have to worry about the application reading the message as the message will be transformed by the broker to suit the consumer application's needs....
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| aditya.aggarwal |
| Posted: Wed Jun 03, 2009 10:45 pm Post subject: |
|
|
Master
Joined: 13 Jan 2009
Posts: 252
|
murdeep wrote:
| Quote: |
| 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. |
It is converting to 546/437 because MQGMO_CONVERT is present in runmqdlq code.
murdeep wrote:
| Quote: |
Unfortunately the broker expects it in EBCDIC but the end point app expects it in ASCII so the message format must be set to MQSTR.
The reason why the broker expects it in EBCDIC is because the flow was written to insert EBCDIC characters to delimit records sent from a z/OS via a file to msg adapter to ensure the end point app can process each record by looking for a LF character. Ideally I'd like to change the flow to do a get with convert and insert an ASCII LF but the flow is not under my authority to change so that isn't going to happen. This is the politics I mentioned before. |
Ideally Your flow should use MQGMO_CONVERT while reading the message from the queue as this is the best practise. But according to you it is not possible to change the message flow then use MQGMO_NONE inplace of MQGMO_CONVERT at runmqdlq code. Even if this does not resolve the issue, stop sending the message in to your DLQ to avoid the politics. 
Cheers,
Aditya |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jun 04, 2009 5:19 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| murdeep wrote: |
| PeterPotkay wrote: |
| murdeep wrote: |
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.
|
"however the msg flow expects the message in z/OS encoding/CCSID"
What if you change the sending app to leave the MQMD_Format field blank? Nothing will be able to convert the message, including the DLQ handler. But you are saying your receiving app expects the message unconverted, even when being handed the message directly by the QM via the regular queue, so this won't be a problem? |
Unfortunately the broker expects it in EBCDIC but the end point app expects it in ASCII so the message format must be set to MQSTR.
|
So can the mainframe send the message with MQMD_Format set to none, and when the Broker sends out the message to the end point, the Broker sets the MQMD_Format to "MQSTR ".
Or is the Broker flow coded to copy the incoming MQMD to the outgoing one, so this is a change that you can't make happen?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| vol |
| Posted: Thu Jun 04, 2009 6:12 am Post subject: |
|
|
Acolyte
Joined: 01 Feb 2009
Posts: 69
|
| I think that runmqdlq converts the msg when reading it from the DLQ because the original destination qmgr and queue are held in the DLH header, which may be in a different CCSID to the qmgr's. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 04, 2009 8:44 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
When using the forwarding rule did you set header(no) ? If you kept the DLQ header you will not have the same CCSID as the payload but you will have the right CCSID on the DLH for the information about the next part of the message...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
