IBM MQ Reviews

The solution allows one to easily configure an IBM MQQueueManager. It's very easy and demonstrates comparatively better performance than that of other products. It is very good and makes it impossible to lose a message. These are very important advantages of the solution, but the greatest one is its robustness. 

It would be nice if we could use the cluster facilities because we are doing active/passive configuration use. Maybe we could implement them in cluster scenario and use the active/active nodes.

We have been using IBM MQ for around 20 years.

The onboarding processes and setup are very easy. 

We solely make use of IBM MQ and are an MQ customer. 

I rate IBM MQ as a nine out of ten. 

We use it for application-to-application integration.

Reliable messaging and throughput are the most valuable.

We are looking at the latest version, and we hope that resilience, high availability, and monitoring will be improved. 

It can have some more improvements in the heterogeneous messaging feature. The current solution is on-premises, so good integration with public cloud messaging solutions would be useful.

I have been using IBM MQ for 20 years.

Its stability is great.

Its scalability is okay. The inside scalability is great. We are hoping that the outside scalability is improved in the latest version.

Most of the users are just using the applications, and they are using IBM MQ without realizing it. In terms of the number of people really dealing with IBM MQ on a global scale, there are probably around 30 users. They are actually working with the product. There are thousands of developers who are using applications with IBM MQ.

I am an architect, and I talk with the architects of IBM. The engineers talk with technical support when needed.

The basic setup is simple. The deployment is fully automated.

We received the software from the vendor, but we deployed it on our own. We also do the maintenance ourselves. 

There is real money involved here. As compared to RabbitMQ, IBM MQ is on the higher side in terms of cost.

I would recommend this solution for similar companies. I am very fond of IBM MQ because of the reliability and throughput part, at least on a single server. On the consumer and application side, RabbitMQ seems a bit easier to consume. It is a bit ahead in terms of the scale-out feature.

I would rate IBM MQ an eight out of ten.

The pub/sub model is the one that we use heavily on IBM MQ. That's the most valuable for us. We are an enterprise team and we provide a lot of integration to the enterprise systems, so when the data changes on the enterprise systems, we publish a lot of these changes to all the subscribers, whether it's a customer change or the account changes.

It provides seamless integration with the enterprise and any enterprise data changes. Also, the reliability is important for us.

Using it as a service, as a platform on cloud, would be an improvement. I think it's always had room for improvement, so I would definitely put more on the cloud-based services than on what we currently use.

Also, ease of use isn't that great, as it's still considered enterprise class, whereas the more modern applications or platforms do offer modern interfaces and a way to integrate with those systems. Still, I feel its very legacy-natured.

I think the stability is great. That's one of the assets IBM MQ is known for.

So far, I think we haven't faced any scalability issues, but it is well architected in terms of its high availability and DR purposes.

I don't have any complaints about the technical support.

I think it was always an IBM MQ base which we used.

I was not involved in the initial setup.

I don't have information regarding which vendors were considered before we chose IBM MQ.

The features and the reliability of the product are important considerations when selecting a vendor.

Definitely it's a great product. But, I think we need better interfaces.

WebSphere messaging, clustering and security are the most important and most valuable features.

Security is the most important thing right now. Nowadays, you can see people are hacking into systems to steal customer data. MQ has very good security features and it supports very good protocols.

The biggest advantage about us using messaging is that we can connect to most of the financial customers across the globe securely and data is always sent only once, asynchronously as well as synchronously.

We are moving toward the cloud. How can we migrate the existing customers to a private cloud? That's what I'm trying to figure out. Maybe it's already there. I need to know.

It is a very stable product. We have been using it for more than ten years. It is very stable.

It's pretty much scalable, but I'm looking to see if we can scale to cloud using the existing infrastructure. It’s like picking up buckets. It’s very lax.

We have used technical support. Not for the solution, but for problems or issues. I would say that they are okay. If you want me to rate between one to ten, I would rate them four.

We did not previously use a different solution. This is something that we started using and it has grown tremendously in eight or ten years. It is one of the most widely used messaging solutions, internally and for external customers.

I was involved in the initial setup. It is straightforward. Since I'm familiar with this tool and been working with it for 12 years, it was straightforward.

We did not evaluate any alternatives.

I think it all depends on the business need or the price. If the budget is strict, then they go with other solutions. They compromise on the business need. If they are OK with the budget, then they just go with it.

We use MQ just for transferring messages to and from applications. We get subscriptions, queues, topics and all the app teams love it. It is an easy way to transfer messages, so that's commonly used as a solution for us.

The benefit is, it is easy to use. You subscribe to your queue, they get the message and then they do what they need to with it. It goes on or it ends, either way; it is very easy to use.

From what I understand from the team, mainly just the security piece needs to be improved, but it sounds like they already have that resolved.

Obviously, there's always a bug or two here and there that could be fixed, but they're constantly evolving and improving it.

I know that they're coming out next with IBM MQ Version 9 or 10, so they are always updating the versions. It is a very stable product.

We did experience some security issues with the older versions. As of now, people can log in as root, i.e., whoever wants to log in as root, they can. However, with the new version, they're taking that away.

