Before you start
Before you start this task, you must
complete the following task:
This topic describes how to migrate a broker domain from WebSphere MQ Integrator Broker Version 2.1 to WebSphere
Business Integration Message Broker Version 5.0.
You can migrate from any service level of WebSphere MQ Integrator Broker Version 2.1 back
to and including Fix Pack 2.
For information about which components
of WebSphere MQ Integrator Broker Version 2.1 can coexist with those of WebSphere
Business Integration Message Broker Version 5.0, see Coexistence with previous releases and other products.
To
migrate a broker domain from WebSphere MQ Integrator Broker Version 2.1 to WebSphere
Business Integration Message Broker Version 5.0, do the following:
- Using a Control
Center session, delete
all brokers that you no longer require after migration from the Topology view
and redeploy the topology. Close this and all other Control
Center sessions.
For information about how to use the Control
Center to
perform this task, see WebSphere MQ Integrator Broker Version 2.1 Using
the Control
Center.
- On each system where one or more brokers are running, do one of
the following for each broker:
- If you no longer require the broker after migration, stop the broker
and delete it.
- If you want to migrate the broker from the Version 2.1 level
of code to the Version 5.0 level, stop the broker
but do not delete it.
- If you want to preserve the broker at the Version 2.1 level
of code, do nothing. You do not have to stop it.
On a UNIX or Windows system, you stop a broker by issuing the mqsistop command
with the name of the broker, and you delete a broker by issuing the mqsideletebroker command
with the name of the broker. For information about how to use these and other WebSphere MQ Integrator
Broker commands, see the WebSphere MQ Integrator Broker Version 2.1 Administration
Guide.
For information about how to stop and delete a broker
on z/OS, see the WebSphere MQ Integrator
Broker for z/OS Version 2.1 Customization and Administration Guide.
- On the system where the Configuration Manager is
running:
- Stop the Configuration Manager by issuing
the mqsistop command for the component ConfigMgr.
- Optional: If you do not want to preserve the assignments,
topology, and topics data in the configuration repository, delete the Configuration Manager by issuing the mqsideleteconfigmgr command
with the -n -m parameters. Using
these parameters causes the configuration repository and the message repository
to be deleted.
- Optional: If you want to preserve the assignments,
topology, and topics data in the configuration repository, do not delete the Configuration Manager.
- On a system where a User Name Server is
running, stop the User Name Server and delete it.
On a UNIX or Windows system, you stop a User Name Server by
issuing the mqsistop command for the component UserNameServer, and you delete a User Name Server by
issuing the mqsideleteusernameserver command.
For
information about how to stop and delete a User Name Server on
z/OS, see the WebSphere MQ Integrator
Broker for z/OS Version 2.1 Customization and Administration Guide.
- On each system, except a UNIX or Windows system that is running
a broker you want to preserve at the Version 2.1 level
of code, uninstall WebSphere MQ Integrator
Broker. Follow
the instructions in the appropriate book for your platform:
- WebSphere MQ Integrator
Broker for AIX Version 2.1 Installation
Guide
- WebSphere MQ Integrator
Broker for HP-UX Version 2.1 Installation
Guide
- WebSphere MQ Integrator
Broker for Solaris Version 2.1 Installation
Guide
- WebSphere MQ Integrator
Broker for Windows NT and Windows
2000 Version 2.1 Installation Guide
On a Windows system, do not select the option to
uninstall WebSphere MQ Integrator
Broker completely, including
data, if you want to preserve the assignments, topology, and topics data in
the configuration repository or the data in broker database tables.
On z/OS, you do not have to remove the WebSphere MQ Integrator
Broker product
code.
- On each system, except a UNIX or Windows system that is running
a broker you want to preserve at the Version 2.1 level
of code, install the components of WebSphere Business Integration Message Broker that
you require. For detailed instructions on how to perform this task,
see:
- On the system where the Configuration Manager is
going to run:
Optional: If you are preserving the assignments,
topology, and topics data in the configuration repository, migrate the data
by issuing the mqsimigratetables command for the
component ConfigMgr. At this time, do
not use the -d parameter. For
information about how to use this command, see mqsimigratetables command.
- Optional: If you are not preserving the assignments,
topology, and topics data in the configuration repository and have previously
deleted the Configuration Manager, create a new Configuration Manager by
issuing the mqsicreateconfigmgr command. For detailed instructions on how to perform this task, see Creating a Configuration Manager.
- Start the Configuration Manager by issuing
the mqsistart command for the component ConfigMgr. For detailed instructions
on how to perform this task, see Starting and stopping the Configuration Manager.
- On each system where the workbench runs,
do the following:
- Start the workbench and connect
the workbench to the broker domain. In the
Domains view of the Broker Administration perspective, make sure that you
can see all the brokers that you have chosen to migrate: those you are preserving
at the Version 2.1 level of code and those you
are migrating from the Version 2.1 level of
code to the Version 5.0 level. Close the workbench.
See Creating a domain connection for
detailed instructions on how to connect the workbench to the broker domain.
- Import the message flows you want to migrate by issuing the mqsimigratemsgflows command. The command also imports information about the user defined nodes that
are used by the message flows. For detailed instructions on how to perform
this task, see Migrating a message flow.
- Import the message sets you want to migrate by issuing the mqsimigratemsgsets command. For detailed instructions on how to perform this task, see Migrating a message set.
- On a system where you have chosen to run a User Name Server,
do the following:
- Create the User Name Server by issuing
the mqsicreateusernameserver command. On z/OS,
you must also configure the User Name Server. For detailed instructions on how to perform this task, see:
- Start the User Name Server. On a UNIX
or Windows system, you do this by issuing the mqsistart command
for the component UserNameServer and,
on z/OS, by starting the User Name Server task. For detailed instructions on how to perform this task, see:
- On each system where you are migrating one or more brokers from
the Version 2.1 level of code to the Version 5.0 level,
do the following:
- On a UNIX or Windows system, change the ODBC connection definition
for each Oracle and Sybase database accessed by a broker. On AIX, also change
the ODBC connection definition for each DB2 database accessed by a broker.
Additionally, if a message flow running in a broker updates an Oracle or Sybase
database within a global unit of work coordinated by the broker queue manager,
change the XA resource manager definition for the database. To
make these changes, follow the instructions in Changing the ODBC connection and XA resource manager definitions for a migrated broker.
- On a UNIX or Windows system, migrate the database tables of
each broker by issuing the mqsimigratetables command
with the name of the broker. If two or more brokers share the same set of
database tables, you need to migrate the database tables only once. On z/OS,
configure each broker. Configuring a broker includes migrating its database
tables.
For detailed instructions on how to perform these tasks,
see:
Create new queues required by migrated brokers. On
a UNIX or Windows system, create the queues by issuing the mqsimigratequeues command.
On z/OS, as you configured the broker during the previous step,
you have already created the new queues. For detailed instructions
on how to perform these tasks, see:

