Steps to export the object definitions and messages from one IBM MQ queue manager in host-1 and import them in another queue manager in host-2? (dmpmqcfg, saveqmgr)

Steps

+++ Copying the object definitions and authorizations (and optionally, the messages) - this is portable across different platforms.

This is a general procedure for "moving" a Queue Manager from one server to another server.
It uses the following tools:

a) Export the object definitions from host-1:

- MQ 7.0: The SupportPaC MS03 (saveqmgr) - only when the source queue manager is at 7.0 (and there are no restrictions on the version of the target queue manager)

- MQ 7.1 or later: The new command "dmpmqcfg" added in MQ 7.1. (Note: saveqmgr cannot be used with MQ 7.1 or later queue managers)
Please note that only the definitions of the objects from the queue managers will be moved. That is, the data (messages) from the queues will NOT be moved.

b) (Optional) Export the messages from host-1:
If you want to move the messages you can use another tool:

- MQ 7.0, 7.1 or 7.5: the qload utility from the following SupportPac:
https://www.ibm.com/support/pages/node/467731
Example of using the qload utility (SupportPac MO03: WebSphere MQ Queue Load / Unload Utility)

- MQ 8.0, 9.0: In MQ V8, the functions of "qload" were included in the new tool "dmpmqmsg" which is shipped with MQ.

c) The tools dmpmqcfg / saveqmgr do not capture the information from the qm.ini file. 
Thus, when you create the target queue manager, you will need to use the proper crtmqm options regarding the logging (circular, number of primary / secondary logs, etc) that the source queue manager had.
Some items in the qm.ini file cannot be specified as options to crtmqm and will need to be manually added after the queue manager is created, such as the CHANNELS stanza (and other stanzas).


++
++ Part 1:  Activities to be done at the source server machine:
++

1) Remove the queue manager from any MQ clusters.
This step is VERY IMPORTANT! Otherwise you will have 2 different queue managers (QMIDs) in the cluster, but with the same name, which will cause a lot of confusion!

https://www.ibm.com/docs/en/ibm-mq/9.3?topic=cluster-removing-queue-manager-from
IBM MQ / 9.3
Removing a queue manager from a cluster

2) Obtain a backup of the object definitions and authorities (and if desired, messages from non-system queues).

2.a) For MQ V6 and 7.0: Use the saveqmgr command to capture the object definitions and authorities. This utility is provided with the following SupportPac:
    MS03: WebSphere MQ - Save Queue Manager object definitions using PCFs
NOTE: This SupportPac has been withdrawn. Please contact MQ Support for a copy of the latest code.
Example: The following saves both the objects (-f) and the authority records (-z). You need to replace "QMgr" for the name of your queue manager:
  Unix:    saveqmgr -m QMgr -f /tmp/mq/QMgr_data.mqsc -z /tmp/mq/QMgr_auth.sh
  Windows: saveqmgr.exe  -m QMgr -f C:\temp\mq\QMgr_data.mqsc -z C:\temp\mq\QMgr_auth.bat
.
2.b) For MQ 7.1 or later:
The dmpmqcfg tool is new in MQ 7.1 and it is an alternative to the SupportPac MS03.

You need to replace "QMgr" for the name of your queue manager:

2.b.1) Capture the data. Specify all attributes (includes also the AUTHRECs for setmqaut)
  dmpmqcfg -m QMgr -a > QMgr.dmpmqcfg.out.all.mqsc

2.b.2) Capture the authentication records in setmqaut format
  Windows:  dmpmqcfg -m QMgr -o setmqaut > QMgr.dmpmqcfg.setmqaut.bat
  Unix:     dmpmqcfg -m QMgr -o setmqaut > QMgr.dmpmqcfg.setmqaut.sh

Notes:
- The output file from saveqmgr or dmpmqcfg is a text file, and you can modify its contents.
- The output file that has the setmqaut commands and it can be run as a batch/script file. It includes the name of the queue manager in each command. Thus, if you want to restore the commands into a different queue manager, you will need to edit the file and specify the desired queue manager name.

2.c) (Optional) You may want to preserve messages from certain non-SYSTEM queues.

2.c.1) For MQ V6, 7.0, 7.1 and 7.5: you can use "qload" to download the messages from a queue into a file, copy the file to the other system, and then use "qload" again to upload the messages from the file into a queue.

https://www.ibm.com/support/pages/node/467731
Example of using the qload utility (SupportPac MO03: WebSphere MQ Queue Load / Unload Utility)

2.c.2) For MQ V8, V9: you can use "dmpmqmsg" (which is based on "qload") to download the messages from a queue into a file, copy the file to the other system, and then use "dmpmqmsg" again to upload the messages from the file into a queue.

https://www.ibm.com/docs/en/ibm-mq/9.3?topic=systems-examples-using-dmpmqmsg-utility
IBM MQ / 9.3
Examples of using the dmpmqmsg utility

