Import queue managers from an MQ Explorer export

In a recent update to MO71 V9.0.4 a new feature was added to allow you to import queue manager location information from an MQ Explorer export file.

MQ Explorer Export menu

The menu option to export MQ Explorer settings

To export your configuration from MQ Explorer, right-click on the top level folder in the left-hand navigation pane, and choose Export MQ Explorer Settings…

This will bring up a dialog for Export. Press Next on the first panel, then on the second panel you can indicate where you want the XML file to be written and what you want to be exported. MO71 will only import the Sets and Remote queue manager information, but will not complain if there is other information in the XML file, so you can go ahead and export it all if you wish.

MO71 doesn’t import local queue managers from an MQ Explorer export file since you can import local queue managers directly in MO71 as discussed in an earlier post.

MO71 Import MQ Explorer Menu

The menu to import queue managers

Once you have your exported XML file from MQ Explorer, you can drive the import from the MO71 File menu, which then brings up a dialog.

In this dialog, navigate to the location where you exported your MQ Explorer settings and click on Read MQ Explorer XML File.

MO71 Import MQ Explorer Dialog

Import MQ Explorer Locations Dialog – choose your queue managers

The list below will show all the queue managers that were found in the MQ Explorer XML file. If any of the found queue managers are already locations in MO71, the Explorer entry will have a ‘no entry’ symbol beside it showing it cannot be added again. You can click on any others to indicate you wish to import them and the red cross will change to a green tick.

If you were using Sets to group your queue managers in MQ Explorer, you can choose to have those associations imported into MO71 as well. MO71 has several grouping concepts (as described in Can you see your QMgr for the trees?). A queue manager can be in a single group on the main window, and it can be in multiple Networks, which are used in various places where queue managers are listed in MO71. Since a queue manager could be in multiple MQ Explorer Sets, you can choose whether to translate this part of the configuration into Network names or the first one into a QM Group, or both.

Once you have selected all the ones you want, click on Import, and you’re done.

And of course, just as with imported local queue managers, and queue managers imported from a CCDT file, you can edit the imported ones after the locations are created to change the location labels and any other settings.


The new version can be downloaded from the MO71 Download Page. 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.

Migrating a Queue Manager?

If you’re planning to migrate a queue manager, from one machine to another, or perhaps you’re consolidating some queue managers onto an MQ Appliance, you are probably aware of, and have even become familiar with, the steps required to export your object definitions and recreate them on the new queue manager. There are a number of tools available that can do this for you – including those from MQGem.

What about your messages though?

While it’s generally a good idea to reduce the load, and drain off as many messages as you can prior to migrating a queue manager. For example if it’s in a cluster, suspend it from the cluster before the move, to reduce the number of messages heading its way. Let all the applications drain the queues of messages and so on. However, it’s not always possible to drain every last message from all your queues.

QLOAD Offload all queuesIn the latest version of QLOAD, V9.0.1, there’s a new feature that will help out when migrating a queue manager. It allows you to unload the messages from all your queues, with one command. And then you can load the messages onto the queues on another queue manager, with one command (or piecemeal if you prefer). You would combine this with your favoured object definition export tool, and before loading the messages, you’d first recreate the queues on the new queue manager with the exported commands.

Here’s an example of QLOAD unloading all the queues on my queue manager.

qload -m MQG1 -i* -f*

The command will produce the following output to show what has been unloaded. Using the -i (lower case) flag means that the messages are only browsed on the queues and are not destructively removed.

APP1.INPUT                                           2  Done.
APP1.RESULT                                         10  Done.
APP2.INPUT                                           1  Done.
APP2.RESULT                                          4  Done.
Q1                                                  28  Done.
Q2                                                  42  Done.
SYSTEM.ADMIN.QMGR.EVENT                              7  Done.
SYSTEM.AUTH.DATA.QUEUE                             126  Done.
SYSTEM.CHANNEL.SYNCQ                                 3  Done.
SYSTEM.CHLAUTH.DATA.QUEUE                            5  Done.
SYSTEM.CLUSTER.REPOSITORY.QUEUE                      3  Done.
SYSTEM.DURABLE.SUBSCRIBER.QUEUE                      1  Done.
SYSTEM.HIERARCHY.STATE                               2  Done.
SYSTEM.INTER.QMGR.FANREQ                             1  Done.
SYSTEM.RETAINED.PUB.QUEUE                            2  Done.
WORK.REQUEST                                         7  Done.

