| Author |
Message
|
| nana046 |
 Posted: Thu Oct 18, 2007 3:38 pm Post subject: Message Version is not supported |
 |
|
Newbie
Joined: 03 Aug 2007
Posts: 5
|
Hi All
I am new to MQ. Can any one please help to solve the below problem
At the server side everything is fine but the message is going to Dead Letter Queue the reason is " Message Version 16777216 is not supported".
Thanks
Naveen |
|
| Back to top |
|
 |
| Nigelg |
| Posted: Thu Oct 18, 2007 9:49 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
There is not a lot of context in this question...
16777216 is equivalent to x01000000 on a byte-ordered (Unix) machine (other way round for Windows). This means that the Version in the header in the msg, which should be x00000001, has not been converted when the msg was read.
As to why this is the case, rather more information about the circumstances in which the error occurs is needed.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| JuulV |
| Posted: Sun Oct 21, 2007 4:32 am Post subject: |
|
|
Apprentice
Joined: 05 Sep 2007
Posts: 28
Location: Belgium
|
Looks like you're sending messages between systems that use different encodings (most Unixes/linuxes use "normal ordering" - aka "little endian", i.e. they store the least significant digit of a number in the last byte of the field; mainly Windows use "reverse ordering" - aka "big endian", i.e. they store the most significant digit of a number in the last byte of the field).
Your problem might be solved by allowing the channels to convert the data automatically... but I guess you'll have to read up on the chapters on data conversion in WMQ
_________________
Juul Vanparijs
Senior Developer
Cressida Technology Ltd |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Oct 21, 2007 11:40 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| JuulV wrote: |
Looks like you're sending messages between systems that use different encodings (most Unixes/linuxes use "normal ordering" - aka "little endian", i.e. they store the least significant digit of a number in the last byte of the field; mainly Windows use "reverse ordering" - aka "big endian", i.e. they store the most significant digit of a number in the last byte of the field).
Your problem might be solved by allowing the channels to convert the data automatically... but I guess you'll have to read up on the chapters on data conversion in WMQ |
| nigelg wrote: |
| 16777216 is equivalent to x01000000 on a byte-ordered (Unix) |
Looks to me which ever way you look at it that the decimal value in reverse byte order would be 256 or 0x0100. No amount of conversion could fix that...
Make sure to use the constant literals in your platform and not set the numbers yourself. It is far too easy to make a mistake when you're setting the numbers yourself.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JuulV |
| Posted: Thu Oct 25, 2007 1:26 am Post subject: |
|
|
Apprentice
Joined: 05 Sep 2007
Posts: 28
Location: Belgium
|
@fjb_saper: not quite correct what you're saying... Version is an MQLONG (so a 32-bit signed integer), thus 16777216 is 0x01000000. This is exactly the value that a BIG-ENDIAN machine uses to store the decimal value 1. If this data is sent to LITTLE-ENDIAN system WITH conversion, that system will get 1 or better 0x00000001. But WITHOUT conversion... we get hughe number....
_________________
Juul Vanparijs
Senior Developer
Cressida Technology Ltd |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 25, 2007 2:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| JuulV wrote: |
| @fjb_saper: not quite correct what you're saying... Version is an MQLONG (so a 32-bit signed integer), thus 16777216 is 0x01000000. This is exactly the value that a BIG-ENDIAN machine uses to store the decimal value 1. If this data is sent to LITTLE-ENDIAN system WITH conversion, that system will get 1 or better 0x00000001. But WITHOUT conversion... we get hughe number.... |
Sorry for your math but it should be dec 16 in that case....
What you mean to say is that it does more than just reversing the byte order it also changes the order of the bits inside the byte?
So 0x 0100 0000 does not become 0x 0000 0100 (256 dec) but 0x 0000 0010 (16 dec) ? Still makes no sense unless you use binary instead of hex which would give you 2 dec.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Oct 25, 2007 10:17 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| fjb_saper wrote: |
Sorry for your math but it should be dec 16 in that case....
What you mean to say is that it does more than just reversing the byte order it also changes the order of the bits inside the byte?
So 0x 0100 0000 does not become 0x 0000 0100 (256 dec) but 0x 0000 0010 (16 dec) ? Still makes no sense unless you use binary instead of hex which would give you 2 dec. |
JuuLv is correct. The "flip" is byte oriented.
Consider the 4 bytes as "abcd". When "converted", it becomes dcba. So, 12345678 would become 78563412.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 25, 2007 10:22 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Right, so '01" stays '01'. It doesn't become '10'.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 25, 2007 2:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
| Right, so '01" stays '01'. It doesn't become '10'. |
got it.
Thanks all for setting me straight...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 26, 2007 6:34 am Post subject: |
|
|
Guest
|
What Version did the programmer specify when he/she built the MQMD? Did he/she put a actual numeric value in the field? Or use the MQMD_VERSION_1 type of specification.
The MD is (should be) converted based on CCSIDs as part of the message flow. |
|
| Back to top |
|
|
| JuulV |
| Posted: Fri Oct 26, 2007 3:00 pm Post subject: |
|
|
Apprentice
Joined: 05 Sep 2007
Posts: 28
Location: Belgium
|
Sorry if I have to set some things straight again...
Numeric fields are converted based on ENCODING; only character fields are converted using CCSID (and as far as I know byte fields, E.g. MessageId, are never converted, but please correct me if I'm wrong here).
And... data conversion is never "fully automatic": it happens either
"pseudo automatically" via definition (E.g. define channels with CONVERT(YES) attribute), or
programmatically (E.g. via channel or data conversion exits)
_________________
Juul Vanparijs
Senior Developer
Cressida Technology Ltd |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 26, 2007 4:00 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| JuulV wrote: |
(and as far as I know byte fields, E.g. MessageId, are never converted, but please correct me if I'm wrong here).
|
You are correct.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Oct 27, 2007 8:45 am Post subject: |
|
|
Guest
|
The original post was about an invalid MD Version. Version is an MQLONG field. MQLONG is supported on all platforms, and will not need conversion. If the programmer stuffs an invalid Version number in the Version field of the MD, it will be invalid at the receiving program.
| Quote: |
And... data conversion is never "fully automatic": it happens either
"pseudo automatically" via definition (E.g. define channels with CONVERT(YES) attribute), or programmatically (E.g. via channel or data conversion exits) |
Data conversion is about conversion of the application payload in the message, CONVERT(YES) or MQGMO_CONVERT. The qmgr converts the MD.
From the MQ APG:
When necessary, MCAs convert the message descriptor and header data into the required character set and encoding. Either end of the link (that is, the local MCA or the remote MCA) can do the conversion. |
|
| Back to top |
|
|
|
|
