If you have trouble remembering what messages are included and excluded from the CurrentQDepth of a queue, the easy way to remember is that we expect all units of work to commit. So it goes down as soon as you do an MQGET, and it goes up as soon as you do an MQPUT.
The CurrentQDepth documentation in the Application Programming Reference does describe this but to my mind it reads like a set of rules to be learned. I remember things much better when given a model that I can understand.
CurrentQDepth is the number of messages currently on the queue. It is incremented during an MQPUT call, and during backout of an MQGET call. It is decremented during a nonbrowse MQGET call, and during backout of an MQPUT call. The effect of this is that the count includes messages that have been put on the queue within a unit of work, but that have not yet been committed, even though they are not eligible to be retrieved by the MQGET call. Similarly, it excludes messages that have been retrieved within a unit of work using the MQGET call, but that have yet to be committed.
The count also includes messages that have passed their expiry time but have not yet been discarded, although these messages are not eligible to be retrieved. See MQMD Expiry for more information.
Unit-of-work processing and the segmentation of messages can both cause CurrentQDepth to exceed MaxQDepth. However, this does not affect the retrievability of the messages; all messages on the queue can be retrieved using the MQGET call in the normal way.