If you want to create the queue manager separately, you must set up a 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 want 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 the default DLQ (unless the queue manager is deleted).
If you use a WebSphere MQ queue manager that has been created independently of the mqsicreatebroker command, you might want to define clusters, which simplifies your configuration in most cases.
If the queue manager is created by using this command, it is not started as a Windows service; therefore the queue manager will stop if you log off. You must, therefore, 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 Windows systems,
the user ID used to start this command must have Administrator authority
on the local system.
On Linux and UNIX systems, the user ID used to start
this command must be a member of both the mqbrkrs group and
the mqm group.
On z/OS systems,
the user ID used to start this command must be a member of a
group that has both READ and WRITE access to the component directory. The
user ID must also have access to WebSphere MQ resources,
and DB2.
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.
(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.
db2 connect to MYDB user db2admin using db2admin db2 bind X:\sqllib\bnd\@db2cli.lst grant public db2 connect resetwhere X: is the drive on which DB2 is installed.
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 do not use the default DB2 user ID and password (db2admin), you must replace the values in the db2 connect command with the correct values.