Queue manager coexistence in Version 8.0

Queue managers, with different names, can coexist on any server as long as they use the same IBM® MQ installation. On [z/OS] z/OS®, UNIX, Linux®, and Windows, different queue managers can coexist on the same server and be associated with different installations.

Single installation queue manager coexistence on all platforms

Single installation queue manager coexistence is useful in development and production environments. In development environments, you can set up different queue manager configurations to support different development activities. You can also work with multiple queue manager configurations on a single server, connected by channels, as if deployed on a network.

In production environments configuring multiple queue manager on a single server is less common. It has no performance or functional advantage over a single queue manager configuration. Sometimes, you must deploy multiple queue managers on server. It might be essential to meet the requirements of a particular software stack, governance, administration, or as a consequence of the consolidation of servers.

Multi-installation queue manager coexistence

Multi-installation 1 queue manager coexistence became available in Version 7.1 on UNIX, Linux, and Windows. Multi-installation queue manager coexistence has always been supported on z/OS.

With multi-installation queue manager coexistence on the same server you can run queue managers at different commands levels on the same server. You can also run multiple queue managers at the same command level, but associate them with different installations.

Multi-installation adds more flexibility to the coexistence of queue managers using a single installation. Any of the reasons behind running multiple queue managers, such as supporting different software stacks, might require different versions of IBM MQ.

The biggest benefit of multi-installation identified by early users, is in upgrading from one version of IBM MQ to another. Multi-installation makes upgrading less risky, less costly, and is more flexible in meeting the migration needs of applications running on a server.

The key to migration flexibility is being able to install a new version alongside an existing installation; see Figure 1, which is extracted from UNIX, Linux, and Windows: Side-by-side migration to a later version.

Figure 1. Side-by-side installation - step 2
A 7.1 installation alongside the running 7.0.1 installation.

When the installation is complete, and verified, migrate queue managers and applications to the new installation; see Figure 2. When migration is complete, uninstall the old installation.

Figure 2. Side-by-side installation - step 4
A running 7.1 installation alongside a 7.0.1 installation.

Think of multi-installation as being the basis for a range of migration strategies. At one end is Single-stage, in which you only have one installation on a server at a time. At the other end is multi-stage migration, in which you continue to run multiple installations at the same time. In the middle is side-by-side migration. Each of the three strategies is explained in these three tasks:

  1. UNIX, Linux, and Windows: Single-stage migration to a later version
  2. UNIX, Linux, and Windows: Side-by-side migration to a later version
  3. UNIX, Linux, and Windows: Multi-stage migration to a later version

Another similar use of multi-installation is to support the migration of queue managers to a new fix level; see Figure 3. You maintain two installations, one of which has the latest fix pack applied, and the other has the previous maintenance levels. When you have moved all queue managers to the latest fix pack level, you can replace the previous fix pack with the next fix pack to be released. The configuration allows you to stage the migrating applications and queue managers to the latest fix pack level. You can switch the primary installation designation to the latest fix pack level.

Figure 3. Rolling fix packs
Two installations: rolling fix pack upgrades to first one installation and then the other.
1 Do not confuse multi-installation queue manager coexistence with multi-instance queue managers. They are completely different, though they sound similar in English.