IBM MQ Reviews

The integration between applications is the most valuable feature. We can use it with multiple applications.

It provides faster interaction between the applications. It makes it easier to integrate the applications.

So we're on MQ version 8, and I was at a recent event for MQ 9 and it looks like they've already added some of the features I was looking. For example, a better monitoring system, and a GUI to display messages, which I think they've already done.

MQ is very stable. It's a very simple application to set up, and once it is set you don't have to really configure or monitor it so much.

Since it is very lightweight, the only thing you have to really scale is hardware. So, migrating is very simple as well. It supports HA, so we have it set up with just an active/passive type set up. And we don't have to scale it as much. So far, its been working out great.

We haven't had to use support yet.

Our first time using a message queue system was MQ, so we went with the IBM MQ product.

Being with a state agency, we actually go through what's called a hub that has a relationship with IBM. We can't directly purchase from IBM, so we have to go send bids. But, since we have quite a few IBM applications, we always you know target IBM since we already have the support that we need and our relationship with our sales person is really great. So, we always choose IBM.

I was involved in the initial setup. It was fairly straightforward. Once you start creating the queue managers, there's some configuration involved, which our developers take care of. I just take care of the basic installation of the product, which is very simple.

I don't know the names of any alternative vendors.

MQ is awesome.

It's good for messaging, very reliable, and forward compatible, so it makes our life easy when it comes to upgrades.

It's reliability really enables us to do our interfaces. Additionally, it scales really well, so when our needs grow, it grows with us.

We would like to see more capabilities with MQ over the internet. It would be very helpful to us to expose our API and web services. We want to see that a little bit more and we want to continue to see that it's a secure means for us to protect our data.

We are absolutely happy with the stability.

We are absolutely happy with the scalability.

We did use technical support mostly when doing upgrades. I would say that we have used this solution for about 15 years already. We only encountered production problems two or three times. It is a very reliable, very solid solution.

I've been involved with integration for a long time. When we first talked about our need to do queue messaging, MQ was the first one that came up. It proves itself.

I was involved in the initial setup. It was straightforward.

I don't recall whether we evaluated alternatives. I think IBM was the first and the last one we reviewed a solution with.

Do the same thing we did. Make sure that you give it a small test first to make sure the solution really works well. Then, make sure it scales.

I've used other solutions, but the most valuable features of this solution are the search capabilities, consolidating the data and searching through the data. I think that these are some of the key things.

For this organization, it was the first log management solution. So, it definitely gave us the ability to search through the data when we had events. We could search based on the identity of the person, or the machine, or the IP address. We could do a lot of different searches.

We could also do payload searches and depending on how much capacity you have, you can do quite a lot with it.

I want to see a three-dimensional perspective to the data. I don't want to see just an event perspective to the data. I want to be able to identify a user and within clicks, know the whole activity of the user. I don't want to see it in events. I want to see it in the relevant information.

There needs to be a little bit more of investment for enhancing the user interface. That is the main thing, i.e., to make it represent the state of the actual incident response and how you would troubleshoot an incident. It was a major position by IBM when they bought it. But, we see a lot of things being done around the Cognitive side, around the Watson side, but what we're not seeing growth in, is the actual tools interface and usability.

We wanted to be able to see seamless identification of log sources, seamless categorization, normalizing of log sources and seamless alerts. All those things that are required for solution maturing, it has to be able to take data and make sense of it by itself, without a lot of input. Those are the areas that they can really improve it.

It's been stable. Stability hasn't been a problem, as long as you have enough capacity. It's all about sizing it right for the size of your environment.

We drop packets every day. So depending on how our log volume increases or reduces, you see the impact on the packets being dropped.

We've used it and it hasn't been great. It didn't seem like we could get the answers we needed without having to use professional services. For a solution like this, there are little things like, how to tune it, how to upgrade it and that as a customer we don't feel the need to use professional services for. We want to be able to just find a document on how to upgrade and that has been difficult to find.

