I've had a few customers lately that are in a situation where they are still running old unsupported versions of WebSphere MQ. Specifically, a problem arises when they are still on MQ version 5.3 and want to upgrade to a recent version such as 7.1 or 7.5 as there is not direct route for upgrading MQ v5.3 to those versions.

Here are links to migration documentation in the information center:

• For MQ v7.1: Migrating and upgrading WebSphere MQ
• For MQ v7.5: Planning WebSphere MQ version 6.0 to WebSphere MQ version 7.5 migration by platform

If you are still on MQ version 5.3, you should plan a 2 step migration: first migrate to MQ v7.0.1 then migrate to 7.1 or 7.5. This section in the information center entitled "Migrating from WebSphere MQ Version 5.3 to WebSphere MQ Version 7.0" gives information about migration from 5.3 to v7.0.1 and can help you determine the first phase of your 2-step migration.

MQ 7.0.1.3 was provided as a manufacturing refresh (which means that when you downloads files from Passport Advantage, it will be: Base 7.0.0.0 + Fix Pack 7.0.1.3 as one package). See the document entitled "Downloading WebSphere MQ Version 7.0.1 from the Passport Advantage Web site" for details.

Important: You should always take a full backup of your queue manager prior to any upgrade (data and log directories)!

The SupportPac for saveqmgr (MS03: WebSphere MQ - Save Queue Manager) is provided in good faith and AS-IS. There is no warranty or further service implied or committed and any supplied sample code is not supported through IBM product service channels.

However, I would recommend a saveqmgr backup is valuable to have. If not directly loadable into runmqsc due to some attribute changes, the backup file could be edited and still useful if you needed it at some point.

If you are performing the two-step migration then it should not be necessary delete and recreate queue managers, thus the saveqmgr would not be used.

Some other points to consider: Are you using MQ cluster qmgrs? If so and you delete then recreate the qmgrs, that would require you to remove old QMID from cluster and add new QMID if new qmgr is built.

It's important if you have MQ listener configured as inetd.conf, then you need to be sure to disable it.

After you migrate a queue manager to WebSphere MQ Version 7.0, you must start that queue manager to migrate your file system structure before you start any WebSphere MQ listener associated with that queue manager. Otherwise, you will not be able to start WebSphere MQ listeners after migration.

It would be preferable to switch from inetd to runmqlsr with listener object defined. Refer to these webpages for more info:

• Why is runmqlsr now the recommended listener over inetd? (external blog link) to "a Hursley view on WebSphere MQ"
• DEFINE LISTENER command in the information center

By planning a strategy, you should be able to bring your WebSphere MQ queue managers to a current MQ v7 level. The best advice I can give going forward is to keep your systems as up-to-date as possible. This includes applying fixpacks in a timely manner and defining a plan for the future that ensures your software is current and does put your business in the position of running "unsupported" versions.



Tags:  listener migration 7.5 installation upgrade websphere runmqlsr mq 5.3 7.1 7.0.1 wmq install migrate