IBM MQ Reviews

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.

We use it for all our integration cases, including the integration of core applications within our company and external solutions from our partners.

We use IBM MQ and IBM Integration Bus, App Connect.

The most valuable feature is the interaction within the system.

I have been dealing with IBM MQ for five years.

The solution is very stable. There are some bugs, but they are very small.

Scaling is difficult with IBM MQ.

The support from IBM Russia is good.

The initial setup is 50/50, between straightforward and complex. The difficult part is because for the integration of other systems with IBM MQ, they need to use software from the IBM client. But the installation itself is not difficult.

We had assistance from an integrator.

It would be a 10 out of 10 if it wasn't so expensive.

I would recommend the solution, but it is very costly.

We work with an organization who has only one product and that works with IBM MQ. Combined with IBM MQ, this product is our primary data store.

There are many things that I like about IBM MQ, such as, its performance and reliability. 

I'm not sure that current version has event-driven mechanism requests that people go for. I would like the latest version to come with both type of event-driven mechanisms: an email server and a POP server. If that is not there, then that would be a great addition.

I have been with a company for the last three years who has been using IBM. I was with another organization before that who used it for four or five years.

For the last three years, I haven't faced any stability issues. I would rate the stability as a nine (out of 10).

Support is managed by the vendor management team. This is being taken care by some of the managers.

I was not involved in the pricing structure.

There are quite a lot of competitors of IBM MQ who have high capabilities.

I would rate the product as a seven (out of 10).

IBM MQ is used heavily in all of the companies I have worked for, mostly in the financial industry. It is easy to set up and has good instrumentation.

The product was already installed which is not surprising as it was first published around 1993.

To be able to programmatically send information stored in 'messages' and send them securely, as well as the ability to check their contents and statistics when things go wrong.

• Better testing by the supplier is needed
• Ability to send to a group of queues without the need to use pubsub and without the need to write one's own programmes.