IBM Support

Steps to export the object definitions and messages from one MQ queue manager in host-1 and import them in another queue manager in host-2?

How To


Summary

What are the steps to export the object definitions and messages from one MQ queue manager in host-1 and import them in another queue manager in host-2?

Environment

NOTE about the withdrawn SupportPacs for saveqmgr and qload mentioned in this article.
.
When dealing with MQ 7.x, the following 2 SupportPacs can be used.
Even though they are labeled as withdrawn, the web pages are active and you CAN STILL DOWNLOAD the code!
You will need to scroll down to the "Download" section.
.
http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg24000673
WITHDRAWN: MS03: WebSphere MQ - Save Queue Manager object definitions using PCFs (saveqmgr)
.
http://www-01.ibm.com/support/docview.wss?uid=swg24009368
WITHDRAWN: MO03: WebSphere MQ Queue Load / Unload Utility
.

 

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:
.
- 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, no data (messages) from the queues will be moved.
However, 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
  http://www.ibm.com/support/docview.wss?uid=swg21585718
  Example of using the qload utility (SupportPac MO03: WebSphere MQ Queue Load / Unload Utility)

.
- MQ 8.0, 9.0: In MQ V8, "qload" was included as the new tool "dmpmqmsg".
.
The tools saveqmgr / dmpmqcfg 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!!!
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.con.doc/q017520_.htm
WebSphere MQ 7.5.0 > WebSphere MQ > Configuring > Configuring a queue manager cluster > Managing WebSphere MQ clusters >
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):
  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.
.
2.b.1) Capture the data. Specify all attributes (includes also the AUTHRECs for setmqaut)
  dmpmqcfg -m QMgr -a > dmpmqcfg.out.all.mqsc
.
2.b.2) Capture the authentication records in setmqaut format
  Windows:  dmpmqcfg -m QMgr -o setmqaut > dmpmqcfg.setmqaut.bat
  Unix:     dmpmqcfg -m QMgr -o setmqaut > 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, 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.
.
http://www.ibm.com/support/docview.wss?uid=swg21585718
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.
.
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.adm.doc/q117770_.htm?lang=en
WebSphere MQ 8.0.0 > WebSphere MQ > Administering > Administering local WebSphere MQ objects > Using the dmpmqmsg utility between two systems >
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).
.
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) It is a best practice to NOT have different queue managers with the same name!
That is, AVOID having QMGR1 in host-1 and another different queue manager also named QMGR1 in host-2. This leads to many headaches!
.
Thus, after the move is completed and verified, then delete the queue manager from the source location to avoid accidental usage of the old queue manager.
.
.
++
++ Part 2: Activities to be done at the target server machine:
++
.
0) Install the desired version of MQ in the target server machine, and apply latest fix packs.
.
1) Create a new queue manager.
.
1.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)
.
1.b) Start the queue manager.
To match the existing queue manager in the other host, you need to use the proper options for crtmqm 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).
.
Create the queue manager:   crtmqm TEST
.
Start the queue manager:    strmqm TEST
.
2) Copy the output files (qmgr_data.mqsc, qmgr_auth.sh/qmgr_auth.bat, qm.ini,  restore_AMS_policies) onto the new server machine.
.
Note:
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.

.
3) Recreate the objects and authorities in the new queue manager.
- 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.
.
3.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
.
3.b) If you used dmpmqcfg (MQ 7.1 or later) in the source host:
.
3.b.1) To restore the data - play back the commands for runmqsc:
  runmqsc Qmgr < dmpmqcfg.out.all.mqsc
.
3.b.2) To restore the setmqaut commands:
Windows: dmpmqcfg.setmqaut.bat
Unix:    chmod 755 dmpmqcfg.setmqaut.sh
         ./dmpmqcfg.setmqaut.sh
.
3.c) 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.
.
4) 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)
.
5) Reset the sender channels of this queue manager at the new location:
 - RESET channel(chan_name) seqnum(1)
.
6) Add the queue manager back to any clusters it was in.
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.con.doc/q017370_.htm
WebSphere MQ 7.5.0 > WebSphere MQ > Configuring > Configuring a queue manager cluster > Managing WebSphere MQ clusters >
Adding a queue manager to a cluster

 

Document information

More support for: IBM MQ

Component: migration

Software version: All Versions

Operating system(s): AIX, HP-UX, Linux, Solaris, Windows

Reference #: 0738087

Modified date: 31 October 2018