| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| EBCIDIC to ASCII conversion for the control character '.' |
« View previous topic :: View next topic » |
| Author |
Message
|
| mqxplorer |
 Posted: Thu May 19, 2011 1:38 pm Post subject: EBCIDIC to ASCII conversion for the control character '.' |
 |
|
Master
Joined: 22 Jun 2009
Posts: 206
|
I am sorry to ask this redundant EBCIDIC to ASCII conversion question, however, I have done some level of research..could not find enough info..still researching..meanwhile, I wanted to post this question in forum so that some experts advice from this forum help me solving my issue without wasting too much time, as this issue happened in production.
This is an event driven service related issue. Student Updates are published from a mainframe system. The messages are delimited filesAfter coming across the channel, broker flow picks up the message and transforms to xml messages and puts into a consumer queue.
I am not pasting the whole input and output messages..just pasting the trouble making elemnts in the input and output messages...
The trouble making data elemnt from mainframe is below:
| Code: |
ebcdic hex: d7 c5 66 23 62 ab c1 6b
P E Ã WUS Â ¿ A ,
|
WUS - Word under Score - the non printable character
Once the message arrives to the queue on broker queue manager across the channel, message flow picks up the message and tarnsforms it to XML message. In the mapping node which does the conversion, I specified the CCSID as 1208 and resulting string for the trouble making element is:
| Code: |
UTF-8 hex: 50 45 c3 83 c2 83 c3 82 c2 bf 41 2c
P E à nbh  nbh à bkh  ¿ A ,
|
nbh - No Break Here
bkh - Break Here
When I am opening the xml message, the xmlspy does not complain anything about the No Break Here, however, the consuming application (in this case Websphere Data Stage job) complains as below:
| Quote: |
| LPX-00217: invalid character 131 (U+0083 |
I am trying to replace the No Break Here (nbh) with some printable character using a CCSID that does for me in my mapping node so that the consuming app does not complain about the No Break Here (nbh).. ..but no luck so far...
Please advise me to solve this strange issue...
Thanks
mqxplorer |
|
| Back to top |
|
 |
| rekarm01 |
| Posted: Thu May 19, 2011 8:57 pm Post subject: Re: EBCDIC to ASCII conversion for the control character '.' |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| mqxplorer wrote: |
| The messages are delimited files |
What is the format of the messages? Is it all character data, or is it a mix of character and numeric data? Character conversion only works for character data.
| mqxplorer wrote: |
The trouble making data element from mainframe is below:
| Code: |
ebcdic hex: d7 c5 66 23 62 ab c1 6b
P E Ã WUS Â ¿ A , |
|
X'66 23 62 ab' does not look like EBCDIC character data. It looks like it already contains invalid xml characters. Conversion won't fix that.
What is the string supposed to look like? And which EBCDIC ccsid is the mainframe using to write the message?
| mqxplorer wrote: |
| I am trying to replace the No Break Here (nbh) with some printable character using a CCSID that does for me in my mapping node so that the consuming app does not complain about the No Break Here (nbh).. ..but no luck so far... |
Look at the input ccsid, and the input message on the mainframe. If that's wrong, then tweaking the output ccsid in the broker won't help. |
|
| Back to top |
|
|
| mqxplorer |
| Posted: Fri May 20, 2011 5:16 am Post subject: |
|
|
Master
Joined: 22 Jun 2009
Posts: 206
|
| Quote: |
| What is the format of the messages? Is it all character data, or is it a mix of character and numeric data? |
It is character data.
| Quote: |
| X'66 23 62 ab' does not look like EBCDIC character data. |
The mainframe CCSID is 500 and as I pasted below:
| Code: |
ebcdic hex: d7 c5 66 23 62 ab c1 6b
P E Ã WUS Â ¿ A , |
X'66, 23, 62, ab' are in the EBCIDIC code page 500 - This links provides the info.
http://en.wikipedia.org/wiki/EBCDIC_500
| Quote: |
| What is the string supposed to look like? |
I am not sure about this. I will have to ask the application team. XMLSPY does not comaplin about the xml..but the application complains about the unicode character U+0083 which is 'No Break Here'. Is it something to do with the MQGet call issued by the application?
Thanks
mqxplorer |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sun May 22, 2011 5:24 am Post subject: Re: EBCDIC to ASCII conversion for the control character '.' |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
Whenever an application writes a character string using a given ccsid, any application that reads it back must always use the same ccsid, in order to preserve the semantics of the original string.
The point is that it looks like something already garbled the resulting string 'PE�¿A,' ... at least twice. For example:
| Code: |
logical characters physical bytes
'PEÿA,'
---> app A writes (ccsid=1208) --->
X'50 45 c3 bf 41 2c'
<--- app B MISREADS (ccsid=819) <---
'PEÿA,'
---> app B writes (ccsid=1208) --->
X'50 45 c3 83 c2 bf 41 2c'
<--- app C MISREADS (ccsid=819) <---
'PE�¿A,'
---> app C writes (ccsid=500) --->
X'd7 c5 66 23 62 ab c1 6b'
<--- app D reads (ccsid=500) <---
'PE�¿A,'
---> app D writes (ccsid=1208) --->
X'50 45 c3 83 c2 83 c3 82 c2 bf 41 2c'
<--- app E MISREADS (ccsid=819) <---
'PE���¿A,' |
Conversion should never alter the logical string (on the left). If any errors occur before the message flow, then that's the best place to fix them.
| mqxplorer wrote: |
| XMLSPY does not complain about the xml ... but the application complains about the unicode character U+0083 which is 'No Break Here'. |
For XML 1.0, U+0083 is discouraged, but allowed.
For XML 1.1, U+0083 is restricted, but allowed, only as a character reference (such as 'ƒ').
Oracle should probably not reject it as an invalid character, but that's a separate problem. |
|
| 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
|
|
|
|
