Is there a way to clear an MQ queue of all messages?

We were recently asked how to clear a queue of all messages within one of our tools.

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

There are two options for clearing a queue of all messages when using MO71. One directly interacts with the messages in a Message List dialog, and the other uses the Clear Queue command via the command server. The latter can fail if someone else has the queue open.

MO71: Using the Message List dialog

In MO71 you can browse a list of messages on a queue, then in the context menu of that dialog choose Message Selection → Apply to all Messages. Then press the Delete All button, or select Delete All from the right-mouse button context menu and all the messages will be deleted.

Delete all messages using MO71

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 All, rather than Delete All, button.

MO71: Using the Clear Queue command

From a Queue List dialog in MO71, you can choose to clear a queue from the context menu. As a destructive command, this will show a confirmation dialog before it goes ahead.

Delete all messages using the Clear command in MO71

Remember that this command can fail if the queue is open by another application at the time.

Using the Q program

You can use the Q program to quickly destructively get off all the messages on a queue, to ensure it is empty before you begin using it for something else. This can work even when the queue is in use (unless it is exclusively in use of course) and the CLEAR QLOCAL command can’t be used.

Here is an example which destructively gets (-I) from Q1 and does not print the messages to the screen (-q), aka ‘quiet’ mode:-

q -m MQG1 -I Q1 -q

Take care when deleting messages from a production queue manager. Consider that it might be safer to Move the messages to a separate holding queue, just in case they prove to be important after all. This is simple to achieve using a command like the following:

q -m MQG1 -I Q1 -o HOLDING.Q
Using QLOAD

You can use QLOAD to quickly destructively get off all the messages on a queue, to ensure it is empty before you begin using it for something else. This can work even when the queue is in use (unless it is exclusively in use of course) and the CLEAR QLOCAL command can’t be used.

Here is an example which destructively gets (-I) from Q1 and discards them (-f null), aka sends them to the null file destination:-

qload -m MQG1 -I Q1 -f null

Take care when deleting messages from a production queue manager. We would recommend using QLOAD to actually move the messages to an output file, in case you change your mind about deleting them!

qload -m MQG1 -I Q1 -f c:\temp\Q1deletedmsgs.qld 
Using MQEdit

In MQEdit you can browse a list of messages on a queue, then in the context menu of that dialog choose Message Operations → Apply to all Messages. Then press the Delete All button, or select Delete All from the right-mouse button context menu and all the messages will be deleted.

Delete all messages using MQEdit

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. MQEdit makes it simple to Move messages too. Just fill in the holding queue name, and then press the Move All, rather than Delete All, button, or simply Drag and Drop the messages onto the new queue.

Using MQSCX

You can of course issue the MQSC CLEAR QLOCAL(q-name) command from MQSCX. However, it can go one better than this. The CLEAR QLOCAL command is problematic because it can fail when someone else has the queue open, even if it is not open in a way that stops you getting messages. Instead you can issue the following command in MQSCX:-

=clear qlocal(Q1)

then MQSCX will first attempt the CLEAR QLOCAL command and if that fails with "object in use" then it will switch to getting the messages off the queue instead. You can read more about this in MQSCX: Clearly a better 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.

Application Viewer in MO71

MO71 can help you visualise your network of queue managers, and also your applications and which queues they use.

When you first load up the Application View, you can position your various applications and queues on the display pane, and you can choose not to display any of them you are not interested in (for example the various queue manager internal connections). You will start off with a basic display something this like:-

A basic MO71 Application View (of a z/OS QMgr)

You can move things around however you like, and save the layout when you have it just how you like it. In this screenshot we can see some inactive applications (the un-filled cog icon) and some active applications (the filled cog icon). There are some client connected applications with the application name that is flowed up from the client (also seen in RAPPLTAG in DISPLAY CHSTATUS) used in preference to the Application Description which on z/OS is always unhelpfully “IBM MQ Channel Initiator”. There is also a batch application, M901APP1. If you don’t like any of these names, you can also give your applications nicknames to change what is displayed.

