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 and a 1-month trial licence will be sent to you.


Following your naming convention

We all know that we should have a naming convention for our IBM MQ objects (read more about creating one here). Whilst, there will be some IBM MQ users who had the luxury of starting their work with MQ with a naming convention to follow from day 1, I suspect there are many more that retro-fitted a naming convention later. And then there’s sticking to it. It’s all very well designing it, but it’s no use if you don’t follow it when new objects are put in place. Now many MQ users will have very strict policies in place to ensure that naming conventions are stuck to rigidly, but for the rest of us, a helping hand would be very useful.

In V8.0.3 of MO71, a new feature was added to allow you to provide your naming convention in the tool, and have MO71 check it for you as you define new objects; when you run a verify against your objects; and if you do comparisons between two queue managers. All this is based off the global naming pattern you supply in MO71.

To enable use of the naming pattern, open the Preferences dialog, either with Ctrl+P or by choosing menu File->Preferences… The settings you want are on the Naming tab.

MO71 Naming Tab

The preferences dialog, Naming tab, allows the provision of a naming pattern

In the screenshot you can see a number of the pattern features illustrated. There are required sections, surrounded by round brackets, with the | character meaning OR. So these queues must have a name that begins with SIF or IAA or CDO. There is also an optional section, surrounded by square brackets, with a post fix representing test and development, or nothing for the production version. Although these postfixes are part of the global pattern, it is clear that a single queue manager would only be for test or for production and not mixed!

So, for an individual queue manager you can specify this in the location dialog for the queue manager. Open the location dialog, either with Ctrl+O or by selecting the right-mouse context menu and choosing Open Location… for the selected queue manager.

In the location dialog, switch to the Naming tab where you can input a simpler version of the naming pattern just to provide any specifics from the ORed options in the global pattern, for which ones apply to this queue manager. In our picture this is a test queue manager, so all it’s objects have the postfix *.TST

MO71 Naming QMgr Settings

The Naming tab on the Location dialog gets any specifics

Now that we have the pattern set up, both globally and for each queue manager we can make use of various features in MO71 that take note of the pattern.

Stick to your naming convention

MO71 Naming ErrorMO71 Naming WarningHaving set up your naming pattern in MO71, the tool will alert you when you try to define an object which doesn’t match what you said was your naming convention. If this is too harsh a setting for you to start with, the preferences dialog had an option “Only warn when defining a badly named object” which will give you the choice to go ahead with the definition or not.

Verify what is already defined

MO71 Naming Problems

View any objects which don’t match in Network verify

So that’s newly created objects covered, but what about the hundreds of queues and channels I had defined before I got MO71 V8.0.3? To check out your existing objects, you can use the verify feature of the network view. Open the Network display, either with Ctrl+N or by choosing menu View->View Network… You need to select Verify to be in either the left or right hand pane so you can see the problems detected. Ensure that the database icon is green so you know MO71 has some data to analyse, if not you can click on it to get MO71 to go and regather the data. Use menu Action->Re-analyse if you need MO71 to take another look at the data, without regathering it from the queue manager, for example if you have updated the global naming pattern to include something you had forgotten. Now all you need to do is decide what to do about the objects that don’t meet the naming pattern.

Comparing queue managers

With a staged approach to development, test and production of your applications, you may well have a progression of queue managers. As you progress an application from one stage to the next, it would be good to know that you have all the objects it needs defined on the next queue manager to be used. If these naming conventions aren’t exactly the same, say because everything in test is postfixed with TST, then a normal MO71 compare of two queue managers wouldn’t be able to show any differences or missing object definitions. Now that naming patterns are understood by MO71, the comparison dialog also takes them into account, so a queue called SIF.CONTROL.TST would be compared against a queue called SIF.CONTROL on the production queue manager thus allowing you to determine if your test system is truly mimicking your production system.

If this is something you’d like to try out yourself, you can download MO71 from the MQGem website and if you don’t currently have a licence, you may email to request a trial licence.

Naming Convention for MQ objects

IBM MQ Naming Convention BookIf there’s one thing we can say for definite it is that you should have a naming convention for your MQ object names. Beyond that point, there are no rules about what names you should choose (other than those provided by IBM MQ for length and allowed characters). However, there are many recommendations that will help you come up with your naming convention.

