Guest post by Ross Cochran, Software Consultant

We all know WebSphere MQ never breaks. MQ is the PVC pipe of the IT world.

(For the non-home repair types, PVC is that long white tubing dangling off the back of the plumber’s truck).

Like PVC pipe, MQ connects everything, is always available, and never breaks. So how do you convince your manager to spend resources to manage something that never breaks?  The answer is simple: you don’t. You spend the resources to defend MQ. In other words, everyone will blame MQ for every problem, so you need something to defend MQ. MQ is presumed guilty (because it touches everything) until proven innocent.

MQ, referred to as middleware, is the glue that holds critical applications running the business together. MQ is the connectivity backbone that allows data transmission between pieces of software. Queue managers send messages back and forth to communicate across a logical connection called a channel. Sounds easy - a queue manager sends a message across a channel to another queue manger, the message arrives “on time,” and a reply is sent back to the originating queue manager. Messages are placed onto a queue as they wait for transmission. Life is good.

But wait, this is not the movies; things never work exactly the way they are designed to work. Queue managers are software (we all know that software breaks). MQ channels are logical definitions (we all know things are not always defined properly). Plus all these queue managers and channels run on systems with operating systems (enough said – this stuff does break).

So the trick is going to be how long will a queue manager keep a message in a queue?  Messages are building up in the queue and somebody needs to come get them. Queue managers all over the place (z/OS and distributed systems) babysit messages until another queue manager comes and gets the messages, or a channel gets the message and sends it to another queue manager. With all these moving parts, it sounds like a message could get lost (loosely meaning it has not arrived at its destination). MQ never loses a message; however, that doesn’t necessarily mean that the message gets where you think it’s supposed to go, and it might not get there as quickly as you think it should. How do you know when this is happening? MQ generates events, and the most efficient way to expose these events is through the use of MQ monitoring tools.

It is apparent that you need to spend resources to keep MQ running smoothly. MQ tends to connect diverse MQ platforms, the largest of which is the mainframe (a.k.a. MVS, OS/390, z/Series) to MQ on distributed systems. The largest bone of contention is the interface to monitoring MQ. Do you go with the traditional 3270 green screen or a graphical user interface (GUI)? We all know which screen has the sexiest interface, but you can’t pry some people’s 3270 terminals from their hands. If the mainframe group brought MQ to your shop, the 3270 interface seems to dominate.

By the way, have you ever wondered if there are any real 3270 devices left, versus 3270 emulation?

The best solution for monitoring MQ in a mixed mainframe and distributed systems environment is an interface that is integrated and supports both platforms. This interface provides a tool set that is comfortable to your end-users, while providing an enterprise view of real-time activities, alerts, and historical reporting.