IBM MQ Reviews

For me, the most important features are its interfaces with RACF and how we can set up the security to allow and disallow who can get to it, who can use it; and then what MQ gets to do on the mainframe and what it does not get to do, basically.

Our organization uses it a lot to interface applications that are outside the mainframe with applications on the mainframe, or to CICS, items like that.

It helps meet that threshold between what do the application people want to do – because they want to do everything now on GUIs and outside applications – and be able to have the security of the data living on the mainframe and how they get to it. It's the go-between between those two worlds.

There are probably dozens of ways we are using MQ to better connect across cloud, mobile, and devices, but it's mostly the fact that they are setting up stuff and then they use the MQ as the go-between between the distributed world and the mainframe. That's mostly what it's being used for.

Sometimes the applications people don't really understand MQ. For example, we had somebody set up a call through MQ and they ended up making dozens and dozens of calls when they only really only needed to do one. They don't understand how MQ really works, and how it pulls the data and then distributes it back to them, etc.

I think the application people understand that MQ can do it, but they don't really understand the mechanics behind it. They need to be better educated; how to use MQ, get the data that they need, and not cause conflicts.

At the level of the application development people, there needs to be more communication, more information that they have so they understand, because, in essence, what you're using MQ to do is to go to the mainframe and get things. They're so used to their Windows environment, and they don't really understand how MQ grabs that data, and what the mechanics are behind the scenes. And I think that the applications people need to better understand it. Or else something put into MQ so that it is more obvious to them. They don't know what to ask for. They just know, "We're going to go against this data" and they don't know the difference between the different types of security they can set up. The different access and the different classes. We use different classes in RACF; they have no clue what a class is.

There either needs to be better education on there, and or some tools built into MQ that helps them know what to ask for.

I have a very high impression of the stability of MQ; we haven't had any problems with it. MQ has been very stable. I think we've had it go down once since I've been here, but it was due to something somebody screwed up somewhere else, not MQ's fault.

So far, we haven't had any scalability problems either, but we're only about a year and a half into this.

I have not had to use technical support. I've had to use IBM technical support because of some issues, but I never had to talk to the MQ people. We have an MQ rep on site and he handles that stuff.

I was involved in the decision process of how we were going to use RACF, and what they were going to set up to do their calls, but they decided they were going to use MQ. I was actually called in as a RACF specialist to help get that interface going.

Before you implement it into RACF, really investigate the classes and how you're going to set those up, and make sure it's clear with the application development folks. Especially if you're trying to test QA and production separately, it's really important how those classes are set up, and how you set up the instructions for those guys.

The most important criteria for me when selecting a vendor to work with are stability, technical support, obviously the more customers they have in a similar type of field; that's probably what's most important to us, generally.

So far, we've had good luck with it. It seems to be working and it seems to be very stable.

It's one of our core parts of a middleware platform for integrating our CRM billing application and our online transaction application as well. That's the key usage for day-to-day activities.

Integration is a key benefit; it integrates easily. Management is easy. Queue management is one of the key features of it; how easy it is to get set up, get started, get running, look at your queues, look at your workloads, etc., and see what's going on.

We’re not using MQ to better connect across cloud, mobile and devices, or part of the internet of things. It's something that we're looking at for IoNT. We're looking at doing mobile parking, our parking meters. It's something that we're looking at, but we're just doing the road mapping. We haven't deployed that yet.

Currently, it's our connection between our web front end and our back end billing, but that's the next step.

Everything that we need so far works, so I think I'd have to look at the road map, what we planned for internet of things and see if it meets that, which it should. At that point, we'll have a better understanding of what we need going forward.

My support guys, because they use it on a day-to-day basis, might want to see improvements from a management perspective, the management interface. That's one of the complaints I've heard: modernize to a more mobile platform. It's not modern enough for what they wanted to do with it, from what I've heard. That's one area I would say improvement could be done, but again, that might be a small component. Beyond that, nothing.

The main reasons why I haven’t rated it higher is the management interface, which has been a topic of discussion among some of the users, and some issues we’ve had with MQ for z/OS; that's probably because we were on an older version. I haven't looked at the newer version. Those are the two main reasons.