In addition to nicknames, you can also associate icons with your applications, an active icon, an inactive icon and an error icon, so you can more easily see what the applications are doing, and whether they are running at the moment. As an example, I gave my applications shown above some 100×100 BMPs as icons with colour versions for active, and black and white line drawings for inactive and now my display looks like this. These BMPs might be slightly large for your purposes; I chose this size for demonstration purposes. N.B. Some of my applications have stopped running since the first screenshot.

An MO71 Application View with custom icons (of a z/OS QMgr)

All this configuration is done from the Application List dialog where you can set all that we have mentioned above and more.


Price list icons, Customer icons, and Sales icons created by Freepik – Flaticon.


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.

Finding the reason why a message was sent to the Dead Letter Queue (DLQ) in IBM MQ

IBM Support recently released a Support Doc which was titled:-

Summary

Finding the reason why a message was sent to the Dead Letter Queue (DLQ) in IBM MQ

The document described several options, which often required you to look at the message in hex and, when required, byte swap the value to find the reason code. In this post we cover how to do this using MQGem tools as several of them offer this capability, and our tools format out the Dead Letter Header so you don’t need to do any manual byte swapping. Open up the twisty for each tool to read how to do this.

Using MO71

In MO71 you can browse the messages on the Dead Letter queue using a Message List. If you choose to show the “Message Summary” column on your list dialog (see Configuring List Dialogs in MO71 for how to change the columns in a list dialog), you will immediately be able to see the reason code in the Dead-Letter header, as that is one of the useful things that Message Summary displays look for.

A message List dialog will summarise the Dead Letter header of a message for you

Alternatively you can double click on a message to look at the full details of an individual message, and you will see the full Dead-Letter header (MQDLH) is formatted out for you to see.

The full message display shows all of the Dead Letter Header formatted out

Using the Q program

To view your messages on the Dead Letter queue, and have them formatted out, you need to use the -df option which also has three levels of detail. For full detail use -df3. Here’s an example command:-

q -m MQG1 -i MQG1.DEAD.LETTER.QUEUE -df3

Which will format the Dead Letter header like this making it really easy to understand the reason why the message was placed on the DLQ.

[  181 bytes] Message Content
[  181 bytes] Dead Letter Queue Header (MQDLH)
StrucId      :'DLH '
Version      :1
Reason       :2085 (Unknown object name)
Dest. Queue  :'TARGET.QUEUE                                    '
Dest. QMgr   :'MQG1                                            '
MQEncoding   :0x'222' (Reversed)
CCSID        :437 (IBM PC)
Format       :'MQSTR   ' (String)
PutApplType  :11 (Windows NT)
PutApplName  :':\mqm9250\bin64\amqrmppa.exe'
Put Date     :'20220411'
Put Time     :'05021009'
Some text
Using MQEdit

When you look at the messages on a queue using MQEdit, the message list will show you a summary of the message in the “Message” column, which for Dead Letter header messages will show you the reason from the header. This makes it very easy to see the reasons why messages are on your Dead Letter queue.

Selecting a message from the list will display it in the pane below with the Dead Letter header formatted out also showing you the reason why the message ended up on the DLQ.

MQEdit shows a summary of the Dead Letter header in the message list, and the fully formatted message in the lower panel

Using QLOAD (honourable mention)

QLOAD isn’t a message formatting tool, so it will not help you to view the reason code in the Dead Letter header of a message. However, it does get an honourable mention in this list because it can help you to move, or unload messages from your Dead Letter queue that have a specific reason code in the Dead Letter header. This can be very helpful if you want to siphon off some specific errors to handle in a different way.

Use a command like this to copy (-i is browse) all the DLQ messages for MQRC_UNKNOWN_OBJECT_NAME (2085) to a file.

qload -m MQG1 -i MQG1.DEAD.LETTER.QUEUE -Gr:2085 -fUnknownObjs.qld

When you’re using this feature, QLOAD will report the message selection that you have active:-

Message selection active:
  Messages with DLQ Reason 2085 Unknown object name

