IBM Integration Bus, Version 10.0.0.9 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS


mqsibroker commands - common text

(Required) The name of the integration node that you are creating. This parameter must be the first parameter, and it is case-sensitive.
(Required) The name of the integration node that you are creating. This parameter must be the first parameter. It is case-sensitive on Linux and UNIX systems.
(Required) The name of the integration node that you are creating. This parameter must be the first parameter. If you create an integration node with an uppercase name, you must also specify the name in uppercase in the IBM® Integration Toolkit.

For restrictions on the character set that you can use, see Characters allowed in object names.

(Deprecated) This parameter is included for compatibility with earlier versions.

For compatibility with existing systems, you can specify <password>. However, if you do not specify a password with this parameter when you run the command, you are prompted to enter a password. You must enter the password a second time to verify that you have entered it correctly.

For compatibility with existing systems, you can specify <password>. However, if you do not specify a password with this parameter when you run the command, you are prompted to enter a password. You must enter the password a second time to verify that you have entered it correctly.

To complete a password change successfully:

  • Stop the integration node.
  • Change the password by using the appropriate operating system function.
  • Use the mqsichangebroker command to update all parameters that reference this same password.
  • Restart the integration node.
(Deprecated) This parameter is included for compatibility with earlier versions.

You can specify the serviceUserId in any valid user name syntax:

  • As a local name:

    username

    .\username

  • As a User Principal Name (UPN):

    username@domain

  • As a traditional style of logon name:

    domain\username

  • As a request to a specific server:

    \\server\username

If you use the unqualified form for this user ID (username), the operating system searches for the user ID throughout its domain, starting with the local system. This search might take some time to complete.

The serviceUserId that you specify must be a direct or indirect member of the mqbrkrs local group. The serviceUserId must also be authorized to access the home directory (where IBM Integration Bus has been installed), and the working directory (if specified by the -w parameter).

If you specify that the integration node is to run as a WebSphere® MQ trusted application (-t parameter), you must also add the service user ID to the mqm group.

The security requirements for the serviceUserId are described in Security requirements for Windows systems.

You can specify the serviceUserId in any valid user name syntax:

  • \\server\username
  • .\username
  • username

Do not use a domain name as part of the serviceUserId parameter.

If you use the unqualified form for this user ID (username), the operating system searches for the user ID throughout its domain. This search, which starts with the local system, might take some time to complete.

The serviceUserId that you specify must be a direct or indirect member of the mqbrkrs local group. The serviceUserId must also be authorized to access the home directory (where IBM Integration Bus has been installed). If you specified the -w parameter, it must be able to access the working directory.

If you specify that the integration node is to run as a WebSphere MQ trusted application (-t parameter), you must also add the service user ID to the mqm group.

The security requirements for the serviceUserId are described in Security requirements for Windows systems.

(Optional) The name of the queue manager associated with the integration node. Use the same name for your integration node and queue manager to simplify the organization and administration of your network. Queue manager names are limited to 48 characters in length, and they are case-sensitive. This queue manager is used by default for WebSphere MQ processing in the message flow if no queue manager has been specified explicitly on the MQ node.

The queue manager specified on the integration node is also required for message flow nodes that use system queues to store state information about messages, such as the CD and FTE nodes, and for event-driven processing nodes that are used for aggregation and timeout flows, message collections, and message sequences. These nodes require a queue manager to be specified on the integration node, and they also require a set of system queues to be created. For information about creating the system queues, see Creating the default IBM Integration Bus queues on a WebSphere MQ queue manager. For more information about the IBM Integration Bus features that require system queues, see Installing WebSphere MQ.

If you specify a queue manager that does not exist, you must create it before the flow is deployed.

If the -q parameter is not specified, some features that require access to WebSphere MQ will be unavailable. For more information about using WebSphere MQ with IBM Integration Bus, see Enhanced flexibility in interactions with WebSphere MQ.

