Restoring components and resources to Version 5.0

This topic explains how to restore components and resources that you have migrated from Version 5.0 products back to their original state.

Restrictions

When you revert a broker from Version 6.0 to Version 5.0, message sets are deleted, so you must redeploy them. You are reminded to do this by warning message BIP8688, which appears when you run the mqsimigratecomponents command.

After migration to Version 6.0, if you have deployed any message flows that use new Version 6.0 functions, such as new nodes or new ESQL syntax, those message flows will not start if your broker is reverted to Version 5.0. Other message flows in your broker that do not use new Version 6.0 functions will continue to run.

Version 5.0 and Version 5.1 Message Brokers Toolkit source files use a new format in the Version 6.0 Message Brokers Toolkit. The files are migrated to the new format when you save them using the Version 6.0 Message Brokers Toolkit. After this, you can no longer use the files with the Version 5.0 or Version 5.1 Message Brokers Toolkit. If you have created message flows in Version 6.0, you cannot revert them to Version 5.0. For detailed information, see Conditions for using migrated resources with previous versions of the Message Brokers Toolkit.

Migrating resources back to Version 5.0

The following sections describe how to restore the Message Brokers Toolkit and your runtime components to Version 5.0.

Restoring the Message Brokers Toolkit to Version 5.0
To restore the Message Brokers Toolkit to Version 5.0, perform the following steps:
  1. Stop the Version 6.0 Message Brokers Toolkit.
  2. Restore the Version 5.0 workspace from the backup that you took before migration.
  3. Restart the Version 5.0 Message Brokers Toolkit.

Any changes that you made in the Version 6.0 Message Brokers Toolkit cannot be used in the Version 5.0 Message Brokers Toolkit.

Restoring runtime components to Version 5.0

Use the -s and -t parameters of the mqsimigratecomponents command to migrate components from Version 6.0 to Version 5.0. Specify Version 6.0 for the source version parameter (-s) and Version 5.0 for the target version parameter (-t). See the mqsimigratecomponents command topic for detailed information about these parameters and the format to use when specifying version numbers.

To revert z/OS runtime components to Version 5.0, perform the following steps:
  1. Submit the BIPMGCMP job to call the mqsimigratecomponents command, specifying the -s and -t parameters as described above.
  2. Replace the started task JCL in USER.PROCLIB with the Version 5.0 copy that you backed up.
Reverting a broker to Version 5.0
To revert a migrated broker to its Version 5.0 state, perform the following steps:
  1. Stop the Version 6.0 broker.
  2. Revert the broker to Version 5.0 using the mqsimigratecomponents command, as shown in the following example:
    mqsimigratecomponents Broker -t 5.0.0.4
    Warning message BIP8688 might be displayed, warning you to redeploy your message sets.
  3. Reverse the changes that you made to the ODBC definitions when you migrated to Version 6.0.
    • On UNIX, reset the ODBCINI environment variable to point to the previous version of the odbc.ini file.
    • On Windows, use the Control Panel to adjust the ODBC settings.
  4. Restart the broker using a Version 5.0 command window.

If you migrate to Version 6.0, deploy a message set to the Version 6.0 broker, then migrate back to Version 5.0, Version 5.0 is unable to recognize the message set that was deployed by Version 6.0. In this case, any message sets that Version 5.0 is unable to use are deleted and a warning message is displayed for each message set, prompting you to redeploy it to Version 5.0 following successful migration.

Reverting a User Name Server to Version 5.0
There are no functional changes in the User Name Server between WebSphere Business Integration Message Broker Version 5.0 and WebSphere Message Broker Version 6.0. To revert a User Name Server to Version 5.0, issue the mqsimigratecomponents command, as shown in the following example:
mqsimigratecomponents UserNameServer -t 5.0.0.4
Restoring a Configuration Manager to Version 5.0

When you migrate a Configuration Manager from Version 5.0 to Version 6.0, the DB2 database is neither changed nor deleted. Version 6.0 does not use DB2 to store data. If you migrate from Version 6.0 back to Version 5.0, the original DB2 database is used again, and if you made any changes after migration to Version 6.0, these changes are not reverted to Version 5.0. As a result, you will lose any domain changes that you made after migration to Version 6.0.

If you deployed any broker configuration changes after migration to Version 6.0, these are lost when you restore the Configuration Manager to Version 5.0. You must rebuild your brokers by deleting them and redeploying them in order to maintain a consistent state. Check carefully that your Configuration Manager works correctly before deploying for the first time after migration to Version 6.0.

If you changed the Configuration Manager's queue manager during migration to Version 6.0, you must keep the new queue manager if you restore using the mqsimigratecomponents command. If the new queue manager is on an operating system other than Windows, you cannot use the mqsimigratecomponents command to restore; instead, you must restore from a backup.

Here is an example of the command to restore the Configuration Manager to Version 5.0 state:
mqsimigratecomponents ConfigMgr -t 5.0.0.4
Related concepts
Conditions for using migrated resources with previous versions of the Message Brokers Toolkit
Related tasks
Migrating and upgrading
Backing up WebSphere Business Integration Message Broker Version 5.0 resources
Uninstalling
Related reference
mqsimigratecomponents command