IBM MQ Reviews

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.

We have a diverse distributed environment that includes Z/OS, Microsoft Windows, Solaris, Linux, and zLinux. We use multiple programming languages and different databases.

IBM MQ was found to be easy to implement and operate. It became the defacto standard, and integration problems moved from an operational issue to application solutions.

The most valuable features are the point to point messaging and the MQ API. This solution is simple and very diverse.

I would like to see faster monitoring tools for this solution.

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.

Originally, we were doing this in-house, and it was a huge effort. Now, with IBM MQ, we have increased our performance, and it performs really well. The queuing system, given the size of information, is helpful.

The on-premise installation is very valuable to us, since we are working with a lot of companies which have a very high degree of compliance.

I will say that, okay, we are coming from a long history as an IT company, and we have almost done queuing systems with other solutions. Moving from that implementation to something that is out-of-the-box, and the rave reviews, it was a great asset already. We didn’t have to worry about all the specific configuration, or installation of our own queue, and queuing system, and the brokers, and so on. It was some things a little bit out-of-the-box, that's why we like it.

I believe there is too much code to be done in order to handle the elements that you develop. We choose a new feature, we would choose something that is a little more … even more out-of-the-box, and gives me the possibility to configure directly where the messages should go, instead.

Also, the IBM MQ, it doesn’t really have a connector.

I believe the stability of the product has decreased since we began using it initially.

We had some load tests, and actually it was quite straightforward to make a scale actually. I believe we are satisfied with it. We are talking about 100,000 users, and it was performing well. So I don't know if it scales well when we talk about millions. But, for our needs, it scales nicely.

We do not have a direct contact with them. We have a desk line with them, and we have some sort of agreement. They treat us very well.

I do not get involved with the setup of the solutions. But, my team member was very happy with it, and said it was quite easy to install. 

We always must consider:

• Reliability is a key requirement
• There should be a roadmap
• Support
• Development

We also considered Apache Kafka as a solution. The main difference is that Kafka is an open-source platform.