|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
missing carriage return on MQPUT using Perl port of MQSeries |
« View previous topic :: View next topic » |
Author |
Message
|
kermit |
Posted: Thu Mar 20, 2003 4:48 pm Post subject: missing carriage return on MQPUT using Perl port of MQSeries |
|
|
Newbie
Joined: 20 Mar 2003 Posts: 2
|
Versions: Perl v5.6, Perl::MQSeries v1.18, NT4.
When sending a message to a queue using the MQPUT function of the Perl::MQSeries module, the carriage return character of a carriage return/line feed combination (xODx0A) is stripped off the message. The message itself is basically ASCII text where each line is terminated by CRLF. For example:
line 1 blah blah blah[CRLF]
line 2 blah blah blah[CRLF]
line 3 blah blah blah[CRLF]
After performing an MQPUT to a local queue, this message is stored as:
line 1 blah blah blah[LF]
line 2 blah blah blah[LF]
line 3 blah blah blah[LF]
If I do an MQGET from the same NT box that I "MQPUT" the message, it is returned with CRLF. It appears that the Perl version of the MQPUT and MQGET functions are removing and adding the CR character, and the queue only stores the LF. The reason I say this is I performed the put and get on a local queue (SYSTEM.DEFAULT.LOCAL.QUEUE) on an NT box to eliminate any possible translation issues between different platforms or codepage or character encoding settings.
Is there any way to turn off this behavior (preserve the CRLF) or is this a "feature" in the Perl::MQSeries API? |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Mar 21, 2003 6:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Are you creating these CRLF's with \n? You could try creating them with hex values instead, and see if that changes the behavior.
Are you specifying convert on your put or get? Try without it. |
|
Back to top |
|
 |
kermit |
Posted: Fri Mar 21, 2003 2:36 pm Post subject: |
|
|
Newbie
Joined: 20 Mar 2003 Posts: 2
|
I am not using convert with the put or get. I'm not sure I want to "jump through hoops" (use hex chars, etc) just to make the carriage return appear in the msg. My main concern is determining why it's happening. We've already taken alternative measures to process the msgs without the CR. If the CR somehow re-appeared in the message if, for instance, the physical queue was changed to a different platform, it would break the program that retrieves and processes the msg. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
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
|
|
|
|