| Author |
Message
|
| al000y |
 Posted: Sun Jun 22, 2014 5:14 am Post subject: vb.net MQ API CCSID problem |
 |
|
Apprentice
Joined: 25 Dec 2013
Posts: 30
|
Hi Everyone,
I build test vb.net application that put a test message on a queue.
| Code: |
QM = New MQQueueManager("QMNAME", "CHANNEL", "COOENCTION")
QUEUE = QM.AccessQueue("QUEUENAME", MQOO_OUTPUT + MQOO_FAIL_IF_QUIESCING)
Dim msg_MQSV_IN As MQMessage = New MQMessage()
msg_MQSV_IN.WriteString(MSG)
msg_MQSV_IN.Format = MQC.MQFMT_STRING
msg_MQSV_IN.CharacterSet = 437
Dim mqPutMsgOpts As MQPutMessageOptions = New MQPutMessageOptions()
mqPutMsgOpts.Options = MQC.MQPMO_NO_SYNCPOINT
QUEUE.Put(msg_MQSV_IN, mqPutMsgOpts) |
The application works perfectly when I set the CCSID to 1202
All other CCSIDs 1208,819,1200,437 give me a truncated message.
My QM CCSID is 437.
Can anyone explain that for me please. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sun Jun 22, 2014 6:51 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you tried setting the CCSID before writing the string?
Setting it after is like closing the barn door after the horses left... 
Setting the value after is telling that the content is in CCSID. You don't know what the content was written as though...
Before you write anything to the message you should also set the message format to MQFMT_STRING...
your order was fine but for the fact that you should write the message text last...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| al000y |
| Posted: Mon Jun 23, 2014 3:08 am Post subject: |
|
|
Apprentice
Joined: 25 Dec 2013
Posts: 30
|
| fjb_saper wrote: |
Have you tried setting the CCSID before writing the string?
Setting it after is like closing the barn door after the horses left...
Setting the value after is telling that the content is in CCSID. You don't know what the content was written as though...
Before you write anything to the message you should also set the message format to MQFMT_STRING...
your order was fine but for the fact that you should write the message text last...
Have fun |
Same results.
My input queue domain is BLOB, I put a test message "test".
What I got in the flow by using this code is only "T"
| Code: |
| DECLARE testvar CHAR CAST(InputRoot.BLOB.BLOB as char CCSID InputRoot.Properties.CodedCharSetId Encoding InputRoot.Properties.Encoding); |
And when I change the domail to XML and put an XML message it give me XML Parser Error message. |
|
| Back to top |
|
|
| al000y |
| Posted: Mon Jun 23, 2014 3:18 am Post subject: |
|
|
Apprentice
Joined: 25 Dec 2013
Posts: 30
|
This is the test code, the input is TEST
| Code: |
DECLARE NAME1 CHAR CAST(InputRoot.BLOB.BLOB as char CCSID InputRoot.Properties.CodedCharSetId Encoding InputRoot.Properties.Encoding);
DECLARE NAME2 CHAR CAST(InputRoot.BLOB.BLOB as char CCSID InputRoot.Properties.CodedCharSetId);
DECLARE NAME3 CHAR CAST(InputRoot.BLOB.BLOB as char Encoding InputRoot.Properties.Encoding);
DECLARE NAME4 CHAR CAST(InputRoot.BLOB.BLOB as char CCSID 1208 Encoding 273);
DECLARE NAME5 CHAR CAST(InputRoot.BLOB.BLOB as char CCSID 1208 Encoding 546);
DECLARE NAME6 CHAR CAST(InputRoot.BLOB.BLOB as char CCSID 1202 Encoding 273);
DECLARE NAME7 CHAR CAST(InputRoot.BLOB.BLOB as char CCSID 1202 Encoding 546);
DECLARE NAME8 CHAR CAST(InputRoot.BLOB.BLOB as char CCSID 819 Encoding 273);
DECLARE NAME9 CHAR CAST(InputRoot.BLOB.BLOB as char CCSID 819 Encoding 546);
DECLARE NAME10 CHAR CAST(InputRoot.BLOB.BLOB as char CCSID 1200 Encoding 273);
DECLARE NAME11 CHAR CAST(InputRoot.BLOB.BLOB as char CCSID 1200 Encoding 546);
DECLARE NAME12 CHAR CAST(InputRoot.BLOB.BLOB as char CCSID 437 Encoding 273);
DECLARE NAME13 CHAR CAST(InputRoot.BLOB.BLOB as char CCSID 437 Encoding 546); |
And this is the output
NAME1 = T
NAME2 = T
NAME3 = T
NAME4 = T
NAME5 = T
NAME6 = TEST
NAME7 = TEST
NAME8 = T
NAME9 = T
NAME10 = 吀䔀匀吀
NAME11 = TEST
NAME12 = T
NAME13 = T |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jun 23, 2014 4:05 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
So you mean to say the input message is lying about the CCSID of it's content... Nothing new there. You need to get back to the input group and make sure they adequately describe the CCSID of the message content, and may be the format. Although XML has a tendency to give you a blob format so that the potential attachments are safe...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| al000y |
| Posted: Mon Jun 23, 2014 5:07 am Post subject: |
|
|
Apprentice
Joined: 25 Dec 2013
Posts: 30
|
| fjb_saper wrote: |
So you mean to say the input message is lying about the CCSID of it's content... Nothing new there. You need to get back to the input group and make sure they adequately describe the CCSID of the message content, and may be the format. Although XML has a tendency to give you a blob format so that the potential attachments are safe...
Have fun |
Can you explain more please  |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 23, 2014 5:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| al000y wrote: |
| fjb_saper wrote: |
So you mean to say the input message is lying about the CCSID of it's content... Nothing new there. You need to get back to the input group and make sure they adequately describe the CCSID of the message content, and may be the format. Although XML has a tendency to give you a blob format so that the potential attachments are safe...
Have fun |
Can you explain more please |
the application that creates the message says that character values are encoded in one codepage, but actually writes character values into the message in a different one.
Ceci n'es pas une pipe.
So the application that sends the message is doing the wrong thing, so that nobody can read it properly. |
|
| Back to top |
|
|
| al000y |
| Posted: Mon Jun 23, 2014 5:21 am Post subject: |
|
|
Apprentice
Joined: 25 Dec 2013
Posts: 30
|
| mqjeff wrote: |
| al000y wrote: |
| fjb_saper wrote: |
So you mean to say the input message is lying about the CCSID of it's content... Nothing new there. You need to get back to the input group and make sure they adequately describe the CCSID of the message content, and may be the format. Although XML has a tendency to give you a blob format so that the potential attachments are safe...
Have fun |
Can you explain more please |
the application that creates the message says that character values are encoded in one codepage, but actually writes character values into the message in a different one.
Ceci n'es pas une pipe.
So the application that sends the message is doing the wrong thing, so that nobody can read it properly. |
Do I have to change the writing function msg_MQSV_IN.WriteString("TEST") to something different or there is another thing that I have to do? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 23, 2014 5:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| al000y wrote: |
| Do I have to change the writing function msg_MQSV_IN.WriteString("TEST") to something different or there is another thing that I have to do? |
Your function uses WriteString, and then assumes that WriteString has written a 437 codepage string into the message.
If you're using modern versions of .NET, it's almost certainly a Unicode string and not in 437.
Particularly
is absolutely not 437.
Remove the line that sets the code page. |
|
| Back to top |
|
|
| al000y |
| Posted: Mon Jun 23, 2014 8:11 pm Post subject: |
|
|
Apprentice
Joined: 25 Dec 2013
Posts: 30
|
| mqjeff wrote: |
| al000y wrote: |
| Do I have to change the writing function msg_MQSV_IN.WriteString("TEST") to something different or there is another thing that I have to do? |
Your function uses WriteString, and then assumes that WriteString has written a 437 codepage string into the message.
If you're using modern versions of .NET, it's almost certainly a Unicode string and not in 437.
Particularly
is absolutely not 437.
Remove the line that sets the code page. |
You are right, when I encode the text before sending it to the queue its work fine, Thanks.
| Code: |
Dim asciiEncoding = Encoding.GetEncoding(437)
Dim asciiBytes = asciiEncoding.GetBytes("TEST".ToCharArray)
Dim unicodeString = asciiEncoding.GetString(asciiBytes)
msg_MQSV_IN.WriteString(unicodeString) |
|
|
| Back to top |
|
|
| pmeekin |
| Posted: Wed Jun 25, 2014 2:25 am Post subject: |
|
|
Novice
Joined: 13 Jan 2003
Posts: 10
Location: UK
|
| al000y wrote: |
You are right, when I encode the text before sending it to the queue its work fine, Thanks.
| Code: |
Dim asciiEncoding = Encoding.GetEncoding(437)
Dim asciiBytes = asciiEncoding.GetBytes("TEST".ToCharArray)
Dim unicodeString = asciiEncoding.GetString(asciiBytes)
msg_MQSV_IN.WriteString(unicodeString) |
|
I think there's some confusion here. I had a very similar issue a while back with a VB app sending to a Java app.
VB seems to use UTF-16 internally so unless you explicitly change this you need to be aware of this. Also, Windows is a Little Endian architecture so the encoding should be 0x222 (546).
CCSID 1200 is the code page for UTF-16, but this does not specify the byte order which for a multi-byte character set like UTF-16 is critical. MQ being clever can use the CCSID and encoding to deduce the correct byte order of the message during conversion. So if you stick with CCSID 1200 and encoding 0x222 you should be ok.
However, you say you are using CCSID 1202. This is also a code page for UTF-16 but this implies a LE byte order. However, MQ doesn't support CCSID 1202 so I can only assume you are doing the Get with noconvert, or ignoring the conversion error.
I suspect you are getting the proper conversion done by WMB which probably does support 1202, as does Java and which recognizes the byte order without needing to know the encoding value. Incidentally I would guess that's why your test 6 works correctly - even though it specifies the wrong encoding this is probably ignored because 1202 has implicit byte order.
So the upshot? As usual make sure your CCSID and encoding correctly describe the data you are sending and you will be ok. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jun 25, 2014 2:33 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
.NET often inserts a byte order mark (BOM) into the start of the message.
This can confuse people and also affect conversion.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 25, 2014 7:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| al000y wrote: |
| mqjeff wrote: |
| al000y wrote: |
| Do I have to change the writing function msg_MQSV_IN.WriteString("TEST") to something different or there is another thing that I have to do? |
Your function uses WriteString, and then assumes that WriteString has written a 437 codepage string into the message.
If you're using modern versions of .NET, it's almost certainly a Unicode string and not in 437.
Particularly
is absolutely not 437.
Remove the line that sets the code page. |
You are right, when I encode the text before sending it to the queue its work fine, Thanks.
| Code: |
Dim asciiEncoding = Encoding.GetEncoding(437)
Dim asciiBytes = asciiEncoding.GetBytes("TEST".ToCharArray)
Dim unicodeString = asciiEncoding.GetString(asciiBytes)
msg_MQSV_IN.WriteString(unicodeString) |
|
No, that's not the point at all.
That takes your lovely unicode text, and discards everything that doesn't fit into windows ASCII.
Put your code back the way it was, and remove the line
| Code: |
| msg_MQSV_IN.CharacterSet = 437 |
|
|
| Back to top |
|
|
|
|
