IBM MQ Reviews

The multiple queuing features, so that everything that we use for talking to our reservation system, the main system we use it for; whatever systems that are sitting on Linux or other environments such as AIX, and then talking to iSeries, which is our “mother ship”, the reservation system. The most valuable features are being able to handle those multiple queues and being able to scale properly.

Before we used MQ, basically it was more of a batch job, sending and receiving messages; kind of like an upload, download type of thing. Now, it's real time, where we can effectively handle millions of transactions an hour, once we implemented MQ.

My only thing for improvement would be the way that we've got it configured. I don't know if it's capabilities and using those capabilities. I feel that we installed it a little bit, say, out of the box. There's a different way we could set up some queue management, that we could do better. It's partly us, but probably using some outside resources to look at our transaction volume and flow. We set it up probably eight years ago and we haven't really changed it since. Our business has changed.

I would just like it to be more resilient. In that area, if there is something that happens, it would alert us better or reset itself automatically, which is the greatest thing, where it tells you, "Hey, there's a problem, but by the way, I've already taken care of it. Just so you know. " That's where I see we've had to do more application monitoring around that to do the actual queue management; understanding that something is wrong. It could help us do that. I lose sleep at night, because of, if we have issues.

It is extremely stable.

Scalability is fantastic, basically because of the Power Systems. It scales along with whatever environment it's sitting on.

We've had problem tickets and things that we've called in to analyze issues. The good part is that it never really was an MQ issue. It was some other issue that came out, but we would get them involved and they would be able to diagnose. It helped us a lot.

Their response was quick; very quick response and very detailed response. Basically, they usually do captures, send in the data and do the analysis. Usually, within 24 hours, we got the information back we needed.

They were really just doing batch file uploads, downloads; probably a couple different things versus MQ. It was a big implementation from IBM. They partnered with us, also to help us. We also started slow and then used it in other areas as well.

I highly recommend it, but I also highly recommend getting services with the actual product to make sure it's implemented correctly.

The most important criteria for me when selecting a vendor to work with is truly being a partner; taking a little bit of the ownership; not just reading from the book of suggestions – because we can read that same book – but really understanding all of our environments, how we do business, make recommendations and implement them. That is important: not just making recommendations; doing it.

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.

Primarily, I use IBM MQ for microservices, modeling, and communications.

IBM MQ's flexibility has sped up our active communication. 

I've been using IBM MQ for five and a half years.

IBM MQ's stability is good.

IBM MQ can scale, but there are some challenges with it.

IBM MQ's pricing is higher than its competitors'.

I would rate IBM MQ seven out of ten.

IBM WebSphere MQ is deployed on a Windows machine, as well as almost all of our infrastructure. Windows services read and write to the MQ server - this is the way that we interact with it. All the messages that we put on the queue are also stored in an SQL Databases. A Windows service reads that message from the SQL Database storage and puts it on a queue on a certain channel; these Windows services are running indefinitely, on a loop so any message is read instantly. 

The solution is very easy to work with.

The solution is very stable, it also offers transaction management and support.

The solution offers very good integration with other services. It's one of the great advantages of the service.

We have had it for a long time now - version 7.1, which is not the latest. 

The admin interface of MQ Explorer that is used to interact with the server seems a little bit dated. It makes it somehow difficult to interact with it. It needs a major update to make it more modern and easy to navigate, maybe a web version.

The solution isn't free. There are other solutions, like RabbitMQ, which are open source and absolutely free to use. This open source solution we use it for non-critical processes.

IBM offers a special version that you need to get if you want to transfer files, especially large files. Maybe it should be included in any version.

We've been using the solution for a very long time. It's been at least a decade - about ten years.

The stability of the solution is good. We've never run into any issues.

IBM MQ offers clustering. We don't have this yet, as it hasn't been implemented, however, I know that you can install it in a cluster of servers. 

My understanding is RabbitMQ is also easier to scale. I'm unsure as to how well IBM can scale in comparison.

I've never contacted technical support in the past. I can't speak to their level or service due to the fact that I've never directly dealt with them.

We're also using RabbitMQ. While IBM is more stable, RabbitMQ is easier to work with. 

We've been trying to change our architecture, and RabbitMQ is more appropriate for us as it's easier to put together with microservices.

While I was part of the process for implementing RabbitMQ, which was very simple and straightforward, in the case of IBM, I didn't install it myself. Unfortunately, I cannot explain how easy or difficult it was as I was not part of the experience. My understanding is it's not too difficult.

In terms of maintenance, we have two people from the support team handling that aspect. They can restart the server or look into the queues. They aren't working in shifts, however, if there are issues, one of them is normally available to troubleshooting.

In comparison, for RabbitMQ, we had only one developer that installed it and created the publishers, workers etc. I believe the support will be the same as for IBM. In both cases, there aren't too many people needed for maintenance.

I'd recommend the solution. It's a very stable solution and very resilient. 

If there is not essential data that needs to be transported between services, then I would go for a RabbitMQ, because it's easier in style, and it's free to use. On top of that, you can have it to wrap around everything in a straightforward way.

That said, I'd rate the solution nine out of ten. We've used it for a number of years and it's always worked very well for us.

