mqsimigratecomponents command

Use the mqsimigratecomponents command to migrate a component from one version of the product to another version on the same computer.

Supported platforms

  • Windows.
  • Linux® and UNIX systems.
  • z/OS®. Run this command by customizing and submitting BIPMGCMP.

Purpose

Migrate components to IBM® Integration Bus Version 10.0 from a previous version:

You can also use the mqsimigratecomponents command to return an integration node from IBM Integration Bus Version 10.0 to IBM Integration Bus Version 9.0, WebSphere® Message Broker Version 8.0 or WebSphere Message Broker Version 7.0 to reverse the effects of forward migration. However, you cannot return an integration node from IBM Integration Bus Version 10.0 to IBM Integration Bus Version 9.0, WebSphere Message Broker Version 8.0 or WebSphere Message Broker Version 7.0 if any of the following events has occurred on the IBM Integration Bus Version 10.0 integration node:
  • The integration node no longer has a default queue manager associated with it.
  • The integration node has been changed to use file-based administration security since it was originally migrated.
  • Integration servers have been created since the integration node was originally migrated.
  • Shared libraries have been deployed to any of the integration servers for the integration node.
When you restore an integration node to Version 9.0, Version 8.0 or Version 7.0, changes that you made to the integration node's state that are compatible with your target version are kept. However, changes that you made that are not compatible with your target version are not reflected in the restored integration node's state, which might cause errors. In addition, the following resources will not be visible in the target version:
  • Applications, libraries, flows, or subflows that have been newly deployed since the original migration.
  • Workload management policies that have been created since the original migration.
Changes that have been made to the following resources since the original migration will not be visible in the target version:
  • Pre-existing message flows where the changes were made by redeployment, commands, APIs, or the IBM Integration Toolkit.
  • Pre-existing subflows where the changes were made by redeployment, commands, APIs, or the IBM Integration Toolkit.
  • Integration server settings where the changes were made by commands, APIs, or have through the commands or the IBM Integration Toolkit.
  • Pre-existing workload management policies.

You must run this command from the later version of the product, regardless of whether it is the source version or the target version.

You must have an installation of the product at both target and source versions, with the required component code installed, to issue this command successfully.

Before you start migration, stop the integration node and all active debug sessions in the IBM Integration Toolkit. You cannot migrate message flows that are being debugged.

Specify appropriate options on this command to perform one of the following actions:
  • Check that the component is suitable for the required migration, without changing that component (-c).
  • Move a component to a different version (-s and -t).
  • Undo a failed migration step (-u).
  • Verify that a move was successful (-v).

Usage notes

If you specified a data source user ID and password on the mqsicreatebroker command for the integration node that you are migrating, the values of these parameters are also migrated and saved in the format that is used by the mqsisetdbparms command. The values are used by the integration node to access databases for which you did not set alternative values by using the mqsisetdbparms command. After migration, if you want to change the user IDs or passwords that the integration node uses to access databases, you can use only the mqsisetdbparms command.

If you update the user ID and password values, and you migrate the integration node back to the previous version, the new values are also migrated back to the original integration node.

Syntax

Read syntax diagramSkip visual syntax diagrammqsimigratecomponentsMoveCheckUndoVerifyComponentName-q
Check
Read syntax diagramSkip visual syntax diagram -c -sSourceVersion-tTargetVersion
Move
Read syntax diagramSkip visual syntax diagram-sSourceVersion-tTargetVersion
Undo
Read syntax diagramSkip visual syntax diagram-u-sSourceVersion -tTargetVersion
Verify
Read syntax diagramSkip visual syntax diagram -v-tTargetVersion
Notes:

Parameters

-c
(Optional) Check a specified component before migration to ensure that the following are true:
  • The auto-detected version of the integration node matches any version that is specified on the command line.
  • Any database tables that are accessed in a previous release do not contain any rows that are incorrectly indexed.

You can check a running component. The check does not affect the component, apart from a slight degradation of performance.

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.

The -c and -v parameters are mutually exclusive. Additionally, if you specify either of these parameters, you cannot specify any other parameter when you run this command.

-v
(Optional) Check a specified component after migration to ensure that the following are true:
  • The registry is in the correct format for the new version.
  • The correct queues exist for the new version.

The -c and -v parameters are mutually exclusive. Additionally, if you specify either of these parameters, you cannot specify any other parameter when you run this command.

-q

(Optional) Print fewer status messages during the operation.

-u
(Optional) Undo a failed migration step. Use this option only when the migration failed, and also failed to auto-recover.
-s SourceVersion
(Optional) The previous version of the component.
  • If not specified, this value is detected automatically.
  • See Purpose for the restrictions to the version numbers of the product that are supported.
-t TargetVersion
(Optional) The destination version of the component.
  • If not specified, this value is assumed to be the current version.
  • See Purpose for the restrictions to the version numbers of the product that are supported.
ComponentName

(Required) The name of the component to migrate.

Authorization

For information about platform-specific authorizations, see the following topics: If you have enabled integration node administration security, you must also set up the authority that is detailed in Tasks and authorizations for administration security.

The mqsimigratecomponents command updates your registry, file system, and WebSphere MQ definitions.

Your user ID must be able to complete the following actions:
  • Write to the registry and the file system for the product
  • Modify queue definitions

Responses

This command can produce many 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 when they are generated, rather than being reported in a batch at the end of the program.

Examples

The following example shows a migration from Version 10.0 back to Version 8.0:

mqsimigratecomponents MYBROKER -t 8.0.0.2