IBM MQ Reviews

It's rock solid. It just works. We have to have guaranteed delivery and support. Support is solid as well, knowing that IBM is there. We looked at some open-source products and other competitors, and at the time that we made the decision, IBM was the one that had the largest support structure. Rock-solid performance really is the most solid feature of it.

We had to integrate different systems and MQ allowed us to send messages between systems and guarantee delivery. What that did is allow us to more easily integrate those systems and feel 100% trust in this solution.

From an MQ perspective, if they had some built-in monitoring, built-in dashboards, maybe some web-enabled functions so we don't have to load specific tools on our workstations. The training and scalability clustering could be a little bit easier. They could also make it failover- and fault-tolerant. The training aspect is a big part. I think IBM maybe has some work to do on the training side a little bit.

Stability is great. Stability is rock solid. We have very few issues with it.

Scalability: We're a smaller shop so we don't have the resources necessarily to take care of it. Scaling out MQ is possible, but it's not as easy as some other products. It's not as easy as other technologies even.

We were not previously using a different solution. The business challenged the pattern we used. Using queuing and messaging presented itself as the best solution.

When choosing a vendor, we want support, access to information, solid products, and, hopefully, building blocks where we can build on and use other products and foundation.

Setup was more complex than what I thought it might be. We have an active-active cluster, meaning that the systems will fail over to each other if they need to. It was more complicated to set up. We had difficulties setting that up initially, even with consultant help.

I would go back to the rock solid performance. If you can get through the setup and the learning curve with the product, it will just run and work for you. That would be the advice I would give.

Stability and reliability are the most valuable features. It's very reliable and very stable. You can do a fast recovery in case of any failure. It's a very consistent and stable system.

The whole integration channel between PowerVM and third-party applications goes through MQ. This is why MQ plays the role of middleware, of integration, and it helps us to quickly integrate all applications around PowerVM.

One possible area with room for improvement is some integration with the alert system to alert us in case of any failure of any message to be transmitted from one source to another; maybe that could help. It doesn't do that right now.

We will see how MQ will help us when we go to cloud, one day.

It’s very stable.

We have never faced any problem with upgrading or scalability between MQ series and the IBM the PowerVM. It's good.

Once you install MQ, you don't need a lot of support. Of course, we have support with an IBM partner in our country, but up until now, we have never faced a major issue that could impact our business.

Implementation was very straightforward.

Our environment is 60% IBM. We did not shop to search for another solution.

In general, though, the most important criteria for me when selecting a vendor to work with are support, response time, credibility, to be near to us, and that they are not working from the cloud.

In a financial institution, for very critical applications, when you invest, you have to invest one time. You don't have time to redo the work over and over. When you build your setup, your infrastructure, to do your service and your financial service for mission-critical applications, you have to choose the best-of-breed application that supports you. This is why we choose IBM without any hesitation.

We have never faced any problem. It works fine.

We are a bank, and regulations restrict us from using the cloud, at this point. We're using MQ only on our data center.

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.

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.

I'm a technical specialist and we are customers of IBM. 

This solution offers good performance as well as scalability and stability. It offers a template that's beneficial for any company.

I'd very much like to see more integration in the monitoring tools.

I've been using this solution for nine years. 

The stability is good. 

The solution offers very good scalability. 

The initial setup was straightforward. It's all about planning because we have multiple application teams involved. Deployment takes somewhere between half an hour to an hour, but for the coordination to check and perform from the application side, takes almost a full day because we have critical, multiple applications. It needs to be coordinated and we need to be sure they are able to connect perfectly with our environment or with the MQ.

We pay an annual license fee. 

I recommend this product and rate it a nine out of 10. 

IBM MQ is one of the biggest message exchanges in our company. We are in the process of migration to a cloud base environment because in some projects we are using RabbitMQ and Amazon SQS. However, IBM MQ is a big part of our technology ecosystem.

Overall the solution operates well and has good integration.

I have been using IBM MQ within the past 12 months.

We have had stability issues using the solution for some of our projects.

We have had scalability issues with some projects in the past.

The technical support has been helpful.

I have used RabbitMQ and Amazon SQS.

The installation can be easy, but it depends on the environment.

I recommend others use a more cloud-native approach to messaging.

I rate IBM MQ a seven out of ten.

We use IBM MQ for message transmission between our customers, and their agents or global message service providers, such as SITA or ARINC, for tier one critical applications.

Applications are time critical, and IBM MQ has played a significant role in ensuring fast, reliable message transmissions. With IBM MQ in place, fear of messages getting lost in the case of an unplanned failure is almost none.

• Data integrity, reliability and security are very important to our business.
• No messages are lost, and recovery is good in case of any serious failures.
• No dependency on the end party service's run status.

No technical issues come to mind.

In terms of cost, IBM MQ is slightly on the higher side.

It allows data transmission from multiple platforms in a fault-tolerant manner, that's the biggest feature. It is important for us because we do a lot of data transformation and data transmission between different systems; that's one of the biggest things that we do.

It's the backbone of all our data transformation and integration. Thus, this solution is our main integration platform.

Maybe, there should be a containerized version of the application, that can be deployed on the enterprises. So, there is need for a Docker container version of this product.

They need to do a better job of getting it into the open-source world, so that other people, who are more dependent on open-source technologies, start using it as well.

We've been using it for ten plus years now, so it's been good.

It has scaled to all our needs.

We have used technical support. I can't think of any issues with technical support. We've received the support that we needed, on time.

We've been using it for a long time. We were not using any other solution before.

We probably looked at IBM and Red Hat solutions. The reason as to why we chose IBM is because they are more mature in that area.

Longevity, deep support and technical depth are my most important criteria in selecting a vendor.

You should take a look into this solution.