Our primary use case is for messaging monitoring. 

The reliability of the queuing is the most valuable feature. 

I can't say pricing is good. It is a popular and reliable solution. IBM can be integrated with other products which is why it gets sold. People also like Oracle. They can be integrated with multiple systems. That is a selling point for these solutions. 

We have been using IBM MQ for fifteen years. 

It is stable.

We never have had a problem with the scalability. We had a problem but the company who was helping us figured out that it wasn't because of IBM MQ, it was another problem. Scalability has been good.

We have a little more than 100 users. 

The product is stable and reliable. We don't generally have support issues. If the product isn't good, people will say that it's not a good product but the support is good. If it's a good product, you won't need much support. 

The initial setup for the messaging part is straightforward. For other features, it's of medium complexity.

I would rate it an eight out of ten. Not a ten because of the pricing.

Reliability is the most valuable feature. MQ is used to support critical business applications.

The installation of product upgrades and patches is very difficult. It requires the use of the IBM Installation Manager (IM). The original IM data location used for installing the base must also be used for the installation of product upgrades and patches. In the Network Deployment edition, upgrades and patches need to be installed in the deployment manager and node agent profiles. I would improve this area by eliminating the need for the IBM Installation Manager.

We have not had stability issues.

We have not had scalability issues.

Technical support is excellent.

We had no previous solution.

Setup was complex. It requires a lot of components to be configured.

Use the new and lightweight version (Liberty) to lower licensing costs.

We didn’t look at other solutions.

Use the new and lightweight version (Liberty) to lower licensing costs. It is also easier to upgrade/maintain.

It doesn't lose transactions, it's fast, and it runs on every platform.

The benefits are the same as the most valuable features. Close coupling between different domains, which reduces your total cost of ownership by not inter-tweaking everything.

For me, there are no areas with room for improvement. We are happy like it is. I don't think we have any special additional needs. I think it does what it's supposed to do and it caters to the requirements we have at this moment.

We would actually like some dashboard improvements, because we've set up some manual dashboarding. We use other tools to monitor MQ. But, if that would be a part of MQ, then we're looking at a TCO reduction again. So it would be interesting if we could get rid of these additional tools.

For me, the management is lacking. It's doable, but it's not graphical. Almost everything you need to do in command line mode. It's pretty technical.

There is no downtime. It is very stable.

We have no problems with scalability. It scales all the way around.

We have used technical support. For MQ, it's very good, compared to other products.

We didn’t have a previous solution. There was a new requirement to handle asynchronous transactions, and MQ seemed to be the best solution at that moment.

I was involved in the setup of the distributive systems. It was straightforward.

We did't look at other vendors, because, at that moment, IBM was our preferred partner, and still is, so we first looked at the IBM solution.

Just do it.

It allows us to do point-to-point integration in an easy manner. It allows different applications to talk to each other; applications that may speak different languages. You have mainframe technologies, Java-based apps, .NET, things of that nature, and MQ allows you the ability to share the data between those different types of systems.

The thing that I like about MQ most is its reliability. It's one of those types of products that just works. You don't have to tinker around with it too much. One of the biggest things that I really look for in a product is from a reliability perspective. Can I count on this to be up 24 hours a day, and do I have to keep hacking around with it? MQ is definitely something that is really reliable, so it's something that I really appreciate it.

I would just like a more user-friendly experience to do common administration tasks. I know that you can use MQ Explorer, but having something that's already built in would definitely be useful.

We haven't necessarily experienced any issues from a migration perspective. Typically, where we see the majority of our issues at is when we're doing upgrades to the Message Broker, or IBM Integration Bus is what it's called now. Those two products are typically married together. Most of our issues ... I wouldn't even call them issues. We see some issues when we migrate from different versions in regards to like, IIB. I think that's just because this is a more complex product. You have customized code in there. From an MQ perspective, everything's pretty straightforward.

I haven't had any stability issues. I think the biggest thing, when there are issues, is having an easy way to figure out what's going on. I think one of the things that I'm looking forward to, from a MQ perspective, is just having more of a user-friendly experience. MQ has traditionally been somewhat of a command-style solution, so anything that they could do to improve that would definitely be helpful.

We have not had any scalability issues.

We have teams that usually interact with IBM. My team doesn't necessarily do that that often but when we do, it's a fairly pleasant experience.

From an MQ perspective, it's something that we've been using for a long time. Unfortunately, when you're dealing with very large companies, it's difficult to transition away from stuff that you built a long time ago, so you have a lot of this stuff that's just hanging around, that's been built a long time ago, and you still have to maintain it. Once something goes into production, it's typically very difficult to get money to update that service five, ten years down the road.

Setup was pretty straightforward. MQ has been around for a long time. It's a reliable product. It doesn't change that much, so I think everybody, at least in my organization, is fairly comfortable with installing and implementing MQ.

MQ was, to me, pretty much the gold standard in regards to what it does. To me there's really no point to look at other vendors.

Have a common understanding of why you feel that you need MQ. MQ was something that we implemented years ago, so there may be new technologies out there that you may be able to utilize to make the project you're trying to do easier, and make your implementation a little easier.