If your goal is to configure a JMS sample on WebSphere MQ, there are several really useful articles and technotes published by IBM. However, in my case they were a little too simple, as they all run the client and server on the same host, using the same userid. In addition, at the time of writing there are a couple of typos in these documents which might trip you up.
The existing articles I found useful were:
1. IBM WebSphere Developer Technical Journal: Running a standalone Java application on WebSphere MQ V6.0 - Limitations: This is based on MQ 6, and some steps are not relevant to newer releases.
2. Configuring and running simple JMS P2P and Pub/Sub applications in MQ V7 - Limitations: This PDF is very good, but is based on 7.0.1. A supplementary technote is referenced for additional steps that are specific to MQ 7.1 and MQ 7.5.
3. Detailed example of running JMSAdmin on MQ 7.1 and 7.5 - Limitations: Does not include the steps to test the pub/sub sample.
None of the above references cover the scenario where the JMS client is on a separate host to the MQ Queue Manager. For that, follow my steps below (for Linux only), and note the additional steps which supplement the existing references:
1. Create user jmsuser1 in group jmsusers, on both client and server hosts.
2. Create a script to set up the MQ JMS environment as documented in reference #3 above. Do this on both client and server (queue manager). Execute the script in the profile of users mqm & jmsuser1 on the server, and jmsuser1 on the client.
Note: The jmsuser1 user is required because an mqm or root user on the client would be considered an administrative user by the queue manager, and would be denied remote access by default.
3. Create a new Queue Manager:
crtmqm -q -d DEFAULT.XMIT.QUEUE -u SYSTEM.DEAD.LETTER.QUEUE QM_IIC
4. Create local queue and topic:
DEFINE TOPIC(T1) TOPICSTR('TOPIC1')
5. Create a channel to be used by the JMS client application:
DEF CHL(JMSCLIENTS.SVRCONN) CHLTYPE(SVRCONN)
Note: The references above use the default channel. I preferred to create a new one to make the scenario more realistic.
6. Configure the queue manager to have a TCP/IP listener:
DEF LISTENER(LISTENER.1414) TRPTYPE(TCP) +
CONTROL(QMGR) PORT(1414) +
Note: This is required because the client needs to connect from a remote host.
7. Grant access to the queue manager & MQ objects for the jmsusers group:
setmqaut -m QM_IIC -t qmgr -g jmsusers +all
setmqaut -m QM_IIC -t queue -n Q1 -g jmsusers +all
setmqaut -m QM_IIC -t topic -n T1 -g jmsusers +all
8. Create directory /var/mqm/JNDI-Directory on queue manager and client hosts.
9. Generate the JMS bindings (using JMSAdmin):
DEF CF(CF1) QMGR(QM_IIC) TRANSPORT(CLIENT) HOSTNAME(<hostname>) PORT(1414) CHANNEL(JMSCLIENTS.SVRCONN)
DEF Q(Q1) QMGR(QM_IIC) QUEUE(Q1)
DEF T(T1) TOPIC(TOPIC1)
Note: When creating the JMS Topic binding, do not enclose TOPIC1 in single quotes.
10. Copy the .bindings file from queue manager to the client host, in directory /var/mqm/JNDI-Directory
Note: MQ supports LDAP and filesystem JNDI repositories. As I wanted to use filesystem, the .bindings file must be copied to each client host.
11. Restart the queue manager:
12. From the client machine, log in as jmuser1 and test the p2p and pub/sub samples as described in reference #3 above.
In summary, the following configurations were made in addition to those documented by the references above:
- User jmsuser1 in group jmusers was created to avoid using an MQ administrative user in the client connection.
- The jmusers group was used to grant permissions for the client user on the MQ queue manager, queue and topic.
- The JMS bindings were copied to the client host.
Adam de Leeuw (IBM Innovation Centre)