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 » WebSphere Message Broker (ACE) Support » Handling special characters

Post new topic  Reply to topic
 Handling special characters « View previous topic :: View next topic » 
Author Message
paranoid221
PostPosted: Thu May 21, 2009 9:56 pm    Post subject: Handling special characters Reply with quote

Centurion

Joined: 03 Apr 2006
Posts: 101
Location: USA

/***
Let me vent some steam & fret for a bit about my work environment:
It sucks that they block MQSeries.net at my workplace; I think primarily because of the ads and the scripts on the page but who knows. We've put in a request to add this site in the exception list of the Network monitor.
Ok I'm done.
****/
Now to the scenario:
I did browse through some of the previous posts on handling special characters and decided to give it a try with a personal touch
Sample XML
Code:
<SResp>
<Name>Seňor paranoid221</Name> // hahahha what the heck
</SResp>


From a windows machine (CCSID=437), I used rfhutil and dropped this XML onto a queue on AIX, had a broker flow listen on the queue and the MQInput node of the flow had a get with convert (MQGMO_Convert) option selected (with default values of 0 for CCSID and Encoding).
If you have a default value of 0 for the CCSID and encoding properties, it is a known that the properties of the QManager will be inherited, which in this case should be 819 for the CCSID since it is AIX.
However, as soon as the flow tried to pick the message, it threw it into DLQ and so the flow never even got invoked.

My question is why did the convert not take place at all? What if you have a client requirement to allow special characters in your messages and these messages travel across the network through disparate systems? How can we ensure that the special characters don't get screwed up and at the same time the messages do not get dumped into DLQ?

It should also be noted here that if I do not set the convert option, the message goes to the output queue successfully and using rfhutil from a windows machine I was able to read the message in its undisturbed format. This obviously is foolhardy test since the put and get are being done on the same platform. What would happen if, instead, a host program on mainframe were to consume this message with and without the convert option set.

I'm specifically looking up to the IBM elites on this forum to shed some light on this. Kimbert, mgk et al ... you listening...!!!!
_________________
LIFE is a series of complex calculations, somewhere multiplied by ZERO.
Back to top
View user's profile Send private message
vol
PostPosted: Thu May 21, 2009 10:41 pm    Post subject: Reply with quote

Acolyte

Joined: 01 Feb 2009
Posts: 69

what was the reason code on the msg in the DLQ?
Post a hex dump of the DLH header
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu May 21, 2009 11:05 pm    Post subject: Re: Handling special characters Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

paranoid221 wrote:
However, as soon as the flow tried to pick the message, it threw it into DLQ and so the flow never even got invoked.


What is the reason given for dead lettering the message (i.e. the code in the DLH)? I'm assuming it's the invalid conversion one but confirmation would be nice.

What conversions are valid on the AIX machine (you may need to ask your admin about that)? Or how have you otherwise ensured that 437->819 will work? Did you actually check the CCSID of the DLQ'd message (it's that confirmation thing again)?

paranoid221 wrote:
I'm specifically looking up to the IBM elites on this forum to shed some light on this. Kimbert, mgk et al ... you listening...!!!!


Well I am not now nor have I ever been IBM or elite, but I do try my best.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu May 21, 2009 11:06 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

vol wrote:
Post a hex dump of the DLH header


I have better things to do on a Bank Holiday Friday to count bytes. Look it up with Explorer and post the answer....
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
rekarm01
PostPosted: Mon May 25, 2009 12:57 am    Post subject: Re: Handling special characters Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 1415

paranoid221 wrote:
Sample XML
Code:
<SResp>
<Name>Seňor paranoid221</Name> // hahahha what the heck
</SResp>

From a windows machine (CCSID=437) ...

ccsid=437 refers to an MS-DOS code page, not a Windows code page. Unless an actual MS-DOS application is creating the source message and putting it on a queue, ccsid=437 is almost always wrong.

The source message contains a Central European Latin-2 character 'ň' (U+0148, n with caron), which does not exist in any of the common Latin-1 based ccsids, such as 437, or 819. So, the source ccsid must be something else. Examine the source application more closely (before rfhutil), to determine the correct source ccsid. If all else fails, rfhutil can display message data in hex; manually compare bytes against supported ccsids.

By the way, 'Señor' is more commonly spelled with a Western Latin-1 'ñ' (U+00F1, n with tilde), but that's a separate issue; correcting the spelling won't resolve the original problem.

paranoid221 wrote:
My question is why did the convert not take place at all? What if you have a client requirement to allow special characters in your messages and these messages travel across the network through disparate systems? How can we ensure that the special characters don't get screwed up ... ?

The convert did take place, but it failed, because the sender put a bad message on the queue. The sender had encoded the message one way, but claimed to have encoded it a different way. If the sender lies to WMQ about the message encoding it used, there's very little that WMQ can do about that.

paranoid221 wrote:
... and at the same time the messages do not get dumped into DLQ?

Define a backout queue for the MQInput queue, or attach the MQInput.Failure terminal, so that bad messages gets dumped elsewhere, instead. For even greater error-handling flexibility, use WMB to convert, rather than WMQ.

--
"On two occasions I have been asked,—'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' … I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." -- Charles Babbage
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 » WebSphere Message Broker (ACE) Support » Handling special characters
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.