The mqsimigratecomponents command migrates a component from a previously installed version of the product to another to prepare it for participation in the broker domain of the target version.
Migrate components to WebSphere® Message Broker Version 6.1 from Version 6.0 or from Version 5.0.
You must run this command from whichever version of the installed product is the later, regardless of whether it is the source version or the target version.
For Version 5.0 of the product, Version 5.0.0.4 (Fix Pack 4) is the earliest release of the product that is supported.
You must have an installation of the product at the required version, with the required component code installed, to issue this command successfully.
Before you start migration, stop any active debug sessions in the Message Broker Toolkit. You cannot migrate message flows that are being debugged.
The mqsimigratecomponents command updates your registry and file system, WebSphere MQ definitions, and database definitions. If the user who is issuing the command does not have the authority to perform all of these steps, the command can be run one part at a time. Different users can run the part for which they are authorized in order to achieve the overall result. This approach is referred to as split migration, and is performed using the -1, -2, and -3 parameters.
1> use master 2> go 1> sp_dboption "BROKER1","ddl in tran",TRUE 2> go Database option 'ddl in tran' turned ON for database 'BROKER1'. Run the CHECKPOINT command in the database that was changed. (return status = 0) 1> use BROKER1 2> go 1> checkpoint 2> gowhere BROKER1 is the name of the Sybase broker database.
The migration check can be run against a running component. The check does not impact the component, except for imposing a slight performance penalty. On Linux and UNIX systems, you must migrate the ODBC configuration file (the file in which you have defined the data sources, for example .odbc.ini) before you run the check, because the checking command must be able to access the broker database.
The check command either succeeds or fails, and prints a message about whether the migration will succeed, but no modifications are made during the process.
If a broker that you are migrating shares a database schema with another broker, warning message BIP8678 is issued and the check fails. In this case, all the brokers that share a database schema must be migrated together.
mqsimigratecomponents FIRSTBROKER -t 6.1.0.0
mqsimigratecomponents BROKERB -1 -2
mqsimigratecomponents BROKERB -1 mqsimigratecomponents BROKERB -2
This command can produce a large number of possible responses, depending on the results of the various operations. This command differs from other commands in the way it produces messages: they are displayed as generated, rather than being reported in a batch at the end of the program. When you migrate database tables, z/OS produces more output than distributed systems. Use the -q parameter to reduce the number of messages displayed.
The following example illustrates a split migration from Version 5.0 to Version 6.1:
mqsimigratecomponents BROKER -1 mqsimigratecomponents BROKER -s 5.0.0.5 -2 mqsimigratecomponents BROKER -s 5.0.0.5 -3
The following example illustrates a migration from Version 6.1 back to Version 6.0:
mqsimigratecomponents BROKER -t 6.0.0.4