| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQRC 2080 and gibberish data when using MQ Explorer |
« View previous topic :: View next topic » |
| Author |
Message
|
| sumithar |
 Posted: Wed Dec 09, 2020 1:48 pm Post subject: MQRC 2080 and gibberish data when using MQ Explorer |
 |
|
Apprentice
Joined: 13 Jun 2008
Posts: 47
|
Hi
I am working with a Cobol batch program on zOS. I am testing what happens if the message length exceeds the buffer specified, i.e. if I get a RC 2080.
The queue is also on zOS.
In setting up the test data I found an oddity.
Scenario 1
I use File Manager on zOS to put a correct length message this queue. The actual content of the message is retrieved by the MQGET. The value in MQMD-ENCODING is 785 and MQMD-CODEDCHARSETID is 500.
Scenario 2
I use File Manager on zOS to put a "long" test messages on this queue. The actual content of the message is retrieved by the MQGET. The value in MQMD-ENCODING is 785 and MQMD-CODEDCHARSETID is 500. (Of course MQRC is 2080 and I handle this)
Scenario 3
I use MQ Explorer on Win 10 to put a correct length message on this queue. The actual content of the message is retrieved by the MQGET. The value in MQMD-ENCODING is 785 and MQMD-CODEDCHARSETID is 500.
Scenario 4
I use MQ Explorer on Win 10 to put a "long" message in this queue. Some gibberish is retrieved by the MQGET. The value in MQMD-ENCODING is 546 and MQMD-CODEDCHARSETID is 1208.
I am puzzled by the difference between scenario 3 and scenario 4. Would you be able to help me understand?
I will admit I haven't done much reading into what encoding and CCSID are but I can see that when I put messages via MQ Explorer, regardless of the length, the values are 585 and 1208 and when I put them via File Manager on zOS, they are 785 and 500. |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Wed Dec 09, 2020 2:17 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Hi Sumithar,
| Quote: |
| I will admit I haven't done much reading into what encoding and CCSID are but I can see that when I put messages via MQ Explorer, regardless of the length, the values are 585 and 1208 and when I put them via File Manager on zOS, they are 785 and 500. |
Encoding indicates the representation of numbers that are that are stored as binary (integers, packed decimal, float). If you are only using pure text message data, it will be irrelevant to your app.
CCSID indicates the code page of text in the message data. 500 is International EBCDIC, which is very common on zOS.
1208 is UTF-8, which is reasonably common on other platforms. The first 128 code points correspond to ASCII codes.
| Quote: |
In setting up the test data I found an oddity.
Scenario 1
I use File Manager on zOS to put a correct length message this queue. The actual content of the message is retrieved by the MQGET. The value in MQMD-ENCODING is 785 and MQMD-CODEDCHARSETID is 500.
Scenario 2
I use File Manager on zOS to put a "long" test messages on this queue. The actual content of the message is retrieved by the MQGET. The value in MQMD-ENCODING is 785 and MQMD-CODEDCHARSETID is 500. (Of course MQRC is 2080 and I handle this)
Scenario 3
I use MQ Explorer on Win 10 to put a correct length message on this queue. The actual content of the message is retrieved by the MQGET. The value in MQMD-ENCODING is 785 and MQMD-CODEDCHARSETID is 500.
Scenario 4
I use MQ Explorer on Win 10 to put a "long" message in this queue. Some gibberish is retrieved by the MQGET. The value in MQMD-ENCODING is 546 and MQMD-CODEDCHARSETID is 1208.
I am puzzled by the difference between scenario 3 and scenario 4. Would you be able to help me understand? |
When you MQGET a message and specify MQGMO_CONVERT and the message is in MQSTR format, MQ will convert the data to your local code page (500) in your buffer. If the message is too long for the buffer, and MQGMO_ACCEPT_TRUNCATED_MSG was not specified, MQ returns the MQRC_TRUNCATED_MSG_FAILED reason code 2080. For this failure, the message is not removed from the queue, and you shouldn't be looking at the data.
_________________
Glenn |
|
| Back to top |
|
|
| sumithar |
| Posted: Thu Dec 10, 2020 8:05 am Post subject: |
|
|
Apprentice
Joined: 13 Jun 2008
Posts: 47
|
Thanks for that explanation of CCSID and encoding!
So the crux of the matter is, if the RC of MQGET is not 0, then the retrieved message has no "sanctity". That makes a lot of sense.
In scenario 1 and 2 since I added the message to the queue in a zOS environment and did MQGET also in a zOS environment, the MQGMO-CONVERT was not really relevant.
in Scenario 3, the MQGMO-CONVERT did its "magic" since the RC is 0 and Scenario 4 since RC is not 0, MQGMO-CONVERT didn't do any conversion.
Nice explanation, thanks again. |
|
| 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
|
|
|
|
