| Author |
Message
|
| Vitor |
 Posted: Wed Sep 09, 2015 9:30 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| yashgt wrote: |
| Agreed that we do not need both MQMI_NONE and MQPMO_NEW_MSG_ID |
Have you tried it with only one yet? 
| yashgt wrote: |
| The Message ID is obtained only After the MQPUT. |
So the message id on the message in the target queue is different from the message id obtained after the put (as my most worthy associate points out, the one logged before the put is either empty or the last one used)?
Does the message id on the message in the target queue have the same format as the logged one, i.e. is it generated by a queue manager? If so, what queue manager name is used?
Are there any channel exits or other intermediate items that could be amending this value?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Sep 09, 2015 10:29 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Have you got pub/sub in the mix?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 09, 2015 8:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
| mqjeff wrote: |
| Passing through a channel should never alter the msgid. |
 however the OP only talks about source and destination, not at all about what is in-between. There could be pub/sub, there could be a broker setting it's own message-id, there could be some app moving message from queue a to queue b.... etc...
As I have never seen the messageId change just because you crossed a channel (hopefully there is no exit changing that on the OP's qmgr) I assumed (yes I know... Dark Territories...) that there must be something in between source and destination manipulating the message...
A message route trace request could probably tell us whether the message goes to the destination or somewhere else... and what routes are involved... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| yashgt |
| Posted: Thu Sep 10, 2015 3:25 am Post subject: |
|
|
Apprentice
Joined: 11 Nov 2014
Posts: 38
|
This is a pure Point to Point communication with no API exit involved.
Message ID array in writer application : 65 77 81 32 68 69 86 50 46 74 86 46 67 79 82 69 122 97 -52 85 32 -33 32 32
Message ID in writer in Hex : 41 4d 51 20 44 45 56 32 2e 4a 56 2e 43 4f 52 45 7a 61 cc 55 20 df 20 20
Message ID on Local Queue in Explorer : 41 4D 51 20 44 45 56 32 2E 50 47 2E 4D 51 4D 20 96 ED D2 55 12 89 0A 20
Received Message ID array : 65 77 81 32 68 69 86 50 46 80 71 46 77 81 77 32 -106 -19 -46 85 17 -119 10 32
Received msg ID HEX : 41 4d 51 20 44 45 56 32 2e 50 47 2e 4d 51 4d 20 96 ed d2 55 11 89 0a 20
Note the bytes have negative decimal values.
We obtain the string representation by converting every byte to 2 hex characters. Agreed that this is wrong for a negative byte. -52 in reality in FFFFFCC in Hex.
Yet, the Binary Message ID on consumer end is different than the Binary Message ID on the Producer end.
What translation does the Explorer apply to convert the negative bytes to Hex characters? -106 is shown as 96. What algorithm is applied here? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 10, 2015 4:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| yashgt wrote: |
Message ID in writer in Hex
| Code: |
| 41 4d 51 20 44 45 56 32 2e 4a 56 2e 43 4f 52 45 7a 61 cc 55 20 df 20 20 |
Message ID on Local Queue in Explorer
| Code: |
| 41 4D 51 20 44 45 56 32 2E 50 47 2E 4D 51 4D 20 96 ED D2 55 12 89 0A 20 |
Received msg ID HEX
| Code: |
| 41 4d 51 20 44 45 56 32 2e 50 47 2e 4d 51 4d 20 96 ed d2 55 11 89 0a 20 |
|
What strikes me is that, apart from one byte that could be a transcription error, the last 2 are the same and all three look to be generated from the same queue manager root. Are you entirely sure you're looking at the same messages?
| Shyam Kishor wrote: |
| Note the bytes have negative decimal values. |
No they don't. They don't have any values.
[quote="Shyam Kishor"]We obtain the string representation by converting every byte to 2 hex characters. Agreed that this is wrong for a negative byte. -52 in reality in FFFFFCC in Hex.
| Shyam Kishor wrote: |
id is a byte array not any kind of binary representation. The id is not a series of values but a unique pseudo-random identifier.
[quote="Shyam Kishor"]Yet, the Binary Message ID on consumer end is different than the Binary Message ID on the Producer end.
What translation does the Explorer apply to convert the negative bytes to Hex characters? -106 is shown as 96. What algorithm is applied here? |
None. The bytes are simply displayed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Sep 10, 2015 4:30 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
From what I observe, the MessageId embeds part of the queue manager name within positions 5-16. The three message ids that you posted would resolve to the following in ASCII:
414d5120444556322e4a562e434f52457a61cc5520df2020
AMQ DEV2.JV.COREzaÌU ß
414D5120444556322E50472E4D514D2096EDD25512890A20
AMQ DEV2.PG.MQM –ÃÃ’U‰
414d5120444556322e50472e4d514d2096edd25511890a20
AMQ DEV2.PG.MQM –ÃÃ’U‰
Message Ids two and three seem to be off by one byte in position 21. Maybe a typo?
It looks like you are dealing with two different queue managers there, and I would question if this is really point to point. An MQ trace might help you to get to the bottom of it.
The MsgId is an array of 24 unsigned chars. There is no concept of negative numbers in this array. Each byte is an unsigned char.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 10, 2015 4:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| tczielke wrote: |
| Each byte is an unsigned char. |
Unsigned byte - or just raw byte or whatever term.
Not a character.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Sep 10, 2015 4:35 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
| yashgt wrote: |
This is a pure Point to Point communication with no API exit involved.
Message ID array in writer application : 65 77 81 32 68 69 86 50 46 74 86 46 67 79 82 69 122 97 -52 85 32 -33 32 32
Message ID in writer in Hex : 41 4d 51 20 44 45 56 32 2e 4a 56 2e 43 4f 52 45 7a 61 cc 55 20 df 20 20
Message ID on Local Queue in Explorer : 41 4D 51 20 44 45 56 32 2E 50 47 2E 4D 51 4D 20 96 ED D2 55 12 89 0A 20
Received Message ID array : 65 77 81 32 68 69 86 50 46 80 71 46 77 81 77 32 -106 -19 -46 85 17 -119 10 32
Received msg ID HEX : 41 4d 51 20 44 45 56 32 2e 50 47 2e 4d 51 4d 20 96 ed d2 55 11 89 0a 20 |
At least MQ Explorer and received msg ID Hex agree. This tells me that the error is somewhere in your app.
| yashgt wrote: |
Note the bytes have negative decimal values.
We obtain the string representation by converting every byte to 2 hex characters. Agreed that this is wrong for a negative byte. -52 in reality in FFFFFCC in Hex. |
Oh so wrong... your are looking at a word or dword here not a byte.
Any value above 7F is a negative number so at the byte level -52 is CC
| yashgt wrote: |
Yet, the Binary Message ID on consumer end is different than the Binary Message ID on the Producer end.
What translation does the Explorer apply to convert the negative bytes to Hex characters? -106 is shown as 96. What algorithm is applied here? |
No algorithm just standard hex.
-106 dec = 96 hex (256 -106 = 150 / 16 = 96)
Remember that FF is -1 so that would be 256 -1 = 255 / 16 = FF
Any value over 7F (127 decimal) is negative. 80 hex = 128 -256 => -128
The values of a signed byte range from -128 to 127 and this does cover 256 (including 0) values...
If you only want positive values you have to consider a WORD where the first or last 2 bytes (depending on little-endian, big-endian) are 00... so 00FF or FF00 has a value of 255...
Hope this little hex math helped...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 10, 2015 4:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you only want positive numbers, you can't let the qmgr generate the MsgID...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Sep 10, 2015 4:58 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| mqjeff wrote: |
| tczielke wrote: |
| Each byte is an unsigned char. |
Unsigned byte - or just raw byte or whatever term.
Not a character. |
The cmqc.h defines the MsgId as an MQBYTE24 which resolves to an unsigned char array of 24. Therefore, there is no concept of a negative number here. If something is displaying the byte as a negative number, that something is probably interpreting the byte as a signed char.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 10, 2015 5:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| tczielke wrote: |
| mqjeff wrote: |
| tczielke wrote: |
| Each byte is an unsigned char. |
Unsigned byte - or just raw byte or whatever term.
Not a character. |
The cmqc.h defines the MsgId as an MQBYTE24 which resolves to an unsigned char array of 24. Therefore, there is no concept of a negative number here. If something is displaying the byte as a negative number, that something is probably interpreting the byte as a signed char. |
Or a signed int. But an MQBYTE24 is only an unsigned char in the C API. You have to use a byte[] to work with it in Java.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Sep 10, 2015 5:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
From IBM's public website http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.0.1/com.ibm.mq.csqzak.doc/fr10260_.htm
| Quote: |
MQBYTE - byte
The MQBYTE data type represents a single byte of data. No particular interpretation is placed on the byte; it is treated as a string of bits, and not as a binary number or character. No special alignment is required.
When MQBYTE data is sent between queue managers that use different character sets or encodings, the MQBYTE data is not converted in any way. The MsgId and CorrelId fields in the MQMD structure are like this. |
Open a PMR
_________________
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 |
|
|
| tczielke |
| Posted: Thu Sep 10, 2015 5:18 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| mqjeff wrote: |
| tczielke wrote: |
| mqjeff wrote: |
| tczielke wrote: |
| Each byte is an unsigned char. |
Unsigned byte - or just raw byte or whatever term.
Not a character. |
The cmqc.h defines the MsgId as an MQBYTE24 which resolves to an unsigned char array of 24. Therefore, there is no concept of a negative number here. If something is displaying the byte as a negative number, that something is probably interpreting the byte as a signed char. |
Or a signed int. But an MQBYTE24 is only an unsigned char in the C API. You have to use a byte[] to work with it in Java. |
It looks like in Java there isn't a primitive type that corresponds to the unsigned char in C. The closest one I see is the byte, like you mentioned which is the following:
byte 8 bits -128 - +127
So if a Java application is trying to display individual bytes in the MsgId using a byte primitive, it looks like it would show a negative number for any byte >= 80.
A little deficient on the Java side to me, if that is the case.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 10, 2015 5:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| tczielke wrote: |
It looks like in Java there isn't a primitive type that corresponds to the unsigned char in C. The closest one I see is the byte, like you mentioned which is the following:
byte 8 bits -128 - +127
So if a Java application is trying to display individual bytes in the MsgId using a byte primitive, it looks like it would show a negative number for any byte >= 80.
A little deficient on the Java side to me, if that is the case. |
Again, the MQ Java API (not the JMS API) says that the MsgID and CorrelID are byte arrays - byte[]. And, yeah, a Java byte is an 8 bit byte, not anything bigger. But unsigned, so you get 0-254, not -128 to +127.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Sep 10, 2015 6:02 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
Even more deficient in java is the decode function of Byte, Integer, etc...
It only accepts positive values...
So if you have a byte that's above 7F you get a number format exception...
The answer is use the Integer.decode function and cast to byte...
For extracting the hex string you can use shift and bit masks so that you never have a value over 15...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
