IBM MQ Reviews

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

• Clustering
• Multi-instance

I have worked with IBM MQ for three to four years.

The stability and performance are good and our customers are happy with these aspects. In my years working with it I haven't seen many issues, and with the type of support IBM provides, it has been fine.

I have been in contact with IBM support many times. I am satisfied with the support.

The initial setup is straightforward. It's not very complex.

Most of our customers are quite happy with the solution but they have an issue with the cost. They want to move to cheaper solutions.

The best advice I can give is that it provides stability and performance and there's no loss of data. That is most important for our customers. The data will never be lost.

It is used by large enterprises.

All our applications run around MQ. We run a backend system working with a mainframe and we distribute records via MQ. We are using it daily.

From the time I joined this company I have been working with IBM MQ. Until now I haven't seen any severe issues related to it. Most of the time it's running. That is the advantage of IBM MQ.

It could be easier to use.

I have been working with IBM MQ for close to 14 years.

It is stable.

It can scale but sometimes, in terms of volume, it is not able to handle a huge volume. We also have limitations of queues related to IBM MQ. We often need to handle a very big volume, but currently we do have limitations. If those kinds of limitations could be relaxed, it would help us to work better.

I'm working on the development side. There is a setup team that is dedicated to working on implementations. I don't have enough hands-on in the configuration of MQ to comment on the setup.

If you're looking for stability I would recommend using IBM MQ. But people, these days, are starting to work with Kafka, which is an open system. I don't have enough knowledge about Kafka to comment on it. I just work with MQ.

We are mainly using it for communication, for connecting to multiple systems. Applications are putting their messages on MQ and, from MQ, we are reading them using IBM Integration Bus. We then process them and send back the response.

The MQ protocol is widely used across multiple applications and it's so simple for connectivity. 

Other valuable features include the 

• messaging format
• message persistence
• security features, including several connection channels and name-based and user-based authentication.

I had some issues earlier, two, three years back. I don't exactly remember them now.

I have been working with IBM MQ for eight years. We are currently trying to implement IBM MQ on OpenShift and cp4i. We have MQ on-premises and we are trying to migrate it to OpenShift, a container platform.

Stability-wise, it's very good. People have been using it for 15 to 20 years. MQ and IIB are the most stable products from IBM.

We can scale up and down anytime. There are no issues there. We have 20 to 30 internal applications connecting to middleware and all of them are connecting using the MQ protocol.

We haven't had major issues, but whenever we have had an issue we have written to IBM and they have gotten back to us on a timely basis.

The setup is straightforward. There is not much to create, it's a one-time setup, including configuring the high-availability. That is the main thing. The parameters create the queues. It takes about 10 to 15 seconds for each queue.

In addition, we had IIB, the IBM Integration Bus deployment, including message flows and DB scripts, etc. So the deployment was not only MQ. In deploying IIB flows, we had some queue creation, server connections, and channel creation. Overall, it was about 80 percent IIB deployment and 20 percent MQ deployment.

We had two people involved: one guy from the support team and one guy from admin. For maintenance, in the sense of the application support, we have four team members but we are handling multiple applications, not only MQ.

We deployed it ourselves.

Although I'm not involved with costs in our company, IBM products, in general, have high licensing costs and support costs are too high. A lot of people have started using open-source, like Kubernetes and microservices. There is also Apache ActiveMQ. There are many other products out there.

I would tell people to use this, except that the pricing and support costs are too high.

I would rate MQ at eight out of 10. 

We mainly use it for exchanging messages between application servers, back applications (e.g., databases), etc.

The message is delivered. This is the most important thing.

Overall, I have been satisfied with the solution's stability and scalability.

They could integrate monitoring into the solution, a bit more than they do now. Currently, they have opened the REST API so you can get statistic and accounting information and details from MQ and build your own monitoring, if you want. IBM can improve the solution in this direction.

15 years.

It is very stable.

It's highly scalable. It provides various ways to establish high availability and workloads. E.g., you can spread workloads inside of your clusters.

We have 20 engineers, admins, and integrators using this solution in our company. 

I would rate IBM technical support as a four (out of five) because they are a big company. If you want to get through all the technical support levels, then you need to spend some time. However, this is normal for such a big company.

The initial setup is straightforward, but you need to take the platform into consideration. If you are talking about Linux, AIX, and Windows, then the setup is really straightforward. However, z/OS or iSeries from IBM are not so straightforward so you need to be familiar with those platforms.

