Migrating WebSphere MQ Isn't Something That Should Go South
MarkWomack 270000PC6X Visits (5038)
Most migrations (upgrades) of WebSphere MQ go swimmingly, don't they? This is a good thing. But we'd like to see every single one of them fall into that bucket. To that end, it's crucial that you include the following information into your migration plans. This is because migration isn't just about moving forward, but it's also about allowing queue managers to co-exist in configurations where queue-sharing groups commingle data; where different levels of the base code may have been installed; and how to create a migration plan where you can recover your old environment if you happen to hit a snafu or two. As they say, prevention is a worth a pound of cure.
Let's get started. The Level 2 and Level 3 organizations try to publicize as much as possible the list of 'recommended' Migration PTFs that you'll need to accomplish the major points above. This list is not 'all-inclusive' of every single migr
Depending on your migration path, you must install every applicable PTF that involves the release you're moving to and the release you're moving from. This is crucial because, as objects related to the queue manager change in size and use, migration code must be provided to ensure that if you find a need to change releases, the queue manager will still be able to recognize the change in these control blocks and handle them properly. This avoids abends and outages which can even prevent the queue manager from starting at all.
While the WebSphere MQ PSP bucket will duly note recommended fixes as well, fair weight should be given to the list of tables at the above website since these are checked frequently and updated often. They're easier to read too.
As you bring the WebSphere MQ product into house, as of April 2012 the implementation of FIXCAT has taken place for our fixes within SMP/E. What this means to you is the ability to run a report in SMP/E to see what fixes you might be missing which are crucial to queue manager migration. The SMP/E REPORT command looks like this: REPORT MISSINGFIX ZONES(mqtgtzone) FIXC
If you're unfamiliar with the utility of FIXCAT then be sure to give this page a read: IBM Fix category values and descriptions
This above report format will tell you what your missing and, since SMP/E resolves the required PTFs to SOURCEIDs this simplifies processing.
Our recommendation is to run the FIXCAT report regularly as a practice associated with maintenance. Our intent is, if there are future release of WebSphere MQ, to create a new FIXCAT for each new release and to make such information public. Note, however, that no PTF/APAR can be placed into a fix category until after it has closed.
Lastly, keep an eye on the migration technotes that Level 2 and Level 3 regularly update to help you keep tabs on any migration anomalies that we need to fix. You'll find the key technote for WebSphere MQ Version 6, Version 7.0.0, and Version 7.0.1 linked to each other at: Important information relating to migration or installation of MQ for z/OS V6.0, includes highlights of new function
Comparable information for Version 7.1 can be viewed at: WebSphere MQ for z/OS V7.1.0 migration and inst