Post migration tasks

Follow the steps to perform the tasks we need to carry out after migrating a single IBM MQ queue manager on z/OS,

About this task

After you have migrated an IBM MQ queue manager on z/OS we need to carry out the detailed steps in this topic, using the links within this overview.

1. Check the changes in behavior; see step 1.
2. Modify the backup jobs to refer to the target version of IBM MQ libraries; see step 2.
3. Update the ZPARM module if you have not already done so before starting the queue manager; see step 3.
4. Perform a full regression test; see step 4.
5. Migrate client applications; see step 5.
6. Exploit the new functions provided by the migrated queue manager; see step 6.

7. Optionally, stop the mqweb server for previous versions; see step 7.

Procedure

1. Check the changes in behavior made by default configuration changes. The default values of some properties might have been changed in the new version, which can lead to changes in behavior.
2. Modify backup and other administrative jobs, such as jobs to backup IBM MQ objects and channel authentication records, and MAKEDEF jobs. For example using CSQUTIL COMMAND MAKEDEF(..); see Use the COMMAND function of CSQUTIL to refer to the target version of IBM MQ libraries.
3. Update the system parameter (ZPARM) module if required. Note the following:
   • We should review changes to the ZPARM parameters between the version you have migrated from, and IBM MQ Version 9.2.0.
   • For to change the value of any parameters, we should generate a new ZPARM at this point. Do this by:
     1. Tailoring the ZPARM sample to use the new IBM MQ libraries
     2. Updating values for the parameters as necessary, and
     3. Recompiling, to generate the new ZPARM.

   • You do not have to recompile the ZPARM, if we do not change the values of any parameters.

   If migrating from Version 9.0.0 you should ensure your ZPARM does not reference the OPMODE parameter as it is no longer supported. If OPMODE is specified, we will get a warning at assemble time.

4. Perform a full regression test.
5. Migrate client applications. Client applications can be considered any time throughout the migration phase.

   Clients are backwards and forwards compatible. It is advisable to migrate the client libraries to the same, or later, level as the queue manager, so that the latest function is available.

6. Exploit new functions provided by the migrated queue manager. Your queue manager has been fully migrated to a new version level, so we can now take benefit of new capabilities.

   However, note that additional configuration might be required to enable selected new features.

   Review What's new in IBM MQ Version 9.2 and check which features best serve the business needs. Plan the action to develop new applications, or changing configurations, to enable those features.

7. If you created a new mqweb server for the latest version, we can stop the mqweb server for any previous versions when all queue managers on the z/OS system have been migrated to the latest version.

Results

We have completed the migration of a single IBM MQ for z/OS queue manager. Parent topic: Migrating IBM MQ for z/OS - order of tasks