IBM MQ Reviews

We are a solution provider and this is one of the products that we implement for our clients.

The primary use case for IBM MQ is handling the transportation of messages between applications.

This is being used in a mainframe environment.

Our clients complain about the price of this solution but otherwise, they have not had any problems with it. They are very happy with the quality of the product.

This product has good security.

There is no data loss while transporting messages.

The licensing fees should be more cost-effective so that we can better pitch the product to our clients. With the pricing as it is, they tend to move away from IBM products. They look for other solutions, such as open-source products.

I have been working with IBM MQ for fifteen years.

This product is used on a daily basis and it is quite stable. In terms of reliability, I would rate it a five out of five.

I have not found any issues related to scalability.

We have multiple clients that use IBM MQ.

We handle the support that initially comes in from our clients. If we have any problem, then we take it to IBM using a PMR (Problem Management Report). When there is an issue then we feel that we can go to them.

We did not use another similar solution prior to IBM MQ.

IBM MQ is not at all difficult to set up.

There is no deployment, per se. A broker will handle the deployment.

We handle the implementation and maintenance in-house. The number of people required for maintenance depends on the team. Our team members support multiple accounts.

The problem with this product is that it's a little bit expensive. This is one of the main challenges that we face with our clients. The charges are high and there should be a less costly solution available. This is especially true when you consider it in comparison to open-source tools that are available.

Overall, I am very happy with this product and my only complaint is that the price is high. I definitely recommend it.

I would rate this solution an eight out of ten.

Enterprise messaging with international clustering in 120 data centers in 82 countries around the world. 

It is the most reliable product that we have ever used.  

It runs everywhere, from the mainframe in the US to the PCs in the Gobi desert attached to an analog modem. 

There is not much room for improvement, except it could get a face lift with a modern marketing campaign. 

99.999 percent availability for less than a penny per message over the past 25 years.  IBM MQ is the cheapest software in the IBM software portfolio, and it is one of the best.

IBM MQ is one of the oldest, most underrated products in history. 

We use MQ as part of the core of our enterprise information bus. We started that journey in 2009. We have it both on the mainframe and in the mid-range. For us, by allowing messaging to integrate with some of our third-party solutions, like for web banking and so on, we are able to create an information highway that took in the legacy events, captured ATM and credit card transactions, and integrates that into a digital web dashboard.

It provides a better customer experience and more timely access to data.

There could be better APIs around cognitive analytics, around how the messages are flowing. For example, plugins to Watson. That would be useful.

Stability is rock-solid.

It is highly scalable.

Technical support has been good.

I was not involved with the initial setup.

You need to have the right use case to support that type of data and flight paradigm. If you do, there are third-party open-source solutions that a lot of vendors have embedded into their products that you have to integrate with. This gives you a really good platform to do that. So, if you don't want to put something in that isn't as robust or scalable, you don't have to. You can rely on this to be the conduit and the glue for your messaging fabric.

It's also really good at asynchronous logging. A lot of times, when you buy these turnkey solutions for whatever vertical, they often don't have robust logging and security. So, we use MQ as an underpinning to get that for us and we have written services within our system that take advantage of those capabilities. So, even if the vendor doesn't provide it, we have it.

When selecting a vendor, stability and security are the most important. Price is also important. But, in banking, because it's mission critical and highly sensitive, stability is probably way up there. If messaging fails, we don't make money.

Most valuable for us are the queue depths and creations for the installations. Being a business in financial solutions, we depend on it more for those things, so it's very valuable for us. For most of the applications like JBoss and others we use IBM MQ.

It just needs a better installation. An easier user-friendly installation.

The stability is good. I mean we do have some issues but we always contact IBM whenever we have performance-based issues and we get solutions quick and fast.

Scalability is great.

The technical support is great. Normally, whenever we have an issue, within 24 hours we will get a resolution, so we can close it and leave it to the IBM technical support guys. We get a solution mostly within 24 hours, so that's great.

We didn't have another solution previously, we have always been with MQ.