We didn't have a previous solution. We inherited it as part of another acquisition, of another purchase from IBM and then we scaled it up to meet our capacity.

I was involved in the setup process. We got the basic functionality working, which is not difficult. It's getting the full value out of this solution that was harder.

From an analytics perspective, it's a good tool but you have to have the resources to own it. It's not only about buying it, nor is it about the capacity, but somebody has to care and feed it. It's not one of those you put it in and you can walk away and just consume the data. If you don't care and feed it, you won't get what you need out of it.

The most valuable feature is the ability to connect our different systems fairly seamlessly. Without it, I don't know how we would have connected our mainframe Intel-based systems and Power Systems together. It's the tool that we utilize to make it happen.

It's the transport tier that connects our systems. Without it, we would be very disconnected.

We're using it entirely for our transactional systems right now.

We're not really using MQ to better connect across cloud, mobile and devices, and the internet of things. I imagine that will be the tool that we will utilize that will help bring that next level in. Right now, we're not utilizing it.

Maybe the administration interface could be improved. Right now, it's very command-line driven. My guess is that if the GUI interface was a little bit better, with more of a singular interface across platforms, that would be helpful.

Like most of the IBM products, it's pretty stable. We haven't really had any real challenges. We run it on the mainframe as well as open systems and both are incredibly stable.

It is very scalable; we use it all the time.

I have not personally used technical support for MQ, but my team has. It has been very responsive.

I did not previously use a different solution.

I was involved in the initial set up at my organization from an infrastructure standpoint. We provide the infrastructure tier. On the open-system side, we helped with it and helped the implementation out on the mainframe.

The actual installation is straightforward. The configuration and the implementation of enabling MQ to talk and communicate between the systems can be complicated.

Before choosing this product, I did not evaluate other options.

From our experience with the functionality and the stability of the product, it's going to be difficult to find something that rivals it in the industry right now.

My rating reflects its functionality and its ability to allow our systems, our enterprise, to run the way it does right now. It's purely a function of MQ's ability to allow the systems to talk to each other.

Support and supportability are the most important criteria for me when selecting a vendor to work with. The ability to handle challenges quickly and responsively.

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.

They keep on increasing the solutions such as for message synchronization. They have really improved it a lot, with major clustering and the high availability that it can do now. I'm still deep diving into the latest version right now. We have been using this solution for a really long time.

Basically, we are using the messaging part of the solution, collaborating with other technologies on the WebSphere platform. Once you do everything, then you don't really need to worry if the network is available or not. Once you are delivering the message, it's going to be sure delivery for you.

I must check this in depth. I can't really comment on areas with room for improvement, because they already introduced a lot already. I'm still new and need to explore what exactly the latest version has in it. So, only after that I can say what more we need exactly.

I have not had any issues but I'm looking for more collaboration with the Message Broker and DataPower. I feel that the MQ takes a longer time when DataPower is trying to connect to the MQ part, so I'm looking for that. But, I don't have a really good point to bring out right now.

The reason we have been using the solution is because we have it for a really long time, i.e., for more than a decade.

The product's stability is really good. I have recently heard that they're introducing a separate appliance for this. That's going to be a very good step for everyone.

I'm so positive about it's scalability. Other than Walmart, I am working with other companies and I work with the same solution. The scalability is going to be really good and I support it to it's extreme.

IBM technical support is always very great and we have a really good opportunity to talk with them, each and every time that we need support. They give us special attention. So, we're happy with the support provided.

I was involved in all the possibilities. In the past, I have carried out the implementation process from scratch. With my current employer, I have started supporting and building more for the already existing environment.

It's stable and they keep on just increasing the facilities they are providing in regards to clustering and the public supplied options. They're really doing good there.

IBM is doing really good and they're still growing. IBM should keep the work up in the same way and eventually they'll get there.

We have multiple offers out there from competitors, to beat out the open-sources and the competitors comparing with the license cause and the product-support cause. However, they aren't competitive enough and IBM is way above. In the end, you will get what you pay for.