As far as the price point, I don't deal with that; that's somebody else's problem. From a deployment perspective, I didn't have an issue. It's a set up and go for me, from an architect's perspective. These are the requirements, these are the design, you go.

Stability is pretty good. We haven't had issues from a stability perspective. It seemed to always be running. Everyone seems to say, "Hey, it's an MQ issue." Once you look at it, though, the bottleneck is always somewhere else.

Scalability is great as well. You can create your queue managers or you can add a node if you need to and just grow your platform.

I personally haven't used technical support, so I can’t comment on that. Once it's deployed, the support team manages everything into it.

I was not involved in the decision to invest in MQ.

I was in the initial setup; I was involved in the design of the environment for MQ and the rollout of that platform.

It was midway between straightforward and being complex. Our environment is quite complex. We have to integrate the different systems; we have MQ on z/OS, we have MQ distributed. It's right across the platform. The setup of MQ was not complex, but the integration with our environment had some complexity. Overall, with the MQ platform, I don’t think we could have done it any easier.

It's a great tool. It's a great integration middleware tool. Once you have your requirements set, MQ should meet it, but review: Make sure that you understand what you need, what you're setting up, and how you're going to deploy it.

The most important criteria for me when selecting a vendor to work with is how easy it is to get the information from that vendor. Usually, when we get a project, it needs to be deployed yesterday; very tight timelines. If a vendor can come to the forefront, come with all the information, show that their product will meet our needs and it's above any other product on the market, or even on par, but you get a little bit of extra service or support, that's what we look for.

The most valuable feature is the ability to connect our different systems fairly seamlessly. Without it, I don't know how we would have connected our mainframe Intel-based systems and Power Systems together. It's the tool that we utilize to make it happen.

It's the transport tier that connects our systems. Without it, we would be very disconnected.

We're using it entirely for our transactional systems right now.

We're not really using MQ to better connect across cloud, mobile and devices, and the internet of things. I imagine that will be the tool that we will utilize that will help bring that next level in. Right now, we're not utilizing it.

Maybe the administration interface could be improved. Right now, it's very command-line driven. My guess is that if the GUI interface was a little bit better, with more of a singular interface across platforms, that would be helpful.

Like most of the IBM products, it's pretty stable. We haven't really had any real challenges. We run it on the mainframe as well as open systems and both are incredibly stable.

It is very scalable; we use it all the time.

I have not personally used technical support for MQ, but my team has. It has been very responsive.

I did not previously use a different solution.

I was involved in the initial set up at my organization from an infrastructure standpoint. We provide the infrastructure tier. On the open-system side, we helped with it and helped the implementation out on the mainframe.

The actual installation is straightforward. The configuration and the implementation of enabling MQ to talk and communicate between the systems can be complicated.

Before choosing this product, I did not evaluate other options.

From our experience with the functionality and the stability of the product, it's going to be difficult to find something that rivals it in the industry right now.

My rating reflects its functionality and its ability to allow our systems, our enterprise, to run the way it does right now. It's purely a function of MQ's ability to allow the systems to talk to each other.

Support and supportability are the most important criteria for me when selecting a vendor to work with. The ability to handle challenges quickly and responsively.

It's fairly easy to set up and configure. It's very effective as far as what we need to do with the type of processing that we're trying to get done, message-based processing. It is easily replicate-able. We have tons of servers that actually handle different queues; it's very helpful with that.

In conjunction with some other products we use, such as IIB, it does a lot of the transformation. It cuts out a lot of programming that has to be done for transforming data from our carrier customers into the format that we need it to be. That's really one of the big benefits.

There is room for improvement with the price. It's actually not really one of the high-priced items, but everything's relative.

I'm not really sure that there's a lot that we could really think of that we would need above and beyond where we are today, and the way we use it.

What would be nice is some kind of a built-in monitor. That would be something that'd be really helpful; some kind of a performance-type monitor. I know there is one, but it should be built-in. It should be automatic.

Or, a particular queue manager; that would be really helpful, I think.