Total : 7 Queues, 94 Messages
 plus : 9 System Queues, 150 Messages

Listing the directory where I ran the qload command, I can now see I have a file for each queue, with an extension .qld. If you prefer to have a different extension then you can alter the command accordingly. For example, use -f*.txt.

I can copy these files to another machine, or simply use a client connection to the other machine accordingly. Then I can run the following QLOAD command to load the messages onto the new queue manager.

qload -m MQG1 -o* -f*

QLOAD will make some checks when you run a load for multiple queues in this way. It will check that all the queues exist that it has files for in the directory matching the file pattern you specified (which assumes an extension of .qld if you just use ‘*’), and it will check that all those queues are empty. If it finds any problems it will report as follows:-

APP1.RESULT                            RC(2085) Unknown object name.
APP2.RESULT                            Not empty.

There are potential problems with these queues.
Are you sure you want to continue?

This lets you know to go and define the missing queues if you need them – there are messages to go onto them so the assumption is that you do need them. It also warns you of non-empty queues. Now if you’ve already started using this queue manager, you might be expecting this situation, but otherwise, you should rectify it, and then re-run QLOAD.

APP1.INPUT                                       2     Done.
APP1.RESULT                                      10    Done.
APP2.INPUT                                       1     Done.
APP2.RESULT                                      4     Done.
Q1                                               28    Done.
Q2                                               42    Done.
WORK.REQUEST                                     7     Done.

Total : 7 Queues, 94 Messages

You’ll notice that this output does not mention the SYSTEM queues that were offloaded. A generic upload will not upload most SYSTEM queues.
SYSTEM.CLUSTER.TRANSMIT.QUEUE and SYSTEM.DEAD.LETTER.QUEUE are the exceptions. The messages were unloaded to files though, so if you really need to load them you can do so the traditional way, by specifying the full queue name on the command and not using the generic upload.


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

Mini-Health Check for your Queue Manager

MO71 HealthcheckYou can pay expert IBM MQ consultants to do a full health check of your queue managers, but in between such events, or even in preparation for such events, how about running a mini-health check of your queue managers without the expense of consultation hours?

MO71 will look for a number of problems in your set of queue managers. Not just problems in an individual queue manager, but also the resolution of the various IBM MQ objects that refer to other objects, for example, from QREMOTE to transmission queue to sender channel to receiver channel to target queue across multiple queue managers.

MO71 HealthCheck Queue Resolution

MO71 will follow the resolution of your queues across queue managers.

Do you have a naming convention? Great! Do all your queue managers stick to it? MO71 will check that for you too.

MO71 HealthCheck Queue Naming

Tell MO71 your naming convention and it will check whether you have any objects not following it.

In order to have MO71 run these checks against your queue managers, open the Network view, and after selecting the list of queue managers you are interested in from the Queue Managers list, look at the Verify view. For each queue manager, you can open up the twisty labeled ‘ Problems’ to see the various things MO71 has detected.

MO71 HealthCheck Network View

Chosen queue managers in the left window; Verify view with problems in the right window.

If there are any of the problems that you don’t want to include in the check, you can deselect them from the Problems list. This is also the view that allows you to see all the problems that are looked for by MO71.

MO71 HealthCheck Problem Selection

The current list of problems checked for by MO71. Can you think of any others you would like to see?

If you have fixed any of the problems, you can refresh the data that the analysis is based on from the Action menu to see if you’ve fixed them all. Alternatively you can click on the database icon next to the queue manager name to only refresh the data from a single queue manager. If you’ve changed the problems being checked for, you can also Re-analyse the problems without retrieving new data from the queue manager.

MO71 HealthCheck Refresh Data

Use the Action menu to request data is Re-analysed, or refreshed from the queue manager.

As you can see, there are quite a number of things that MO71 can check for you, and it’s quick and easy. You simply need to tell MO71 where your queue manager is by adding it as a location into the tool, and then you can use it to detect these problems.


This is not a new feature of MO71. You already have it in the version you’re using. However, we do add new problems to be checked for from time to time. If you would like to see other things checked by MO71 to add to a mini-health check, please drop us a line or add a comment below.


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.

What’s in Command Levels 90x

MQ90x StairsIBM MQ released Long Term Support release V9.0.0 back in June 2016 which had a Command Level of 900. The subsequent Continuous Delivery releases, V9.0.1, V9.0.2 and V9.0.3 have each introduced their own Command Levels, 901, 902 and 903 respectively.

