| Author |
Message
|
| sandeepp@cislworld.com |
 Posted: Thu Apr 12, 2007 5:58 am Post subject: Error 2033 |
 |
|
Newbie
Joined: 12 Apr 2007
Posts: 6
|
Can any one let me know why 2033 occurs i know that if there are no messages i get it.
I have seen another message for this
2033 The field name has a default value not within the range of its include list values.
The indicated field has both a DEFAULT attribute and an INCLUDE attribute, but they disagree. The default value is not one that is allowed. Modify one of the attributes, and recompile the form specification.
can any one one explain what this means exactly......
[/b] |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Apr 12, 2007 6:02 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
That's not an MQRC 2033, that's some other program's error number that happens to also be 2033.
An MQ REASON CODE # 2033, MQRC_NO_MSG_AVAILABLE is only returned when either the queue has a qdepth of 0 or when there were no messages on the queue that matched the options passed to the Get.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 12, 2007 1:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
That's not an MQRC 2033, that's some other program's error number that happens to also be 2033.
An MQ REASON CODE # 2033, MQRC_NO_MSG_AVAILABLE is only returned when either the queue has a qdepth of 0 or when there were no messages on the queue that matched the options passed to the Get. |
Let us rectify the qdepth of 0 to no more messages on the queue in a gettable state. The qdepth need not be 0.
I know Jeff didn't do it on purpose...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 12, 2007 1:45 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Eh. I commented on that situation in the OTHER thread.
But, yes. The qdepth could be full, and no program could be able to get anything other than a 2033.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| EricCox |
| Posted: Wed Feb 04, 2015 12:13 pm Post subject: You mentioned |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
Jeff Lowrey,
You mention
| Quote: |
'But, yes. The qdepth could be full, and no program could be able to get anything other than a 2033. |
Could you point me to that thread and/or explain what you mean here.
We seem to be experiencing just this on a service unexpectedly all of a sudden.
Thanks,
Eric |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 04, 2015 12:49 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If the MQGET is issued with no matching options, and all of the messages on the queue have been put in a transaction that has not been committed - the messages are uncommited - then the get will return MQRC 2033.
Likewise, if the app doing the GET has done a get on all messages in the queue, in a unit of work, but not committed that unit of work, then all of the messages will be unavailable for further getting.
If you are using Browse, instead of plain Get, then there's an entirely different set of reasons why you could get a 2033 with qdepth>0. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Feb 04, 2015 1:53 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Or you are specifying particular Message ID and /or CorrelID values on the MQGET, telling MQ you want only a message that matches, but the queue is full of messages none of which match the criteria you provided.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| EricCox |
| Posted: Wed Feb 04, 2015 5:36 pm Post subject: MQRC 2033 |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
We are getting MQRC 2033 at this time.
We are experiencing this on V8.0.0.2 using the Aggregate Control, Aggregate Request and Aggregate Reply Nodes.
The MQRC 2033 is forcing an HTTP Input Node timeout and we are getting an ugly Service Consumer experience.
I need to identify what the source of the 2033 failures is.
We know queue depth is building on the affected STATE queue but cannot pinpoint the reason why.
The AggregateReply Node has control and fails to match but I'm not sure why. Either the message is not there or it cannot find it for some reason.
2033 is pretty clear. It is not a MQ Get error it is a match not found error.
All your help and ideas are great and much appreciated.
Eric |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 05, 2015 5:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You might double-check whether you need the AggregateControl node or not.
Also, the AggregateReply node expects that messages will come back with the msgid of the message passed to the AggregateRequest node has been copied into the correlId of the message passed to the AggregateReply node.
I believe there's a sample for using aggregation with HTTP Input, but maybe I'm wrong.
Also, you probably need to make sure that the message going to the AggregateRequest node has an MQMD on it and not an HTTP Header. |
|
| Back to top |
|
|
| EricCox |
| Posted: Thu Feb 05, 2015 5:42 am Post subject: Looking |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
Jeff,
Thanks. I'm looking at all of that on this service. I built a Broker Web Service with no Aggregate Nodes and MQ to COBOL on the backend.
That service has zero defects, so it is unclear why this service is being affected by 2033. I have another pure MQ service using Aggregate Nodes doing a million transactions a day...also with no defects.
Regards,
Eric |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 05, 2015 6:08 am Post subject: Re: Looking |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| EricCox wrote: |
Jeff,
Thanks. I'm looking at all of that on this service. I built a Broker Web Service with no Aggregate Nodes and MQ to COBOL on the backend.
That service has zero defects, so it is unclear why this service is being affected by 2033. I have another pure MQ service using Aggregate Nodes doing a million transactions a day...also with no defects.
Regards,
Eric |
Check your aggregate requests. Make sure each branch of the aggregate request sends a message with a correlationid set to MQCI_NONE, a message id set to MQMI_NONE, create new message id set on the MQOutput node.
Check your service replying to the aggregation. Verify they are all returning the messageid in the correlationid field.
So for each branch of the aggregation you have a different msgid on output and a different correlation id on reply...
Note you may have to add another branch to the aggregation to pass the original MQMD to the fan-in part.
How many replies are you expecting on a single branch? If the answer is more than one you may have to add a collection node before forwarding to the aggregation.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