When creating a multi-instance integration node where the queue manager does not exist on the server, a multi-instance queue manager is created beneath the multi-instance integration node shared work path using the WebSphere MQ crtmqm command as follows:
  crtmqm -md /<integration node sharedWorkPath>/mqm/qmdata
         -ld //<integration node sharedWorkPath>/mqm/qmlog queueManagerName

If this shared queue manager path is not appropriate, create the multi-instance queue manager on the server before you run this command. For more information, see Creating a multi-instance integration node.

For restrictions on the character set that you can use, see Characters allowed in object names.

(Optional) The name of the queue manager associated with the integration node. Use the same name for your integration node and queue manager to simplify the organization and administration of your network. Queue manager names are limited to 48 characters in length, and they are case-sensitive. This queue manager is used by default for WebSphere MQ processing in the message flow if no queue manager has been specified explicitly on the MQ node.

The queue manager specified on the integration node is also required for message flow nodes that use system queues to store state information about messages, such as the CD and FTE nodes, and for event-driven processing nodes that are used for aggregation and timeout flows, message collections, and message sequences. These nodes require a queue manager to be specified on the integration node, and they also require a set of system queues to be created. You create the queues by running the script iib_createqueues.bat in the install_dir\server\sample\wmq directory. Alternatively, you can create the queues by running the WebSphere MQ define qlocal command. For more information about using the define qlocal command, see the WebSphere MQ product information. For more information about the IBM Integration Bus features that require system queues, see mqsicreatebroker command.

If you specify a queue manager that does not exist, you must create it before the flow is deployed.

If the -q parameter is not specified, some features that require access to WebSphere MQ will be unavailable. For more information about using WebSphere MQ with IBM Integration Bus, see Enhanced flexibility in interactions with WebSphere MQ and Installing WebSphere MQ.

If creating a multi-instance integration node where the queue manager does not exist on the server, a multi-instance queue manager is created beneath the multi-instance integration node shared work path using the WebSphere MQ crtmqm command as follows:
  crtmqm -md \<integration node sharedWorkPath>\mqm\qmdata
         -ld \\<integration node sharedWorkPath>\mqm\qmlog queueManagerName

If this shared queue manager path is not appropriate, create the multi-instance queue manager on the server before you run this command. For more information, see Creating a multi-instance integration node.

For restrictions on the character set that you can use, see Characters allowed in object names.

(Optional) The name of the queue manager that is associated with the integration node. This parameter changes the queue manager for the integration node to the specified queue manager name. If a queue manager with that name does not exist, the command completes successfully, with the assumption that a queue manager with that name will be created later.
You can remove an association between an integration node and a queue manager by specifying the -q parameter followed by double quotation marks. For example:
mqsichangebroker IB10NODE -q "" 
You cannot remove the queue manager association if the integration node was created as multi-instance by using the -e parameter. Similarly, you cannot change the queue manager name if -d was defined.

If a queue manager is specified on the integration node and administration security is active, the queue-based (mq) mode of security is used by default, and the required queues that are used for setting authorization are created automatically when the integration node is created. If the queue-based mode of security is set and the queue manager is subsequently removed from the integration node, all access to the integration node is denied until a queue manager is specified on the integration node again, or until the authorization mode is changed to file and the required permissions are set. For information about using the mqsichangeauthmode command to specify the mode of administration security, see Configuring administration security to use file-based or queue-based authorization.

If you want to use the IBM Integration Bus functions that require access to WebSphere MQ queues, you can use the script iib_queues_create.mqsc to define them. The script is in the directory install_dir/server/sample/wmq or install_dir\server\sample\wmq. To learn which features require access to WebSphere MQ, see IBM Integration features and Enhanced flexibility in interactions with WebSphere MQ.

The name of the queue manager that is associated with the integration node. This parameter changes the queue manager for the integration node to the specified queue manager name.