- Start each broker. On a UNIX or Windows system, you do this
by issuing the mqsistart command with the name of
the broker and, on z/OS, by starting the broker task. For detailed
instructions on how to perform this task, see:
You do not have to do anything for the brokers that you are preserving
at the Version 2.1 level of code.
- On a system where the workbench runs,
do the following for each broker that you are migrating from the Version 2.1 level
of code to the Version 5.0 level:
- In the Domains view of the Broker Administration perspective,
right-click the name of the broker and then click Remove Deployed
Children. All the broker's execution groups,
and their contents, are deleted and a new empty default execution group is
created.
- Recreate the execution groups that were originally within the
broker. Recreate only the execution groups you want to preserve. Use the information
you recorded previously for this purpose. For detailed instructions
on how to perform this task, see Adding an execution group to a broker.
- For each execution group that was originally within the broker,
prepare a broker archive (bar) file. The broker archive file must
contain the following:
- The message flows that were originally assigned to the execution group
- The message sets that were originally assigned to the broker
For each assigned message flow, set the following properties:
- Additional instances
- Commit count
- Commit interval
- Coordinated transaction
Recreate only the assignments configuration data you want to preserve.
Use the information you recorded previously to prepare the broker archive
file.
- When the broker archive file is ready, deploy it to the broker. For detailed instructions on how to perform this task, see Deploying message flow applications.
Deploy migrated message flows and message sets to a
test environment first of all. When you are sure that they are working correctly,
you can then deploy them to a production environment.
- On a system where the workbench runs,
deploy the complete topology and topics configuration data. For
detailed instructions on how to perform these tasks, see Deploying a topology configuration and Deploying a topics hierarchy.
The migration is now complete and the broker domain is ready for use.
You can drop any database tables or databases, and delete any queue
managers, you no longer require.
If you preserved the assignments, topology,
and topics data in the configuration repository during the migration and did
not delete the Configuration Manager, the Configuration Manager database
tables after migration contain development data that the Configuration Manager no
longer requires. When you are sure that the migration has been successful,
you can delete this data. For information about how to do this, see Cleaning up the Configuration Manager database tables after migration.