Post installation setup

Note:
Remember to check the WebSphere MQ README file. It might contain information that supersedes the information in this book.

After installation, on any platform other than Windows, you must update your environment variables as described in Environment variables.

Additional setup for publish/subscribe mode

Before you can use the WebSphere MQ JMS implementation of JMS publish/subscribe, some additional setup is required:

You also need to know publish/subscribe concepts as discussed in Writing WebSphere MQ JMS publish/subscribe applications.

Ensure that you have access to a publish/subscribe broker
With WebSphere MQ JMS, you have the choice of these brokers: Differences between these brokers are discussed in Writing WebSphere MQ JMS publish/subscribe applications. Read the documentation for each broker for installation and configuration instructions.

Note, however, that broker based subscription stores are not supported by WebSphere MQ Integrator, Version 2. For more information about subscription stores, see Subscription stores.

Ensure that the broker is running
WebSphere MQ Publish/Subscribe
To verify that the broker is installed and running, use the command:
dspmqbrk -m MY.QUEUE.MANAGER
where MY.QUEUE.MANAGER is the name of the queue manager on which the broker is running. If the broker is running, a message similar to the following is displayed:
WebSphere MQ message broker for queue manager MY.QUEUE.MANAGER running.

If the operating system reports that it cannot run the dspmqbrk command, ensure that the WebSphere MQ Publish/Subscribe broker is installed properly.

If the operating system reports that the broker is not active, start it using the command:

strmqbrk -m MY.QUEUE.MANAGER
WebSphere MQ Integrator, Version 2, WebSphere Business Integration Event Broker, Version 5.0, or WebSphere Business Integration Message Broker, Version 5.0
To verify that the broker is installed and running, refer to the product documentation.

The command to start the broker is:

mqsistart MYBROKER

where MYBROKER is the name of the broker.

WebSphere MQ Event Broker, Version 2.1
To verify that the broker provided in WebSphere(R) MQ Event Broker is installed and running, refer to the product documentation.

The command to start the broker in WebSphere MQ Event Broker is:

wmqpsstart MYBROKER

where MYBROKER is the name of the broker.

Create the WebSphere MQ JMS system queues
This does not apply if you use a direct connection to a broker.

For a publish/subscribe implementation to work correctly, you must create a number of system queues. A script is supplied, in the bin subdirectory of the WebSphere MQ JMS installation, to assist with this task. To use the script, enter the following commands:

For i5/OS:
  1. Copy the script from the integrated file system to a native file system library using a command similar to:
    CPYFRMSTMF FROMSTMF('/QIBM/ProdData/mqm/java/bin/MQJMS_PSQ.mqsc')
               TOMBR('/QSYS.LIB/QGPL.LIB/QCLSRC.FILE/MQJMS_PSQ.MBR') 
  2. Call the script file using STRMQMMQSC:
    STRMQMMQSC  SRCMBR(MQJMS_PSQ) SRCFILE(QGPL/QCLSRC)
For z/OS:
  1. Copy the script from the HFS into a PDS using a TSO command similar to
    OGET '/usr/lpp/mqm/java/bin/MQJMS_PSQ.mqsc' 'USERID.MQSC(MQJMSPSQ)'
    The PDS should be of fixed-block format with a record length of 80.
  2. Either use the CSQUTIL application to execute this command script, or add the script to the CSQINP2 DD concatenation in your queue manager's started task JCL. In either case, refer to the WebSphere MQ for z/OS System Setup Guide and the WebSphere MQ for z/OS System Administration Guide for further details.
For the other platforms:
runmqsc MY.QUEUE.MANAGER < MQJMS_PSQ.mqsc

If an error occurs, check that you typed the queue manager name correctly and that the queue manager is running.

For a broker running on a remote queue manager

For operation with a broker running on a remote queue manager, further setup is required.

  1. Define a transmission queue on the remote queue manager with a queue name matching the local queue manager. These names must match for correct routing of messages by WebSphere MQ.
  2. Define a sender channel on the remote queue manager and a receiver channel on the local queue manager. The sender channel should use the transmission queue defined in step 1.
  3. Set up the local queue manager for communication with the remote broker:
    1. Define a local transmission queue with the same name as the queue manager running the remote broker.
    2. Define local sender and remote receiver channels to the remote broker queue manager. The sender channel must use the transmission queue defined in step 3a.
  4. To operate the remote broker, take the following steps:
    1. Start the remote broker queue manager.
    2. Start a listener for the remote broker queue manager (TCP/IP channels).
    3. Start the sender and receiver channels to the local queue manager.
    4. Start the broker on the remote queue manager.

      An example command is

      strmqbrk -m MyBrokerMgr
  5. To operate the local queue manager to communicate with the remote broker, take the following steps:
    1. Start the local queue manager.
    2. Start a listener for the local queue manager.
    3. Start the sender and receiver channels to the remote broker queue manager.

Queues that require authorization for non-privileged users

Non-privileged users need authorization granted to access the queues used by JMS. For details about access control in WebSphere MQ, see the chapter about protecting WebSphere MQ objects in the WebSphere MQ System Administration Guide.

For JMS point-to-point mode, the access control issues are similar to those for the WebSphere MQ classes for Java:

For JMS publish/subscribe mode, the following system queues are used:

Also, any application that publishes messages needs access to the STREAM queue that is specified in the topic connection factory being used. The default value for this is SYSTEM.BROKER.DEFAULT.STREAM.

If you use ConnectionConsumer, additional authorization might be needed. Queues to be read by the ConnectionConsumer must have get, inq and browse authorities. The system dead-letter queue, and any backout-requeue queue or report queue used by the ConnectionConsumer must have put and passall authorities.