Since IBM MQ version 9.0.1, IBM z/OS Connect Enterprise Edition has been supported but a System Administrator had to copy some files in the MQ product into the z/OS Connect installation directory. In z/OS Connect version 3.0.21 we have made some changes to improve the user experience. This blog explains the changes that have been made.

Integrated supported

The MQ service provider is now shipped inside the z/OS Connect EE product, this eliminates the System Administrator needing to copy files around. The RAR is still shipped inside MQ so you will have to set the location in the server.xml. The name of the service provider has changed to zosconnect:mqService-1.0. The following code snippet 1 shows the feature manager section of server.xml:


 <variable name="wmqJmsClient.rar.location" value="${MQ_RA_ROOT}" /> 

Build tool kit now supported

Since MQ first developed the service provider, z/OS Connect EE has continued to develop and have produced the build toolkit which is designed for the system administrator to define services without having to edit server.xml. Instead they can use the tool to take a some of properties and creates a SAR (Service Archive) which can be uploaded to a specific location in USS which is automatically imported into a running z/OS Connect EE system.

In my next blog IBM MQ in IBM z/OS Connect Enterprise Edition – Walk Through I will give you a walk through on how to create a MQ service using the build toolkit, but first it is important that we understand some concepts.

MQ service provider uses JNDI

There are up to three properties that the MQ service provider uses which are JNDI objects. The mapping for the objects are in the server.xml file. This allows the details of the queue manager or queues to be configured differently on different LPARs (e.g. test and development). To give an example say the following was supplied as a property:


In the server.xml you might have:

 <jmsConnectionFactory id="mqClient" jndiName="jms/connectionFactory1"
  <properties.wmqJms transportType="CLIENT" 

Therefore a System Administrator can change which queue manager one or more services uses by changing the server.xml instead of altering all the services. You can also extract the configuration strings e.g. queueManager name from the e.g. ${QM1_NAME}.

MQ is another transport

MQ is an asynchronous queuing system so when z/OS Connect puts the request onto a queue it hasn’t reached the destination as it would if a IBM CICS transaction is started. Instead it only reaches the destination when an application gets the message off the queue. MQ is used in many ways but when it comes to z/OS Connect MQ services can be categorised into two:

  • Two-way: these put a message to a request queue and get a reply on a reply queue. One usage of this type of service would be to look up a stock level. So the request message would contain the the stock code and the reply message would contain the stock level and other information.
  • One-way: a application might only want to put a messages or get a message. For example an application might use MQ to log that it has been called.
    See service types for more information about the two MQ service types.


In this blog I have described the changes that have been made in the z/OS Connect product to improve the usability of using MQ. In my next blog IBM MQ in IBM z/OS Connect Enterprise Edition – Walk Through I am going to provide a walk through of using the new function.

Join The Discussion

Your email address will not be published.