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.

Advertisements

6 thoughts on “Migrating a Queue Manager?

    • The QLOAD feature in MO71 is a very basic version. There are a number of features in QLOAD that are not part of MO71. Some features of QLOAD lend themselves better to a command line tool, and this is one of those. So it will not be added to MO71.

      Like

  1. Very informative. I have a question. This approach is similar to take the objects backup from old machine and create a queue manager at another machine then execute the objects.
    Why can not we stop the queue manager gracefully at old machine, then take the queue manager directory backup then move to the new machine and start the queue manager. I do feel this approach also can be considerable and well tested approach. Please suggest me.

    Like

    • If you have already have a mechanism for migrating your messages from one Queue Manager to another then that’s great, continue to use it if you wish. We have looked for the official description from IBM on how to do this but can’t find it, Do you have a link you can share ? Our belief is that there are limitations with the directory approach. For example, I wouldn’t want to use it if I was moving the type of server, for example migrating from Linux to Windows or AS/400. It is also a bit all or nothing – you wouldn’t want to restore all SYSTEM queues for example. The QLOAD approach also has the advantage that each queue’s messages are safely stored away in a separate file which you can restore at any time, on any queue manager, if something goes wrong further down the line.

      Like

      • You are right(Your approach is 100% recommended). Apparently, playing with messages is little tedious. As you told, we have option with offload messages from queues to a file then restore to new queue managers. I was referring approach for persistence messages and at the same level of operating system. In this case, if we stop the queue managers then the move the working directory to new server, I hope it should work(as messages will be retained during QMGR restart). in case of different operating systems/other concerns, we don’t have option.
        I have one question. Suppose if I move messages to a file from windows queue manager and recreated a queue manager in AS/400 or other in operating system, if i try to reload the messages from file to a queue, will I get any CCSID problems or any message conversion issues?

        Like

      • When saving messages using QLOAD, the whole MQMD is also saved which naturally includes the CCSID and Encoding. When restoring the messages from a QLOAD file they are restored with the same CCSID and Encoding, therefore the contents of the message are still correctly represented by the CCSID and Encoding. So long as your applications use MQGMO_CONVERT, all will be well (even moving from an ASCII Little Endian machine to an EBCDIC Big Endian machine).

        If however, your applications don’t use MQGMO_CONVERT, and expect the messages that they get to be in the correct CCSID and Encoding already, you can use QLOAD to convert them accordingly when you unload them so that when you load them onto the target system they are already converted. You use the ‑c parameter for this.

        Like

The team at MQGem would love to hear what you think. Leave your comments here.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s