It's extremely stable. We very seldom have any issue with it. We have it clustered between z/OS and zLinux. We've never had any serious problem with it.

It is easily scalable; very scalable. We can scale both internally in a virtual machine – the size of a queue or a number of queues – and it's also across multiple virtual machines. We use it both ways to scale up.

On z/OS, queue managers are very easy for us to generate and build new ones if we need to or multiple queues on the same queue managers; it’s a very effective tool.

We have occasionally used technical support for MQ, if we really run into an issue. That has worked out pretty well. As a matter of fact, most of the time, for any kind of an issue, we've usually had it resolved within a day. That's the way we want it.

The decision to invest in MQ was made prior to my starting at the company I'm at. I can't take claim for that. I was at another site, and we weren't using MQ at that other site.

I'm a director and me and my team were involved in the initial set up of MQ. It was very straight forward. We had people that were familiar with it. Some of the people that I worked with, or that worked for me, really had a good background, so it went very quickly, and it was very straight forward.

One of the things that we've been asked about is using open-source message queuing alternatives. One of the things we've always fallen back on is that we like the IBM support; we like the release. We don't want to have to worry as much about the levels of software; IBM already takes care of that. It integrates with the other products that we're using. All of those things kind of play together, especially in our case; we're a very big WebSphere Application Server, and as I’ve mentioned, a very big IIB server as well. It's really important that they all work and play together.

I’ve had really very little trouble with it. It's very effective. I don't think on either side, z/OS or zLinux, we've really had any trouble with it to speak of. Sometimes when we do some of the clustering things, we've run into questions or we run into things.

In general, it's been very, very solid.

The most important criteria for me when selecting a vendor to work with is that they're established; that we're not going to be concerned with, "They're here today, and gone tomorrow."

Probably one of the bigger criteria, nowadays, is the ability to support the software. We know we're going to run into trouble. We know we're going to have problems. We know we're going to have questions. We want to make sure that we have a vendor that can support us at that point.

One of the most valuable features is the standardization in terms of messaging; if you have MQ, you probably can talk to anybody. That's one thing: its compatibility. The other one is its stability.

It has improved my organization in many ways. As I’ve mentioned, it's sort of the standard in the market. If you use MQ, you probably can talk to anybody in the market. We also use IBM Integration Bus and they integrate well.

I would like to see them continue to improve the security features to make sure messages are both posted and delivered properly.

For the most part, it is stable. Sometimes, we have issues, but they are internal issues.

On the mainframe, it scales quite well. We're happy because it uses the mainframe's best qualities.

Technical support is average. In terms of efficiency and response time, it's average, comparable to any other vendor. It isn’t better than anybody else that we know.

It's a good product. Don't complicate things. Try to stick to the, let's say, out-of-the-box solutions. Don't be too creative. MQ is about sending messages; it doesn’t incorporate any logic at all.

When selecting a vendor to work with, the most important criteria is that it has to be a strategic vendor for my company to begin with. We have had a mainframe for a long time, so that's quite natural.

The most valuable feature is its stability because we're in the financial services; message persistence and reliability, speed, performance. Those are probably the key attributes that we appreciate.

It's incredibly flexible. It's not software that people get into a religion over; where it’s mainframe or distributed. MQ runs; you don't have to worry about what platform it's on. I find that to be very, very useful. It recovers extremely well in disaster recovery, which is very near and dear to our hearts. High availability options are outstanding.

Support is excellent. The team in Hursley are outstanding, very responsive. They listen to suggestions, and they deep dive into problems.

The very mainframe-centric zIIP offload is very critical to me. I appreciate any and all work IBM can do to offload work onto a zIIP engine to reduce my operating costs. I always tell every vendor that answer. It doesn't make a difference if it's IBM or any other vendor. Exploitation of zIIPs is absolutely critical. I'd say that's probably the biggest thing for me right now. That really impacts my price on my total cost of ownership.

Also, and I think IBM's addressing this in the newer versions of MQ, I would like to see improved MQ data sharing. Again, I'm a mainframe guy. MQ in its original flavor didn't lend itself particularly well to data sharing. There was too big of a chance for data loss. With the new version, where they're using more pointers to the data than data itself, I think that's very promising.