It all depends on the budget. If you have the budget, then I always prefer IBM.
IBM is the more expensive solution out there, but it's worth it.

We use it right now for transferring a lot of big files. Sometimes, for some reason, the file doesn't get all the way to the other side. We do it between different cities. MQ keeps track of it and gets it all done. We at least know if it was half-done or not. We also have scheduled jobs through ESB, but it doesn't send that kind of notification to us. It says whether the script has run or not run. That's all we get. This has been a better product.

Besides that, we do a lot of our jobs through it. We queue them and run them.

These files are critical. They have to reach the whole file. Sometimes, a half file gets the same name and gets processed as a half file. The result is like replenishing all those files. The results are really screwy if you get half files. Since started using MQ, we haven't seen this.

In some cases, when a file got transferred, it has same name on both sides. That could have something to do with the product or it could have to do with something else. We are working on it. That's confusing. I would like that improved. If it didn't appear with the same name, that would definitely be better.

We've been using it for 8-10 years.

It's very stable. We've been using it for quite some time now, 8-10 years.

We started with very few. Stability’s good. It's scalable all the way. It meets our requirements.

Technical support is very good. Whenever we have a question, they are very responsive.

We've been using MQ for so many years. It's been really, really working great for us. I recommend it rather than looking at other solutions.

The most important criteria for me when selecting a vendor to work with is that the product has to be good. Second, the support has to be really good and the people working with it should be genuine, and not just come up with what you want to hear. They have to be genuine. Sometimes the product is good, the support is good, but the people are not.

Integration with my vendor product is the most valuable feature. The vendor strongly prefers MQ. We had a lot of configuration issues when we tried other products. The second-most valuable feature is the stability.

The reliability is a benefit. We rely on it to operate our business. The fact that it's stable enables us to run our business.

With the tooling around being able to see what's in the queue, we found third-party products to be friendlier than the out-of-the-box products, as far as, "Let me see what the content is of the object that's on the queue." I want to actually be able to see what's on the queue, and the tools we were given from IBM or from the representatives were terrible. I guess that would be the thing I’d like to see. I've got the third-party products that I use now and it’s at the operating-system level, but that would be the suggestion.

It is very stable. We’ve had outages and downtime but, out of about 9,000 servers, we'll have a couple go down a month. Overall, that's pretty good.

Scalability hasn't been a problem. We have a highly distributed environment. We run it across a large server farm. Each server has its own instance. I don't try to scale it vertically, so I don't have a vertical problem with it, and it scales fine across.

Technical support is very disappointing. They didn't respond. Then, we nagged them a lot. We basically got, "That's why you should just upgrade to the latest version of IBM. That's a known problem with the stack. You should just upgrade. Why are you still so far behind?"

We had some trouble when we tried to get the vendor product working with the open-source products; that didn't go well. We tried HornetQ, maybe ActiveMQ. (It was eight years ago.) We liked it better than the embedded WebSphere MQ one; better than the one inside the app server.

The vendor had a dependency that their product worked better with IBM MQ. Also, we have an extensive relationship with IBM, so that made the decision straightforward. If you're having trouble with the alternatives, just go with the existing vendor.

Initial setup was complex because of what we were trying to do, as far as the distribution of a number of clones. With the IBM team, there was more internal drama and relationships – more personal problems – than there were technology problems.

We considered other solutions. It was, "Do we really have to?" with this vendor, or could we look at other things? So, we tried other things, and then came back full circle. We picked MQ because we struggled with the other ones. There's a lot of money on the table, so we actually looked at it, we did try it.

Reliability is the most important criteria for me when selecting a vendor to work with.

Look at which features you really need.

It works fine. It does what it's supposed to do. As far as being the best product in the universe, it's a plumbing product; it doesn't have a huge range of functionality; it has a very specific functionality. But it's reliable, so it's a good product.