Deploying IBM MQ as a Gateway

It all started with the specifics of connecting a large number of IBM MQ Clients to a Queue Manager on a z/OS mainframe system. The rest is history.

Not all, but most z/OS systems share some common ground:

  • Mission critical: Most z/OS systems on this planet are running 24×7 mission critical systems.
  • Costly: z/OS systems can be expensive to own and operate. True, in the end, they may actually be cost effective, because they handle large workloads and are supremely stable, but expensive they are.
  • Charges: z/OS systems often incur monthly licence charges (MLCs) based on utilization.

Unhappy hiccups

So what happens when a large number of MQ clients are connected to a Queue Manager that runs on z/OS? Well… what happens is that you end up with a customer who is not very happy.

To start with, many of of these clients can be geographically distributed. Consequently, networks may be unstable. Even enterprise-quality networks experience the occasional hiccup, say, once a week, which over 200 connections makes it about once an hour, while over 400 connections… well, you get the idea.

Leaks

TCP connections are lost and then reconnected, which sometimes causes the z/OS Queue Manager to “leak” connections. Restarting the Queue Manager on the z/OS system can be difficult and could potentially disrupt business critical production. Last but not least, regardless of connection leaks, large numbers of client connections increase utilization on the z/OS systems, which drives up the monthly payments!

IT pioneers

Having faced all these issues with numerous clients in the past, XQuadro has pioneered the deployment of IBM MQ as a Gateway. What we do on a presumably 24×7 system is, briefly:

  1. Setup a separate system that runs an IBM MQ instance. Usually, this would be a Linux system, but it can be any reasonable hardware and OS that runs IBM MQ. We call this an (MQ) Gateway.
  2. We setup the required MQ infrastructure on the Gateway system.
  3. We setup the required MQ infrastructure on the z/OS host system:
    1. Sender Channel
    2. Receiver Channel
    3. Transmission Queue
  4. If Channel tab file is used, a new Channel tab file is distributed to all MQ Clients. The new Channel tab file contains connection details for one (or more) Gateway systems.

Business as usual

Up to this point production systems run as usual and nothing has changed at all. Once this is done, MQ clients can switch and connect to the Gateway system. Not all clients need to switch at the same time. This can be done gradually over a long period of time. Once all MQ Clients are switched to the Gateway, the structure allowing Clients to connect directly to the z/OS host, may be removed in order to ensure that no “rogue” clients can exist. But this is optional, and can be done or not. There are several ways to prevent Clients from connecting directly:

  1. The z/OS Queue Manager definition is removed from the Channel tab.
  2. MQ objects required for the MQ clients to connect are removed from the z/OS Queue Manager.
  3. User access rights are changed accordingly.

In large installations, more than one MQ Gateway can be deployed:

  • It may be a good idea to cater to geographically distributed clients, by locating Gateways closer, in network terms, to the clients.
  • Clients may be clustered geographically or logically and each cluster may get its own Gateway(s) for easier administration.

MQ Gateway Benefits

Benefits of MQ Gateways are many:

  • Improves the infrastructure, allowing expensive, mission critical systems running on z/OS to be dedicated to what they are supposed to do.
  • Allows easier administration, better segmentation of Client systems, and finer control.
  • Helps reduce Monthly License Charges, aka MLCs.
  • Allows changes to be done dynamically without 24×7 mission critical systems being disrupted.