If a queue manager is specified on the integration node and administration security is active, the queue-based (mq) mode of security is used by default, and the required queues that are used for setting authorization are created automatically when the integration node is created. If the queue-based mode of security is set and the queue manager is subsequently removed from the integration node, all access to the integration node is denied until a queue manager is specified on the integration node again, or until the authorization mode is changed to file and the required permissions are set. For information about using the mqsichangeauthmode command to specify the mode of administration security, see Configuring administration security to use file-based or queue-based authorization.

(Optional) The directory in which working files for this integration node are stored. If you do not specify this parameter, the files are stored in the default work path, which was specified when the product was installed. If you specify a directory name that does not exist, it is created automatically. You must have permission to create this directory, or the command fails and returns an error.

When an integration node has been enabled for multi-instance mode using the -e flag, the integration node workPath is divided between data that is specific to this integration node instance, and that which is shared between this integration node and any of its instances created using the mqsiaddbrokerinstance command. Data specific to the multi-instance enabled integration node is stored in the workPath directory on the local server, whereas the shared data is held in a directory on network storage at the location that is specified using the -e flag.

This directory is also used for trace records that are created when tracing is active. These records are written to a subdirectory, log, which you must create before you start the integration node.

Error logs that are written by the integration node when a process ends abnormally are stored in this directory.

The error log is unbounded and continues to grow. Check this directory periodically and clear out old error information.

You cannot change this parameter by using the mqsichangebroker command. To specify or change the work path, delete and re-create the integration node.

Specifying this parameter creates a separate working directory for the integration node. This working directory is a subset of the default working directory structure that contains fewer subdirectories and no common\profiles subdirectory.

(Optional) Setting this value enables the integration node for the multi-instance mode of operation.
You must specify a queue manager (-q) for the integration node to use this parameter. You must ensure the integration node has access to this network storage location before you start the integration node, and that the queue manager for the integration node has been configured as a WebSphere MQ multi-instance queue manager. The information that is stored in this shared directory includes:
  • The integration node registry
  • Component directories
  • Internal integration node tables and files for deployed message flows
  • Configurable service properties.
(Required) The value represents the directory in which globally accessible working files for this integration node are located in shared network storage (NFS or NAS).

You must ensure the integration node has access to this network storage location before you start the integration node, and that the queue manager for the integration node has been configured as a WebSphere MQ multi-instance queue manager.

The information stored in this shared directory includes:
  • The integration node registry
  • Component directories
  • Internal integration node tables and files for deployed message flows
  • Configurable service properties.
(Optional) The name of the WebSphere MQ queue manager that is associated with the User Name Server.

Specify this parameter if you require either authentication services or publish/subscribe access control. If you do not specify this parameter, the integration node assumes that no User Name Server is defined. To enable publish/subscribe access control, specify the -s and -j parameters.

