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 Conditions for a Version 2.1 broker participating in a Version 5.0 broker domain.
To migrate
a broker domain from WebSphere MQ Integrator Broker Version 2.1 to WebSphere
Business Integration Message Broker Version 5.0,
perform the following steps:
- Using a Control Center session, delete
all brokers that you no longer need 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, perform one
of the following steps 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 Version 2.1
to Version 5.0, stop the broker but do not delete it.
- If you want to preserve the broker at Version 2.1,
do nothing. You do not have to stop it.
On a UNIX or Windows system,
stop the broker by issuing the mqsistop command
with the name of the broker, and delete the 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 and -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,
stop the User Name Server by issuing the mqsistop command for the component UserNameServer, and delete the 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 that you want to preserve at the Version 2.1 level,
uninstall WebSphere MQ Integrator
Broker. Follow
the instructions in the appropriate book for your operating system:
- 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 that you want to preserve at the Version 2.1 level,
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 on Windows.
- 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,
perform the following steps:
- Start the workbench and connect
it 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 that you are preserving at Version 2.1 level
and those that you are migrating from Version 2.1 to Version 5.0. 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 that 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 that 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,
perform the following steps:
- Create the User Name Server by issuing
the mqsicreateusernameserver command.
On z/OS, 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,
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 Version 2.1 to Version 5.0,
perform the following steps:
- On a UNIX or Windows system,
change the ODBC connection definition for each Oracle and Sybase database
that is accessed by a broker. On AIX,
also change the ODBC connection definition for each DB2 database
that is accessed by a broker. Additionally, if a message flow that is running
in a broker updates an Oracle or Sybase database within a global unit of work
that is 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, 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 the new queues required by migrated brokers.
On a UNIX or Windows system,
create the queues by issuing the mqsimigratequeues command.
On z/OS, you configured the broker during
the previous step, so you have already created the new queues.
- Start each broker. On a UNIX or Windows system,
issue the mqsistart command
with the name of the broker or, on z/OS,
start the broker task. For detailed instructions on how to perform
this task, see:
You do not need to do anything for the brokers that you are preserving
at Version 2.1.
- On a system where the workbench runs,
perform the following steps for each broker that you are migrating from Version 2.1 to Version 5.0:
- In the Domains view of the Broker
Administration perspective,
right-click the name of the broker then click Remove Deployed Children. All of the broker's execution groups, and their contents, are
deleted and a new empty default execution group is created.
- Re-create the execution groups that were originally within the
broker. Re-create only the execution groups that you want to preserve. Use
the information that 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 items:
- 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.
Re-create only the assignments configuration data that you want
to preserve. Use the information that 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.
Deploy migrated message flows and message sets to a
test environment first. When you are sure that they are working correctly,
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 publish/subscribe topology and Deploying a publish/subscribe topics hierarchy.
The migration is now complete and the broker domain is ready for use.
Drop any database tables or databases and delete
any queue managers that 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,
delete this data. For information about how to do this, see Removing the Configuration Manager database tables after migration.