Read    - Files:   0  Messages:     3  Bytes:      5616
Written - Files:   1  Messages:     1  Bytes:       181

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 SYSP Commands

What do I mean by the “SYSP Commands”? On z/OS queue managers, there is a set of three DISPLAY and SET commands that allow you display and, to some extent, manipulate, the values provided by the queue manager start up parameter module.

CSQ6 macro DISPLAY command SET command
CSQ6ARVP DISPLAY ARCHIVE SET ARCHIVE
CSQ6LOGP DISPLAY LOG SET LOG
CSQ6SYSP DISPLAY SYSTEM SET SYSTEM

I refer to them as the SYSP commands because in the PCF interface they all have a field called Parameter Type which tells you whether the response is a set of MQSYSP_TYPE_INITIAL or MQSYSP_TYPE_SET, and a variety of the other PCF constants are spelled MQIACF_SYSP_… or MQIACF_SYSP…

The latest version of MO71 now includes the output of these DISPLAY commands as part of the queue manager dialog, in four new tabs – DISPLAY LOG is spread across two tabs, one for the Initial and Set parameters and one for the Log Status.

Examples of two of the four new tabs on a queue manager dialog

The fields from these DISPLAY commands are also available as columns in a multi-queue manager list dialog, allowing easy comparison of the values across several queue managers. As always, use Alter List to select the columns you want to see in your list dialog.

Multi-QMgr list dialog showing several fields from these new commands

