If you choose to create the queue manager separately, you must set up a dead letter queue (DLQ). The DLQ is referenced by WebSphere Message Broker when errors occur processing messages in message flows.
If a message in either a user-defined message flow or in the publish/subscribe model cannot be processed, it is routed to this DLQ as a last resort. If you prefer to back out the message onto the input queue, effectively halting the message flow until the problem is resolved, disable the DLQ.
The mqsideletebroker command does not delete this queue (unless the queue manager is deleted).
If you are using a WebSphere MQ queue manager that has been created independently of the mqsicreatebroker command, you can define clusters if you choose. This simplifies your configuration in most cases.
If the queue manager is created by this command, it is not started as a Windows service; it will therefore stop if you log off. To avoid this happening, you must either remain logged on, or change the startup status of the queue manager service. (If you lock your workstation, the WebSphere MQ queue manager does not stop.)
On z/OS, if you create an uppercase broker name, you must use this name in uppercase also for your broker in the workbench.
For restrictions on the character set that can be used, see Characters allowed in commands.This can be specified in any valid username syntax. On Windows platforms these are:
On Linux and UNIX systems, only the last format, username, is valid.
If you use the unqualified form for this user ID (username) on Windows platforms, 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 specified must be a member of the local group mqbrkrs. On Windows platforms, it can be a direct or indirect member of the group. The ServiceUserID must also be authorized to access the home directory (where WebSphere Message Broker has been installed), and the working directory (if specified by the -w flag).
If you specify, on Windows platforms, that the broker is to run as a WebSphere MQ trusted application (flag -t), you must also add this user ID to the group mqm. On Linux and UNIX systems, specify the ServiceUserID as mqm if you set the -t flag.
The security requirements for the ServiceUserID are detailed in Security requirements for Windows platforms.
If you use this user ID for database access (that is, you do not specify a different user ID with the -u flag) and you are using SQL Server for your database, you must create this user ID as an SQL Server login ID and give it the correct access before you create the broker (see Considering security for a broker for further details). If your broker database exists in DB2, and this user ID is not known to DB2, DB2 automatically creates if for you.
For compatibility with existing systems, you can still 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 during its invocation, and to enter the password a second time to verify that you have entered it correctly.
On Linux andUNIX systems -a is required for Windows platforms compatibility, but is not used in relation to ServiceUserID; it is used as a default only if -p is not specified. (See notes about the -p parameter for further details.)
Each broker must have
its own unique queue manager. A broker cannot share a queue manager with another
broker.
If the queue manager does not already exist, it is created by this command. It is not created as the default queue manager; if you want this queue manager to be the default queue manager on this system, you must either create the queue manager before you issue this command, or change the settings of this queue manager to make it the default. Use either the WebSphere MQ Explorer or the WebSphere MQ Services snap-in, depending which version of WebSphere MQ you are using.
The queue manager attribute MAXMSGLN (maximum length of messages that can be put to queues) is updated to 100 MB. This is done whether or not the queue manager is created by this command.
For restrictions on the character set that can be used, see Characters allowed in commands.
This database must already exist. You must create a System DSN ODBC connection for this DSN, if you have not already done so.
If you have a DB2 database on Linux, enter the appropriate DB database alias name; an ODBC DSN is not required.
This user ID must have the authority to create tables within this database, and read from and write to those tables.
On Windows platforms, if your broker database exists in DB2, and this user ID is not known to DB2, it is created for you within DB2. On Linux and UNIX systems, the service user must have previously been granted the correct privilege. If your database is SQL Server, you must create this user ID as an SQL Server login ID and give it the correct access before you create the broker (see Security requirements for Windows platforms for further details).
If you have an application database in DB2 that was created by this user ID, or to which this user ID has appropriate read, write, or create authority, message flows executing in this broker can access and manipulate the application data held within it without having to specify explicit schema names.
This user ID must have the authority to create tables within this database, and read from and write to those tables.
If you have an application database in DB2 that was created by this user ID, or to which this user ID has appropriate read, write, or create authority, message flows executing in this broker can access and manipulate the application data held within it without having to specify explicit schema names.
For compatibility with existing systems, you can still 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 during its invocation, and to enter the password a second time to verify that you have entered it correctly.
For DB2 on Linux and UNIX systems, -u and -p can be specified as empty strings (two double quotation marks "") . In this case, DB2 grants WebSphere Message Broker the privileges of the ServiceUserID, which results in a database connection as "already verified". If you specify -a as an empty string as well as -u and -p, no passwords are stored by WebSphere Message Broker, creating the most secure configuration.
This directory is also used for trace records created when tracing is active. These are written to a subdirectory log, which you must create before you start the broker.
Error logs written by the broker when a process terminates abnormally are stored in this directory. On Windows platforms, use this option, to specify a directory on a drive other than the one on which the product is installed.
The error log is unbounded and continues to grow. Check this directory periodically and clear out old error information.
You cannot change this option using the mqsichangebroker command. If you want to specify, or change, the workpath, delete and recreate the broker.
If you specify this option on Windows platforms, add the ServiceUserID (identified by flag -i) to the group mqm. If you specify this option on HP-UX and Solaris, specify the ServiceUserID as mqm. For more details about using WebSphere MQ trusted applications, see WebSphere MQ Intercommunication.
You must create your own directory for storing your .lil or .jar files. Do not save them in the WebSphere Message Broker install directory.
If you specify more than one additional directory, they must be separated by the default platform-specific path separator (semicolon (;) on Windows platforms, colon (:) on Linux and UNIX systems).
You cannot include environment variables in this path: if you do so, they are ignored.
When a message flow is processing an application message, it cannot respond to a configuration change. If any one of the message flows within the execution group that has been requested to change its configuration does not finish processing an application message and apply the configuration change within this timeout, the execution group returns a negative response to the deployed configuration message.
The value that you set for this timeout depends on the system load (including CPU utilization) and on each execution group's load. You can make an initial estimate by deploying the broker's entire configuration. The time taken for this to complete successfully gives you an indication of the minimum value to set.
The value is specified in seconds and can range from 10 to 3600. The default value is 300.
The sum of the ConfigurationTimeout and the ConfigurationDelayTimeout (described below) represents the maximum length of time that a broker is allowed to process a deployed configuration message before it generates a negative response.
This represents the time it takes for a minimal deployed configuration message to be processed by the broker and its execution groups, and depends on queue manager network delays, the load on the broker's queue manager, and system load.
mqsireporttrace brokerName -e "Execution Group Name" -u
F MQP1BRK,reporttrace u=yes,e='exgrp1'
The response time of each execution group differs according to system load and the load of its own processes. The value that you set must reflect the longest response time that any execution group takes to respond. If the value that you set is too low, the broker returns a negative response, and might issue error messages to the local error log.
The value is specified in seconds and can range from 10 to 3600. The default value is 60.
If the broker is on a production system, increase the values for both ConfigurationTimeout and ConfigurationDelayTimeout to allow for application messages currently being processed by message flows to be completed before the configuration change is applied.
If the broker is on a development or test system, you might want to reduce time-outs (in particular, the ConfigurationTimeout) to improve perceived response times, and to force a response from a broker that is not showing expected behavior. However, reducing the time-out values decreases the probability of successfully deploying a configuration change.
This listener is started by the broker when a message flow that includes Web services support is started, and has a default value of 7080.
Ensure that the port that you specify has not been specified for any other purpose.
An interval of zero minutes indicates that the platform has an external method of notification and is not using an internal timer within WebSphere Message Broker.
On Windows systems, the user ID used to invoke this command must have Administrator authority on the local system.
On UNIX systems, the user ID used to invoke this command must be a member of the mqbrkrs group.
On z/OS systems, the user ID used to invoke this command must be a member of a group that has READ and WRITE access to the component directory.
Using LDAP: Ensure that the registry is appropriately secured to prevent unauthorized access. The setting of LdapPrincipal and LdapCredentials options on mqsicreatebroker is not required for correct operation of the broker. The password is not stored in clear text in the file system.
Access authority is granted for the WebSphere Message Broker group mqbrkrs to all these queues. If the DLQ is enabled, it also has the same authority.
This command returns the following responses:
(51002)[IBM][CLI Driver][DB2/NT]SQL0805N Package "NULLID.SQLLF000" was not found. SQLSTATE=51002.
This error occurs when the bind to the database is not successful.
On Windows platforms, binding is not needed for broker databases, but is required for user databases. If you have created the database using the DB2 Control Center, the bind is completed for you. If you use the command interface, it is not. For the database MYDB, for example, you can create or re-create a bind by entering the following commands at the command prompt:
db2 connect to MYDB user db2admin using db2admin db2 bind X:\sqllib\bnd\@db2cli.lst grant public db2 connect reset
where X: is the drive on which DB2 is installed.
On UNIX platforms, binding is necessary for all databases. For the database WBRKBKDB, for example, you can effect this by entering the following commands at the command prompt (where <user_name> is the user ID under which the database instance was created):
db2 connect to WBRKBKDB user db2admin using db2admin
db2 bind ~<user_name>/sqllib/bnd/@db2cli.lst grant public CLIPKG 5
db2 connect reset
If you are not using the default DB2 user ID and password (db2admin), you must replace these values in the db2 connect command with the correct values.
If you run the mqsicreatebroker command for a second time because of a failure the first time, you receive a series of messages. These indicate any items that cannot be created. There should not be any detrimental effects as a result of this. For example, as long as the reason for the first failure has been resolved, attempting to create a broker which failed the first time should result in a properly created broker.
mqsicreatebroker WBRK_BROKER -i wbrkuid -a wbrkpw -q WBRK_QM -s WBRK_UNS_QM -n WBRKBKDB
mqsicreatebroker WBRK_BROKER -i wbrkuid -a wbrkpw -q WBRK_QM -n WBRKBKDB -t
mqsicreatebroker WBRK_BROKER -i wbrkuid -a wbrkpw -q WBRK_QM -n WBRKBKDB -x /opt/3rdparty/wmbexits
mqsicreatebroker CSQ1BRK -q CSQ1 -u BRKUSER -n DBA0
mqsicreatebroker CSQ1BRK -q CSQ1 -u BRKUSER -n DBA0 -2
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
an07080_ |