To remove topic-based security, specify an empty string (two single quotation marks ").

(Optional) If you require publish/subscribe access control, specify this parameter. You must also specify the -s parameter.
(Optional) Publish/subscribe access is enabled for the integration node. This parameter is valid only with the -s parameter.
(Optional) The integration node runs as a WebSphere MQ trusted application.

If you specify this parameter on HP-UX and Solaris, specify the serviceUserId as mqm.

(Optional) The integration node runs as a WebSphere MQ trusted application.

If you specify this parameter, add the serviceUserId (identified by the -i parameter) to the mqm group.

(Optional) The integration node runs as a WebSphere MQ trusted application.

If you specify this parameter on Windows systems, add the serviceUserId (identified by the -i parameter) to the mqm group.

If you specify this parameter on HP-UX and Solaris, specify the serviceUserId as mqm.

(Optional) The integration node runs as a WebSphere MQ trusted application.

For more details about using WebSphere MQ trusted applications, see the Intercommunication section of the WebSphere MQ Version 7.5 product documentation online.

(Optional) The maximum time (in seconds) that is allowed for a user configuration request to be processed. It defines the length of time taken within the integration node to apply to an integration server a configuration change that you have initiated. For example, if you deploy a configuration from the IBM Integration Toolkit, the integration node must respond to the Configuration Manager within this time.

A message flow cannot respond to a configuration change while it is processing an application message. An integration server returns a negative response to the deployed configuration message if any one of its message flows does not finish processing an application message and apply the configuration change within this timeout.

Specify the value in seconds, in the range 10 - 3600. The default is 300.

For information about how to set the value for this timeout, see Setting configuration timeout values.

(Optional) The maximum time (in seconds) that is allowed for an internal configuration change to be processed. For example, it defines the length of time taken within the integration node to start an integration server.

The response time of each integration server differs according to system load and the load of its own processes. The value must reflect the longest response time that any integration server takes to respond. If the value is too low, the integration node returns a negative response, and might issue error messages to the local error log.

Specify the value in seconds, in the range 10 - 3600. The default is 60.

For information about how to set the value for this timeout, see Setting configuration timeout values.

(Optional) The time interval (in minutes) at which statistics and accounting archive records are written. The valid range is from 1 minute to 43200 minutes; the default value is 60.
(Optional) Specify the interval (in minutes) at which statistics and accounting archive records are to be written. The valid range is from 1 minute to 43200 minutes; the default value is 60.

An interval of zero minutes indicates that the operating system has an external method of notification (the ENF timer), and is not using an internal timer within IBM Integration Bus.

(Optional, but mandatory when ldapCredentials is provided.) The user principal for access to an optional LDAP directory that holds the JNDI administered Initial Context for the JMS provider.
(Optional, but mandatory when ldapPrincipal is provided.) The user password for access to LDAP.
(Optional) A delimited set of directories to search for additional code page converters. On Windows systems, the delimiter is a semicolon (;). On UNIX and Linux systems, the delimiter is a colon (:).
(Optional) A set of directories to search for additional code page converters, delimited by a semicolon (;).
(Optional) A set of directories to search for additional code page converters, delimited by a colon (:).
(Optional) A delimited set of directories to search for additional code page converters.
The code page converters must be either of the form codepagename.cnv, or in an ICU data package called icudt48.dat. The code page converters must be in a subdirectory named icudt48_<platform_suffix> of the specified directory where <platform_suffix> is one of the following values:
  • l for little-endian ASCII platforms
  • b for big-endian ASCII platforms
  • e for EBCDIC platforms
(Optional) The path that contains the location of all user exits to be loaded for integration servers in this integration node. This path is added to the system library search path (PATH,LIBPATH,LD_LIBRARY_PATH,SHLIBPATH) for the integration server process only.
(Optional) The path that contains the location of all user exits to be loaded for 64-bit integration servers in this integration node. This path is added to the system library search path (PATH,LIBPATH,LD_LIBRARY_PATH,SHLIBPATH) for the integration server process only.
(Optional) Enter the number of the port on which the web services support is listening.

The integration node starts this listener when a message flow that includes HTTP nodes or web services support is started; the default is 7080.

Ensure that the port that you specify has not been specified for any other purpose.

(Optional) A list of paths (directories) from which the integration node loads Loadable implementation libraries (LIL files) for user-defined message processing nodes.
(Optional) A list of paths (directories) from which the integration node loads 64-bit loadable implementation libraries (LIL files) for user-defined message processing nodes. You can define 32-bit or 64-bit LIL files on the following platforms:
  • AIX®
  • HP-UX on PA-RISC
  • Linux on x86-64
  • Solaris on SPARC
Therefore, use the following flags:
  • -r to set the path where the 64-bit LIL files are stored.
  • -l to set the path where the 32-bit LIL files are stored.

On Linux and UNIX systems, directory names are case-sensitive. You must include the names in single quotation marks if they contain mixed case characters.

Do not include environment variables in the path; the integration node ignores them.

Directory names are case-sensitive, and you must include the names in single quotation marks if they contain mixed case characters.

Do not include environment variables in the path; the integration node ignores them.

Do not include environment variables in the path; the integration node ignores them.

This name is case-sensitive; enclose the names in single quotation marks if they are in mixed case.

Do not include environment variables in this path; IBM Integration Bus ignores them.

Create your own directory for storing your .lil or .jar files. Do not save them in the IBM Integration Bus installation directory.

If you specify more than one directory, separate directories by using a colon (:).

Create your own directory for storing your .lil or .jar files. Do not save them in the IBM Integration Bus installation directory.

If you specify more than one directory, separate directories by using a semicolon (;).

Create your own directory for storing your .lil or .jar files. Do not save them in the IBM Integration Bus installation directory.

If you specify more than one directory, separate directories by a semicolon (;) on Windows systems, or a colon (:) on Linux and UNIX systems.

Create your own directory for storing your .lil or .jar files. Do not save them in the IBM Integration Bus installation directory.

If you specify more than one additional directory, each directory must be separated by a colon (:).

Create your own directory for storing your .lil or .jar files. Do not save them in the IBM Integration Bus installation directory.

If you specify more than one additional directory, each directory must be separated by a semicolon (;).

Create your own directory for storing your .lil or .jar files. Do not save them in the IBM Integration Bus installation directory.

If you specify more than one additional directory, each directory must be separated by the default platform-specific path separator.

The -l parameter sets the LIL path for 32-bit integration servers only.
The -l parameter sets the LIL path for 32-bit integration servers only.

For 64-bit integration servers, which are the default in WebSphere Message Broker Version 6.1, you must append the corresponding library path to the environment variable MQSI_LILPATH64.

You can run 32-bit or 64-bit integration servers on the following operating systems:
  • AIX
  • HP-UX on PA-RISC
  • Linux on x86-64
  • Solaris on SPARC
Therefore, use the following flags:
  • -b to set the path where the 64-bit user exits are stored.
  • -x to set the path where the 32-bit user exits are stored.
(Optional) Active user exits. By default, user exits are inactive. Adding a userExit name to this colon-separated list changes its default state to active for this integration node. You can use the mqsichangeflowuserexits command to override the default state at the integration server or message flow level. If you specify a user exit name, and no library is found to provide that user exit when the integration server starts, a BIP2314 message is written to the system log. The integration server fails to start.
(Optional) Use this parameter to enable function that becomes available in IBM Integration Bus fix packs. Valid values that you can set are all, which enables all functions, or a version string of the form V.R.M.F (for example, 9.0.0.3), which indicates the maximum level of feature function to enable. You can use this parameter to revert to a prior fix pack level, but you must first remove any flows that are using the new functions.

This command does not disable all new features, and it is not possible to use this flag to run the integration node at a different major version.

-s security_status
(Optional) Preserved for compatibility. To change the administration security status and set the authorization mode for the integration node, use the mqsichangeauthmode command instead of using this parameter. To view the authorization mode, use the mqsireportauthmode command.
Specify this parameter to change the administrative security status of the integration node.
  • If you specify active, administrative security is enabled for the integration node. If the queue-based mode of administration security has been set, this command creates the required authorization queues, if they do not exist. The queue-based mode of administration security is used by default if a queue manager is specified on the integration node. You can check which administration security mode is set by using the mqsireportauthmode command, and you can change it by using the mqsichangeauthmode command.
  • If you specify inactive, administrative security is disabled for the integration node. The command does not delete or clear the security queues that are associated with this integration node and its integration servers.
If you omit this parameter, the security status is unchanged.
(Optional) Preserved for compatibility. To set and view the administration security mode, use the mqsichangeauthmode command and mqsireportauthmode command instead of using this parameter.

Specify the administrative security status for the integration node. If you specify -s active, administration security is enabled. Only user IDs that you authorize are permitted to complete actions on the integration node. Read, write, and execute authority is always granted on the integration node to all user IDs that belong to the security group mqbrkrs. When the integration node has been created, you can add further user ID authorizations.

If you are using queue-based security, the queue SYSTEM.BROKER.AUTH.integration_server_name is created when you create an integration server on an integration node for which administrative security is enabled. Populate the queue with the appropriate user authorization.

If you specify -s inactive, or omit this parameter, integration node administration security is not enabled. All users are able to complete all actions against the integration node and all integration servers.

If integration node administration security is not enabled, web users can access the web user interface as the default user, with unrestricted access to data and integration node resources.

(Optional) Specify this option to delete all administrative security queues for this integration node when the integration node is deleted. The queue SYSTEM.BROKER.AUTH and the queue for every defined integration server (SYSTEM.BROKER.AUTH.integrationServerName) are deleted.

If you do not specify this option, the security queues are retained and can be reused if you re-create the integration node.

For more information about security, see Administration security overview and Authorizing users for administration.
Note: You must be a member of the mqm group to run the mqsicreatebroker command with the -d parameter.
(Optional) Specify whether you enable an integration node to be started and stopped as a WebSphere MQ service when the queue manager starts and stops. If you set this parameter, you cannot later change this setting. You must specify a queue manager (-q) for the integration node to use this parameter.

This option is an alternative to starting a multi-instance integration node in standby mode using the mqsistart command.

If you specify -d defined, the MQ Service is defined to the queue manager, and the integration node starts and stops when the queue manager starts and stops.
Note: Ensure that the mqm user ID is a member of the mqbrkrs operating system group because the integration node is started by the mqm user ID.

If you specify -d undefined, the MQ Service is not defined to the queue manager, and the integration node does not start and stop when the queue manager starts and stops. This is the default setting.

For more information about running the integration node as an MQ Service, see Creating a multi-instance integration node.

Note: You must be a member of the mqm group to run the mqsicreatebroker command with the -d parameter.
(Optional) Specify whether you enable an integration node to be started and stopped as a WebSphere MQ service when the queue manager starts and stops. If you set this parameter, you cannot later change this setting. You must specify a queue manager (-q) for the integration node to use this parameter.

This option is an alternative to starting a multi-instance integration node in standby mode using the mqsistart command.

If you specify -d defined, the MQ Service is defined to the queue manager, and the integration node starts and stops when the queue manager starts and stops.

If you specify -d undefined, the MQ Service is not defined to the queue manager, and the integration node does not start and stop when the queue manager starts and stops. This is the default setting.

For more information about running the integration node as an MQ Service, see Creating a multi-instance integration node.

(Optional) The policy to use for the cache manager. Set this parameter to default, disabled, none, or the fully qualified name of an XML policy file.
  • If you specify default, the default cache policy is used.
  • If you specify disabled, the global cache components in the integration node are disabled. The cache is disabled by default.
  • If you specify none, the cache manager in each integration server uses the values that you set. The integration server properties that were set most recently by the broker-level policy are retained as a starting point for customization.
  • If you specify the fully qualified name of a policy file, the integration nodes listed in the policy file are configured to share the data in the global cache. The path must be absolute, not relative.
(Optional) The range of ports to be used by the cache manager. Set this parameter to generate or to a specific range of ports.
  • If you specify a range of ports, the value of this parameter must be in the format xxxx-yyyy, and the range must contain at least 20 ports.
  • If you specify generate, the integration node generates a range of ports that are not being used by another integration node on that computer. The integration node chooses a range that starts from 2800. If, for example, another integration node is using ports 2800 to 2819, the integration node generates a range from 2820 to 2839.
(Optional) The internal CCSID of the integration node. The default is set during installation and is based on the values that are set for the locale and language variables. If these variables are not set, a default value of 1208 is used.

To change other integration node properties, first delete and re-create the integration node, and then use the IBM Integration Toolkit to redeploy the integration node configuration. If you want to update the user ID credentials that the integration node uses to access one or more databases from deployed message flows, use the mqsisetdbparms command. For more information, see Accessing databases from message flows.


anbroker.htm | Last updated 2017-07-17 12:45:44