One of two of these new fields provide the same information that is found for distributed platform queue managers in DISPLAY QMSTATUS (which doesn’t exist on z/OS – see IBM MQ Little Gem #6: QMSTATUS), specifically the queue manager start date and time. So these will show up in the same column in the queue manager list so that you can compare the start dates and times of your queue managers whether distributed or z/OS. With the combined date+time field that MO71 constructs, these are also sortable.

If you don’t want to see the output from these commands on your queue manager dialogs and lists, you can disable this on the Location dialog by unchecking the “SYSP commands” checkbox. If you want to do this for multiple queue managers, remember that you can use the Change Multiple Locations dialog.

Disable the SYSP commands from the location dialog

These three SYSP commands, DISPLAY ARCHIVE, LOG, and SYSTEM, follow a similar pattern. Each one provides two sets of output showing the “Initial” values (those set by the queue manager parameter module passed in on the START QMGR command) and the “Set” values (those subsequently changed by a SET command). In the MO71 queue manager dialog, these are displayed in two columns, “Initial” on the left and “Set” on the right, with any set values highlighted. You can see an example of a set value in the screenshot above.

When viewing this data in a queue manager list, the current in use values are shown. That is, the “Set” value, if there is one, and otherwise the “Initial” value.

Not all values from DISPLAY ARCHIVE, LOG and SYSTEM can be changed using a SET command. The IBM Doc links to the macros, in the table at the top of this post, document which fields are SETable. In MO71, fields that are not SETable, are displayed as read only. For those fields that can be SET, you can provide a new value in the right hand column and then choose the appropriate SET command from the context menu. Changes to these tabs are not sent to the queue manager when you press the Update button on the dialog, you must choose the command from the menu.

You can also drive the SET commands from the context menu

These menu options for the Set commands can be hidden from view using Usage Tailoring with the following statements in the MQMON.AUT file.

nomenu_set_archive
nomenu_set_log
nomenu_set_system

We hope this feature now gives you a more complete view of your z/OS queue manager configuration.


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.

Focus fields in MO71

In the recent release of MO71 a new feature was added that allows you to open an object to edit a particular attribute and immediately be positioned on the attribute you want to edit. This comes into effect when you start from a list of objects, and then open one individual object by double clicking (or right-clicking) on the row showing the object you want.

In list dialog, there are a number of columns displayed for each object. You can configure what these columns are, and you can therefore have the list dialog showing all the various attributes you might be interested in. From this list, you might spot a value for a particular attribute that is not correctly set and open up the individual dialog by double clicking (or right clicking) on that object. In previous releases you might then have to try various tabs in order to find the attribute in question. Some objects have a lot of attributes! Now, however, if you click on the attribute column within the row showing the object you want to open, it will open the object dialog with the focus field placed on that attribute.

Double-click (or right-click) to bring up an individual dialog, and the column you clicked on in the row, positions the focus field in the new dialog

If you don’t want to use this feature, and always want your object dialog to be opened on the first tab, with focus on the first field, there is a preference option on the “Lists” tab, called “Double-click field is significant” which you can uncheck to turn off this feature.

We use the ability to set the focus field for a few other purposes too.

Object creation – missing or error fields

If you are creating a new object, and you do not provide all the mandatory fields, you will get a message in the status bar at the bottom of the dialog, telling you what you are missing. In addition it will now also move the focus field to the attribute being mentioned.

If MO71 detects missing or incorrect attributes in your object definition, not only will it report in the status bar, but will also place the focus on the problematic field

Problem reporting

MO71 problem detection, a.k.a. healthcheck, has had an enhancement in this release, and one of the enhancements is that when you open up an object dialog from a problem report, it will put the focus field on the problematic attribute. For example, if your queue manager does not have a Dead Letter Queue defined, and you click on the queue manager name hyperlink in the problem report, it will bring up the queue manager dialog with the focus field on the Dead Letter Queue attribute. This makes it very quick for you to ‘fix’ the problem.

When clicking on hyperlinks in problem reports, many have focus fields to take you straight to the problem attribute


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 More Queue Manager Problems

In this release of MO71 we have added quite a number of additional IBM MQ configuration problems that we can look out for. This meant that we changed the long list of problems into a dialog with multiple tabs to make viewing and selecting all the problems easier to do. Read more about the new Problem Selection dialog here.

This post wants to introduce you to some of the new problems we look out for.

Missing SYSTEM objects

IBM MQ queue managers rely on a number of SYSTEM objects in order to operate successfully. If any of these objects are missing, this might cause you issues. This can especially occur on z/OS if you run with copies of the CSQINP2 sample data sets and forget to update them for new objects when you start using a new release. However, it is not solely a problem on z/OS, so we check for all SYSTEM objects on both distributed and z/OS. These problems can be individually selected or deselected on a per object basis, so if you have a good reason to delete, say, the SYSTEM.AUTO.SVRCONN, then you can uncheck that problem from the list we will check for. Different missing SYSTEM objects have a different impact on the queue manager, so these problems also have different severities depending on the object.

The Definitions tab of the Problem Selection dialog, showing some of the problems we check for (others are scrolled off the page)

Bufferpools and Pagesets

The verify feature of MO71 now follows the definitions of queues to their storage classes, to their pagesets, and to their bufferpools as you can read about in this post. This means that we can also check for configuration problems with these definitions. For example, our problem checking will encourage you to have a 1:1 mapping between pageset and bufferpool; to get your bufferpools into 64-bit storage, since LOCATION(BELOW) is now deprecated; not to use pageset zero for queues; and to reassign spare buffers on any over-sized buffer pools.

The Media tab of the Problem Selection dialog

Clustering

Checking for same named queue managers with different QMIDs was a customer requested problem we added.

Problem description: More than one CLUSQMGR definition with different QMID values

We also check for different queue managers using the same channel name which is at best a confusing naming convention to have! These two were added to a selection of incomplete cluster style problems we already checked for.

Clusters tab of the Problem Selection dialog

Publish/Subscribe

The last two problems added prior to this release were to check for topic strings that had leading or trailing spaces, so it made sense to add a few more checks for the publish/subscribe area. There are various referenced object that could be missing so those have been added as checks.

Pub/Sub tab of the Problem Selection dialog

Miscellaneous

As a result of Lyn’s blog post about APAR PI85424, we added a check for the QDEPTHHI and QDEPTHLO settings. We also put in a check for channels using the CONVERT(YES) option which seems to still come up regularly on the forums, and since INDXTYPE can make such a difference for performance, we added various checks for system queues that are supposed to use a particular INDXTYPE on z/OS (as can be seen in a number of the earlier screenshots).


We are always on the look out for more checks to add to our health checker, so please feel free to contact us or leave a comment below with any suggestions you have.


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 Object Relationships

There are many objects in IBM MQ that have relationships, for example a channel uses a transmission queue, or an alias points to another queue or topic. The MO71 network view follows these relationships and lets you look at them in reverse. One of the longest chains of objects related to other objects, is queue → storage class → pageset → bufferpool. In the latest version of MO71, the network view also follows these relationships.

The handy thing about this is when you want to look at it in reverse. For example, which queues are sharing a particular pageset?

A view of the queues used by a particular pageset

In this view, the twisty for pageset 3 has been opened and the list of queues that (via their storage class definitions) are using pageset 3 are shown.

Or harder still (since it is one more step along the relationship chain), which queues are sharing a particular buffer pool?

A view of the queues sharing a particular bufferpool

In this view, the twisty for bufferpool 3 (which supports pagesets 4 and 25) has been opened and the list of queues that will use buffers in this bufferpool are shown.

The second of those two might become a redundant question if everyone moves their z/OS Queue Managers to have a one-to-one relationship between pageset and bufferpool as IBM recommends, but until that time it could well be handy to see all the queues, and thus applications, competing for memory in the bufferpool.

N.B. The one-to-one relationship between pageset and bufferpool is one of the new healthchecks we added this release too.

A new healthcheck to encourage you to have a one-to-one mapping between pageset and bufferpool

We hope these views of your IBM MQ objects help you to get to know your pageset and bufferpool usage even better, and move toward better application isolation.


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 Exporting in a QSG

As I wrote about recently in this blog post, when exporting your object definitions from a queue manager which is a member of a Queue Sharing Group (QSG) you really want to ignore all the QSGDISP(COPY) objects and instead export the QSGDISP(GROUP) objects which, when restored, will cause the creation/update of the QSGDISP(COPY) objects as required.

The latest release of MO71 has a small enhancement to the Export tab of the Location dialog where you control the automatic, regular, export of your queue manager’s objects. If your z/OS queue manager is a member of a QSG, then three additional check boxes will be available to you to select Shared Queues, Group Objects, and if you can think of a reason to need them, Copy Objects.

The default settings of these check boxes will be to export Shared Queues and Group Objects, but to ignore Copy Objects. This is a change of behaviour from earlier releases, so if you really do want to continue having Copy Objects exported you will have to go in and select that check box too.

Export all the required Queue Sharing Group objects with these settings

N.B. QSGDISP(QMGR) objects are always exported if that object type is ticked.

You may find these check boxes useful for another reason. You may consider that exporting the QSG objects on all queue manager’s in the Group is duplicating effort and wish only to export those objects on one member of the group and on all other members just export the QSGDISP(QMGR) objects. If this is the case, you can uncheck these options, and also uncheck CFSTRUCT objects from the list of object types, as these objects are QSG-wide.

Only want to export QSG-wide objects on one queue manager? Use these settings on the other queue managers

These options now give you appropriate controls of exactly the objects being exported from your QSG member queue manager’s.


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 Problem Selection

MO71 has had a facility to run a mini-health check on your queue managers for a long time. We had a list showing the problems that we checked for, and you could scroll down that list and see what they all were and uncheck any that you didn’t want checked against your queue managers. From time to time we have added additional problems to look for and this list got longer.

In this release we have added quite a number more problems (more about these in another blog post soon) and the single long list was just getting too unwieldy to use, so we have introduced the new Problem Selection Dialog. This is accessed from the View Menu on the Network display and looks like this:

The new Problem Selection dialog in MO71

Now the long list is arranged into several tabs of different categories of problem. An individual problem can be shown on more than one tab, for example the problem that checks whether your channels are using a CipherSpec can be found on both the Channels tab and the Security tab.

You can untick any specific problem that you don’t want to have checked against your queue managers, or the whole of one tab by using the “All Shown” buttons to select or deselect. On the right of each problem title a number will indicate how many instances of that problem have been found in the set of queue managers that you are verifying.

For each problem we also now provide guidance about the problem. You can see this by clicking on the blue i in circle to the left of the problem title. This will bring up a dialog which describes the problem in more detail, tells you what the hyperlinks in the problem report will do and makes a suggestion on how you should fix the problem. It also displays all the instances of this problem across all the queue managers you verified so you can use this view to concentrate on fixing a specific problem everywhere.

An example instance of a problem with two queue managers suffering from it

The same guidance dialog can also be opened from the list of problems shown for one queue manager in the verify view, by clicking on the same blue i in circle to the left of the problem title. This allows you to quickly discover whether other queue managers are reporting the same problem.

All the problems found on the TERRIBLE queue manager

We hope this makes it easier for you to navigate the problems that MO71 is checking for on your queue manager.


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.3 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:-

Object resolution for queues → storage classes → page sets → buffer pools and queues → process objects

Extending the object resolution currently in MO71 of various types of queues, now various other objects are resolved and have their definitions checked. Read more about this here.

Title information can be configured for Storage Classes, Pagesets and Bufferpools

Having resolved all your storage classes, pagesets and bufferpools, MO71 knows how many of each are in use. You can configure titles against the definitions made up of the collective knowledge about them. For example in the screenshot here; each bufferpool shows how many buffers it has, and how many queues are having to share those buffers; each page set shows how many pages it has and what percentage of all the pages in all the pagesets that number is; and storage classes show how many, and what percentage of the whole set of queues, are assigned to each storage class. You can configure these titles to show what you think are the most useful bits of information.

Example Media Titles – you can make them completely your own

Problem Selection dialog added

Since our scrollable list of problems to check for was getting a little unwieldy, we have created a new tabbed dialog, making it much easier to examine all the problems that MO71 will check your queue managers for, and to deselect any that you do not wish to use. Full problem descriptions are also now provided with suggested resolutions; counts of problem instances found; and a display of all the instances of an individual problem on all queue managers checked. Read more here.

Extended list of configuration problems checked for

Several additional configuration problems are now checked for including; missing or incorrectly defined system objects; resolution issues with process objects, storage classes, page sets and buffer pools; backout queues; topic object model queues and more. Read all about this here.

DISPLAY ARCHIVE / LOG / SYSTEM added to queue manager dialog and multi-queue manager list

See these other configuration attributes of your z/OS queue manager, and view these attributes in a multi-queue manager list dialog making it easy to sort or compare the values used across several queue managers. Look out for a later blog post all about this and the next item.

SET ARCHIVE / LOG / SYSTEM added to queue manager dialog context menu

Make changes to these other configuration attributes of your z/OS queue manager, using Set commands.

Reduced start-up time for the API Exerciser dialog

As quite a complicated dialog, it did a lot of setup and this caused a long wait before it appeared. This has now been streamlined.

You can now export the dialog contents in JSON format

To add to the Text, MQSC, CSV and XML formats that were previously available, we now add JSON too.

Automatic export choice of QSGDISP for export of z/OS QMgr objects

Choose to export QSGDISP values of SHARED, GROUP and/or COPY, in addition to all QSGDISP(QMGR) objects for queue managers that are a member of a Queue Sharing Group (QSG). Read all about this here.

Initial focus field in object dialogs

When starting an object dialog from a list dialog (for example double-clicking on a Queue) then the field which is clicked on is the field that is in focus when the single object dialog is displayed. This technique is also used in a number of new places, like when looking at an object that has had a problem found with it. Read all about this here.

Predefined dialog group context

A new Predefined Dialogs field “Context Applicable” is introduced which controls whether a Group context command is shown only when all group members are applicable or any of them. To illustrate, imagine a group of commands made up of an AMQP Channel Status dialog and a Connections dialog. The AMQP Channel Status command is not applicable to z/OS, but the Connections command is. Do you want this predefined dialog group to show on the context menu of your z/OS queue managers or not? If you set Context Applicable to All, then it will only show on the context menu of queue managers where ALL the dialogs in the group are applicable, whereas if you set it to Any, then as long as at least one of the commands in the group is applicable to that queue manager, it will show up.


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.