ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ API Support » vb.net MQ API CCSID problem

Post new topic  Reply to topic
 vb.net MQ API CCSID problem « View previous topic :: View next topic » 
Author Message
al000y
PostPosted: Sun Jun 22, 2014 5:14 am    Post subject: vb.net MQ API CCSID problem Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Sun Jun 22, 2014 6:51 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
al000y
PostPosted: Mon Jun 23, 2014 3:08 am    Post subject: Reply with quote

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
View user's profile Send private message
al000y
PostPosted: Mon Jun 23, 2014 3:18 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Mon Jun 23, 2014 4:05 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
al000y
PostPosted: Mon Jun 23, 2014 5:07 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Mon Jun 23, 2014 5:17 am    Post subject: Reply with quote

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
View user's profile Send private message
al000y
PostPosted: Mon Jun 23, 2014 5:21 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Mon Jun 23, 2014 5:25 am    Post subject: Reply with quote

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
Quote:
NAME10 = 吀䔀匀吀

is absolutely not 437.

Remove the line that sets the code page.
Back to top
View user's profile Send private message
al000y
PostPosted: Mon Jun 23, 2014 8:11 pm    Post subject: Reply with quote

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
Quote:
NAME10 = 吀䔀匀吀

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
View user's profile Send private message
pmeekin
PostPosted: Wed Jun 25, 2014 2:25 am    Post subject: Reply with quote

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
View user's profile Send private message
zpat
PostPosted: Wed Jun 25, 2014 2:33 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
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
View user's profile Send private message
mqjeff
PostPosted: Wed Jun 25, 2014 7:29 am    Post subject: Reply with quote

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
Quote:
NAME10 = 吀䔀匀吀

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ API Support » vb.net MQ API CCSID problem
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.