I have not used any technical support for this solution.

Usually we just go with the IBM products, so I don't think we've looked outside that much for another messaging solution.

From our perspective, we use the IBM suite. They provide great support when we need it. They're always evolving and are very stable, so all around it is a very good suite from IBM.

Its integration capabilities and the security features are the most valuable features of this product.

We are using it to integrate systems. It's an asynchronous system and there are a lot of benefits of this method for us, so we are using IBM MQ.

If one of our servers or systems fail, MQ will store the messages for a long time, so we do not lose any information or messages. That's why we are using MQ.

• Security enhancements
• Active-active clustering: IBM MQ does not support active-active clustering, but we need that.

It is very stable.

It is very scalable, and very expensive.

We have used the technical support once or twice; it's good. We opened some tickets and received responses within a short time; so it was okay.

I did not previously use a different solution at my current firm but I have also used Microsoft Queues. However, there were a lot of issues with it in terms of the performance, stability and security. IBM MQ is better.

Initial setup was quite straightforward.

If you have money, then you can use IBM MQ. It is very expensive.

We are using almost every vendor such as Oracle, Microsoft, HPE, Solaris, etc. Our core systems are running on WebSphere, i.e., developed in Java code, so we are using most of the IBM tools. But, the most important issue when selecting a vendor is the support.

For us, the most valuable feature is the fact that we can move data from disparate systems quite easily. It's not a mountain of data for us, because of the nature of our business, but it's critical that we move information through the queues, from many varying different systems.

It makes it much easier to have people from different experience levels be able to interface with one another, without having to be cross-trained on many different platforms. A business benefit is, it can take somebody who's a Windows guy or a Linux guy, and he can fully communicate with the z/OS system, or vice versa, without having to have that extra knowledge of those other systems.

For our internal systems and connecting things together, it works really well. If we're trying to connect to something in the web or other things, we don't use it, because we feel that REST or other APIs are more easily adaptable to that environment. Perhaps; I'm not even sure how MQ could do that.

For instance, one of the things we do is, we collect social media data; the public APIs. We're doing a REST call; we're getting back a JSON object. If there was a way that we could do that, perhaps with MQ; set up a way that it could go out, collect the information that we need, and bring it back as a queue, as opposed to a JSON object. That might be something beneficial.

Stability is a hallmark of the product. It's extremely reliable. We set up a queue and we say, “Go,” and we have virtually zero issues with it. Considering that it's interfacing with multiple different products, it's remarkably reliable.

It's one of those things where, if somebody says there's a problem, you're like, "What? That can't be possible." We really haven't really had any outages to speak of.

We don't have a tremendous transaction volume, but obviously, the scalability is a factor that many large organizations would have to work on. I think that the transaction volume, in some of the testing we've done for performance and things like that, have shown that is a very, extremely reliable product at scale.

I'm not sure that we've really had to use technical support for WebSphere MQ. We’ve figured out how to do it. We've known how to use MQ, set up queues and so on, for a long time. They interface well with our products. We really don't need the support, which I guess is a hallmark of how simple it is to use the product.

We might have had some issues with installation, or some initial setup calls. Once it's gone live, we've really not had to ask for help, had a queue break, or had transmissions not happen.

We've had MQ for a long, long time. It was something that we've always supported.

The people on my team were involved in the initial setup, absolutely. There was a little bit of complexity involved with the mainframe section, around some general ways that the thing is implemented in the system, and things that have to happen early on during the IPL and some other processes that we have. That's the part I'm most familiar with. The other platforms it's run on, I'm not sure.

In general, once we got through some of those issues, it was pretty straightforward.

If you have a lot of internal systems that you rely on passing queue transactional data, and queuing data back and forth between a lot of systems, it's definitely a very reliable, very robust, very easy-to-use product. It's a very eloquent way of providing a solution to the problem of having disparate systems talk to each other.

I think it's a very stable product. It works well. It does exactly what you think it's going to do. It scales well. It's easy for the application people that use it to identify with it, and know what they're doing. My rating is primarily based on all those things, and the reliability.

Honestly, selecting a vendor to work with is different than how we chose a product, in general. Pricing is always an option, but stability, support, the willingness of the vendor to cooperate if you need help, and other things like that are important. It's different than it was a long time ago. Most of the time now, you deal with the fact that companies have only been around for a few years.

It used to be that somebody had to be around 10 or 15 years before you would invest in it and believe in it. Now, very strong companies have only been around for one or two years, and have very vibrant products. When dealing with a vendor, it's how willing they are to listen to the customer; how dynamic they can be in enhancing their products; how quickly they can implement features and functions into their products; how strong their support is if you do have problems; and how well the product operates without having an intense learning curve, or a lot of training necessary. It's how elegantly the vendor delivered the product, the documentation; all those things kind of speak to the vendor themselves.

We don't directly use MQ for cloud, mobile, and devices as part of the internet of things. We use direct REST calls. We use z/OS Connect and other mainframe-related REST services. We're generating APIs in order to connect to the internet, and to connect to cloud-based services.

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.