IBM MQ Reviews

IBM MQ could improve capacity, monitoring, and automatization.

I have been using IBM MQ for approximately 22 years.

IBM MQ is a stable solution, it is used mainframe computers and it is secure.

The scalability of IBM MQ is good.

We have approximately 100 people using this solution in my company.

The support from IBM MQ is good.

IBM MQ has a complex setup. The time it takes for deployment take approximately two to three months.

We have a special contract with IBM MQ that give us a certain price.

I am satisfied with the solution overall.

We have five to six people for the maintenance of this solution.

I rate IBM MQ an eight out of ten.

I use IBM HQ to communicate with subsystems within our plants e.g. the supply chain.

I've been using IBM HQ for eight years.

IBM HQ's stability is great - we send six million messages a day, and we're very satisfied with HQ's ability to handle that volume.

IBM HQ's scalability isn't the best.

IBM's technical support is great.

The initial setup was straightforward and took around half an hour.

We used an in-house team and a system integrator.

I would absolutely recommend IBM HQ to others as a very robust, reliable, responsive product. I would give IBM HQ a rating of nine out of ten.

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.

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 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.

For me, the most important features are its interfaces with RACF and how we can set up the security to allow and disallow who can get to it, who can use it; and then what MQ gets to do on the mainframe and what it does not get to do, basically.

Our organization uses it a lot to interface applications that are outside the mainframe with applications on the mainframe, or to CICS, items like that.

It helps meet that threshold between what do the application people want to do – because they want to do everything now on GUIs and outside applications – and be able to have the security of the data living on the mainframe and how they get to it. It's the go-between between those two worlds.

There are probably dozens of ways we are using MQ to better connect across cloud, mobile, and devices, but it's mostly the fact that they are setting up stuff and then they use the MQ as the go-between between the distributed world and the mainframe. That's mostly what it's being used for.

Sometimes the applications people don't really understand MQ. For example, we had somebody set up a call through MQ and they ended up making dozens and dozens of calls when they only really only needed to do one. They don't understand how MQ really works, and how it pulls the data and then distributes it back to them, etc.

I think the application people understand that MQ can do it, but they don't really understand the mechanics behind it. They need to be better educated; how to use MQ, get the data that they need, and not cause conflicts.

At the level of the application development people, there needs to be more communication, more information that they have so they understand, because, in essence, what you're using MQ to do is to go to the mainframe and get things. They're so used to their Windows environment, and they don't really understand how MQ grabs that data, and what the mechanics are behind the scenes. And I think that the applications people need to better understand it. Or else something put into MQ so that it is more obvious to them. They don't know what to ask for. They just know, "We're going to go against this data" and they don't know the difference between the different types of security they can set up. The different access and the different classes. We use different classes in RACF; they have no clue what a class is.

There either needs to be better education on there, and or some tools built into MQ that helps them know what to ask for.

I have a very high impression of the stability of MQ; we haven't had any problems with it. MQ has been very stable. I think we've had it go down once since I've been here, but it was due to something somebody screwed up somewhere else, not MQ's fault.

So far, we haven't had any scalability problems either, but we're only about a year and a half into this.

I have not had to use technical support. I've had to use IBM technical support because of some issues, but I never had to talk to the MQ people. We have an MQ rep on site and he handles that stuff.

I was involved in the decision process of how we were going to use RACF, and what they were going to set up to do their calls, but they decided they were going to use MQ. I was actually called in as a RACF specialist to help get that interface going.

Before you implement it into RACF, really investigate the classes and how you're going to set those up, and make sure it's clear with the application development folks. Especially if you're trying to test QA and production separately, it's really important how those classes are set up, and how you set up the instructions for those guys.

The most important criteria for me when selecting a vendor to work with are stability, technical support, obviously the more customers they have in a similar type of field; that's probably what's most important to us, generally.

So far, we've had good luck with it. It seems to be working and it seems to be very stable.