| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| JMS Byte message |
« View previous topic :: View next topic » |
| Author |
Message
|
| zrux |
 Posted: Fri Oct 02, 2020 7:06 am Post subject: JMS Byte message |
 |
|
Apprentice
Joined: 21 May 2006
Posts: 37
Location: UK
|
We are trying to move our platform and got 2 systems running currently
Our 3rd party consumer of the message we send is complaining that the new platform is not sending BytesMessage, and its sending com.ibm.jms.JMSTextMessage.
The 3rd party has not made any changes, the changes are our end because of new platform
I am trying to compare the messages generated from both the platforms using RFHUTIL, and I don't spot any obvious difference.
I can see the encoding(273)/CCSID (1208)is same on both
I can see the JMS folder has message domain set as "jms_byte" same on both
I can see the MQMD "MQ Message format" is set as MQRFH2 same on both
Is there a particular tab/field that needs to be checked when using the RFHUTIL tool?
Is there any other way to look at this? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Oct 02, 2020 10:19 am Post subject: Re: JMS Byte message |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| zrux wrote: |
| We are trying to move our platform ... |
Are saying that you are moving the physical server platform from one location to another?
Or, do you mean you are moving an app to a different O/S?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Oct 02, 2020 11:20 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
(1) Is the mcd folder spelled/formatted correctly?
It should be:
| Code: |
| <mcd><Msd>jms_byte</Msd></mcd> |
Note: the only capital letter is the 'M' in Msd.
(2) What is the MQRFH2.Format set to? It should be all blanks and not MQSTR.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| zrux |
| Posted: Mon Oct 05, 2020 2:33 am Post subject: |
|
|
Apprentice
Joined: 21 May 2006
Posts: 37
Location: UK
|
I am pasting the 2 messages side by side from the 2 different environments.
The difference between the 2 environments is - one is running older JMS and application that works, and the other one has a newer version of the JMS code and libraries.
I notice the first message on the left has "L" after the RFH, which the 2nd message doesnt have. Not sure what is the significance of this L.
When I browse on the RFHUtil, I dont notice any difference.
'RFH .......L....' 'RFH ............'
'.... ....' '.... ....'
'....... <mcd><Ms' '....... <mcd><Ms'
'd>jms_bytes</Msd' 'd>jms_bytes</Msd'
'></mcd> ....<jms' '></mcd> ....<jms'
'><Dst>queue:///T' '><Dst>queue://PN'
'O.xxxxxxxxxx</Ds' 'xxxxxxxxxxxxxxxx'
't><Rto>queue://M' 'A</Dst><Rto>queu'
'yyyyyyyyyyyyyyyy' 'e://yyyyyyyyyyyy'
'yyyyyyyyyyyyyyy<' 'yyyyyyyyyyyyyyyy'
'/Rto><Tms>160163' 'RESP</Rto><Tms>1'
'8324822</Tms><Dl' '601640272622</Tm'
'v>2</Dlv></jms> ' 's><Dlv>2</Dlv></'
'...x<usr><Depart' 'jms>...,<usr><Co' |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Oct 05, 2020 9:48 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
The first two and a half lines of your output are not string data. It is important to look at this in hex format (or better still use a tool that can actually format out the MQ headers). Just because these numeric fields at the beginning of the RFH(2) header print out as dots, does not mean that they are the same, it simply means that they are, in both cases, non-printable characters as far as the tool you are using to output the header is concerned.
The RFH2 header will have the following fields:-
| Code: |
struct tagMQRFH2 {
MQCHAR4 StrucId; /* Structure identifier */
MQLONG Version; /* Structure version number */
MQLONG StrucLength; /* Total length of MQRFH2 including all */
/* NameValueLength and NameValueData */
/* fields */
MQLONG Encoding; /* Numeric encoding of data that follows */
/* last NameValueData field */
MQLONG CodedCharSetId; /* Character set identifier of data that */
/* follows last NameValueData field */
MQCHAR8 Format; /* Format name of data that follows last */
/* NameValueData field */
MQLONG Flags; /* Flags */
MQLONG NameValueCCSID; /* Character set identifier of */
/* NameValueData */
}; |
The first four dots will be the Version field which will likely contain 0x00000002 - so that seems fair.
The next four dots, or 3 dots and a letter L will be the Struclength which again will be a number, including the length of the XML data that follows. It is likely no surprise that these are different lengths, and it just happens that one of them is a numeric value that ends up with 0x4C in one of the bytes that results in a string printout of the letter 'L'. This shouldn't concern you.
The rest of the dots could be the same or could be different - please dump in hex so we can see what, if anything, is different.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 06, 2020 7:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| hughson wrote: |
| ... Just because these numeric fields at the beginning of the RFH(2) header print out as dots, does not mean that they are the same, it simply means that they are, in both cases, non-printable characters as far as the tool you are using to output the header is concerned. |
It's quite common (an industry standard, almost) for display utilities to render a non-printable character as a dot. It's also possible that a dot merely represents a dot character in text or a queue name TEST.QUEUE.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Oct 06, 2020 2:32 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2494
Location: Melbourne, Australia
|
| zrux wrote: |
I am pasting the 2 messages side by side from the 2 different environments.
The difference between the 2 environments is - one is running older JMS and application that works, and the other one has a newer version of the JMS code and libraries.
I notice the first message on the left has "L" after the RFH, which the 2nd message doesnt have. Not sure what is the significance of this L.
When I browse on the RFHUtil, I dont notice any difference.
|
As already pointed out, MQ messages may contain byte values that can't be interpreted or displayed by whatever tool is being used to browse the message. The tool may substitute other characters or display unexpected characters because its not using exactly the same character set encoding as the message. This is a common trap.
When in doubt, I use the "amqsbcg" sample program, which displays bytes in hex. This leaves no doubt about the actual value.
_________________
Glenn |
|
| 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
|
|
|
|
