The MQ blogosphere is currently ringing with all the function that is available in MQ 9.1.2, but I want to use this blog to go back and look at something we did in 9.1.1. Largely because I forgot to blog about it at the time, and seeing all the new 9.1.2 content coming out reminded me!

MQ added support for z/OS Connect EE (zCEE) way back in 9.0.1. If you don’t know what zCEE is, it is a nice, simple way to expose existing z/OS assets as REST APIs without having to change any existing code, or expose callers of those REST APIs to things like COBOL copybooks. More details on zCEE are here.

MQ’s support for zCEE is delivered in the form of the MQ service provider. The MQ service provider interacts with MQ for z/OS queue managers using JMS. When we originally created the MQ service provider we only supported scenarios where the zCEE server and the MQ queue manager were collocated on the same z/OS LPAR. That is the MQ service provider had to use a JMS connection factory that was configured to use bindings mode.

However the world has moved on since MQ 9.0.1, which shipped way back in November 2016. And in MQ 9.1.1 we announced that the MQ service provider is now also supported in scenarios where the zCEE server and MQ for z/OS queue manager are on different LPARs. This new approach meant that the connection factories used by the MQ service provider could be configured to use client mode, and to connect to MQ over the network.

Supporting client mode with zCEE gives the potential for much more flexible deployments of zCEE, and other z/OS subsystems. For example you could configure a pair of z/OS LPARs just for zCEE, which then act as a REST gateway to the rest of your z/OS LPARs. The following picture shows how this can be done in a highly available environment with Sysplex Distributor and an MQ queue sharing group, but could equally well include IMS and CICS too.

While client mode connections to MQ from zCEE allow for flexible deployments, its worth pointing out that it is more CPU intensive compared to bindings mode. So you should consider the performance, and MLC, impact before you adopt it.

Join The Discussion

Your email address will not be published.