| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| need sample ESQL to convert ExceptionList tree into Char str |
« View previous topic :: View next topic » |
| Author |
Message
|
| ydsk |
 Posted: Wed Aug 16, 2006 8:48 am Post subject: |
 |
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
Jeff,
Your last suggestion didn't work.
Since we can't modify Root structure in the database node I replaced the database node with a Compute node and inserted the same ESQL ( of course replacing Root with Input/Output Root, and ExceptionList with Input/Output Exceptionist as needed).
Then instead of copying ExceptionList into Environment ( as Environment too doesn't have a parser ) I copied it into OutputRoot as the last child as given below and it finally worked:
Create LASTCHILD of OutputRoot DOMAIN('XML') Name 'XML';
SET OutputRoot.XML.ExceptionList = InputExceptionList;
DECLARE EXCEPTIONBLOB BLOB ASBITSTREAM(OutputRoot.XML.ExceptionList);
DECLARE FULLEXCEPTION CHAR CAST(EXCEPTIONBLOB AS CHAR CCSID InputRoot.Properties.CodedCharSetId);
Thank you all for your inputs. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Aug 16, 2006 9:54 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you cast a BLOB as a CHAR and you do not specify a CCSID, then when you ask for the string representation of that CHAR, you will always get the X'....' notation.
If you cast a BLOB as a CHAR, and you do specify a CCSID, then when you ask for the string representation of that CHAR, you will get the string data instead of the X'....' notation.
I think if this is broken, and you can actually demonstrate it, then you can raise a PMR.
I do not think you actually demonstrated that this was broken.
Change your working code to eliminate the CCSID on your CAST, and see what happens.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| ydsk |
| Posted: Wed Aug 16, 2006 10:58 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
I removed the CCSID from the last CAST statement in my code and the result is X'3c5265636f7665 ..... f6e3e'
Jeff, can you please explain why this is happening ? I mean, why not providing a CCSID leaves the data as is, and doesn't convert it into CHAR ?
Does it happen the other way too ? I mean, when we cast a CHAR into BLOB do we need to provide a CCSID ? what will happen in that case if we don't provide a CCSID. I am not much interested in the result but just curious to know why this is happening.
Thanks. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 16, 2006 11:15 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The X'...' notation is the String representation of Binary data. It's like what Java gives you when you do a "toString" on an object (unless that class implements something useful for toString).
You get this when you CAST as CHAR without a CCSID because the CCSID tells the broker what Characters each BYTE (or double-byte!) represents. Otherwise, broker doesn't know that X'65' represents an 'a', a 'A', a '*', half of a yen-sign or etc, and so it can only show you the byte values (in hex so they are readable).
That's what the Coded Character Set ID does - it identifies which table makes byte values to characters. Remember, down deep everything is just a string of 1's and 0's. So how do you know what "11010111" means?
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
