| Author |
Message
|
| bruce2359 |
 Posted: Tue Oct 09, 2012 5:45 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
A best-practice is for the developer to initialize all of the app data portion of the input buffer to nulls or blanks BEFORE the get. If the next get call fails, it will be really easy to recognize NO data vs. corrupted data.
_________________
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 |
|
 |
| fjb_saper |
| Posted: Tue Oct 09, 2012 7:17 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bruce2359 wrote: |
| A best-practice is for the developer to initialize all of the app data portion of the input buffer to nulls or blanks BEFORE the get. If the next get call fails, it will be really easy to recognize NO data vs. corrupted data. |
Not quite getting you. Would he not have received the truncated error?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 09, 2012 7:20 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| bruce2359 wrote: |
| A best-practice is for the developer to initialize all of the app data portion of the input buffer to nulls or blanks BEFORE the get. If the next get call fails, it will be really easy to recognize NO data vs. corrupted data. |
Not quite getting you. Would he not have received the truncated error? |
While  , it's still recommended practice to provide an empty buffer, *as well as* recommended practice to ALWAYS check the MQRC/CC before accessing the buffer. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 09, 2012 8:17 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| fjb_saper wrote: |
| bruce2359 wrote: |
| A best-practice is for the developer to initialize all of the app data portion of the input buffer to nulls or blanks BEFORE the get. If the next get call fails, it will be really easy to recognize NO data vs. corrupted data. |
Not quite getting you. Would he not have received the truncated error? |
He'd get the msg too big error, but no data would be in the buffer from prior successful gets.
_________________
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 |
|
|
| sumithar |
| Posted: Tue Oct 09, 2012 9:41 am Post subject: |
|
|
Apprentice
Joined: 13 Jun 2008
Posts: 47
|
| bruce2359 wrote: |
| sumithar wrote: |
OK, so I got to the bottom of this. What happens is that if the message read from the queue is greater than the specified length in the variable buf-len then somehow the MQGMO-CONVERT option gets "corrupted", i.e. the conversion doesn't happen anymore.
|
Nothing got corrupted.
Unless the accept-truncated-message GMO is specified, the get call fails when MSG length exceeds buffer size. If the call fails, no MSG is delivered, therefore no message can be converted.
. |
Sorry I didn't make myself clear.
I'm checking the completion code and have this in place
| Code: |
****2080 - MESSAGE LENGTH TOO LARGE **********
IF WS-MQ-RC = (2080 OR 2010)
ADD 1 TO WS-QUEUE-GET-CTR
MOVE WS-MQ-RC TO AUDIT-ERROR-CODE
PERFORM 2100-PROCESS-LENGTH-ERR THRU 2100-EXIT
GO TO 2000-EXIT
END-IF |
.
I can see that I'm getting a 2080 in the situation I've specified. What I do then is issue another MQGET call (in the 2100- paragraph) this time with a large enough buffer size and then write out the errant message into an error file which I can look at later on.
What I'm trying to say is that when the MQGET encounters an error due to the length, the subsequent MQGETs are being impacted even if messages are the right length in the sense that they are not being converted from ASCII to EBCDIC. This is what I termed as the MQGMO-CONVERT getting corrupted.
I wonder if having the Accpeted Truncated message option in GMO will alleviate that issue.
Also, I'm initializing the buffer into which I am GETting the data before each GET. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Tue Oct 09, 2012 2:11 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| sumithar wrote: |
| Code: |
****2080 - MESSAGE LENGTH TOO LARGE **********
IF WS-MQ-RC = (2080 OR 2010) |
|
Hopefully, the application is also checking for any other non-zero MQRC.
| sumithar wrote: |
| Also, I'm initializing the buffer into which I am GETting the data before each GET. |
What about also initializing the MQMD and GMO parameters before each GET? Particularly after a failure due to MQRC 2080? |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Oct 09, 2012 2:58 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| A best-practice is for the developer to initialize all of the app data portion of the input buffer to nulls or blanks BEFORE the get. If the next get call fails, it will be really easy to recognize NO data vs. corrupted data. |
It's really easy to recognise a nonzero completion code / reason code. Why waste CPU cycles clearing out a buffer before an MQGET? Sure it can't do any harm to your data, but I'd say think twice about the energy and performance implications of writing code like that. IMHO.
Last edited by mvic on Tue Oct 09, 2012 3:03 pm; edited 1 time in total |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Oct 09, 2012 2:59 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqjeff wrote: |
| While , it's still recommended practice to provide an empty buffer, *as well as* recommended practice to ALWAYS check the MQRC/CC before accessing the buffer. |
I'd go for the second half of that, not the first half. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Oct 09, 2012 3:02 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| sumithar wrote: |
| What I'm trying to say is that when the MQGET encounters an error due to the length, the subsequent MQGETs are being impacted even if messages are the right length in the sense that they are not being converted from ASCII to EBCDIC. This is what I termed as the MQGMO-CONVERT getting corrupted. |
Sounds wrong. Did you open a PMR with IBM?
| Quote: |
| I wonder if having the Accpeted Truncated message option in GMO will alleviate that issue. |
Only tell MQ you will accept a truncated message if you really want to accept a truncated message. Do you want that?
| Quote: |
| Also, I'm initializing the buffer into which I am GETting the data before each GET. |
Don't bother. See my previous posts. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 09, 2012 3:17 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| sumithar wrote: |
What I'm trying to say is that when the MQGET encounters an error due to the length, the subsequent MQGETs are being impacted even if messages are the right length in the sense that they are not being converted from ASCII to EBCDIC. This is what I termed as the MQGMO-CONVERT getting corrupted.
I wonder if having the Accpeted Truncated message option in GMO will alleviate that issue.
Also, I'm initializing the buffer into which I am GETting the data before each GET. |
So are you setting the options before every get?
Are you sure that in your loop you are not just dropping the convert option when you hit the error? Hence subsequent messages without convert?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Oct 09, 2012 3:20 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| fjb_saper wrote: |
So are you setting the options before every get?
Are you sure that in your loop you are not just dropping the convert option when you hit the error? Hence subsequent messages without convert? |
Best suggestion so far. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 09, 2012 3:49 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The resolution for Message-too-big-for-buffer error is to increase buffer length to.a size larger than your longest message, recompile.
_________________
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 |
|
|
| bruce2359 |
| Posted: Tue Oct 09, 2012 4:09 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
One of the items output from the mqget call is the actual length of the message in the queue. This is especially useful for the message-too-big-for-buffer failure.
_________________
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 |
|
|
| mvic |
| Posted: Wed Oct 10, 2012 5:48 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| The resolution for Message-too-big-for-buffer error is to increase buffer length to.a size larger than your longest message, recompile. |
I do not agree. Yes you need a bigger buffer, but there is no need to rebuild your application each time! Just free the buffer you have allocated, and ask the runtime library for a bigger buffer.
Having said that, I am not sure what runtime facilities are available in the language the OP is using. I was thinking about the C runtime when I made my comments. |
|
| Back to top |
|
|
| sumithar |
| Posted: Wed Oct 10, 2012 7:31 am Post subject: |
|
|
Apprentice
Joined: 13 Jun 2008
Posts: 47
|
| fjb_saper wrote: |
| sumithar wrote: |
What I'm trying to say is that when the MQGET encounters an error due to the length, the subsequent MQGETs are being impacted even if messages are the right length in the sense that they are not being converted from ASCII to EBCDIC. This is what I termed as the MQGMO-CONVERT getting corrupted.
I wonder if having the Accpeted Truncated message option in GMO will alleviate that issue.
Also, I'm initializing the buffer into which I am GETting the data before each GET. |
So are you setting the options before every get?
Are you sure that in your loop you are not just dropping the convert option when you hit the error? Hence subsequent messages without convert? |
Yes, this is the full sequence.
| Code: |
2000-PROCESS-QUEUE-MESSAGES.
-----------------------------*
INITIALIZE WS-RRBF362-LAYOUT.
MOVE MQMI-NONE TO MQMD-MSGID.
MOVE MQCI-NONE TO MQMD-CORRELID.
COMPUTE MQGMO-OPTIONS = MQGMO-NONE +
MQGMO-NO-WAIT +
MQGMO-SYNCPOINT +
MQGMO-CONVERT +
MQGMO-FAIL-IF-QUIESCING
CALL MQGET USING WS-MQ-HCONN
WS-MQ-HOBJ
MQMD
MQGMO
WS-MQ-BUF-LEN
WS-RRBF362-LAYOUT
WS-MQ-DATA-LEN
WS-MQ-CC
WS-MQ-RC. |
I understand now that initialize statement is not strictly necessary...
What I could potentially do is set the value of WS-MQ-BUF-LEN to be very large. I could define a constant for what I expect the actual max message length to be, let's say WS-MAX-MSG-LEN or some such thing.
Then when I GET i won't get 2080 error.
I can then compare WS-MQ-DATA-LEN (the actual length of retrieved message) with WS-MAX-MSG-LEN and if greater treat it as a length error and write out into error file.
This being COBOL it's not as straightforward as C to allocate memory dynamically (at least I've never done it!)
I can talk to the SYSPROG people about the PMR. |
|
| Back to top |
|
|
|
|