This post captures the changes that are available in each of those Command Levels.

Release Command Level Features protected by Command Level – details below
V9.0.0.0 900 AMS Protection Policy enhancement – Confidentiality Policy
LDAP Authorization on Windows
V9.0.1 901 No changes protected by Command Level
V9.0.2 902 Log management features
V9.0.3 903 No changes protected by Command Level

AMS Protection Policy enhancement – Confidentiality Policy

With the introduction of Confidentiality Policies in Command Level 900, there is a new attribute on the Set Policy command. A confidentiality policy has no signature algorithm, but does have a encryption algorithm. The Key Reuse feature is applicable to this type of policy. Jon Rumsey has a great write-up of this IBM MQ V9 feature on the MQDev blog, MQ V9 Fast encrypted messages with MQ – Introducing AMS Confidentiality Policies.

AMS Policy

New Attribute MQSC name
See SET POLICY
Look for KC 9000 indicator
PCF constant and values
See Set Policy
Look for KC 9000 indicator
Key Reuse

KEYREUSE

  • DISABLED
  • UNLIMITED
  • 1 – 9999999

MQIA_KEY_REUSE_COUNT (267)

  • MQKEY_REUSE_DISABLED (0)
  • MQKEY_REUSE_UNLIMITED (-1)
  • 1 – 9999999

LDAP Authorization on Windows

Introduced in Command Level 801 on Unix, this feature extended the V8.0.0 Connection Authentication feature which checked your user ID and password, to allow LDAP authorization as well. The fields now available on Windows are the same as those noted in the earlier post for Command Level 801, and are not repeated here.

Log management

With the introduction of Automatic management of linear log extents, and Automatic writing of media images, in Command Level 902, there are new attributes on the queue manager object, queue manager status, and one on queue objects. Mark Whitlock has written about this in an MQDev Blog Post: Logger enhancements for MQ v9.0.2.

Queue Manager Object

New Attribute MQSC name
See ALTER QMGR
Look for KC 902 indicator
PCF constant and values
See Change Queue Manager
Look for KC 902 indicator
Image Schedule

IMGSCHED

  • AUTO
  • MANUAL

MQIA_MEDIA_IMAGE_SCHEDULING (268)

  • MQMEDIMGSCHED_AUTO (1)
  • MQMEDIMGSCHED_MANUAL (0)
Image Interval

IMGINTVL

  • 1 – 999 999 999
  • OFF

MQIA_MEDIA_IMAGE_INTERVAL (269)

  • 1 – 999 999 999
  • MQMEDIMGINTVL_OFF (0)
Image Log Length

IMGLOGLN

  • 1 – 999 999 999
  • OFF

MQIA_MEDIA_IMAGE_LOG_LENGTH (270)

  • 1 – 999 999 999
  • MQMEDIMGLOGLN_OFF (0)
Image Recover Object

IMGRCOVO

  • NO
  • YES

MQIA_MEDIA_IMAGE_RECOVER_OBJ (271)

  • MQIMGRCOV_NO (0)
  • MQIMGRCOV_YES (1)
Image Recover Queue

IMGRCOVQ

  • NO
  • YES

MQIA_MEDIA_IMAGE_RECOVER_Q (272)

  • MQIMGRCOV_NO (0)
  • MQIMGRCOV_YES (1)

Queue Manager Status

New Attribute MQSC name
See DISPLAY QMSTATUS
Look for KC 902 indicator
PCF constant and values
See Inquire Queue Manager Status
Look for KC 902 indicator
Archive Log Extent Name

ARCHLOG

MQCACF_ARCHIVE_LOG_EXTENT_NAME (3208)

  • String of length MQ_LOG_EXTENT_NAME_LENGTH (24)
Archive Log Size

ARCHSZ

MQIACF_ARCHIVE_LOG_SIZE (1416)

Media Log Size

MEDIASZ

MQIACF_MEDIA_LOG_SIZE (1417)

Restart Log Size

RECSZ

MQIACF_RESTART_LOG_SIZE (1418)

Reusable Log Size

REUSESZ

MQIACF_REUSABLE_LOG_SIZE (1419)

Archive Log In Use

LOGINUSE

MQIACF_LOG_IN_USE (1420)

Archive Log Utilization

LOGUTIL

MQIACF_LOG_UTILIZATION (1421)

Reset QMgr command

