Migrating a Version 5.0 Configuration Manager to Version 6.0: to a different computer that has DB2 installed

This topic describes one of three ways to migrate a Version 5.0 Configuration Manager to Version 6.0.

Before you start

Read about Coexistence with previous versions and other products.

An existing Windows Configuration Manager can be migrated to a Version 6.0 Configuration Manager on any of the supported operating systems via a JDBC Type 4 Universal DB2 connection.

To migrate a Configuration Manager to a different computer that has a JDBC Type 4 Universal DB2 connection installed, complete the following steps:

  1. Install WebSphere Event Broker Version 6.0 on the computer to which you are migrating your Version 5.0 Configuration Manager.
  2. Add the following files to the environment in which you are going to create the new Configuration Manager. On z/OS, update the BIPCPROF file and submit the BIPGEN job. On all other operating systems, update the local environment.
    1. Add the following files to the CLASSPATH:

      db2 install/jcc/classes/sqlj.zip
      db2 install/jcc/classes/db2jcc.jar
      db2 install/jcc/classes/db2jcc_javax.jar
      db2 install/jcc/classes/db2jcc_license_cisuz.jar                                  

    2. Add to the computer specific environment variable for libraries (for example LIBPATH on z/OS):

      db2 install/jcc/lib

    3. Add to The PATH:

      db2 install/jcc/bin

    where db2 install is where DB2 is installed at your location (for example /usr/lpp/db2710/db2710).
  3. Stop the Version 5.0 Configuration Manager.
  4. Create a Version 6.0 Configuration Manager on the second computer by issuing the mqsicreateconfigmgr command (or the BIPCRCM job on z/OS), specifying the database name, user name, and password required to access the Version 5.0 Configuration Manager database. For example:
    -u (userid)
    The database userid on the Windows computer for the Configuration Manager
    -p (password)
    The database password on the Windows computer for the Configuration Manager
    -n (database name)
    //server:port/database name
    where:
    • //server is the IP address of the Windows computer (for example //9.20.235.197)
    • :port is the port number of DB2 on Windows
    • /database name is the name of the Windows Configuration Manager database (for example /MQSICMDB)
    For example: //9.20.235.197:50000/MQSICMDB

    Use different queue manager names for the two Configuration Managers to maintain uniqueness in the WebSphere MQ network.

    When you create the Version 6.0 Configuration Manager, domain information from the Version 5.0 Configuration Manager database is copied automatically to the Version 6.0 Configuration Manager internal repository so it might take a few minutes to migrate the database.

  5. On the second computer, configure WebSphere MQ to allow the Version 6.0 Configuration Manager to communicate with the broker network. For example, you might need to configure channels, transmission queues, and remote queue manager definitions.
  6. Start the Version 6.0 Configuration Manager.
  7. In order to associate all brokers in the domain with the new Configuration Manager, so that the brokers publish their status messages to the correct queue manager, a complete topology deploy is required on the second computer. Deploy the topology using either the Message Brokers Toolkit or the command-line interface.

    When the topology deploy has completed re-subscribing to the brokers in the domain, the brokers are managed by the new Configuration Manager on the new system; do not use the previous Configuration Manager.

  8. If necessary, uninstall DB2 and the Version 5.0 broker.
Before you migrate your brokers, or make any configuration changes, ensure that your Configuration Manager has been migrated correctly by performing the following checks:
  1. Start the migrated Configuration Manager.
  2. Start the Message Brokers Toolkit and connect it to the Configuration Manager's domain.
  3. Check the list of domain components and see if any errors are produced.
  4. Check the list of alerts for the domain and see if anything has stopped.
  5. Check that you can open the Event Log.
  6. Optional: If you have a broker running, stop and start a message flow, and check for a successful response; check that the Alerts view is updated when the message flow is stopped, and clear when the message flow is started.
If these steps are successful, your Configuration Manager has been migrated successfully. If they are unsuccessful, resolve any problems before you migrate further components or make configuration changes.
When you have migrated the Configuration Manager, ensure that you have migrated the rest of the components: then see the post-migration tasks for information about tasks that you might want to perform after migration.
Related concepts
Configuration Manager
Related tasks
Migrating a Configuration Manager from WebSphere Business Integration Event Broker Version 5.0 to WebSphere Event Broker Version 6.0
Starting and stopping a Configuration Manager
Deploying a publish/subscribe topology
Related reference
Installation Guide