| Author |
Message
|
| Mut1ey |
 Posted: Tue Jan 08, 2008 3:56 am Post subject: MQRC 2010 on PUT |
 |
|
Acolyte
Joined: 07 Oct 2005
Posts: 74
Location: England
|
A couple of messages exceeeded the client channel maxmsgl so where thrown back to the (.NET) application with mqrc 2010 (MQRC_DATA_LENGTH_ERROR).
There is a concern that one of those two messages was written to the queue, in truncated form, and however I have tested as close to this scenario as possible, and cannot replicate it. The reason the client think it has worked is that both messages have a "random" application key as part of the message data. This key is subsequently used as a backend database entry lookup. The client see a DB record matching that key, indicating that the message did get through.
There are two reasons why I do not want to believe this. Intuitively the atempt to put will fail completely. Part of backend process is to parse the XML message data. If the message was truncated how can the XML remail well-formed? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Jan 08, 2008 7:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The message couldn't have been put to the queue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Mut1ey |
| Posted: Tue Jan 08, 2008 7:19 am Post subject: |
|
|
Acolyte
Joined: 07 Oct 2005
Posts: 74
Location: England
|
| jefflowrey wrote: |
| The message couldn't have been put to the queue. |
Jeff - thanks for the vote of confidence. Can you elaborate on why it could not have been put to the queue?
Also I forgot to mention this is MQ5.3 CSD 11 Windows to AIX. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jan 08, 2008 7:23 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Because a 2010 MQRC is always a "2" for the MQCC.
"2" =
| Quote: |
"The processing of the call did not complete, and the state of the queue manager is normally unchanged; exceptions are specifically noted. Only the CompCode and Reason output parameters have been set; all other parameters are unchanged.
The reason might be a fault in the application program, or it might be a result of some situation external to the program, for example the application's authority might have been revoked. The Reason parameter gives additional information." |
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqsao.doc/csq0519.htm?resultof=%22%32%30%31%30%22%20
There is no exception noted for MQRC 2010, so nothing was changed at the Queue Manager.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jan 08, 2008 7:25 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Either your "random" key is not that random, the client is not giving you all the details, or you have discovered a bug in MQ where 2010 allows a message thru. I doubt there is a 2010 bug.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 08, 2008 7:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Mut1ey wrote: |
| Can you elaborate on why it could not have been put to the queue? |
Because the put call returned a fatal 2010 error?
Or are you seeing the error someplace other than your application?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mut1ey |
| Posted: Wed Jan 09, 2008 2:55 am Post subject: |
|
|
Acolyte
Joined: 07 Oct 2005
Posts: 74
Location: England
|
| PeterPotkay wrote: |
Because a 2010 MQRC is always a "2" for the MQCC.
"2" =
| Quote: |
"The processing of the call did not complete, and the state of the queue manager is normally unchanged; exceptions are specifically noted. Only the CompCode and Reason output parameters have been set; all other parameters are unchanged.
The reason might be a fault in the application program, or it might be a result of some situation external to the program, for example the application's authority might have been revoked. The Reason parameter gives additional information." |
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqsao.doc/csq0519.htm?resultof=%22%32%30%31%30%22%20
There is no exception noted for MQRC 2010, so nothing was changed at the Queue Manager. |
Looking at the manual it states:
2010 (X'07DA')MQRC_DATA_LENGTH_ERROR
Explanation:
The DataLength parameter is not valid. Either the parameter pointer is not valid, or it points to read-only storage. (It is not always possible to detect parameter pointers that are not valid; if not detected, unpredictable results occur.)
This reason can also be returned to an MQ client program on the MQGET, MQPUT, or MQPUT1 call, if the BufferLength parameter exceeds the maximum message size that was negotiated for the client channel.
Completion Code:
MQCC_FAILED
Programmer Response:
Correct the parameter.
If the error occurs for an MQ client program, also check that the maximum message size for the channel is big enough to accommodate the message being sent; if it is not big enough, increase the maximum message size for the channel.
-------
What concerns me is the explanation section: "(It is not always possible to detect parameter pointers that are not valid; if not detected, unpredictable results occur.)" Does this imply that actually a message may have been written? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 09, 2008 3:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Mut1ey wrote: |
| Does this imply that actually a message may have been written? |
I would say not, because a client connection is syncronous so if the client call fails with a 2010 (or other fatal error) nothing has actually happened.
IMHO the explaination is a bit of IBM catch-all - translates as "if your code has done something whacky with the pointers we may do something whacky as well". I'm reminded of a phrase commonly seen in old mainframe manuals when talking about various invalid opperations or calls - "The results of this are undefined". Accepted translation was "Something bad will happen but we're damned if we know what. Accept you're doomed and exit."
I'd still be surprised if the "something whacky" included firing random bits of message down the connection.
With luck a passing IBMer will offer a more definative insight.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
