I swear at least once a month I read about someone complaining that they are seeing garbage (unreadable) output when they try to read their JMS (aka MQRFH2) message in IBM MQ.
The user will put a message to a queue with their JMS application then try and read it with a non-JMS tool and immediately start complaining that they are seeing weird and/or garbage output or ‘what happened to my message data’.
First off, if you are going to put a JMS message to a queue then use a JMS application or a tool that understands JMS messages but do NOT use non-JMS tools and the start whining about seeing weird and/or garbage output. Nobody cares that you are new to MQ. Use Google to help you understand the issue or read the MQ Knowledge Center or go to MQ Technical Conference which is super cheap and has lots of great MQ sessions.
In MQ terminology, a JMS message means that it is formatted as an MQRFH2 message. If you are new to MQ, then read and read and read the Overview for MQRFH2 page until you completely understand it and yes I am being serious.
So what am I talking about? The user will put a message to a queue with their JMS application and then use the sample MQ application like amqsget or amqsbcg (which are both non-JMS applications) and start complaining.
When the user runs amqsget, it will look like:
Sample AMQSGET0 start message <RFH ☻> no more messages Sample AMQSGET0 end
Or when the user will runs amqsbcg, it will look like:
****Message descriptor**** StrucId : 'MD ' Version : 2 Report : 0 MsgType : 8 Expiry : -1 Feedback : 0 Encoding : 273 CodedCharSetId : 1208 Format : 'MQHRF2 ' Priority : 4 Persistence : 1 MsgId : X'414D51204D5157543120202020202020673AC65A243D0D02' CorrelId : X'000000000000000000000000000000000000000000000000' BackoutCount : 0 ReplyToQ : ' ' ReplyToQMgr : 'MQWT1 ' ** Identity Context UserIdentifier : 'tester ' AccountingToken : X'16010515000000FAE66C00D5EA80C2BF2341ACEE03000000000000000000000B' ApplIdentityData : ' ' ** Origin Context PutApplType : '28' PutApplName : 'MQTestJMS11 ' PutDate : '20180405' PutTime : '16463591' ApplOriginData : ' ' GroupId : X'000000000000000000000000000000000000000000000000' MsgSeqNumber : '1' Offset : '0' MsgFlags : '0' OriginalLength : '-1' **** Message **** length - 203 of 203 bytes 00000000: 5246 4820 0000 0002 0000 0098 0000 0111 'RFH .......ÿ....' 00000010: 0000 04B8 4D51 5354 5220 2020 0000 0000 '....MQSTR ....' 00000020: 0000 04B8 0000 0020 3C6D 6364 3E3C 4D73 '....... <mcd><Ms' 00000030: 643E 6A6D 735F 7465 7874 3C2F 4D73 643E 'd>jms_text</Msd>' 00000040: 3C2F 6D63 643E 2020 0000 004C 3C6A 6D73 '</mcd> ...L<jms' 00000050: 3E3C 4473 743E 7175 6575 653A 2F2F 2F54 '><Dst>queue:///T' 00000060: 4553 542E 5131 3C2F 4473 743E 3C54 6D73 'EST.Q1</Dst><Tms' 00000070: 3E31 3532 3239 3436 3739 3539 3036 3C2F '>1522946795906</' 00000080: 546D 733E 3C44 6C76 3E32 3C2F 446C 763E 'Tms><Dlv>2</Dlv>' 00000090: 3C2F 6A6D 733E 2020 4E69 6365 2073 696D '</jms> Nice sim' 000000A0: 706C 6520 7465 7374 2E20 5469 6D65 2069 'ple test. Time i' 000000B0: 6E20 276D 7327 2069 7320 202D 3E20 3135 'n 'ms' is -> 15' 000000C0: 3232 3934 3637 3935 3839 34 '22946795894 '
If the user simply ran a JMS application then the message payload would be:
Nice simple test. Time in 'ms' is -> 1522946795894
Which I’m 99.99% sure that is what they actually wanted to see.
So, why the difference? A JMS (aka MQRFH2) message is MEANT for a JMS application and not for a non-JMS application. Secondly, did you read Overview for MQRFH2 page that I mentioned above. Third, guess what, a non-JMS application can understand a JMS (aka MQRFH2) message IF it has been coded to do so. Note: amqsget and amqsbcg have not been coded to understand a JMS message.
Coded you say – yup. The non-JMS consumer (getter) application has 2 ways of receiving the JMS application. The default is for the application to receive the message as an MQRFH2 message. The other way is to receive the message (as a string) with Named Properties.
How you say? The MQGMO structure (or MQGetMessageOptions class for Java & .NET) has a field called ‘options’. You can add (OR) either MQGMO_PROPERTIES_IN_HANDLE or MQGMO_PROPERTIES_FORCE_MQRFH2 option to that field. Read here for more details.
Ok, so let me show you the same message above using MQ Visual Edit, first with the MQGMO options set to MQGMO_PROPERTIES_FORCE_MQRFH2 (screen-shots 1, 2 & 3) and then with the MQGMO options set to MQGMO_PROPERTIES_IN_HANDLE (screen-shots 4, 5, 6 & 7).
In MQ Visual Edit, to change how it handles receiving the messages, click File -> Preferences and select the MQ General icon. On the window, you will see:
For the first screen-shots below, I have it set to “Show message properties as an MQRFH2 structure in message body” which means MQ Visual Edit is setting the MQGMO options value to MQGMO_PROPERTIES_FORCE_MQRFH2.
Screen-shot #1 shows that the MQMD Format of the message is ‘MQHRF2’:
Screen-shot #2 shows the message payload in HEX format:
Screen-shot #3 shows the message properly formatted for MQRFH2:
Now switching MQ Visual Edit’s Preferences to “Show message properties as Named Properties“:
Which means MQ Visual Edit is setting the MQGMO options value to MQGMO_PROPERTIES_IN_HANDLE. Hence, the exact same message will be displayed follows:
Screen-shot #4 shows that the MQMD Format of the message is ‘MQSTR’ (string):
Screen-shot #5 shows the message payload in HEX format:
Screen-shot #6 shows the message payload as:
Screen-shot #7 shows that all the values from the MQRFH2 folders are now Named Properties:
So, I have shown you the EXACT same JMS (aka MQRFH2) message 4 different ways. i.e. amqsget, amqsbcg and 2 ways in MQ Visual Edit. So, it is not MQ that is giving the user weird and/or garbage output but rather it is the application that is not understanding the format of the message.
Bottom-line, when dealing with JMS (aka MQRFH2) messages, either use a JMS application to consume the messages or use a tool that understands a JMS message. Hence, there will be a lot less complaining/whining about weird and/or garbage output.
Regards,
Roger Lacroix
Capitalware Inc.
