We have MQ Series installed on mainframe and distributed systems with numerous production applications. Most of the applications are some type of client application, which connects to a Queue Manager and then does a transaction to perform a query or update on a database.
The production apps are written by programmers working for different departments or agencies, which use our services to support the Middleware during test phases, the migration to production and also when the application is in production. Support includes such things as setting up queue definitions, creating channels or creating queue managers. To expedite the support process we needed a tool for managing MQ Series, which was easier to use than creating objects via the command line and also for giving us an enterprise-wide Middleware management tool. By enterprise wide, we were interested in a tool that would allow us to manage mainframe and distributed Queue Managers with the same tool.
After evaluating several state of the art technologies, we chose Nastel MQ Control (now known as AutoPilot/WMQ) to manage our Middleware infrastructure.
MQ Control enabled us to see and manipulate Queue Managers from multiple platforms in one central console. The look and feel was the same no matter if you were looking at a UNIX or mainframe Queue Manager. We also chose Nastel Message Explorer, which enables us to help programmers troubleshoot their applications by allowing us to view the actual MQ Series byte array message.
We had been using MQ Control for quite some time, approximately 2 years, before we realized that, while we could manage the Middleware infrastructure very efficiently, we had no way to monitor our production systems. We were consistently getting phone calls from agencies who were telling us that their applications were down, and we would normally have no way of knowing this until they called. Sometimes by luck, we might notice something out of the ordinary, but 99% of the time we were being notified of problems by our customers before we knew about them. Typically, problems like channels stopping, bad messages causing queues to back up and maybe even queue managers going down were some of the problems that we might encounter. Needless to say, the customers questioned the quality of our services.
We began looking at several products for monitoring our Middleware system. In the end we chose Nastel Autopilot for 2 reasons. First and most importantly, it fit together with our existing Nastel MQ Control environment. Secondly, the cost of the product was much more reasonable than the other large vendors. Other factors like the web interface and the wizards for creating business views were important in making the decision to go with Autopilot.
The licenses were purchased for Autopilot and we began to deploy the components. We chose to deploy our Domain Server on an NT Server and we also deployed Autopilot Web on the same machine. Our managed nodes were deployed on the same UNIX machines where our MQ Control Group Managers ran. There were 2 managed nodes, one for the production system and one for test. Initially, there were some issues with performance and configuration, but we received excellent support from Nastel and it wasn’t very long until we began developing businessviews for production systems.
The first businessview that was created was actually one of the out-of-the-box businessviews that is shipped with Autopilot. Particularly, the nmqs.bsv businessview. All we had to do was alter the name of the Group Manager and we had a valuable businessview that would tell us if ANY queue manager was not active, if messages were in any queues, if channels were stopped or if channel listeners were not running. Amazingly, with only this one businessview, we were already picking up on problems almost immediately after they happened. We later implemented the paging and e-mail features with Autopilot so we were even more on top of things.
This out-of-the-box businessview was good enough for us to monitor test and production, but with Autopilot Web, we wanted each agency to be able to look at their own Middleware systems and get the status at any time and not have to call us. So, we created numerous businessviews. We included things like Queue Manager status, Dead Letter Queue Depth, Queue Depth of XMIT or Local queues relevant to their apps, Channel Status and other things like queue attributes and channel attributes. Once the businessviews were created, we would get feedback from each agency and they would ask for certain things to be included and also would tell us if they wanted to receive pages or e-mails when certain thresholds were met. For instance, if a queue reached a depth of 20 messages, they might want to receive a page once this happens.
Once all the businessviews were deployed to Autopilot web and also deployed as policies on the production Group Manager machine, we saw an immediate change. Instead of getting calls from customers when there was a problem, we would already be troubleshooting or even have the problem fixed by the time they called. The customers were more informed when they called since they could log into Autopilot Web and see for themselves if there was an issue with their Middleware. After a short while, the businessviews were tweaked and things like automatic channel restart were added and also things like the ignore options since we have a mainframe IPL weekly at the same time. We became very efficient at creating businessviews since normally we could just take one that was already done and just modify bits and pieces of it.
All in all, we are operating much more efficiently and providing a much better service to our customers. We’ve taken total control of our Middleware system and are able to take proactive measures and respond to problems very quickly. Autopilot has proven to be a very effective tool in our environment and we look forward to the ongoing use of the product to help us better serve our customers.