IBM MQ Reviews

Mainly we are using MQ to pass the orders in the format of messages. We use MQ mainly for all the asynchronous messages that we pass.

It's easy to use and also quite compatible with all the language technologies where they can read messages and they can push messages to Java. It's easy to integrate and compatible with most coding languages.

The solution is stable.

I have found that the solution scales well. 

The integration capabilities could be even easier. 

I've been using the solution for a while now. It's been maybe ten or 15 years. 

The stability has been good. The performance is reliable. There are no bugs or glitches. It doesn't crash or freeze. 

The scalability is good. If a company needs to expand it, it can do so. It's easy.

We have a team of about five on the solution right now. 

We do not have plans to increase the number of users at this time. 

IBM technical support for any product is pretty much the same across the board. I have no complaints. They are okay. They are fast and knowledgeable. 

We have been using MQ for a long time. In the past we were using a custom-developed framework instead of MQ, however, that was ten to 15 years ago.

I can't speak to how the initial setup went. Those kinds of tasks are handled by the technology team. Therefore, I can't say if it was an easy or complex process.

I'm not sure, ultimately, how long the deployment process was.

I wasn't a part of the process. I can't say if we enlisted outside help or not. 

You do need to pay a licensing fee in order to use this product. We pay it on a yearly basis. 

I'm not following the versioning part. I'm not sure which version we are using currently. 

I'd advise new users to try it out as it is easy to integrate, scalable, and stable. 

I'd rate the solution, in general, at a seven out of ten.

The solution allows one to easily configure an IBM MQQueueManager. It's very easy and demonstrates comparatively better performance than that of other products. It is very good and makes it impossible to lose a message. These are very important advantages of the solution, but the greatest one is its robustness. 

It would be nice if we could use the cluster facilities because we are doing active/passive configuration use. Maybe we could implement them in cluster scenario and use the active/active nodes.

We have been using IBM MQ for around 20 years.

The onboarding processes and setup are very easy. 

We solely make use of IBM MQ and are an MQ customer. 

I rate IBM MQ as a nine out of ten. 

We're a service provider. My company provides services to different clients that include financial institutions in the banking sector.

IBM MQ is used for queue messaging. I have to install and configure, the MQ features of listener channels, remote queues, and some transmit queues. We enable these as per customer requirements.

The solution offers very good features, including listener channels, remote queues, and transmit queues.

The solution is stable.

The initial setup isn't overly complex. It's pretty straightforward. 

Technical support is very good.

IBM MQ is not very user-friendly. MQ needs to redesign or add some sort of user-friendly interface in order to offer better performance.

This is a very old solution. Nowadays, some other products are designed to be much more user-friendly as compared to IBM MQ. 

The product needs better administration.

I've been working with the solution for three years. 

The solution is very stable. There are no bugs or glitches. It doesn't crash or freeze. It's reliable. 

We've found the technical support to be very good. they tend to match the severity level of the situation. We're quite happy with the way they respond.

While the initial setup is not overly difficult, the user interface is not very user-friendly. 

I cannot speak to the pricing of the product. I can't say if it's overly expensive or reasonably priced as I don't deal directly with licensing. 

We are an IBM partner. 

I'd rate the soluton at an eight out of ten. For the most part, I've been pretty happy with its capabilities. 

We provide a channel that we call "the link," so we are distributors of numbering services. These links are connected to a simulator, for example, when MQ is related to some application or the scanner. It's a synchronized communication where we first check two-step authentication. So first, we start with the authentication. In the second step, the MQ server provides the connection. Then the system decides if it can make the connection or not. For example, if I'm uploading something, it will check one cluster, not the other five. So next time, I'm just checking to see if we can connect. After that, the other side is also checking. Those clusters are physical connectivity clusters.

We are sending everything. The partner and we create an acknowledgment number and check to see if everything is fine or not. Once everything checks out and we have verified the person with our partner, we establish the connection, sending a message. Then we are also checking the permissions and format. Sometimes there are some errors, so we have to check the login acknowledgment number and figure out what the error code means. We are handling everything for the project, from the code and deployment to support. We are handling everything through an RFP repository. So from there, we are handling every version released in the last two years. Every year, we upgrade according to the guidelines.

There are so many good things with IBM MQ networking. So many complicated issues arise when you're trying to configure your network, and MQ helps by providing the clustering. In our project architecture, we have a cluster that distinguishes between major requests from applications. There is also a centralized cluster. Let's suppose 10 applications are connecting to that cluster. In each application, we add differently. 

If I need to add multiple features to the centralized cluster, we can create another cluster. From there, the GMG is connected. Also, clusters can provide a backup. So suppose this solution faces some failure, like a power outage, MQ can automatically redistribute the load to other servers. 

We are using the synchronizer and another module in our product. We are stepping the connection from the IBM channel. After that, we can send or receive any message. This is synchronizing. We are handling the clustering, and we have created a design for how the NP is built with the partner.

IBM is still adding some features and coding some other systems on the security end. However, it has the most security features I've seen in a communication solution. Security is the most important thing for our purposes.

Sometimes, there are network issues, which means more applications are connected to those messages, so I would like to fix that. For example, suppose there's a new network, and I want to add virtual memory to address a network issue within the cluster. So there is a network issue that needs to be resolved from the cluster. So I need to add the permissions for that particular team or particular time. There are many complications with IBM MQ servers.

I've been using IBM MQ since last year.

IBM MQ is reliable.

We don't use IBM support much. Sometimes partners will come to us with questions, so we just guide them. Sometimes, you need an MQ person because they have access. We guide the customer to ask this question. You have to ask the MQ entity or the entry person. They will help you. And we are not writing any protocols because a separate team does that. And also, if anything goes wrong with the MQ product, then IBM will address that.

