Staging maintenance level updates on Linux
On Linux®, you can use multiple installations of IBM® MQ on the same server to control the release of maintenance level updates.
Before you begin
Inst_1 and
Inst_2, and a number of applications and two queue managers, QM1
and QM2, running on a server. To set up your configuration for this scenario,
complete the following steps:- Install two copies of IBM MQ. In this example, they
are named
Inst_1andInst_2. - Make
Inst_1primary by running setmqinst. - Associate all the queue managers on the server with
Inst_1by running setmqm. - Start all the queue managers on the server.
- Show and connect all direct connections with the queue managers associated with
Inst_1in IBM MQ Explorer. - Set up remote connections to all the queue managers in each instance of IBM MQ Explorer.
- Fix packs, which contain roll-ups of all defects fixed since the previous fix pack delivery (or GA). Fix packs are produced exclusively for Long Term Support (LTS) releases during their normal support lifecycle.
- Cumulative security updates (CSUs), which are smaller updates and contain security patches released since the previous maintenance (GA). CSUs are produced for LTS releases (including releases in extended support), and also for the latest IBM MQ Continuous Delivery (CD) release, as required to deliver relevant security patches.
For maintenance releases in or after 1Q 2023, the fourth digit in the VRMF represents either a fix pack number or a CSU number. Both types of maintenance are mutually cumulative (that is, they contain everything included in older CSUs and fix packs), and both are installed using the same mechanisms for applying maintenance. Both types of maintenance update the F-digit of the VRMF to a higher number than any previous maintenance: fix packs use "F" values divisible by 5, CSUs use "F" values not divisible by 5.
For maintenance releases before 1Q 2023, the fourth digit in the VRMF always represents the fix pack level. For example, the first fix pack of the IBM MQ 9.3.0 LTS release is numbered 9.3.0.1.
For more information, see Changes to IBM MQ's maintenance delivery model.
About this task
You can install multiple copies of IBM MQ on a server to stage the release of IBM MQ maintenance level updates. For example, as in the scenario that is described in the task steps, by using two installations to roll out maintenance level updates, you maintain two maintenance levels on a server, with the aim of getting all queue managers and applications to the production maintenance level before replacing the previous level of maintenance with the next level.
Which installation an application uses is driven by the queue manager that an application connects to. The setmqm command associates a queue manager with an installation. You can associate a queue manager with a different installation as long as the installation is at the same or higher command level. In this scenario, 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 or cumulative security updates (CSUs).
In this scenario, an application links to the primary installation. When it connects to a queue manager, IBM MQ switches the linkage to the installation associated with the queue manager; see Multi-installation queue manager coexistence on AIX, Linux, and Windows.
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 you 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 command,
Inst_2_Installation_path/bin/strmqm QM1 fails.
If you 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.
Procedure
Apply the first maintenance level update to Inst_2.
Apply the second maintenance level update to Inst_1.
For subsequent maintenance fixes, alternate between Inst_2 and
Inst_1.