I'm a little concerned about scalability. We're still on the older version of MQ. On the mainframe, we're on the older version. I'm not sure where we are in distributed. Page set expansion is a problem for us. We deal a lot with U.S. equity markets. When we're dealing with a lot of message traffic, a lot of market fluctuation, if we reach a page set expansion and MQ basically goes into a halt to expand the pages, that slows us down immeasurably. I know there are larger versions that have larger buffers, larger page sets; we just have to get there.

We're not using MQ to better connect to mobile. The type of business we are doesn't really lend itself to mobile. On the other hand, it is deeply entrenched in our cloud strategy. In terms of the internet of things, I'm going to steal a comment a heard: It really is becoming part of our nervous system. It makes pretty much everything go. We do billions of messages every day. We'd be in a lot of trouble without MQ.

Right now, I'm not seeing any barrier to success. I don’t have anything on that.

The most important criteria for me when selecting a vendor to work with are that it has to match a business need. Stability, for me, is incredibly important. Ease of use, installation, and maintenance; I don't want to purchase anything from any vendor where they have to send a team in to install it and get it running. If they have to send in their engineers to install it because they don't think my engineers can do it, I don't want the software. I guess those are big ones.

It's an incredibly reliable, stable product for us. I think there are things our firm can do better. I think we're going to get better at them. Right now, I don't see that as being IBM's challenge, I see it as ours.

As far as specific advice, I would make sure you stay current with the maintenance cycles and the patching. This is one of the things we're looking to improve on. We inevitably seem to get caught being a version behind or a few patch levels behind. Because it is such a rapidly evolving technology, you have to stay on top of the patch levels.

The most valuable features are content security and content delivery, from a whole network protocol perspective.

It's adapting itself to get into every single component throughout the entire world being Java enabled.

We are able to transport data across any platform in a secure fashion, be it internal or external.

From the send and forget perspective, MQ allows you to – on your own – manage your data, collect your data, and manage your data perspective.

The barrier to success is basically the engine behind the collection of the data.

I also think the administration could be a little more straightforward. Right now, we have to develop our own truly distributed administration system. There's a GUI that's really not manageable; not that easy to use.

It's very stable.

It’s very scalable.

Technical support is responsive; it comes out of Hursley, which is their main support and development location. There is a direct line to their development; it's very good.

We were previously using all kinds of solutions, including SCP, SFTP, FTP and proprietary APIs. MQ allowed standardization to port data.

We decided to use WebSphere MQ because we needed data transport from all kinds of systems.

Responsiveness is the most important criteria for me when selecting or working with a vendor.

Initial setup was straightforward and flexible.

We did not really consider any options other than MQ.

My advice is to lay out your infrastructure in a fashion you can support.

The most valuable feature is primarily seeing the messages as soon as I log in; being able to see in real time that information.

It allows us to observe the status of our applications in real time; basically, very quick.

I would say it makes the organization more efficient, more reliable; and whenever there is an error, I guess resilient is the word I'd use.

It would be nice to see it outside of the z/OS environment, I think. If there was any other type of standalone client application, that's something that I would be interested in.

It's within z/OS, so it's green screen. It's not user friendly, but I can understand that. I've had the training to be able to look at it. It definitely could be improved, but within z/OS, you know you're not going to get any type of color graphical interface. I don't know what else you could do with it.

It's pretty stable. I don't work with the support of it much, so I'm a general user.

We do have issues from time to time, but because our environment is so complex, it's hard to say whether it's MQ's fault or the messages coming in and out of MQ. I deal a lot with performance and capacity. When there are capacity concerns, when there is too much taking up the system’s CPU, it's difficult to see where the issue lies, but I would say it's been solid for what I use it for.

As far as advice, I would just say familiarize yourself with MQ as much as you can. The Redbooks are great. The implementation of that software solution is something that anyone should be knowledgeable about.

We have a list of approved vendors so I guess the most important criteria for me when selecting a vendor is just a reliable relationship. That's all approved by a different team. We have a hand in maintaining some of the relationships but not much in the creation of them.