Is there a way to delete a single message from an MQ queue?

IBM Support recently released a Support Doc which posed the question:-

Question

Is there a way to delete a single message from an MQ queue (arbitrary position in the queue)?

The document described a couple of options. In this post we cover how to do this using MQGem tools as several of them offer this capability. Open up the twisty for each tool to read how to do this.

Using MO71

In MO71 you can browse a list of messages on a queue, then from that list, select an individual message (or multiple messages if you need to). Then press the Delete button, or select Delete from the right-mouse button context menu and the selected message(s) will be deleted.

MO71 uses the MQ facility, get by message token, so only the exact message(s) that you select from the list will be deleted. While the position of the message on the queue is shown, this is not used for deletion and neither is Message Id, since there is no guarantee that this will be unique either. Each message on a queue is guaranteed to have a unique Message Token.

Alternatively, you can double click on a message from the list, to view the whole message individually. Then from that display, having checked all the details, and made sure it is the message you want to delete, you can press the Delete button, or select Delete from the context menu.

Take care when deleting messages from a production queue manager. Consider that it might be safer to Move the message(s) to a separate holding queue, just in case the message proves to be important after all. MO71 makes it simple to Move messages too. Just fill in the holding queue name, and then press the Move, rather than Delete, button.

Using the Q program

To delete a single message from an MQ queue using the Q program, you should first discover the message ID of the message you wish to delete, to ensure you are addressing the correct message that you intend to delete. Do this by displaying the messages on the queue like this:-

q -m MQG1 -i Q1 -dd

This will browse (-i) the messages on the queue and display the MQMD after the MQGET (-dd) allowing you to see the Message ID of each message on the queue. You will see output like this for each message:-

