Queue sharing group migration
We can combine queue managers from different releases in a queue sharing group. Limit the amount of time you manage a queue sharing group with queue managers at different versions, to only as long as it takes to migrate all the queue managers to the same version. We cannot combine a queue manager at Version 9.2.0, or later, in the same queue sharing group as queue managers earlier than Version 9.0.0.
Queue managers running at Version 9.0.n, Version 9.1.n, and Version 9.2.n LTS and CD releases (where n is greater than or equal to 0) can coexist in a queue sharing group.
When we migrate queue managers in a queue sharing group, aim to migrate all the queue managers to the new version as soon as we can. Queue sharing groups can contain queue managers with a restricted set of different versions. This is supported so that we can migrate and test the upgrade of each queue manager.
Queue sharing groups with queue managers at different versions are harder to administer, than if all the queue managers are at the same version.
Migrate each queue manager, one at a time, leaving the queue sharing group running. At no stage is an outage of the entire queue sharing group required.
Migrating each queue manager comprises the bulk of the work of migrating a queue sharing group. Approach migrating a queue sharing group as requiring some extra tasks that must be performed during the migration of each queue manager. These tasks are listed in Migrating IBM MQ for z/OS - order of tasks as part of the procedure to migrate a single queue manager.
A good approach is to create a migration plan incorporating queue sharing group migration; see Plan to migrate IBM MQ to Version 9.2 on z/OS for further information.
Parent topic: Migrating IBM MQ on z/OS
Related reference
- MQSC commands in a queue sharing group with queue managers at different versions on z/OS
- Properties of objects in a queue sharing group with queue managers at different versions on z/OS
- Queue sharing group coexistence on z/OS