It takes half a day to fully configure MQ on Windows and Linux, and a bit longer on AIX. For z/OS and iSeries, it takes about five days to fully configure their environments.

There is a different platform price between Windows, z/OS, and iSeries.

I would definitely recommend IBM MQ to other people who are looking to implement this solution. They are going in the right direction. Everything is really in place and can be fully obtained. For me, the solution is a perfect product.

I would rate this solution overall as a nine (out of 10).

We use it for message transfer, mostly for a queue of the messages. Sometimes, we also consider using the topic space solution. But it is mostly for transferring messages between two applications. The applications are located in a different country, so it is also used for communication of MQ to MQ. 

What I like the most about IBM MQ is the 

• reliability
• robustness.

What could be improved is the high-availability. The way MQ works is that it separates the high-availability from the workload balance. The scalability should be easier. If something happens so that the messages are not available on each node, scalability is only possible for the workload balance. That's a big difference. And the application must be prepared to consume from each node so that it doesn't lose a message. Otherwise, you lose the ordering of the messages.

I've been using IBM MQ for more than five years. We're currently using version 8 and we are switching to version 9.

MQ is known for its stability.

The technical support depends on the kind of request you have. IBM is a big organization, and sometimes it takes time, while other times it's very quick. But what is great is the documentation and they even define some bugs. They have a willingness to describe these as an APAR (authorized program analysis report) on IBM pages and they're easy to find for the solution.

The installation is easy but the configuration could be complicated because you have to specify a lot of stuff, like queues. It could be a little bit complicated to configure if you have some specific scenarios. For a simple scenario it's easy, but when you have somewhat more complicated scenarios — for example, when you have a hybrid or you need to support some specific security requirements which you use to implement custom components — then it's not easy.

The time it takes to deploy depends on what type of clusters you need. For deployment for testing purposes, where you do not need any cluster, it can really be done in one day, maximum. It's not that difficult. But if you need to deploy a cluster, like a Veritas Cluster, and to prepare the workload balance, it can take days, with system testing etc. You have to combine a lot of other components.

I would recommend it. If you're looking for a traditional queuing system, IBM MQ is the right choice because of the stability and the performance. And from the support perspective, it's enough to have a really small team. It depends on the number of instances, of course. But MQ is not difficult to support. It's mostly to solve communication issues for applications and to determine what type of communication you prefer: the traditional MQ or via JMS, where you have to put it into the headers. But if you pass it, it is very stable after that and has very good performance.

Everything looks fine. It is 

• stable
• reliable 
• scalable.

I am not involved with it at the architect level. I am providing entry-level support for the product. But perhaps if they could come up with monitoring dashboards that would be good. We are using external monitoring tools, apart from our IBM MQ, to monitor IBM MQ. If we could get monitoring tools or dashboards to keep everything simple for the user to understand, that would be good.

The stability looks good.

The scalability is good. I don't have any issues with it.

The initial setup is not complex. It's very simple. I didn't find any difficulty with it.

Apart from IBM MQ, we are using IBM Integration processor. We are pretty satisfied with the product.

I would strongly recommend the solution, depending on the elements and architecture you're using. If you want to keep your data safe, I would definitely recommend using IBM MQ. We are satisfied with the service provided by IBM MQ. We don't have any issues.

I would rate it at 10 out 10. It's the best.

We use it for file transfer and batch processing. We upload electronic documents to the Chilean government.

We use version M2002 Model B and our clients use version 7.5.

We use it for our factory where we have a system that uploads electronic documents for the entire country.

The high availability and session recovery are the most valuable features because we need the solution live all day.

The product gives us security.

I have been using it for six years.

We are happy with the solution. It is stable and doesn't require much maintenance. Two people maintain this solution: an architect and engineer.

We have two appliances, and that is enough for now.

There are a million end users.

The technical support is good. They respond in a timely fashion when we have problems.

We switched to IBM MQ when we consolidated our software and hardware integrations.

The initial setup was easy because IBM did the installation and integration of MQ with our appliance.

The deployment took a month.

The vendor did the MQ installation. We had a good experience with the IBM consultants.

We don't keep track of return on investment because we offer a public service.

The price is high. 

I did not choose this solution. The company has had it for over 20 years.

If you want high availability with little maintenance, choose this solution.

We don't use containers yet.

I would rate the solution as a nine (out of 10) because it is not perfect.