0
votes

requirement is to remove carriage return from an incoming message in IBM MQ.

Our Application expects character length of 1579 in response message, but its comes as 1581 with "CRLF" at end

When execute below command
/opt/mqm/samp/bin/amqsbcg TXN_RCV_FRM_SYS TXNSYS850.QM
length - 1581 of 1581 bytes

When same response message placed by removing "CRLF" with /opt/mqm/samp/bin/amqsput TXN_RCV_FRM_SYS TXNSYS850.QM , application able to pick the message from QM

Please guide me any configuration setting to remove these characters from queues or QM level

28 march 2018 issue resolved :-)

MQGMO_CONVERT
Set above value to true...
This option converts the application data in the message to conform to the CodedCharSetId and Encoding values specified in the MsgDesc parameter on the MQGET call. The data is converted before it is copied to the Buffer parameter.  The Format field specified when the message was put is assumed by the conversion process to identify the nature of the data in the message. The message data is converted by the queue manager for built-in formats, and by a user-written exit for other formats. See Data conversion for details of the data-conversion exit.  If conversion is successful, the CodedCharSetId and Encoding fields specified in the MsgDesc parameter are unchanged on return from the MQGET call.  If only conversion fails the message data is returned unconverted The CodedCharSetId and Encoding fields in MsgDesc are set to the values for the unconverted message. The completion code is MQCC_WARNING in this case.  In either case, these fields describe the character-set identifier and encoding of the message data that is returned in the Buffer parameter. See the Format field described in MQMD - Message descriptor for a list of format names for which the queue manager performs the conversion.

CCSD Details of working and not working from amqsbcg

not working
Encoding : 273 CodedCharSetId : 1208
working
Encoding : 546 CodedCharSetId : 1208

1
If CRLF was the problem, then surely MQGMO_CONVERT didn't fix it. The convert option can change how characters are encoded, but not the characters themselves.Attila Repasi

1 Answers

0
votes

There are no QUEUE or QM level settings that would accomplish removing the CRLF from the end of a message.

The options you have are:

  1. Modify the sending app so it does not send a message that has CRLF as the last two characters.
  2. Modify the receiving app so it will ignore CRLF.
  3. If you can not change the sending or receiving app then the only other option is to put something in the middle that does this work for you, a simple program that reads a message from one queue, strips off the CRLF and writes to a second queue.

Update related to Encoding

The PDF attached to IBM Technote "Data Conversion under WebSphere MQ" goes into a lot of detail about how encoding and CCSID impact conversion.

Encoding

Encoding is generally taken to mean the method that this platform uses to represent numeric data. There are two general types:

  • ‘LittleEndian’, used by Intel processors (e.g Windows, Linux on Intel). In this encoding, the least significant digits appear in lower memory locations, e.g. the number 437 would be represented (in hex) as X’BF01’.
  • ‘BigEndian’. The most significant digits are in lower memory locations. e.g. the number 437 would be represented (in hex) as X’01BF’.

Regarding your working and non-working messages:

Encoding 273 corresponds to Unix (Non-Intel) operating systems, for example AIX or Solaris Spark, this is referred to as Big Endian.

Encoding 546 corresponds to Linux and Windows operating systems on Intel, this is referred to as Little Endian.

In both cases you have CCSID 1208 which corresponds to UTF-8 which is a Variable Byte character set it can have from one to four bytes per character.


I am not sure why encoding would impact your ability to process the message body. Can you provide details of the MQ queue manager version for the send and receive app along with the IBM MQ jar file versions for the send and receive app?