| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQSTR |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Sun Oct 23, 2011 5:14 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| zpat wrote: |
| However fixing the receiving application is always the best way. |
And, this is IBM's recommended method - let the receiver make good.
_________________
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 |
|
 |
| rekarm01 |
| Posted: Sun Oct 23, 2011 7:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
Generally, the recommended practice is to establish feasible requirements between the sender(s) and receiver(s). If a sending application doesn't meet the requirements, then modify the sending application. If the receiving application doesn't meet the requirements, then modify the receiving application. If the requirements aren't feasible, then modify the requirements.
| zpat wrote: |
| There are many "solutions", but modifying the sending application is not recommended. |
Based on the (admittedly unclear) current problem description, it seemed that the sending application was still under development, so the developer was already modifying it, while the receiving application was a third party tool, which might require the cooperation of an external vendor to modify. MQGET with MQGMO_CONVERT is an excellent practice, but it's sometimes difficult to impose new requirements on an external vendor, in a timely manner. The sending application needs to convert the data anyway, to generate an output message; is there a requirement that the sender must convert the data to Unicode, rather than EBCDIC?
| zpat wrote: |
| You could set up another sender channel to the mainframe and set convert data to YES on this channel. Then by using another xmit queue - route the message over this channel. |
Channel conversion introduces other issues; for example, neither the sending nor receiving application can detect a lost message due to channel conversion errors. This should be the last resort, only when the sending platform supports a specific conversion that the receiving platform does not, and it's not practical to modify either the sending or receiving applications. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Oct 23, 2011 7:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If the sending app is broken, fix it.
If the receiving app is broken, fix it.
If the two apps are both correct, but disagree on what should be sent, then fire one of the architects in charge...  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Oct 23, 2011 10:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| rekarm01 wrote: |
Channel conversion introduces other issues; for example, neither the sending nor receiving application can detect a lost message due to channel conversion errors. |
As has been discussed here often, it is ultimately the responsibility of applications (both sending and receiving) to recognize, and deal with, so-called "lost messages."
| rekarm01 wrote: |
| This should be the last resort, only when the sending platform supports a specific conversion that the receiving platform does not, and it's not practical to modify either the sending or receiving applications. |
From the browse utility, it is not clear in what ccsid the data was created. The MQMD will identify the ccsid.
The incompatibility of ccsids should have been quickly detected and resolved in testing of the application.
There is an entire section of the APR and APG manuals (and InfoCenter equivalents) that discuss data conversion issues.
_________________
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 |
|
|
| rekarm01 |
| Posted: Sun Oct 23, 2011 3:34 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| bruce2359 wrote: |
| it is ultimately the responsibility of applications (both sending and receiving) to recognize, and deal with, so-called "lost messages." |
Then that seems like another reason not to use channel conversion.
| bruce2359 wrote: |
| From the browse utility, it is not clear in what ccsid the data was created. The MQMD will identify the ccsid. |
Based on the given source code, and the garbled data, it is clear that the sending ccsid and data are both UTF-8, but the receiver is expecting some form of EBCDIC.
| bruce2359 wrote: |
| The incompatibility of ccsids should have been quickly detected and resolved in testing of the application. |
If the initial testing is still on-going, then perhaps it's too soon to use the past tense. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Oct 24, 2011 4:49 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| rekarm01 wrote: |
| bruce2359 wrote: |
| it is ultimately the responsibility of applications (both sending and receiving) to recognize, and deal with, so-called "lost messages." |
Then that seems like another reason not to use channel conversion.
|
No. There are a variety of reasons that messages appear to be lost. Failed sender channel-driven conversion is only one of them. CONVERT(YES) works fine.
Applications that are not tested adequately will/may cause conversion to fail, whether the conversion takes place on the sender-end or the receiver-end of a channel.
Please search here for well-behaved applications.
_________________
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 |
|
|
| rekarm01 |
| Posted: Mon Oct 24, 2011 9:35 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| bruce2359 wrote: |
| There are a variety of reasons that messages appear to be lost. Failed sender channel-driven conversion is only one of them. CONVERT(YES) works fine. |
The point was more about where to convert, rather than how to deal with lost messages. There are a variety of reasons why channel conversion is usually not the best option. Failed sender channel-driven conversion is only one of them.
That doesn't mean that channel conversion is never a good option. In some cases, it is the best available option -- just not in this particular case. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