==============================================================
----- MQMD after MQGET -----
[  324 bytes] Message Descriptor (MQMD)
Report       :00000000
Message Type :8 (Datagram)
Format       :'MQSTR   ' (String)
Priority     :0 (Lowest)
Persistence  :0 (Not Persistent)
Message Id   :414D51204D514731202020202020202099FA4A6020B74B02
              A M Q   M Q G 1                 . ú J `   · K .
ReplyToQ     :'                                                '
ReplyToQMgr  :'MQG1                                            '

Now you can copy that message ID and use it on another invocation of the Q program to delete that specific message from the queue.

q -m MQG1 -IQ1 -gxm:414D51204D514731202020202020202099FA4A6020B74B02

Bear in mind that message IDs are likely to be unique, but this is not guaranteed. It would be safer to move the messages to a separate queue, before deletion. This is simple to achieve using a command like the following:

q -m MQG1 -IQ1 -o HOLDING.Q 
-gxm:414D51204D514731202020202020202099FA4A6020B74B02
Using QLOAD

If you have already browsed the queue contents and output them to a file, you can find the message Id of the specific message you are attempting to address by looking for the Message Descriptor attribute “MSI”. Here is a snippet from a QLOAD file to show an example.

A FMT MQSTR
A PRI 0
A PER 0
A MSI 414D51204D514731202020202020202099FA4A6020B74B02
A COI 000000000000000000000000000000000000000000000000

Now you can copy that message ID and use it on another invocation of the QLOAD program to delete that specific message from the queue. We would recommend using QLOAD to actually move that message to an output file, in case you change your mind about deleting it!

qload -m MQG1 -IQ1 -f c:\temp\deletedmsg.qld 
-gxm414D51204D514731202020202020202099FA4A6020B74B02

Alternatively, you can use the very flexible search and filtering capabilities of QLOAD to narrow down your search of messages on the queue until you find the one you wish to delete, and then offload it to a file, or delete it entirely.

For example, this invocation removes all messages on a queue that are older than one week, and moves them instead to the named file:-

qload -m MQG1 -I Q1 -T7:0:0 -f c:\temp\oldmsgs.qld

Another example, here we remove messages larger than 1MB from a queue:-

qload -m MQG1 -I Q1 -z 1M -f c:\temp\bigmsgs.qld

A third example, here we remove message containing the string “Acme Limited”:-

qload -m MQG1 -I Q1 -s "Acme Limited" -f c:\temp\acmemsgs.qld
Using MQEdit

In MQEdit you can browse a list of messages on a queue, then from that list, select an individual message (or multiple messages if you need to). Then press the Delete button, or select Delete from the right-mouse button context menu.

MQEdit uses the MQ facility, get by message token, so only the exact message that you select from the list will be deleted. While the position of the message on the queue is shown, this is not used for deletion and neither is Message Id, since there is no guarantee that this will be unique either. Each message on a queue is guaranteed to have a unique Message Token.

Alternatively, you can double click on a message from the list, to view the whole message individually in the pane below, and then from that pane, having checked all the details, and made sure it is the message you want to delete, you can select “Delete Message” from the context menu.

Particularly for production queue managers, we would always suggest that it is safer to move message(s) to a holding queue rather than deleting them immediately. In MQEdit it is very simple to move a message between queues, all you need do is drag and drop the required message(s) from one queue to another. You can even copy and move messages between queue managers this way.


If you don’t have any of these tools, but would like to try any or all of them out, please contact support@mqgem.com and a 1-month trial licence will be sent to you with no obligation to buy. You can download the tools from our website.

MO71 Web Access Navigation Links

MO71 provides a web interface view into your IBM MQ Queue Managers and their objects and status. The default set of HTML files we supply with MO71 have a navigation pane on the left-hand side of your browser window and the data that you choose to look at, say a list of channels, gets shown to the right. The look and feel of the web pages are highly configurable. In these examples, we show screenshots of an alternate set of webpages we made for a fictitious mining company that we used in the video introducing MO71’s Web Access. These garish colours just illustrate that you can make it look any way you wish.

An MO71 Web access browser showing the Navigation Pane on Left

It’s this navigation pane that has had a recent enhancement and which will be covered in this blog post.

The default set of links

Before this change, you could control the links that were inside the twisty for each queue manager to a certain extent. You could configure which object types you wanted links for, and these would then be automatically generated. The downside of these links was that they showed every object of that type in the list. There was no opportunity to configure them, add filters, or object types to reduce the size of the initial list of objects you were presented with. The screenshot to the left illustrates the default set of links that were generated when your HTML file included the MO71 %[qmlist] insert as follows:-

%[qmlist MQG*: grp : def : linkhtml=(target="dataframe")]

If you wanted a specific set of links, you could replace the default set (identifier ‘def’) with a list of the identifiers that you wanted. For example, in this next command, the links would be Channels, Channel Status, Queues, Processes, and Namelists.

%[qmlist MQG*: grp : chl,chs,q,prc,nl: linkhtml=(target="dataframe")]

With this latest enhancement you can now create literally any links you want to put into this list. To do so, you create a small HTML file, mylinks.html in this example, to contain the snippet of HTML to go inside the twisty, and then code your qmlist statement as follows (note you don’t include the .html file extension:-

%[qmlist MQG*: grp : file=mylinks : linkhtml=(target="dataframe")]

You can put any links you want in this file, and if your links need the queue manager name as part of them then you code the %[qm] insert at that point. Here’s an example of a few links you might consider using.

<a href="https://www.MiningCo.com/qmgrcontacts/%[qm].html" target="dataframe">QMgr Contacts</a><br>
<a href="/mq/admin/msgs/%[qm]/SYSTEM.DEAD.LETTER.QUEUE" target="dataframe">DLQ Messages</a><br>
<a href="/mq/admin/chstatuses/%[qm]?filter=&quot;status=retrying&quot;" target="dataframe">Channel Status</a><br>
<a href="/mq/admin/authrecs/%[qm]?objtype=queue" target="dataframe">Queue Auth Recs</a><br>
<a href="/mq/admin/events/%[qm]?evreason=command" target="dataframe">Command Events</a><br>
<a href="/mq/admin/queues/%[qm]?type=qlocal;filter=&quot;!(queue==&quot;SYSTEM.*&quot;)&quot;" target="dataframe">Our Queues</a><br>

This selection of links illustrates that:-

  • The links don’t have to be MO71 links at all. If you have links that are specific to the queue manager and the URL contains the queue manager name, you can build the link using the %[qm] insert
  • You can have a message list as one of the links. This wasn’t possible before because you needed a queue name to build the link
  • You can have links with filters on them. This one only shows retrying channels
  • You can use lists that are reduced by object type or indeed any type
  • In fact you can use lists that are reduced by any keyword on the command. Here’s the MQEV event list reduced to show only command events
  • You can also combine keywords and filters

In short any link, an MO71 link or an outside link, can be put into this HTML snippet file, and used to build your navigation links.

In addition, this HTML snippet file can be combined with the original identifiers, so you can have your list as well as so of the original links if you want, for example:-

%[qmlist MQG*: grp : chl,chs,q,prc,nl,file=mylinks : linkhtml=(target="dataframe")]

Have a go and see what you think.


The new version can be downloaded from the MO71 Download Page. Any current licensed users of MO71 can run the new version on their existing licence. If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

MO71 version 9.2.2 is released

MQGem Software is pleased to announce that a new version of MO71, our GUI Administrative tool for IBM MQ, is now available.

The main features of the release are as follows:-

Addition of HTTPS to Web Access

A number of you have asked for this feature, so now the MO71 Web Server can be configured to use HTTPS. Configure the location of the Microsoft certificate store that contains a certificate to identify the MO71 web Server, preferably with a Subject Alternative Name extension matching your server DNS name so that browsers don’t complain, and start it up.

Configuration of the MO71 HTTPS Web Server

Now your MO71 generated web pages can be served up over an HTTPS secured transport.

Your MO71 generated webpages can now be served up over HTTPS

Updates to the HTTP Connections List

Related to the above feature, the HTTP connections List has been updated to show some additional fields.

When using HTTPS you can see the protocol (e.g. TLS 1.2), the encryption algorithm (e.g. AES256) and the signing algorithm (e.g. SHA384) that were negotiated for the connection from the browser to use.

For all connections (HTTP or HTTPS) the User Agent field is available. This is field that identifies the browser making the connection.

Details of the connections made to the MO71 Web Server

Support for DISPLAY CFSTATUS added

List, and individual record dialogs, as well as web access support, and usage tailoring support have been added for the DISPLAY CFSTATUS command.

An example CFStruct Summary Status dialog

New options to automatically fold Userid and Password fields to uppercase

This is another customer requested feature also added in MQEdit in it’s most recent release. You can select either or both of your Userid and Password fields for a location be folded to uppercase. Note that when selected, the dialog where you type in your password will remind you that you have these settings on. This can be especially useful for z/OS TSO logins where it can be easy to forget that you have an upper case password because the TSO login panel always folds it to upper case for you.

MO71 Location Dialog – Upper Case of Userid and Password

Blank columns in CSV exported data

When exporting MO71 dialog lists, normally if a column is completely empty, it is not shown on the list dialog, and it is not exported either. This feature adds an over-ride so that if you are exporting to CSV, you can request that empty columns ARE included.


The new version can be downloaded from the MO71 Download Page. Any current licensed users of MO71 can run the new version on their existing licence. If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

Example MO71 filter – Expiring Certificates

Tim Zielke recently wrote a blog post with a marvellous idea for keeping track of all the certificates that affect your environment. In short, he put useful additional information into the CHLAUTH description field of each rule that allowed a channel using a certificate to connect to his queue manager. That information was the expiration date of the certificate. This gave two immediate benefits.

  • It is easy to see when certificates have expired, and when CHLAUTH rules are written to include serial numbers, this allows the rule to be cleaned up because it is now no longer necessary.
  • It is also easy to determine whether there will soon be some problems as a result of certificates expiring, with new CHLAUTH rules being needed to be put in place, especially when serial numbers are included in the rule. All the information is on one display, instead of being scattered about in various different places.

You can read his whole blog post here.

This got me thinking about MO71 filters. Having put the information into the description field of the CHLAUTH rules as Tim suggests, a filter could highlight those records that were problematic (i.e. expired) or soon to be so.

Here is the filter I wrote.

@offset:= findstr(descr,"Expires=");
if (@offset > 0)
{
  @$date:=substr$(descr,@offset+8,10);
  @exptime:=mqtime(@$date,"00:00:00");
  @ttl:=(@exptime - _time)/86400;
  bg(@ttl<=0,red);
  bg(@ttl>0 AND @ttl<7,yellow);
  usrcol("Time to Live", @ttl,text+left);
}
true
  1. This filter finds the text in the Description field “Expires=”
  2. If present it takes the next 10 characters to be a date.
  3. It passes this date, along with midnight as the time, into the MO71 built-in filter function mqtime() to get the expiry time in seconds.
  4. The time-to-live (TTL), that is the remaining life of the certificate before it expires, is calculated as the difference between the date in seconds and the time now, using the MO71 built-in system variable _time. This TTL is then adjusted to days instead of seconds.
  5. We then set the background colour based on whether it has already expired, coloured red, or whether it will expire in the next 7 days, coloured yellow.
  6. Finally we put this TTL variable value into a user column because that way we can sort the whole list by that column if we need to.

Here’s a screenshot of the filter in operation. For the purposes of screenshot brevity, I have omitted serial numbers as Tim uses in his blog post since they are not needed to illustrate this filter.

Use a filter to colour different rows of interest


If you’re not familiar with filters in MO71, they are a very powerful tool for helping you show exactly what you need to see on your MQ displays. You can watch a video about them here.


If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

MO71 and referenced objects

There are lots of places in IBM MQ objects where other objects are named. As few examples include:-

  • A local queue name in the transmission queue field of a channel
  • An authentication information object named in the Connection Authentication field of the queue manager
  • A topic object in a subscription
  • A connection ID in when viewing subscription status

When you view such objects with MO71, you can interact with these fields by double-clicking on them.

Viewing already existing objects

If you are viewing an individual object dialog that refers to another object, double clicking on that field will open up another individual object dialog to show the referenced object. It’s just a simple action, but very handy, and will save you time when looking at inter-connected objects or status.

Double click on the Connection Authentication field to view the referenced object

Double-click setting for Queues

This double-click action pays attention to the preference “Double click should browse on queue lists”. If you have this preference checked, then you should hold down the Alt key to get the alternate action which is to display the object definition.

Creating new objects

Another time when this feature of MO71 really comes in handy is when you are defining new objects and their referenced objects. For example, when defining a sender channel and its transmission queue.

Imagine you are part-way through defining the sender channel, and you get to the field where you need to put the transmission queue name. You realise that you haven’t yet defined the transmission queue. Rather than going and starting up a queue dialog and defining it, you can instead type in the name you want the transmission queue to have, and then double click on that field. Again, this is just a simple action, but it saves you time.

MO71 will open up an individual dialog for that queue name, but it doesn’t exist yet.

Double clicking on the transmission queue name brings up queue dialog even if it doesn’t exist

The dialog will have the name filled in, and you can now go ahead and populate the rest of the fields for the transmission queue. Once done, you can press Create on the queue dialog and then go back to the channel dialog, and when you’re finished press Create on that one too.

Press Create on each dialog to create the objects

In the Web Interface

The same inter-connections can also be seen when using the MO71 Web Interface. Referenced objects named inside objects or status, become hyperlinks, so you can click on them to view the details about the referenced object in a web page. In the screenshot below, I’ve open the hyperlink in a new tab to make it clear what happens, but if you just click on it, it will open in place.

In the web interface, referenced objects become hyperlinks


If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

MO71 version 9.2.1 is released

Hot on the heels of MO71 V9.2.0, MQGem Software is pleased to announce that a new mini release of MO71, our GUI Administrative tool for IBM MQ, is now available.

This release was created to deliver three features requested by customers, which are as follows:-

Change the value of a field for many locations at once

If you have lots of queue managers, and you need to change something in the location definition for a number of them, this new dialog can make your life much easier. You can now change values in multiple location definitions at once. For example, if you want to organise your queue managers into various “groupings”, you can make use of network names. Read this post for more about that. To set up network names by editing individual location definitions one by one would take some time, so now you can easily do it with the “Change Multiple Locations” feature of MO71.

Open the dialog from the MO71 File menu; select the queue managers to be changed in the left hand list; choose the field to be updated in the right hand list; type in the new value in the entry box and press Set New Value.

MO71 – Change Multiple Locations dialog, showing Network names

Network names is actually a comma-separated list of names, so not only can you set the entire field, you can add or remove individual items from the comma-separated list using the Add and Remove buttons.

There are quite a number of fields in the location dialog that you might find it helpful to update many at once. Take a look to see if any of those provided would be helpful to you.

Set locations to be members of the same security group

Do you have queue managers using user IDs and passwords? Are a number of them in the same security domain, for example, you have AD set up; or multiple z/OS queue managers in the same RACF; or you are using LDAP for your authentication? To save you having to make lots of changes each time you set up a new password on one of these domains, MO71 now has the concept of a security group. You can indicate queue managers are members of the same security group in their location and then when you change the password of one member of the security group, all other members get that update too. This saves you having to provide the new password on every queue manager on password change day.

This security group is just a name for MO71, it doesn’t have to match the domain, or group name or anything defined in a security repository. It is simply a grouping to tell MO71 that these queue managers all use the same user id and password at connection time.

MO71 Location Dialog – Security Group settings

The description is optional, but if provided will be used in the password prompt box that is displayed when you connect to a queue manager, or press the Set Password button, as shown in the screenshot above.

In order to initially set up the security group each queue manager is in, you can also use the “Change Multiple Locations” dialog described above.

Set CCDT imported location as MVS

You can import locations into MO71 from a number of sources (see these posts for more details). In the case of importing from CCDTs (either binary or JSON format) there is no information in the source file to indicate if a queue manager is MVS or not. However, you can now manually indicate, at import time, that the queue managers being added should be marked as MVS.

Import CCDT Dialog – choose your queue managers


The new version can be downloaded from the MO71 Download Page. Any current licensed users of MO71 can run the new version on their existing licence. If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

MO71 version 9.2.0 is released

MQGem Software is pleased to announce that a new version of MO71, our GUI Administrative tool for IBM MQ, is now available.

The main features of the release are as follows:-

Graphing

MO71 has had the ability to graph numeric data from your queue manager for many releases. You could graph the depths of queues, for example. This graphing feature of MO71 has been improved with many new features, and additionally you can now also graph MQEV data in the same way.

New graphing features include:

  • Column Stacks
  • Long and Short Average lines
  • Saving of graphing defaults
  • Saving of line defaults
  • Drag resize
  • Improved time labels added to graphs
  • Auto-range of axes
  • Column relative sizing and overlap
  • Pie chart labels

This slideshow requires JavaScript.

Improvements to MO71 Web Access

Several improvements have been made to the web access feature in MO71.

  • MQEV objects
    MQEV objects and status can now be shown on the web access interface.
    View MQEV events through the MO71 web interface
  • HTML5 templates
    The template HTML files that are provided with MO71 now use HTML5, and the “twisties” generated by MO71 in the navigation area, now use HTML5 <details> and <summary> tags, so now there is no need for JavaScript for them.
  • New dialog list combinations in qmlist[]
    When you build your navigation section, you can choose which commands you want to see shown there. There are some new options now, including “all”, “allmq” and “allev”.

    <h2>Queue Managers</h2>
    %[qmlist : grp : allmq : linkhtml=(target="dataframe")]

Import from JSON CCDT file

You can seed your MO71 location definitions by importing data from a CCDT, an MQ Explorer exported config, locally defined queue managers, another MO71 config file, and now a JSON CCDT file.

More information on a Queue Manager list dialog

Information from the location definition can now be displayed on the queue manager list dialog. This includes fields that are part of connecting to the queue manager, such as channel name, connection name and user id; and also fields that help you sort and group your queue managers, group and network names.

Set Default Lists – now grouped

The menu for all the Set Default Lists dialogs was getting pretty long, so it has now been grouped up. If you’ve never used Default Lists, read this post to learn more about them and what they are for.

Service Objects can be compared

MO71 can compare the definitions of many objects types. Service objects are now one of the types that can be compared.


The new version can be downloaded from the MO71 Download Page. Any current licensed users of MO71 can run the new version on their existing licence. If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

Running Cluster Channel Commands in MO71

Our graphical administration tool for IBM MQ, MO71, allows you to issue all sorts of IBM MQ administrative commands. This blog post is going to specifically take a look at cluster channel commands.

As an MQ administrator, you are probably aware that not all channels that might be running on your queue manager, have channel objects. This is true for those automatically installed cluster sender channels that get created based on the cluster-receiver template from another queue manager.

Even though they don’t have the traditional channel object, you might still want to run commands against them. Some of those commands you might want to run require that the channel is not currently running, for example a START CHANNEL command! Yes, it is perfectly reasonable to want to manually start a cluster-sender channel, even though you know that they get automatically started when messages need to flow.

How then, can you issue a command against a cluster channel when it doesn’t show up in the channel object list, or even the channel status list?

In MO71, this is handled from the “Cluster Queue Manager List” dialog, an example of which is shown below. The “Cluster Queue Manager List” dialog uses the data from the DISPLAY CLUSQMGR or Inquire Cluster Queue Manager MQ administrative commands.

View and manage your MQ Cluster channels from this list dialog

This is a very useful display to use when managing an MQ cluster, showing a combination of cluster information, such as the name of the cluster, and the role the queue manager plays in the cluster, for example is it a full repository; all the channel definition attributes, such a heartbeat interval; and the channel status. If you’re not familiar with all the information available through this command, and this list dialog, I encourage you to get to know it.

You may also find the MO71 Network view useful when getting to know a cluster. It gives a very good at-a-glance view of the cluster, and who does what, and allows you to drill down into the objects. In addition, all queue manager icons, as elsewhere in MO71, have a right-mouse-click context menu for commands just like the main window.

View your MQ cluster using the MO71 Network view

The Network view allows you to create a diagram of your clustered queue manager (as seen above), and it pictorially shows you the status of your channels. In addition, in the verify view on the left, you can drill down to see all object types (including cluster objects) and any problems detected in the objects in your queue manager. See the “Mini-Health Check for your Queue Manager” blog post for more details about MO71 problem checking.

See the resolution of objects, and detected problems


If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.


I was prompted to write this blog post as a result of a discussion about a recently raised MQ RFE.

Does MO71 log the commands it issues?

This is a question that we get asked quite regularly, so we thought it worth writing up the answer as a blog post.

If you’re asking this question, there are two reasons that immediately come to mind that might be behind your question:-

  • You just want some sort of documentary log, a history of what you have done to look back on.
  • You need a log of commands issued for audit reasons.

However, applications logging their own activity have a number of disadvantages. For example, if the log file were on your own machine, then you have to manage those files, house-keep them as they get old enough to delete, etc. Flat log files are not very easy to search through, say to find out what happened last weekend, or all the activity associated with a particular object.

If you want something for audit reasons, using a log file on the user machine has a number of additional problems:-

  • Firstly, it is not audit proof because
    • It is easy to circumvent
    • It is incomplete since other tools might be used to issue commands to the queue manager
    • The user could switch off the logging feature in their tool, or install a new version of it to avoid the logging configuration
  • Secondly, it is hard to collect the logs from all the different users’ machines to have the complete picture.
  • Thirdly, if individual applications are creating the log file, e.g MO71, runmqsc, MQ Explorer and so on, then you get a myriad of different log file formats.

To solve all of the above, IBM MQ Queue Managers have a feature called Command Events. When enabled these result in an event message being emitted by the queue manager for any command issued (with a tweak to avoid DISPLAY commands if you wish – see EVENT Switches). This is a far better solution than logging in the user-facing tool (e.g. MO71), for reasons such as:-

  • Central collection is better because it is easier to obtain a complete record, since the records are not segregated across many user machines
  • It cannot be subverted by non-privileged users
  • The format is consistent regardless of the tool used by the user
  • No updates are required to any tool, the logging capability is available immediately for all applications


If all you want is something to pass an audit, command and configuration events might be enough. But if you want a record for diagnostic purposes there are other things you might wish to add to the record of what happened, such as:-

We have been recommending using Command (and Configuration) events rather than logging at the user-side MQ administration tool, for many years. Previously the problem with this recommendation was the collection and searching of the event data. However, we have recently released a new product, MQEV, which will help you in this regard. MQEV will collect, process and store your event data, and make searching and report building very simple. You can now easily get the information from the event messages that your IBM MQ queue manager is designed to emit. If required you can process the events real-time, and make changes immediately, or even raise alerts to your MQ administrators for follow-up.


Lumberjack image courtesy of vectorolie at FreeDigitalPhotos.net

Lots of viewers of MQ status data

Lyn Elkins recently published a post about the costs of object creation/deletion, and specifically the cost of using temporary dynamic queues with monitoring tools looking at a queue manager on z/OS. Read her blog post here:-

MQ SMF – Data Manager Object totals

She mentions lots of people watching a problem and constantly refreshing their MQ screens to see if the problem goes away, causing more work on the queue manager, and thus not helping the poor CPU constrained queue manager in the process.

This sort of scenario is where MO71’s web interface becomes very useful. A single instance of MO71, and therefore a single connection to the queue manager, with a single reply queue, can serve up the web pages showing MQ status pages, which then lots of people can be refreshing to their hearts content. Regardless of how many people are refreshing the webpage, or how often, MO71 will only request new data from the command server at a sensible request interval (which you can configure in MO71’s preferences).

Here’s a video showing the Web Access capabilities of MO71, with the start time set to show an automatically refreshing department display example on a smart TV – which of course could also be shown on a department monitor, or everybody’s own machine. Earlier in the video it also demonstrates how the data contents can be incorporated into any webpage of your own choosing so the queue list data can be amongst your own department style webpages with links to other content or MQ displays.

 
P.S. All our monitoring tools have the choice of whether to use a temporary reply queue or a pre-defined one.