Author |
Message
|
maxis |
Posted: Thu Dec 11, 2003 11:47 am Post subject: ccsid |
|
|
Centurion
Joined: 25 Jun 2002 Posts: 144
|
whats the the best way to handle CCSID .. Is it
1. Convert in the Input node
2. Convert in Compute node ( I think this the better solution )
And is it possible to claim that flow will handle most of the Character if we convert the input message to UTF-8 ?
Is it possible to determine MRM element length at the run time ? -- its just a brain tickling question ... not a real time requirement.
M |
|
Back to top |
|
 |
kimbert |
Posted: Fri Dec 12, 2003 4:22 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
re: the last question...it depends what you mean by 'element'. You can use ESQL to get the length of any string stored in the message tree. If you're interested in the original length of the 'element' when it was in the bitstream, you need to make sure that you're not trimming away any characters that you were interested in - those settings are on the physical format. |
|
Back to top |
|
 |
EddieA |
Posted: Fri Dec 12, 2003 10:11 am Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
For the CCSID questions.
Unless the format is MQSTR, then to convert it in the Input node you will have to write a Conversion exit. Standard MQ.
When the message is parsed, in a Compute (or other node), WMQI will convert the message internally to Unicode. When WMQI (or you with a BITSTREAM) create the output message, WMQI will convert the message to the outgoing CCSID.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
maxis |
Posted: Fri Dec 12, 2003 12:31 pm Post subject: |
|
|
Centurion
Joined: 25 Jun 2002 Posts: 144
|
hi ..
some how I've trouble in accepting the fact that WMQI will convert the message internally to Unicode .
Because .. message flow is throwing exception .. when it gets the following message Àn Élephanto
steps involved
1. Input ( no conversion read it as blob )
2. a compute node .. { convert it to CCSID 819 ie ISO 8859 }
b just pass it { here its throwing exception }
After every compute node ...have trace node. Message is getting delivering on the 2.a path ... where as in the second case .. its not even going to Trace node
Is there is any proven and certified steps
thanks
M |
|
Back to top |
|
 |
warrenpage |
Posted: Fri Dec 12, 2003 2:36 pm Post subject: |
|
|
Acolyte
Joined: 19 Feb 2002 Posts: 56 Location: Australia
|
yeah i dont think it converts to unicode I think it converts to the local CCSID (typically 819/1208 or 437 on AIX/Windows boxes)
If you send in an invalid unicode char it will not convert that char to a valid unicode char when you do the convert and bitstream.. |
|
Back to top |
|
 |
EddieA |
Posted: Fri Dec 12, 2003 3:40 pm Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
First. Are all the characters on the input message 'legal' for the CCSID in the MQMD.
Next.
Quote: |
{ convert it to CCSID 819 ie ISO 8859 } |
Are YOU trying to convert the mesage using ESQL. Under 'normal' circumstances, you don't have to do this. You just referernce a field, and WMQI, under the covers, does the conversion from the incoming CCSID to (as I am led to believe) Unicode.
If WMQI is throwing an exception, what is in the log/Event Viewer.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
jfluitsm |
Posted: Fri Dec 12, 2003 3:47 pm Post subject: |
|
|
Disciple
Joined: 24 Feb 2002 Posts: 160 Location: The Netherlands
|
When you don't select the Convert option in the MQInput-node the broker will convert all 'strings' from the CCSID of the message to Unicode (UCS-2). What the broker sees as string is dependend on the Message Domain (blob is not converted, MRM is converted acording to the message defintion etc.).
The CCSID only plays a role during parsing from bitstream to message-tree and during writing from message-tree to bitstream, so changing the CCSID without reparsing is of no use.
My advice:
- The CCSID on the input message should be the correct value for the contents of the message (for instance 1208 for XML from an XML-writer or 5348 for Windows SBCS programs).
- Define the length of all text fields in characters, not bytes.
- Write the output in UTF-8 (1208), this prevent the broker from conversion errors.
- Let the receiving application do a MQ convert.
Ofcourse this advice is not always possible. _________________ Jan Fluitsma
IBM Certified Solution Designer WebSphere MQ V6
IBM Certified Solution Developer WebSphere Message Broker V6 |
|
Back to top |
|
 |
|