You are currently browsing Russell Finn’s articles.

It seems that not everyone knows this and it’s well worth knowing.

The default preferences for WMQ Explorer are to show progress dialogs for a minimum of 3 seconds. For example, when deleting a queue there is a progress dialog displayed saying “Deleting the object named MY_QUEUE”. You will always be waiting for 3 seconds before getting the “The object ‘MY_QUEUE’ was deleted successfully” message, even though the command itself was actioned in less than a second.

Given that you just asked for the queue to be deleted you might not want to artificially wait for 3 seconds.

Screenshot of the main WMQ Explorer preferences screenYou can change the minimum display time down to zero. This makes the Explorer seem much more responsive.

Choose Windows -> Preferences and click on the “WebSphere MQ Explorer” folder to bring up the panel below.

Change the value from 3 to 0.

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.

An MQ message has a priority associated with it. Normally, the value specified is between 0 (the minimum) and 9 (the maximum). However, it is possible to specify a value greater than 9.

An MQPUT() call specifying MQMD.Priority=77 will complete with the MQRC_PRIORITY_EXCEEDS_MAXIMUM warning reason code.

The message is treated by MQ as a priority 9 message, but the MQMD.Priority field is set to the supplied value, 77 .

If you consider another messaging provider product, A, whose priorities range from 0 to 99, then the MQ behaviour would allow MQ to preserve the original priority whilst transporting a message from one instance of A to another instance of A.

Follow

Get every new post delivered to your Inbox.

Join 33 other followers