Updated attribute MQSC name
See RESET QMGR
Look for KC 902 indicator
PCF constant and values
See Reset Queue Manager
Look for KC 902 indicator
Action

TYPE

  • REDUCELOG
  • ARCHLOG

MQIACF_ACTION (1086)

  • MQACT_REDUCE_LOG (10)
  • MQACT_ARCHIVE_LOG (11)
Archived Log

ARCHIVED

MQCACF_ARCHIVE_LOG_EXTENT_NAME (3208)

  • String of length MQ_LOG_EXTENT_NAME_LENGTH (24)
Log Reduction

REDUCE

  • AUTO
  • ONE
  • MAX

MQIACF_LOG_REDUCTION (1422)

  • MQLR_AUTO (-1)
  • MQLR_ONE (1)
  • MQLR_MAX (-2)

Queue Local and Queue Model

New Attribute MQSC name
See DEFINE queues
Look for KC 902 indicator
PCF constant and values
See Change, Copy, and Create Queue
Look for KC 902 indicator
Image Recover Queue

IMGRCOVQ

  • NO
  • YES
  • QMGR

MQIA_MEDIA_IMAGE_RECOVER_Q (272)

  • MQIMGRCOV_NO (0)
  • MQIMGRCOV_YES (1)
  • MQIMGRCOV_AS_Q_MGR (2)

You can get the equivalent information for earlier Command Levels from these posts.

Visibility of QMgr’s Server in MO71

The MO71 product allows you to administer queue managers that are both local and remote to the machine where it runs. When remote, you can connect in via mode, or in client mode. Since WebSphere MQ V7.1 was released, queue managers could be configured as multi-instance, and client connections could be made with a comma-separated list of hostnames (and ports) in the CONNAME field.

This comma-separated CONNAME has been available to use in MO71’s direct client configuration since that time. You can also make MO71 client connections using a CCDT if you prefer.

When using a comma-separated list of hostnames, it is useful to know which of the hostnames you actually managed to connect to, perhaps so you can have a quick view of which machine is currently the primary in order to log into the machine directly, or because you have a preferential Primary and Backup machine and you need to know when the Backup is in use.

MO71 Client configuration

MO71 Client configuration for Multi-instance queue manager

MO71 showing multi-instance annotation

MO71 showing multi-instance annotation

When configuring the list of hostnames in MO71’s client connection dialog, you can now optionally add a string to be displayed when that hostname is the one successfully connected to. You don’t have to include the string for each hostname. You may prefer to only have the annotation on the screen when the Backup server is in use and so would omit the string for the primary hostname and add it to the secondary hostname.

Here are a few examples

Connection Name : win9.mqgem.com(1701) “Primary”, win12.mqgem.com(1701) “Secondary”
Connection Name : win9.mqgem.com(1701), win12.mqgem.com(1701) “**Backup**”

Note that you must configure the client channel directly for this annotation to work. You cannot, for example, use a channel defined in the Client Channel Definition Table (CCDT).


Comma-separated CONNAME has been in MO71 for a while, but the recent 9.0.2 release added the ability to see which of the instances is in use.

Can you see your QMgr for the trees?

When you have a lot of queue managers to manage, if you’re not careful it can get to point where you can’t see the wood for the trees. Where’s that queue manager I’m after/need to make a change to/have just been phoned about?

MO71 is capable of managing hundreds of queue managers, but you don’t have to spend your time scrolling down a very long list of queue managers looking for the one you want. There are several ways that MO71 allows you to organize your queue managers.

MO71 Main Window - Grouped QMgrs

MO71 Main Window showing Grouped QMgrs

Grouping

The main window of MO71 shows all your queue managers, and to arrange that otherwise long list, you can organize your queue managers into groups. A group name is set in the location dialog, along with the queue manager name and connection details (see the screenshot below).

Import and Set Group name

Set the Group name during import

You can also choose a group name when you import queue managers from the local machine, or from a CCDT, allowing your newly imported queue managers to be immediately placed in an appropriate group.

Network Names

MO71 Network View

MO71 Network View with one network selected

In addition to putting a queue manager in a group, you can also put each queue manager into one, or many, networks. Networks are other groupings of queue managers and can be anything you like, but some examples include by platform; by environment, for example, Devt, Test, QA, Production; or by application group. Clearly these would all overlap, you could have a Windows queue manager in the QA environment for the Sales application group. Adding that queue manager to all three networks then allows you to filter your queue manager list by any or all of these. As you’ll see in a moment, you can search by these network names, but they are also used for choosing which queue managers are shown in the network display.

