| Author |
Message
|
| Amod Gole |
 Posted: Sat Aug 07, 2010 7:10 am Post subject: Issue With CCSID 1208 |
 |
|
Newbie
Joined: 09 Jun 2010
Posts: 8
|
Hello All,
I am using CCSID 1208 in my application. In My message defination I have one element 'DRLDBKEY' with Type long and length 8.
In My application I have requirement like I have to convert My data into BLOB and I have to send it over network thats why by using ASBITSTREAM function I am converting my entire message into BLOB
Code :
SET ddlblob=ASBITSTREAM(InputRoot.MRM
ENCODING 273
CCSID InputRoot.Properties.CodedCharSetId
SET 'ISDKCPG002001'
TYPE 'drl6MSG'
FORMAT 'Text1');
Next I am again converting it into Character by using CAST because I have to send it to next node where I am appending some more Data to this data.
Code For Casting:
SET OutputRoot.XMLNSC.NSKRequestMSG.PayLoadFieldData =
CAST(ddlblob AS CHARACTER CCSID InputRoot.Properties.CodedCharSetId ENCODING 273); -- Actual Data
SET OutputRoot.XMLNSC.NSKRequestMSG.SessionFieldData = Environment.Preprocessing.sessionId;
here in casting I am facing issue, I am getting Exception
Exception : Error casting the value ----My Bolb Data gose here-----
cannot be converted to Unicode from codepage '1208'. : F:\build\S610_P\src\CommonServices\ImbConverter.cpp: 496: ImbConverterCPP::internalToUnicode:
What I observed is that If I am passing 639 and below value to 'DRLDBKEY' its working fine but If I pass 640 and above it throws exception.
I am using CCSID 1208, If i use some othr CCSID in casting it changes the value. I tried with 437, 819,850.with all these CCSID I am able to cast but all these gives me some different value.
If I use 1200,1208,1209 ,13488 all these throws exception.
Please help me I am not getting what to use for CCSID field.
Thanks In Advance,
Amod Gole |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Sat Aug 07, 2010 8:58 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
It may help if you told us what version of Broker (including fixpack) and on what platform you are having these problems on.
If you are running V6.1 then please take a user trace and show us all the wonderful things in the trace about the error.
You seem to be 'serialising' your message tree. The usual problem (if this forum is anything to go by) for this is that the incoming message is incorrect. You may sometimes be lucky with certain values in your input message.
So please check that the incoming message is correctly tagged with the right CCSID.
On the ASBITSTREAM code. Is there anywhy you have not setup the options for the operation. The default is (if I remember correctly) is RootFolder. This may not be correct for your type of operation.
When you reply please put the code & output inside 'code' tage. It really doe help with readability.
_________________
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 |
|
|
| rekarm01 |
| Posted: Sat Aug 07, 2010 5:50 pm Post subject: Re: Issue With CCSID 1208 |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| Amod Gole wrote: |
| I am using CCSID 1208 in my application. In My message defination I have one element 'DRLDBKEY' with Type long and length 8. |
Is this element character data, or numeric data? Check its 'Physical Type' property. ASBITSTREAM() uses ENCODING, not CCSID, to convert Integer types to BLOB.
Converting Integer Type -> BLOB -> CHARACTER either generates garbage or throws an Exception.
| Amod Gole wrote: |
| In My application I have requirement like I have to convert My data into BLOB and I have to send it over network thats why by using ASBITSTREAM function I am converting my entire message into BLOB |
The MRM parser already serializes the data (tree -> bitstream) on output; it's usually not necessary to convert it to BLOB first, to send it over a network.
| Amod Gole wrote: |
| Code: |
SET ddlblob=ASBITSTREAM(InputRoot.MRM
ENCODING 273
CCSID InputRoot.Properties.CodedCharSetId
SET 'ISDKCPG002001'
TYPE 'drl6MSG'
FORMAT 'Text1'); |
|
If the InputProperties are correct, it's better to use them, instead of hard-coding literal values:
| Code: |
SET ddlblob=ASBITSTREAM(InputRoot.MRM
ENCODING InputProperties.Encoding
CCSID InputProperties.CodedCharSetId
SET InputProperties.MessageSet
TYPE InputProperties.MessageType
FORMAT InputProperties.MessageFormat); |
or better yet:
| Code: |
| SET ddlblob=ASBITSTREAM(InputRoot.MRM OPTIONS EmbeddedBitStream); |
... assuming that a call to ASBITSTREAM() is still necessary.
| Amod Gole wrote: |
Next I am again converting it into Character by using CAST because I have to send it to next node where I am appending some more Data to this data.
| Code: |
SET OutputRoot.XMLNSC.NSKRequestMSG.PayLoadFieldData =
CAST(ddlblob AS CHARACTER CCSID InputRoot.Properties.CodedCharSetId ENCODING 273); -- Actual Data |
|
CAST(BLOB AS CHARACTER) doesn't use the ENCODING parameter. To assign a BLOB containing mixed data to an XML element, either encode it as hexBinary:
| Code: |
| SET OutputRoot.XMLNSC.NSKRequestMSG.PayLoadFieldData = CAST(ddlblob AS CHARACTER); -- Actual Data |
or as base64Binary. Adjust the downstream code as needed.
| Amod Gole wrote: |
| What I observed is that If I am passing 639 and below value to 'DRLDBKEY' its working fine but If I pass 640 and above it throws exception. |
In this case, "working fine" still means generating garbage, rather than throwing an Exception. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Aug 09, 2010 6:39 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Same question posted in another forum, with more information:
| Quote: |
All,
I need to achieve the following.
1) Create a byte stream out of the XML received from the client.
2) The incoming request fields are mapped to the respective elements in the message definition. The elements are of various types like string, long, short and integer.
3) Create a byte stream from the value of the elements in the message definition and pass it down over TCP/IP to NSK (Tandem) system.
4) The tandem system takes the byte stream and maps it to its defined structure. (More like C structure). Mind it tandem does not perform any logic to map it to its structure. Its more like IPC.
5) NSK then performs its business logic and returns another byte stream to MB which parses it back to another Message definition and sends the XML back to the client.
Issue we are facing.
1) We use the asbitstream function to create the blob out of the XML. This is the payload data which is sent to the NSK system.
2) We then cast it to CHARACTER using the cast function.
This is done so that we can append other information to this payload like the headers etc which we have defined in another sub flow. We then recreate a new blob from a character field. This character field has the header as well as the payload. As far as I know you cannot append one blob value to another. Please correct me if I am wrong.
3) The main issue. We have some fields in the Message Definition which are of type long. This field needs to be of length 8 bytes as it has to be of the same length of the field defined in NSK. Else the exact field to field mapping is lost due to byte shifting. The default value assigned to this long field is "0".
Main problem: When we cast the blob value in step 1 to character we receive a parsing error. What we observed is that it is caused when ever we have a long value which is of more then 5 digits. The value which we receive from the client is 9 digit long.
Our broker is running on an AIX box. We first tried the CCSID from the Inputroot.properties.CodedCharsetid. This did not work so we tried with other values like 437 and 850. When we use 437 or 850 we do not receive parsing error but when the data is sent to the underlying tandem system, we observed that NSK does not receive the correct value. The value gets changed (shirnked)... Rest all the fields are intact except of the long value.
|
|
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Aug 09, 2010 6:43 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
a) the information that I have quoted above is *much* more useful than the information that you quoted on this forum. On this forum, you have missed out some important details, and you have wasted our time.
b) it sounds as if you are trying to send a non-XML message to another system. Why are you not using the MRM domain for that? |
|
| Back to top |
|
|
| Amod Gole |
| Posted: Wed Aug 11, 2010 2:44 am Post subject: |
|
|
Newbie
Joined: 09 Jun 2010
Posts: 8
|
Thanks For Reply.....
But its not Me  .....................  |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Aug 11, 2010 3:43 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
 How embarassing! The similarities between your question and the one which I quoted were so striking that I assumed that you must be the same person.
