I agree with the answer Enio has posted - likely an uncommitted message.
I would also like to offer that this is not an appropriate way for an application to operate. An application should not query the current depth of a queue to decide whether or not to attempt to get a message from the queue. The MQGET call already has a way to tell you that there is no message should you issue an MQGET call when the current depth is zero. The way it does this is to return MQRC_NO_MSG_AVAILABLE (2033). It is expected that the application should catch that return code and behave appropriately.
There are many reasons why an application should not be query the current depth before deciding to attempt to get a message:
- The current depth will include uncommitted messages (as already noted by Enio)
- The current depth may change a nano-second after you inquire what it is, resulting in a delay before your application realises it needs to get a message
- If there is more than one application instance reading from the queue (a very common model) then another instance may get the message before you do
- You are sending a command to the command server every second - that's at least 2 messages you are causing in the system every second before you even attempt to process your actual message off your queue, instead of just making an MQGET call to get your message
Your question indicates that you are not handling the reason code MQRC_NO_MSG_AVAILABLE. You should fix that. Once that is done, you should remove the code that inquires the current depth and instead put whatever processing was done if the current depth was zero into the catch for reason code MQRC_NO_MSG_AVAILABLE.
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
------------------------------