I would say it was both straightforward and complex, but not that complex. I mean the installation normally would take some time and with all of them open, it's just a button click and you're done.

I wasn't involved in the selection of the vendors.

Go for it. You should always check out the performance and trust for a good solution.

So far, it's helped us with our Maximo integration between the users and the database administrators. I know we kind of lagged behind on some updates, which caused us problems. We recently upgraded, which had made things a lot easier, got rid of some of the issues we had with the older versions.

It helped us with some of our security, on some of our roles, if I remember correctly. It helped us integrating; we’re trying to move a bunch of different things, like trying to move EZMaxMobile into our Maximo and a few other things. Part of that was bringing up WebSphere to the newest version for all the integration.

Off the top of my head, I can't really think of any features I’d like to see in future versions. Right now, I don’t have any improvements to the version we’re using. We just upgraded two or three months ago, and we're still getting it all set up.

The configurations were not difficult, but like I’ve mentioned, again, I believe when they went through the integration, they talked to IBM to make sure that we're going to go through OK. So, there was some interface back and forth during the upgrade.
We’re happy with the user interface, so far.

Getting more analytics coming out of MQ is something we're working with across the board with everything, with our Maximo data, with all the applications we have. We get tired of having to pull reports and somebody has to manually crunch the numbers. We need something behind the scenes tabulating everything and coming up with answers, so we don't spend all our time just collecting everything. If there would be an integrated tool that would give us reports, that would be amazing.

With the newest version, we haven't really had any stability or scalability issues. I guess that's a good thing.

With the previous versions, it was just that we were a version behind on what the version of Maximo and everything we were using, so it was causing a few little glitches and buggy issues.

We frequently use technical support. They have been pretty good, so far.

We knew we needed to invest in a new solution mainly because of the issues we were having with the old version; it was pointed out that they were going to be fixed by the new version, so that was kind of a simple thing.

I was not involved in the initial setup with this current version.

We were already using WebSphere MQ, so we didn’t look any other solutions.

Don't be afraid to call. If you're worried about tackling it all on your own, don't be afraid to call IBM or call somebody that's already gone through the process and get some help, because we're all willing to help; you just have to ask.

I have not given it a perfect rating because there's always room for improvement. I can't give them the improvements; they have to figure that out. It works really well but like I’ve mentioned, with the way everything's changing and developing every day, you always have to be on the lookout for what's coming up next.

In general, when I am looking at vendors, the number one criteria is responsiveness. Number two is time frames and that they meet the schedules. Those are our two biggest things. We've had issues with other vendors in the past with those same things.

The scalability of the environment is the most valuable feature. We also like the speed and the manageability of this tool.

It keeps all of our large systems interconnected, so the MQ is at the base of all of our system integration.

I would like better control over the depth of messages that go in there from all the learning and notifications, better management tools around queue depth, queue issue, that kind of stuff. If things are backing up in the queue, getting better at learning from a dashboard of how the whole ecosystem of MQ is running, that'd be really nice. Because we're using a third party to get that now.

Stability is very strong. We haven't had any issues.

We really like the multi-channel queue manager that allows us to have different entries into the queue and manage that traffic; kind of splitting it out. That gives us an immense amount of scale as we add new applications.

We have used support. They are okay. Opening a PMR is a pain in the neck. When you're in a critical event, you don't want to go open up a web ticket. You want to get somebody on the phone, it could fix the problem now. We get that it all goes with the support level and we are pretty high.

We had a mainframe that had MQ associated to it, so we just kept it going forward.

I was not involved in the initial setup.

Study hard, and implement small, and then scale.

Responsiveness, the tool, and price are what I look for in a vendor.

The integration it provides makes a lot of stuff easier. There are a lot of ways to integrate things but it works on a lot of different platforms and with a lot different technologies.

We've been able to get some disparate applications that weren't originally written to be integrated, but we've been able to make that happen.