2.d) Obtain a backup of the qm.ini file (to keep it as a reference for the corresponding changes on the new qm.ini for the target queue manager).
Additional files to take a backup:
- mqat.ini (configuration file for the application activity trace)
- ssl directory with certificates.

2.e) For 7.0: The saveqmgr command does NOT export the AMS Policies.
Thus, in case that you want to export these AMS Policies into a file that is part of backup procedures, you can use the command “dspmqspl” with the -export flag, as shown below.
dspmqspl -m QMgrName -export > restore_AMS_policies.ksh

Note that the dmpmqcfg command does export the AMS policies (in the output file search for "SET POLICY").

3) Stop the queue manager.

4) If there are user exits in the source queue manager, then prepare a tar/zip file with them.

5) Do not delete yet the queue manager. Keep it as a backup, until the transfer is completed and verified. Keep this queue manager stopped, do not restart it.

6) The following advice is only applicable when you are cloning a queue manager, that is, you are not moving the queue manager from host-1 to host-2 and your intention is to keep only 1 queue manager, the one at host-2.
.
It is a best practice to NOT have different queue managers in operation with the same name!
That is, AVOID having an active QMGR1 in host-1 and another different active queue manager also named QMGR1 in host-2. This leads to many headaches!

7) If your intention was to move the queue manager from host-1 to host-2, then, after the move is completed and verified, then delete the queue manager from the source location (host-1) to avoid accidental usage of the old queue manager.

++
++ Part 2: Activities to be done at the target server machine:
++

1) Install the desired version of MQ in the target server machine, and apply latest fix packs.

1.a) Create in the new host, those "groups" and "users" that were used in the old host. For example, if "user1" belonging in group "mquser" in the old host is still expected to access the queue manager in the new host, then that user and group need to exist in the new host.

2) Create a new queue manager.

2.a) If there are user exits in the source queue manager, then get them here and untar the file.
Make sure permissions of the user exits are appropriate (mqm:mqm everywhere).
- Recompile the user exits if the OS in host-2 is different than in host-1, and/or if the version of MQ is different.

3) Start the queue manager:    strmqm QMgrName

4) Copy the output files (qmgr_data.mqsc, qmgr_auth.sh/qmgr_auth.bat, qm.ini,  restore_AMS_policies) onto the new server machine.

- Compare the new qm.ini with the old qm.ini and make any changes from the old that you want to preserve in the new.
 

5) Edit the *.mqsc file as needed:
If you are going to create a new queue manager that has a different name, then you will need to modify the contents of the file to replace the old name with the new desired name.
You should take great care when you copy the object definitions, because some manual modification of the definitions might be needed:
Various attributes need to be checked and might need to be changed. These include:
- IP addresses and ports in channels, listeners, and other objects
- Security information such as user IDs
- startcmd in services
- Various other attributes.
- Durable subscribers that are not administered might lose messages.
- Other queue managers might also need to be changed so that their channels connect to the moved queue manager.
- Old objects no longer used and that should not be recreated
- Authority records (setmqaut) regarding the @class for users/groups that are not "mqm" and that are not going to use anymore the migrated queue manager.
 - Unless you have made explicit modifications to some SYSTEM objects (to use non-default values), then there is no need to recreate the SYSTEM objects in the new queue manager, and can be deleted from the file.

6) Recreate the objects and authorities in the new queue manager.

6.a) If you used saveqmgr (MS03) in the source host:
Redefine your objects:        
   runmqsc TEST < QMgr_data.mqsc
Redefine authorities:  
   In Unix run:    chmod 755 QMgr_auth.sh
                           ./QMgr_auth.sh
   In Windows run: QMgr_auth.bat

6.b) If you used dmpmqcfg (MQ 7.1 or later) in the source host:

6.b.1) To restore the data - play back the commands for runmqsc:
  runmqsc QMgr < QMgr.dmpmqcfg.out.all.mqsc

6.b.2) To restore the setmqaut commands:
Windows: dmpmqcfg.setmqaut.bat
Unix:    chmod 755 QMgr.dmpmqcfg.setmqaut.sh
         ./QMgr.dmpmqcfg.setmqaut.sh

7) If you used "qload" (MQ 7.0, 7.1, 7.5) or "dmpmqmsg" (8.0, 9.0) to download messages into files, then use the same tool to upload them.

8) Visit the remote queue managers that use sender channels that connect to this queue manager:
 - ALTER the CONNAME of those sender channels to reflect the new hostname(port)

9) Reset the sequence number for the sender channels of this queue manager at the new location:
  RESET channel(chan_name) seqnum(1)

10) Add the queue manager back to any clusters it was in.
https://www.ibm.com/docs/en/ibm-mq/9.3?topic=cluster-adding-queue-manager
IBM MQ / 9.3
Adding a queue manager to a cluster
 

+++ end +++