From a coding perspective, it's a straightforward process. There are no complications. We cannot directly access the IBM server because there is a separate team assigned to do some security and get some code of conduct from the MQ team. They are handling the MQ server. So we ask them to create these entry servers to discuss that. And also, we are defining everything. We are responsible for handling invalid queries. So they recreate a wrong question or wrong to them. So, whatever is an appropriate question. 

In terms of maintenance, there are three reasons you'll get a maintenance window. On the maintenance window, we are just restarting the epicenter. Nothing else. If it requires any patching or updates, we perform those. But you don't have to restart the application.  The epicenter typically runs continuously.

I rate IBM MQ seven out of 10. It's a good option for anything banking-related where you need secure communications. There are some other similar products out there, but I'm not about other servers. But I'm aware of our BME. So if you're doing banking or anything that requires secure channels, I would recommend IBM MQ. 

IBM MQ can be used as an integrated bus system in an API for message queuing.

The solution is easy to use and has good performance.

I have been working with IBM MQ for a few months.

The solution is stable.

The scalability of the solution is good.

We have approximately 100 users using this solution in my organization.

The technical support from IBM is very good, they are responsive, and customer friendly.

The installation is not difficult for IBM MQ and takes approximately one day.

We have approximately seven engineers and administrators that do the implementation and maintance.

The price of the solution could be reduced, and we are on an annual subscription.

I would recommend this solution to others.

I rate IBM MQ a nine out of ten.

I'm a technical specialist and we are customers of IBM. 

This solution offers good performance as well as scalability and stability. It offers a template that's beneficial for any company.

I'd very much like to see more integration in the monitoring tools.

I've been using this solution for nine years. 

The stability is good. 

The solution offers very good scalability. 

The initial setup was straightforward. It's all about planning because we have multiple application teams involved. Deployment takes somewhere between half an hour to an hour, but for the coordination to check and perform from the application side, takes almost a full day because we have critical, multiple applications. It needs to be coordinated and we need to be sure they are able to connect perfectly with our environment or with the MQ.

We pay an annual license fee. 

I recommend this product and rate it a nine out of 10. 

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 are using the solution for taking messages off the mainframe and distributing them down to a large, high-performance computing environment supporting over 4,000 servers.

The most valuable features I have found to be the message queue itself and its ability to bridge between mainframe type services to distributed services.

The clustering capabilities have provided some difficulties when it comes to resiliency. This has been a challenge for managing the environment.

I have used the solution for approximately 15 years.

We had stability issues with the solution. I would be looking at replacing the product, but I am not in charge.

I was not on the team that was on our internal MQ for support but I know IBM support services are really good. While I have had some issues and long nights supporting IBM software in my 33 years of IT, the support personnel are good. I always say good things about them. It is not their fault that their products come up short, but they do a good job at supporting customers.

The installation was straightforward until we started to have resiliency problems, it then became more complex to have to set up clustered MQ servers. We were using Linux Red Hat cluster services, which became an extra burden. When it eventually came time to do other activities, such as updating the operating system or a specific driver, for example, a firmware driver for the bare-metal servers themselves, having the MQ's clusters being sensitive caused a challenge for service and support.

The solution costs are high, it is going to cost a fair bit for annual operating costs and support.

I would advise, if I was the person in charge, I would tell my architecture team, "Bring me three other MQ-type solutions and do a POC to see if we can get better performance, resiliency, and reliability at a lower cost."  I guarantee there are solutions out there that can do just those three things.

I rate IBM MQ a six out of ten.

The subscribe and publish features are excellent. We use them a lot.

The usability of the solution is very good.

There isn't that much happening with the installation consoles and monitoring consoles. This could be improved.

We need to have a better administration console and better monitoring features. Right now, they are not good and could be a lot better.

The pricing could be better.

I've been using the solution for ten years. It's been a decade so far, therefore, it's been a rather long time overall.

The technical support has been pretty good. Every time I've used it, they were pretty good and I found them to be knowledgeable and responsive. I'm quite happy with their level of service.

The pricing could be lower. It's not the cheapest option out there. However, I don't have comparison prices with other solutions at this time. We're working on comparison pricing currently.

We are currently evaluating other options. We are starting the comparison now and we are starting on the technical scope, not on the budget. However, we will also consider pricing as we evaluate other potential options for our company.

We're just a customer. We don't have any business affiliation with the organization.

On a scale from one to ten, I'd rate this solution at a nine.

We use it for application-to-application integration.

Reliable messaging and throughput are the most valuable.

We are looking at the latest version, and we hope that resilience, high availability, and monitoring will be improved. 

It can have some more improvements in the heterogeneous messaging feature. The current solution is on-premises, so good integration with public cloud messaging solutions would be useful.

I have been using IBM MQ for 20 years.

Its stability is great.

Its scalability is okay. The inside scalability is great. We are hoping that the outside scalability is improved in the latest version.

Most of the users are just using the applications, and they are using IBM MQ without realizing it. In terms of the number of people really dealing with IBM MQ on a global scale, there are probably around 30 users. They are actually working with the product. There are thousands of developers who are using applications with IBM MQ.

I am an architect, and I talk with the architects of IBM. The engineers talk with technical support when needed.

The basic setup is simple. The deployment is fully automated.

We received the software from the vendor, but we deployed it on our own. We also do the maintenance ourselves. 

There is real money involved here. As compared to RabbitMQ, IBM MQ is on the higher side in terms of cost.

I would recommend this solution for similar companies. I am very fond of IBM MQ because of the reliability and throughput part, at least on a single server. On the consumer and application side, RabbitMQ seems a bit easier to consume. It is a bit ahead in terms of the scale-out feature.

I would rate IBM MQ an eight out of ten.