I use the character-based interface for things but a lot of my peers like the GUI. Maybe there's a GUI available that I'm not aware of but that would be something that would facilitate it for some other people. Any kind of GUI; it could be on a phone or a browser or whatever. As far as I know, that is currently lacking, but maybe I just don't know. I primarily use the character-based interface for management when I work with it.

Because you can only put so much information on a text screen, sometimes you have to kind of shift views to look at things. That's something that, I imagine, if there was a GUI interface, you could do that a lot more easily. That would be an enhancement, I guess.

To some extent, it just runs in the background and you kind of forget about it. You don't really think about what else you could do with it. It’s just kind of running there.

It's rock solid.

I don't think we've tested the really high-end but it handles everything we can throw at it.

We have used technical support very occasionally. It's gone well when we've called, but we really haven't had too many opportunities.

Give it a try. It's not hard to do a proof of concept, get something going and build on that. You'll find that it's pretty easy to work with and it does a lot for you.

The only reason I haven’t given it a perfect rating is probably because I don't know everything it can do. I probably could take better advantage of it, but I might not be doing that right now.

The most important criteria for me when selecting a vendor to work with is reliability. I've got to trust that the product will do what they say, that they'll be able to support it, and that they'll be around in 5 or 10 years when I'm still using it. I kind of lump that into reliability. When I invest in something, I want it to be there and still working later on.

We are not using MQ to connect across cloud, mobile and devices as part of the internet of things. We don't do that on this project. The barrier to success is that nobody's interested. It's that blunt.

Our use cases for IBM MQ involve share markets.

In this organization, we are not using many of the features because we have a very small infrastructure. In my previous organizations, I used many of the components including AMS. However, here, we are just using it as a messaging solution and not any of the other components.

The MQ appliance has very good performance.

The user interface should be easier to use.

The user interface should be enhanced to include more monitoring features and other metrics. The metrics should include not only those from the IBM MQ point of view but also CPU and memory utilization. These kinds of features would be really helpful when we have a large infrastructure. Right now, this limits us from using the product.

In general, the user interface should be more catchy, to entice users.

IBM should promote the use of the MQ appliance because the speed and performance are superior when compared to traditional ways of using the product.

If IBM were to release as least some limited features for MQ as open-source, then it would be great because people will migrate to this solution instead of choosing open-source products like Apache Kafka or RabbitMQ.

I have been working with IBM MQ for almost 13 years across different organizations. I began working with version 5.3 and am currently using version 9.

The stability is absolutely perfect when it is running on AIX. However, I have experienced some issues with certain Linux distributions. With AIX, I have not had any problems with IBM MQ. With other flavors of Linux, there is some instability whereby the MQ configuration parameters are not giving the proper information. From this, I have concluded that the stability of MQ depends on the Linux distribution that it is running on.

The number of users in my current organization is six or seven. This is the number of applications that we have. This is not an extensive use of the product but we do plan to increase usage in the future.

In my previous organization, our use was more extensive. We had between 700 and 710 users.

This product scales and the number of users depends on the industry, as well as the financial strengths that the organization has.

The technical support from IBM is always reachable.

Internally, we provide technical support to our users. This is possible because our team is only six or seven users.

This initial setup is not complex at all. Deploying it was very easy.

Limited staff is required to maintain this solution because of its stability.

The licensing fees are paid quarterly and they are expensive. This is something that I have heard from all of the organizations that I have worked with.

I have evaluated Apache Kafka and RabbitMQ because of the open-source features and benefits. The open-source aspect is an advantage. I have found that not many users choose IBM MQ, even though it is stable, because of financial constraints.

If IBM were to release MQ or at least some limited version as open-source, it would become more popular. People would choose it instead of implementing other products, or other streaming solutions. This is what people are trying to do with DevOps.

IBM MQ is much more stable than these other products, although the rest of them work well with cloud providers such as AWS.

Overall, this is a good product. The only thing that I found complex was to build the user interface with the latest versions of IBM MQ. It was a little bit tricky to do.

I would rate this solution an eight out of ten.