On UNIX and Linux, we can use multiple installations of IBM MQ on the same server to control the release of maintenance
fixes.
Before starting
Set up your configuration modeled on the first row of Figure 1. We can
apply this scenario to any version of IBM MQ from
IBM WebSphere MQ Version 7.1 onwards. In this scenario it is assumed you
have a number of applications and two queue managers, QM1 and QM2,
running on a server. IBM WebSphere MQ Version 7.0.1 is not installed on the server.
Install two copies of IBM MQ. In the example, they
are named Inst_1 and Inst_2.
Make Inst_1 primary by running setmqinst.
Associate all the queue managers on the server with Inst_1 by running
setmqm.
Start all the queue managers on the server.
Show and connect all direct connections with the queue managers associated with
Inst_1 in IBM MQ Explorer.
Set up remote connections to all the queue managers in each instance of IBM MQ Explorer.
We can install multiple copies of IBM MQ on a server
to stage the release of IBM MQ fixes. Figure 1 illustrates a way of using two installations to roll out fixes. In this
approach, you maintain two fix levels on a server, with the aim of getting all queue managers and
applications to the production fix level before replacing the previous level on fix pack with the
next level.
Which installation an application uses is driven by the queue manager an application connects to.
The setmqm command associates a queue manager with an installation. We can
associate a queue manager with a different installation as long as the installation is at the same
or higher command level. In this example, all the installations are at the same command level. You can associate or reassociate a queue manager with either of the installations running any of the fix
packs.
For applications built with the link options described in the product documentation, the simplest
way to configure the link library search path for IBM MQ applications is to make an installation primary. Only if it is important to pick up a fix in the
IBM MQ link library itself, must you review the search
path. Either we must make the installation with the IBM MQ link library fix primary, or make a local adjustment for
the application, perhaps by running the setmqenv command.
Running commands is a different matter. Commands are always run from the primary installation, or
the installation you have selected by running the setmqenv command. If you run a
command from the wrong installation, the command fails. For example, if QM1 is
associated with Inst_1, running the Windows command, Inst_2_Installation_path/bin/strmqm
QM1 fails.
If we are using IBM MQ Explorer and you have two
installations, you also have two IBM MQ Explorer instances.
One linked to one installation, and one to the other. Each IBM MQ Explorer shows locally connected queue managers that are
associated with the same installation as the instance of IBM MQ Explorer. To monitor all the queue managers on a server, set up
remote connections to the queue managers associated with the other installations.
Start the Inst_2 instance of IBM MQ Explorer
Tip: On Windows, hover over the IBM MQ icon in the system tray. The hover help shows the
installation name associated with the IBM MQ Explorer
instance.