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:
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.
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!
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 24x7 system is, briefly:
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:
In large installations, more than one MQ Gateway can be deployed:
Benefits of MQ Gateways are many: