| Author |
Message
|
| bdaoust |
 Posted: Fri Jul 10, 2015 6:22 am Post subject: CCSID is 0 from .NET Application |
 |
|
Centurion
Joined: 23 Sep 2010
Posts: 130
|
We have a .NET application that sends a string message to a queue using the .NET MQ Client.
It looks like all messages from this web server are going on the queue at the queue manager (which sits on a Unix Box) and the CCSID is 0. This is causing a problem according to the MQ Admin who said this message cannot be read since it's CCSID of 0.
In our development area - the CCSID is showing correctly.
The .NET developer says the same code is deployed in both DEV and UAT - using the same versions of the .NET framework and MQ client and the character code set is set both to 437 on the web server.
MQ Admin is saying the cause of CCSID of 0 is from the application server - that there must be some difference. But we looked everywhere.
MQ admin told me that the CCSID on the queue manager is set to the same in both environments. And channel conversion is not applicable because we are not going through a sender channel since we are using a client connection.
Any ideas of what is not being considered?
Thanks |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Jul 10, 2015 6:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
do a byte comparison (amqsbcg) of the same message in both environments.
That will tell you if the message is actually in a different ccsid, or if the ccsid is just misidentified.
Confirm that the versions of the app code and the .net libraries and etc. are the same in both envs. |
|
| Back to top |
|
|
| bdaoust |
| Posted: Fri Jul 10, 2015 6:50 am Post subject: |
|
|
Centurion
Joined: 23 Sep 2010
Posts: 130
|
Thanks mqjeff.
The .NET developer is saying the .NET code base is the same as is the .NET framework version. I believe with the MQ client there is a DLL, which I asked him to check those version as well.
The MQAdmin is saying this is an app issue because since the CCSID is 0, he cannot read the message. However, we have other messages coming from that web app server and landing on a separate queue manager that then sends messages to our broker (which is what I'm responsible for) Those are working - meaning they hit my message flow with a CCSID of 0 and broker doesn't seem to care. I would think that if the MQAdmin is saying the issue is because CCSID is 0 - then even the broker messages should fail?
Unfortunately, I only have access to broker and these messages aren't going through broker, so I don't have access to these queues or queue managers to grab the message off queue or even look at config settings. Frustrating cause I'm flying blind.
I should point out the messages that are not working (meaning getting to their destination queue properly) are those not going through the broker. The ones going through the broker are getting to the destination and working fine but it's properly because I'm setting CCSID before I send the message off.
Thanks |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jul 10, 2015 6:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Well, tell the MQ admin to capture the messages using amqsbcg.
Or tell the developer. |
|
| Back to top |
|
|
| bdaoust |
| Posted: Fri Jul 10, 2015 7:51 am Post subject: |
|
|
Centurion
Joined: 23 Sep 2010
Posts: 130
|
Some added info.
We used amqsputc to place a test message from the UAT server and it sent over the correct CCSID of 437.
So, it's something within the .NET app. Both the .NET app and amqsputc use the MQ client on the server - with the difference is that the .NET app has a wrapper class.
But we know it's not an issue on the queue manager level now.
 |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Jul 10, 2015 8:05 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
bdaoust - Are you saying that a message is being PUT on a queue and the resulting CCSID of that message on the queue is zero? I wouldn't think that is possible. You can PUT a message with the CCSID in the MD being zero, but that just means that the default CCSID of the queue manager will be used. When the queue manager puts the message on the queue, it would show the CCSID that is the default of the queue manager. Also, the developer needs to understand that when you do specify a CCSID of zero in the MD, you are affirming that bytes of your message are currently in the default CCSID of the queue manager.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| bdaoust |
| Posted: Fri Jul 10, 2015 10:53 am Post subject: |
|
|
Centurion
Joined: 23 Sep 2010
Posts: 130
|
tczielke:
Yes, it's 0 when we PUT to queue manager from .NET app, but when we use amqsputc in command line and just send a string - the Windows Server Character Code of 437 does go on queue manager.
MQ admin sent me screenshots showing the messages on the queue with CCSID of 0.
One thing I didn't mention is the .NET is just sending a simple string. |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Jul 10, 2015 11:08 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
That doesn't make sense to me, but maybe there is something about CCSIDs that I don't understand.
For example, when I use the amqsput to PUT a message on a queue, I see the following in the trace:
| Code: |
7444.1 CodedCharSetId (MQLONG) : 0
7444.1 x'00000000'
7444.1 CodedCharSetId MQCCSI_UNDEFINED
7444.1 CodedCharSetId MQCCSI_DEFAULT
7444.1 CodedCharSetId MQCCSI_Q_MGR
|
so the CCSID was zero in the MD.
But when I look at the resulting message using amqsbcg, I see the following:
| Code: |
Encoding : 273 CodedCharSetId : 819
|
The CCSID of the message is now the default of the queue manager, which is 819.
Conceptually, it makes no sense to have a message on a queue with a CCSID of zero. That would mean the character set of the bytes are unknown, so how could MQ then interpret the bytes correctly? Again, maybe I am just ignorant about something here with MQ and CCSIDs.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jul 10, 2015 11:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| again, without seeing the amqsbcgc output of the message, there's just a lot of guessing that can be done from this side of the browser. |
|
| Back to top |
|
|
|
|