MO71 Location Dialog

MO71 Location Dialog showing a group name and multiple network names.

Searching for queue managers

MO71 Main Window Search

MO71 Main Window with the Search bar

There are a number of places in MO71 where you can search for queue managers in the list. First there is the main window. If the search bar is not visible at the top of the list, enable it from the View menu. In this search bar you can reduce the queue managers shown temporarily by typing in a search string which can be part of the queue manager name, the queue manager location, the group name, the network name or the client connection name.

MO71 will remember your last 20 searches, so after you’ve used them once you’ll be able to select them from the drop-down list.

The other place this is useful is on a multi-queue manager list dialog. Again, typing your search string temporarily reduces the queue managers shown, and you can use buttons to easily add those shown to the dialog with one click.

MO71 Multi-QMgr queue list dialog

MO71 Multi-QMgr queue list dialog with search string

If you have a search string present in the main window when you open a list dialog, it’s search bar is initially populated with the same search string.

In both these locations you can explicitly search a specific field by qualifying your search string, for example adding “<net>” to indicate you only want to search network names.

Location Dialog Field Qualifier Qualifier Shortform
Queue Manager name qm m
Queue Manager Location loc l
Group Name grp g
Network Names net n
Client Connection Name conn c

When you use one of these qualifiers it should be specified between < and > characters.

So, don’t struggle with scrolling long lists of queue manager names, get your queue managers organised into groups and networks.


Most of these features have been in MO71 for a while, but the recent 9.0.1 release added the search bar to the multi-queue manager list dialog

Only run MQSC script on intended Queue Manager

Correct QMgr?IBM MQ is a robust product and queue managers can run without problems for months, or even years at a time. In fact, often when problems do occur they are the result of human error, and one example of such as error can be running an MQSC script against an unintended queue manager.

I think we have all pushed an MQSC file into the wrong queue manager. 😦

So, the question was asked, how can I ensure that I only run my MQSC script against the queue manager it was intended for?

This is something that MQSCX can help you with. There are a few ways you can do this.

Check that you are connected to the correct queue manager

One way to protect against running an MQSC script against the wrong queue manager is to start the script with a quick test to see which queue manager it is currently connected to and to exit the script immediately if it is found to be administering the wrong one.

if ( _qmgr != "QM1" )
  print "Wrong queue manager! Script expects to be used on QM1"
  leave
endif

_qmgr is an MQSCX system variable that tells you which queue manager you are administering. There are also some others that might be helpful when coding up checks at the start of a script, _connqmgr tells you which queue manager you are connected to, and will be different from _qmgr if you are using a via connection. _client tells you if you are connected as a client. You can see these in action in the DISPLAY DQM for Distributed blog post.

You could also make the check broader and have it query some attribute of the queue manager to determine if it was an appropriate queue manager to run the script against. For example, looking for the word “(Test)” in the queue manager description. This means a script couldn’t accidentally be run against one of your production queue managers. Using this simple technique, each script can be limited to a class of queue managers; Production, Test, Devt and so on.

DISPLAY QMGR DESCR
if (!findstr("(Test)",DESCR))
  print "Queue Manager",_qmgr,"does not appear to be a test QMgr"
  print "Queue Manager",_qmgr,"DESCR(",:n:DESCR,:n:")"
  leave
endif

Have the script connect to the appropriate queue manager

As an alternative, rather than having the script check that the human running it has used the correct queue manager, the script could make the connection itself.

=conn qm(QM1)
if (_lastrc)
  leave
endif
ALTER QMGR ...
DEFINE CHANNEL ...

A script with commands for different queue managers

Having made a script that connects to the correct queue manager before running the commands against it, it is not difficult to make the next step where you can have a script that issues commands on multiple queue managers – has a section for each queue manager prefixed by an =conn command.

=conn qm(QM1)
ALTER QMGR ...
ALTER CHANNEL ...
 
=conn qm(QM2)
ALTER QMGR ...
ALTER QLOCAL ...
 
=conn qm(Q3)
ALTER QLOCAL ...

This is only scratching the surface of what MQSCX can do, but it can certainly make administration of your IBM MQ queue managers less error prone.


If you’re not a current MQSCX licence holder, and you’d like to try out MQSCX, please email support@mqgem.com to request a trial licence.


I was prompted to write this post as a result of this list-server question.