I'm clutching at straws here, but is it possible that you are both trying to solve the same problem? Are you converting some incoming XML to a non-XML format? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 11, 2010 8:41 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
@rekarm01
As much as I agree with you to use the InputRoot.Properties.CodedCharSet for the PARSE command, I beg to differ on the ASBITSTREAM command.
There you should use the OutputRoot.Properties.CodedCharSet and you should make sure that it is already set to the correct value.
As well it seems to me that the input format is non xml (MRM) and the output format might be something like String, not necessarily XML.
This being said, you need to convert all your numeric formats to characters before the output or the ASBITSTREAM is called, or use different message sets for input and output...and the output message set should not have any numeric format that does not get serialized into text form on the wire.
Hope that sheds some light on this 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 11, 2010 9:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
As much as I agree with you to use the InputRoot.Properties.CodedCharSet for the PARSE command, I beg to differ on the ASBITSTREAM command.
There you should use the OutputRoot.Properties.CodedCharSet and you should make sure that it is already set to the correct value. |
ASBITSREAM produces a bitstream using whatever CCSID value you pass in. It's not terribly relevant whether this value is stored in InputRoot or OutputRoot.
It is vitally important that the Output message is propagated with a CCSID that indicates the correct value, and setting OutputRoot.Properties.CodedCharSet is the right way to do this. But setting it before or after ASBITSTREAM is not terribly relevant. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 11, 2010 9:35 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
It becomes relevant if you use the reference OutputRoot.Properties.CodedCharSet in your ASBITSTREAM command.
Especially if you go later in the ESQL and change that value before serialization... and as such have a value / content mismatch...
But as you said, if you are dealing in absolute values it is of little importance as long as the value in the output matches the content.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Thu Aug 12, 2010 1:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| fjb_saper wrote: |
@rekarm01
As much as I agree with you to use the InputRoot.Properties.CodedCharSet for the PARSE command, I beg to differ on the ASBITSTREAM command.
There you should use the OutputRoot.Properties.CodedCharSet and you should make sure that it is already set to the correct value. |
My original point was only that developers shouldn't hard-code literal values unless they have to. If the desired parameter values are already available somewhere else, then use those instead.
Though for either "ASBITSTREAM(FieldReference ...)" or "CREATE ... PARSE(BitStreamExpression ...)", sometimes InputRoot.Properties is suitable, sometimes OutputRoot.Properties is suitable, and sometimes neither is. It really depends on the source data, the desired result, and the surrounding code.
The example above was based on my best guess as to what the OP was trying to accomplish. It could be wrong ... |
|
| Back to top |
|
|
|
|