When designing the names of your queue objects, consider what it is you need a naming convention to tell you. One important piece of information is the ownership of the queue, which department, and perhaps which application suite it belongs to. So if you have acronyms for these departments or application groups, include these in the object names. The same kind of convention will also be helpful for any processes, namelists and other ancillary objects you define. Then, when something goes wrong, a queue is full for example, it is immediately apparent what department and application it belongs to, and also the possible impact of the problem.

Another consideration is to include a TEST and PROD marker on an object name, especially if there is any likelihood of overlap of connectivity with the systems at all

Some useful tips when putting together a naming convention:

  • Use upper case object names
    While MQ does allow you to have lower and mixed case names, life is simpler and easier to read if you stick to upper case names. There is no confusion on case, no requirement to remember to put quotation marks round the names in scripts, and no issues using any names across different platforms.
  • Stick to numbers, letters and the dot character
    While MQ does allow a few other punctuation characters, like %, avoiding all except the dot will leave you assured that no matter which platform you are on, and which security profiles you wish to use, it will always work.
  • Avoid the dot in queue manager names
    While the dot is fine in object names to separate up sections of the name, avoid using it in queue manager names, thus making your channel names more easy to understand.
  • Always use the description field
    You’re not saving any space by not using it. MQ will store 64 blank characters so use it, and aid your object documentation by explaining what the object is there for, right on the object!
  • NEVER begin objects with SYSTEM
    The namespace starting SYSTEM is reserved for use by IBM MQ. Who knows when a new version might use a name you’ve started using? Just don’t risk it. Keeps the security simpler as well.
  • Keep queue manager names short
    While you may have a whole 48 characters available from IBM MQ, you don’t have to use it all! Imagine what you’d like to have to type in at a console when starting, ending or administering queue managers, and stick to that length. Keeping to 9 or less characters helps with channels (see below).
  • Include user name in dynamically created queues
    Applications which create dynamic queues should follow the above guidelines, but additionally include the user name running the application in the generated name. This then allows an administrator to determine which instance of an application is, for example, not tidying up its dynamic queues properly. The generated name is kept unique by allowing the queue manager to complete the name you supply as a prefix, by adding a unique timestamp.

Additionally, when thinking about channel names:-

  • Include both queue managers in a channel name
    For channels that are point to point, you can have the luxury of naming both sending and receiving channels in the channel name. In general, stick with a de facto standard of have the sending queue manager first and then the receiving queue manager with a dot separator. Assuming you haven’t put any dots in your queue manager names, then there will only be one dot in the channel name and this will make it very clear which queue managers are connected by this channel. Remember that channel names are only up to 20 characters, hence the limitation suggested on queue manager names.
  • At minimum include the receiving queue manager name in a channel name
    If you use generic receivers, then having the sending queue manager name as part of the channel name is not useful. Where above having TO between the queue manager names doesn’t add anything, and removes a few precious characters, for generic receivers, you might consider a pattern that is TO.<QMgr‑name>, or alternatively, <QMgr‑name>.RCVR (where normally it would not be expected to add object types to the name).
  • Include the cluster name in cluster channels
    It is best practice to only ever use one cluster per channel name (avoiding the CLUSNL keyword on channels completely). This allows channels to be controlled independently for different clusters, thus ensuring that there is no reliance, or impact shared by clusters just because of a common channel. This best practice allows you to then add the cluster keyword to the channel name which means you have immediate awareness of which cluster is impacted when you see a channel having connectivity issues for example.

I hope these guidelines help you with designing the naming convention that suits your business and your MQ applications. A naming convention will help your business by:-

  • making it easier to find objects
  • allowing an understanding of the purpose of objects at a glance
  • easing the creation of security profiles
  • reducing errors caused by using the wrong resource
  • allowing environments to be easily replicated

There is no single naming convention that everyone SHOULD use. But everyone should have a naming convention. If you want help sticking to your naming convention read “Following your naming convention”.

Great additional resources to read when considering your IBM MQ Naming Convention

IBM Certified Specialist

Morag Hughson is a Certified IBM MQ Specialist
IBM Certified System Administrator – MQ V8.0
Find her on: LinkedIn: Twitter: SlideShare: