| Author |
Message
|
| christopher j |
 Posted: Wed Mar 02, 2011 12:57 pm Post subject: converiting special characters using ESQL and CCSID |
 |
|
Novice
Joined: 01 Jan 2010
Posts: 20
|
Hi,
¼,¾ are some of the special characters comes as input to my application.I need to convert them as a ,b .CCSID for QM is 437.I tried CCSID 437 and 1208.But ESQL is not recognising the special characters.Before the conversion i put a compute node and i set
SET OutputRoot.Properties.CodedCharSetId=1208;
but i got output as,
â•
I got some additional special characters.
which CCSID i have to use to convert ¼,¾ to a,b? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Mar 02, 2011 12:59 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You first have to make sure that you know the actual and correct CCSID that describes the characters properly, and that the message that contains them is correctly and fully in that CCSID and labelled as being in that correct CCSID.
Then you have to figure out if there is any CCSID that has the replacement characters you want in the right places, such that a swap will create the correct thing.
or you could just use an ESQL function that REPLACEs or TRANSLATEs characters. |
|
| Back to top |
|
|
| christopher j |
| Posted: Wed Mar 02, 2011 1:03 pm Post subject: |
|
|
Novice
Joined: 01 Jan 2010
Posts: 20
|
I used below esql.But it didnt work
SET Formattedvalue = REPLACE(Formattedvalue,'¼','a'); |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 02, 2011 3:39 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
What did it do instead of 'working'?
Is the ESQL character literal '¼' the same as the character in the Formattedvalue you are dealing with?
How would you find out? |
|
| Back to top |
|
|
| jborella |
| Posted: Thu Mar 03, 2011 1:30 am Post subject: |
|
|
Apprentice
Joined: 04 Jun 2009
Posts: 26
|
| christopher j wrote: |
I used below esql.But it didnt work
SET Formattedvalue = REPLACE(Formattedvalue,'¼','a'); |
Have You tried debugging Your flow?
1. You need to verify, that the data are read and understood as ccsid 437. In that case You should be able to see the characters 1/2 and 1/4 in Your message before applying the line above.
2. You can debug to after Your routine to see if the call worked (which it will with the correct input).
If the above works, data is propably obfuscated further down the road. I've experienced problems with MQ formatting data, if You specify MQMD.Format as mq_str. A lot of other scenarios might apply. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Mar 03, 2011 2:32 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
look at the data BEFORE is gets put into Broker.
Verify that the BINARY values of these characters do actually match up with what the Character Set Tables for 437 show them as.
Remember that outside of A-Z,a-Z & 0-9 characters in the ISO-8859-x family of character sets have a contact admin habbit of moving around or not being there at all.
This is the same for other Character Sets including 437. A 90% match is not good enough as you are finding out.
Once you have verified that the binary values for these characters match correctly then verify what the internal to broker values are.
Then you can do the requisite searching for and replacement of these characters.
mqjeff said this very thing(and I hope I've understood him correctly). I'm trying to steer you in the right general direction of a solution.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Mar 03, 2011 4:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| smdavies99 wrote: |
| mqjeff said this very thing(and I hope I've understood him correctly). |
 |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Mar 03, 2011 5:07 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Verify that the BINARY values of these characters do actually match up with what the Character Set Tables for 437 show them as. |
I agree with mqjeff and smdavies99.
Of course, you can't verify that the BINARY values match the CCSID unless you know what characters the message contains. So you may need to go to the upstream application and inspect the message that it is putting onto the queue. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Fri Mar 04, 2011 1:23 am Post subject: Re: converiting special characters using ESQL and CCSID |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
"convert" means to change the physical format, without actually changing the value, such as from one datatype to another. But a character should still be the same character, no matter what its physical representation is. "Substitute" or "replace" or "translate" implies changing the actual value.
| christopher j wrote: |
| CCSID for QM is 437. |
CCSID for the QM is not entirely relevant. What is the InputRoot.Properties.CodedCharSetId?
The input ccsid converts the input msg from bytes to characters.
The output ccsid converts the output msg from characters to bytes.
| christopher j wrote: |
but i got output as,
â• |
The display tool also needs to convert the output msg from bytes to characters; if it chooses the wrong ccsid to convert with, the characters won't display properly. That would be a problem with the display tool, not the message. (Though there's no obvious single mis-conversion from '¼' or '¾' to 'â•' - which could indicate multiple conversion issues).
| christopher j wrote: |
| which CCSID i have to use to convert ¼,¾ to a,b? |
That's an unusual requirement, but it has nothing to do with which CCSID the message uses. As mqjeff, smdavies99, and kimbert suggest, first verify that the message is correct. Then figure out where to go from there. |
|
| Back to top |
|
|
|
|
