+

Search Tips | Advanced Search

Migrating on UNIX and Linux: side-by-side

Side-by-side migration is the term used to describe installing a later version of IBM MQ alongside an earlier version on the same server. Queue managers remain running during the installation and verification of the later version of IBM MQ. They remain associated with the earlier version of IBM MQ. When you decide to migrate queue managers to the later version of IBM MQ, you stop all queue managers, uninstall the earlier version, and migrate them all to the later version of IBM MQ.


Before starting

Attention: From IBM MQ Version 9.0, the ccsid_part2.tbl file replaces the existing ccsid.tbl file, used in previous versions of the product, to supply additional CCSID information. The ccsid_part2.tbl file takes precedence over the ccsid.tbl file and:

  • Allows you to add or modify CCSID entries
  • Specify default data conversion
  • Specify data for different command levels

The ccsid_part2.tbl is applicable to the following platforms only:

  • Linux - all versions
  • Windows

If we have added any of our own CCSID information into your existing ccsid.tbl file, we should copy this information into the new ccsid_part2.tbl file, if we want to take advantage of the new formats in your customizations

We should copy the required information, rather than move the information, so that your existing version of IBM MQ continues to work.


In the side-by-side migration scenario, you install the later version of IBM MQ alongside queue managers that continue to be associated with the installation of the earlier version of the product.

When we are ready to migrate the queue managers, and applications, to the later version:
  1. Stop all the queue managers.
  2. Uninstall the earlier version of the product.
  3. Migrate all the queue managers and applications to the later version.


Procedure

  1. Install the later version in a different installation directory from the earlier version.
    1. Decide on an installation naming convention. Give the installation a name of our choosing, or accept the default installation name. For the first installation, the default name is Installation1. For the second installation, the name is Installation2, and so on.

      On AIX there is no option to set the installation name, Installation1 is set by default.

    2. Verify the installation.

      Run the installation verification procedures and your own tests.

  2. Uninstall the earlier version of the product.

    • When uninstalling the earlier product, we must stop all queue managers and applications that have loaded an IBM MQ library on the server. For this reason, you might choose to postpone uninstalling the earlier version of the product until a convenient maintenance window. When an earlier version of the product is not installed on a server, it is sufficient to stop the queue managers and applications that have loaded libraries from the installation that we are uninstalling or updating. It is not necessary to stop applications and queue managers associated with other installations.

    1. Stop all applications that have loaded IBM MQ libraries on the server.
    2. Stop the queue managers and listeners on the server.
    3. Uninstall the earlier version of the product.

      • Stop all local IBM MQ applications
      • You do not need to stop all the queue managers at this point.

        For migration from IBM WebSphere MQ Version 7.0.1 to a later version, we needed to stop all your queue managers and listeners, ensuring that you did not delete the queue managers. However, this does not apply to migration from a later version than IBM WebSphere MQ Version 7.0.1.

  3. Make the later version of the installation the primary installation.
    1. Run the setmqinst command 
      Inst_1_INSTALLATION_PATH/bin/setmqinst -i -n Inst_1

    • Make the installation primary to avoid specifying a search path to run IBM MQ commands.
    • If there is a primary installation, UNIX and Linux applications that expect to find the IBM MQ library in /usr/lib, find a symbolic link to the library in /usr/lib/32 1 . /usr/lib/32 is normally in the default search path. It is also specified as a load path in the IBM MQ build scripts for UNIX and Linux.
    • It is sufficient to link applications only to /usr/lib. With a primary installation of the later version of the product defined on the server, an application can connect to any queue manager associated with any installation on the server. IBM MQ loads the correct library for the application.

    Use the dspmqinst command to discover the Installation name, or use the default value Installation 1.

    Doing this means that we do not have to specify a search path on IBM MQ commands.

  4. Start the queue managers and applications.

    • When an application connects to a queue manager, the operating system searches its load path to load the IBM MQ library 2 . A Version 7.1, or later, library contains code that checks that the queue manager is associated with an installation. If a queue manager is associated with a different installation, IBM MQ loads the correct IBM MQ library for the installation the queue manager is associated with.

    During this process you continue to use queue manager QM2 while you upgrade queue manager QM1 and we use queue manager QM1 while you upgrade QM2.

    Note that each queue manager needs to be stopped in order to be associated with the new installation.


What to do next

We cannot reinstall an earlier version of the product on a system that has the latest, or any other, version of IBM MQ installed.

Parent topic: Migrating a queue manager to a later version on UNIX and Linux


Related tasks

1 /usr/lib for 64 bit applications.2 On Windows, the IBM MQ library is a DLL. A DLL is sometimes called a load library or a shared library. The entry points to a DLL are defined in a link library, with the file extension .lib32 or .lib. The .lib library is linked at build-time and the DLL loaded at runtime.

Last updated: 2020-10-04