IBM MQ Reviews

We're using the IBM MQ series in development, integration, UAT, and production areas.

What I found most valuable in this software is its reliability because messages that are sent into the queues are consumed by the other end of the connectivity. It has helped us maintain integration between two different systems, so that has been part of one of the layers of our architecture that communicates, for example, a back-end platform and back-end core system with a front-end platform. In our case, we are using the backend as a 224 banking system and the frontend we are using the Wall Street front office system. Those two systems are interconnected via the IBM MQ series.

An area for improvement for this software is that sometimes, messages are not consumed in the queues. We have seen queues where not all messages are emptied. That issue has been solved by our IBM team located in Spain, but we haven't received detailed technical information as to why those queues are not totally consumed. A probable reason could be some service and availability issue because of server updates in IBM MQ itself, or server updates related to the operating system, which in our case, we are using Red Hat Linux.

I have seen a lot of problems with the file transfers, e.g. using FTP or SFTP or LFTP. Normally with all these kinds of transfers, they are not on a transaction boundary, meaning a transfer can fail during the execution. We are not certain why it hasn't reached the destination as these protocols are not transactional which you normally have in MQ messages. What I would like to see in the next release is a solution for the MQ file transfer. I saw some literature about it, but I am not sure if the feature is available, or if it will be easy to configure and maintain in the bank.

We've used IBM MQ within the last year. We've being using it on a continuous basis because it is the secure platform we have in our banking system.

IBM MQ is very stable. It's the best server in terms of interconnectivity. The reliability that the MQ series has, I haven't seen in other servers that are also based in MQ.

My impression of the scalability of this software: We started with a very easy installation where we have very few queues defined. Then, we had a huge integration where we applied, pulled, and observed that the scalability is very straightforward. We also found an easy way: making an active-passive configuration automatic. For example: If you have one active server going down, the passive server is switched on automatically, without us needing to do anything from our end, which means the active-passive configuration works properly.

I haven't been involved in contacting IBM's support, but in general, we didn't have any vendor issues.

The setup for this software was very complex, particularly with the integration between the two systems I was talking about earlier: on the core backend and on the user frontend that is the Wall Street system. It has a lot of different types of flows, and all those flows are defined into the server that is called TTI that is working under the MQ series. That contains a lot of complexities because the vendor of the front-end system has included in the MQ side the server functionality for the application, instead of doing it directly in either the backend or the frontend. This means the MQ part is also helping with the logic for processing messages, and the logic is maintained in a layer: the MQ layer in the server that's called TTI. This is the first time we have faced such complexity, but regarding the MQ as is, meaning the vanilla version, it is quite straightforward. That server works the proper way.

We used consultants for the implementation and those were consultants from the vendor who were already experienced in the TTI server.

The licensing for this software is on a yearly basis, but the bank is holding just one license for the entire bank: a corporate license. As for additional costs, it's a standard fee that includes the maintenance and updates that are released periodically.

I didn't download Active MQ and IBM MQ. I was checking on the website because I wanted to know certain functionalities about those two series. So what I downloaded was the literature about their functionalities.

Regarding IBM products, the only one that I was working with was the MQ series.

All products in our organization, particularly the banking systems are on-premise. We are not yet ready to do cloud deployment.

Deployment of this software in the TTI part took three months. For the core part, deployment took approximately one month. The time that it took for deployment is also associated with the number of servers that we had.

We have four groups: development, integration, user acceptance test, and production. In each of these groups, they have their own MQ servers. We started with the installation for the development group, then going forward and solving the issues we found at the beginning with the installation instructions. We continued with the other areas until we reached the production server recently, back in mid-October.

We currently have 200 users of this software.

Deployment of the IBM MQ at core requires two people in our organization, but for the personalized application or the customized one, we have 10 people.

I'm rating this software a five because it is quite expensive and complex. I'm giving this a five over ten rating not just because it runs, but because it has a lot of features.

We have two different use cases for this solution. We use it for the interactive interconnectivity between clients into the cloud and applications communicating within our enterprise software.

I have found the solution to be very robust. It has a strong reputation, easy to use, simple to configure in our enterprise software, and supports all the protocols that we use.

Everything in the solution could be simplified a little. We have trouble with the configuration and cost which is mostly an internal issue, but nevertheless, the errors do come up when there are configuration changes across a specific version. We have slightly different versions, which may have slightly different configurations which cause issues.

It is intensive to maintain and train people to use the application. There has to be a certain amount of education going into the developers, as well as the infrastructure staff. This could be improved.

I have been using IBM MQ for approximately 20 years.

The solution is very stable.

We have found the solution is highly scalable. It is very easy to scale horizontally, we can scale across and make another instance of the application if we need to.

We have approximately 2,000 to 10,000 are using this solution in my organization.

The quality of service can vary depending on the level of support for different issues. If it is on an issue with what IBM does within their cloud that they control as an ASP it can be somewhat complicated because it is not visible to us. They only support and run the model for us. They will do the updates, manage, and make sure everything is working, it is an effective service but if we have an issue, we do not get that much of a response from them. However, when it is on-premise with us on our side and we talk directly to IBM and they support us fully for the application. 

The installation can be fairly simple, but when changes or modifications are necessary within the system for the implementation it can be a bit difficult. We standardize a lot of the process whether it is using Jenkins or Pipelines, or another solution to make it as simple as possible. However, when we make changes and more errors and configuration problems come up, it can be quite difficult to narrow down those problems. Generally, we automate most of this part which has limited the impact but the process could be improved.

Since we automate a lot of the deployment elements I am not sure the breakdown of how long it takes for each part, but typically all together it takes approximately half a day.

We do the implementation of the solution.

This solution is a message exchanges system for queuing messages. The messages come in and if they are rejected or if they fail to be received, they sometimes fall into something that is called a dead letter queue, queues that are dead, or queues that are ineffective. Those have to be maintained and monitored at all times. There is quite a lot of attention needed. It is extremely critical and the robustness is extreme when it is on the edge. When it is in the enterprise is not that bad, but if it is on the edge, outward-facing to the client, we do a lot of work to maintain and ensure that it is working at all times.

You have to license per application installation and if you expand vertically or horizontally, you will be paying for more licenses. The licenses are approximately $10,000 to $15,000 a license, it can get expensive quite quickly.

We maintain and support a lot of applications across a wide enterprise. Therefore the cost of licenses increases with each individual implementation of a client because we have to pay for licenses. We are looking for an alternative solution to reduce costs by going to an open-source messaging system because we do not need the robustness of IBM MQ.

I have evaluated Rabbit MQ.

If you want a robust enterprise application that you know is going to be around that you can trust and you are very comfortable with the concept that you are going to pay for that stability and robustness, then IBM MQ is the best choice. If you are on a lighter throughput or you do not need to worry about the robustness as much then Rabbit MQ could be the better choice. It is a fairly stable application, and it works very well but you do not have that industrialization and long-term code benefit that you receive from IBM WebSphere. If your use case and budget fit then this solution would be a great choice.

We have used the application for a long time. I understand it, how it works and therefore I feel comfortable with it. From a pure usage standpoint, it is great. It will handle anything, but you have to be willing to understand that you are getting into something you cannot go backward on very easily. You cannot easily swap another suitable or similar application out without a lot of work involved. You have to be very careful what you are trying to accomplish with your software.

I rate IBM MQ an eight out of ten.

We use it as our enterprise messaging bus, not from the transformation use cases. It's mainly from the messaging use cases only. We use it for connecting to mainframes predominantly.

It was the main messaging bus for us for a very long time. Therefore, we have applications connecting, and even some of the modern applications are still using MQ. From a company's productivity perspective, we see a lot of benefits. It's all point-to-point connectivity. For any point-to-point messaging needs, MQ is very good.

The reliability is great. You will not see a case of a message loss in IBM MQ unless there's a queue full or there's some issue with the capacity of the queue. I haven't seen any issues with respect to the message loss. That's the main thing I like about MQ.

It's very robust.

It's a stable product.

Support is helpful and there is lots of good documentation available. 

The solution can potentially scale. 

While there is support for API, it's not like the modern API capabilities. If you want to automate the creation of queues and topics, IBM provides command-line utilities. It does provide API capability; it's just not that complete.

They should make CI/CD available. There is no CI/CD support from the product. Maybe MQ should think about the modern way to handle deep-based development. 

As a user, I have about eight to nine users of experience with this solution. 

Stability-wise, we have no problems. It's very stable. 

Scalability-wise, in terms of the implementations that we have currently, it's not quite scalable. The implementations that we had were more active-passive kind of implementations up until now. There are product features that came up that allow it to scale. We understand it is scalable. However, we still need to explore it. There's a new HA capability that has come from IBM, which is a cloud-native replica set way of doing it. It's possible, it's just more difficult how we have it arranged.

We have a user base of millions and maybe 50 to 100 developers working on the solution. 

With MQ, we are trying to reduce usage since we have better products to support JMS. Most of the applications are Java-based applications, which have native support for JMS. We only use MQ right now for mainframe use cases. For all the other messaging use cases, we use Solace.

Technical support is quite good. They are some of the best. They are responsive.

Since we've used IBM for a very long time, we need to rely on them less. Most issues can be dealt with by looking at the documentation, which is available online. You often do not even have to reach out to support. That said, if you do, they are great.

We did not previously use a different solution. 

From an implementation perspective, it was hard for the features that we were using. However, recently, it has become quite easy to implement.

The setup team is a bigger team due to the size of MQ in the company, which is quite huge. We have around 200 managers and the size of the team is around 20 members and they can all assist with deployment tasks.

The initial setup is done by our deployment team. In fact, I currently work in pipeline development for MQ, so it's easy to implement.

Returns are quite good for the amount that you pay, since, with IBM products, you see fewer bugs.

I don't have any information related to licensing costs. 

We likely have an enterprise license, based on the size of infra that we have. My understanding is it is not very expensive. However, for a new company, it may be pricier.

We get everything in a bundle. There are no extra costs involved. 

I didn't look into other options. When I arrived at the company, MQ was already there. They've used it for even longer than I have - for maybe 15 years. 

We are customers and end-users.

We have various versions that we use, including versions 7 and 9.1. We have both cloud and on-prem deployments and mainly deal with on-premises. 95% is on-premises. 

If you're looking for a guaranteed messaging platform, MQ is quite good. That said, it might be expensive for new organizations. If you're looking for a cheaper option, maybe you may need to look for other MQ open-source protocols or open-source products. You may not get the same guaranteed message delivery experience that you have with MQ. However,  it might be more affordable. With MQ, from a reliability perspective, you see very few bugs. It's been running in the bank for a long time. We have very few cases where we had to reach out to IBM support. It's just too bad they do not have CI/CD capabilities.

I'd rate the solution nine out of ten.

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. 

I haven't used 100% of the IBM product. That said, the message transformation is very good. My application may not always be running, yet even if it is off, whenever I stick on my applications, I get all the messages that I'm supposed to get. Also, the sending functionality of the application may not always be on. I can keep sending the message, and they will get my messages when their applications turn on.

The initial setup is easy.

The GUI part could be better. The command line part is fine if the person knows the commands. However, we started using it on the GUI. It needs more direction, and it needs to be easier to understand. If the connectivity is not happening between the receiver and sender, it would be ideal to have some kind of a GUI that helps me to find the issue. Right now, whenever the connection is not happening, I use the debug a lot, and I use it to see configurations. I'd rather just have a message in the GUI that can say, for example, "The port is not enabled. The port is wrong." 

I used to get an issue with the connection. Maybe the configurations are perfect. However, the issue is on the other side, where maybe the component is down. I will only come to know that when I ping or ask the other person. Instead of that step, if there was a GUI that would tell me exactly what the issue is would make troubleshooting clear.

In general, they need better visibility and not just the GUI design side. They need something that elaborates to the customer or user where the issue is. 

Technical support needs to be faster and more knowledgeable. 

I've been using the solution for more than four years. 

Product-wise, there is no problem with the stability.

That said, when there are a lot of messages, I may need to increase the bandwidth or the queue size. If I have to increase the queue size, maybe I can increase it to even a million, however, in the down sessions, when I extract the transaction, it takes a lot of time. When I want to see what information is inside the queue when I extract it, it takes much more time, which could be looked into. It might be a performance issue or something. It might not happen every time. Whenever there is an issue with a large set of transactions, for example, if, in a minute, you get a lot of transactions, we might have an issue. Still, it rarely happens. 

We have had a limited number of users. We haven't tried scaling since we are rather small. There are very limited users. 

I have raised a couple of tickets with IBM support. The one thing I say is, all the support members are not always knowledgeable. I need a very senior person when I need something. Whenever I log a ticket, there will be one person who will not have the information to help, and I need to escalate. Every time I have to push and ask for somebody more senior, only I can get help.

What is expected is, as soon as we give some logs or share some issues, that we get a person to help immediately. However, that's not the case. It takes too long. 

I have not worked with other products. 

In terms of the initial setup, we never faced any problems. It's quite easy. Even the cloning and queue managers are really good. 

I'm not involved on the licensing side. 

I have only really been into IBM MQ. It's a good product at the moment. I didn't get an opportunity to look into or work with other products.

We're IBM partners. 

So far, I am satisfied. I'd rate the solution eight out of ten. 

I'd recommend the solution to others. 

The methodology and the way in which the platform has been produced as a standard is most valuable. There are so many different versions of it now, but the actual basic functionality and the simplicity of it have made it far easier to be implemented in so many different instances. When I worked with the OS/2 or PS/2 machine environment, the messaging mechanisms were based upon IBM MQ. It is so versatile, which is the main reason that I'm a fan of it. 

There are things within the actual product itself that can be improved, such as limitations on message length, size, etc. There is no standardized message length outside of IBM. Each of the implementations of the MQ series or support of that functionality varies between various suppliers, and because of that, it is very difficult to move from one to the other. We have IBM MQ, but we couldn't use it because the platform that was speaking to MQ didn't support the message length that was standard within IBM MQ. So, we had to use a different product to do exactly the same thing. So, perhaps, there could be more flexibility in the standards around the message queue. If we had been able to increase the message queue size within the IBM MQ implementation, we wouldn't have had to go over to another competing product because the system that was using MQ messaging required the ability to hold messages that were far larger than the IBM MQ standard. So, there could be a bit more flexibility in the structuring. It has as such nothing to do with the IBM implementation of MQ. It is just that the standard that is being put out onto the market doesn't actually stipulate those types of things. As a result, rather than following the recommendations and the standard that was within the IBM MQ implementation, some suppliers say that we need the ability to have longer message lengths than they've implemented, but that's the way it is. Other than that, I'm very pleased with it as it is. It is good at doing what it does. I love the actual implementation, and I've used it a lot.

I've been using IBM MQ since it came along. We've got a lot of different platforms. We have IBM MQ. We have had BizTalk, IMMQ, WebSphere, and WebLogic platforms, but we're moving very much into the cloud.

The support that we have goes through third-party vendors. In the past, their support has been very good, but I can't say anything about it today. About 15 years ago, in the companies I was working with as a consultant, we had very good support. We were working very closely with IBM, and IBM implemented the PS/2 and OS/2 operating system together with Microsoft. The implementation there in terms of the connectivity was an implementation of the IBM MQ series in the OS/2 operating system, PS/2 environment. The support we received for that work back in the late '80s was fantastic.

The initial setup is usually left to other people to do. I've never actually done the installation and setup of it myself. It has been other people with a bit more deep technical knowledge who have done the implementation and actual installations. It was a very long time ago when I received the first set of CDs where we were going to be doing the installation of it, but I don't have that deep technical knowledge of the implementation as such.

I think it's pretty reasonable, but I'm not so too sure of the current pricing strategy from IBM. We use many bundled services, and most often, we go through a service provided by some other third-party implementation. So, I can't really give an honest opinion about that.

I would rate IBM MQ an eight out of 10.

Our use cases for IBM MQ involve share markets.

In this organization, we are not using many of the features because we have a very small infrastructure. In my previous organizations, I used many of the components including AMS. However, here, we are just using it as a messaging solution and not any of the other components.

The MQ appliance has very good performance.

The user interface should be easier to use.

The user interface should be enhanced to include more monitoring features and other metrics. The metrics should include not only those from the IBM MQ point of view but also CPU and memory utilization. These kinds of features would be really helpful when we have a large infrastructure. Right now, this limits us from using the product.

In general, the user interface should be more catchy, to entice users.

IBM should promote the use of the MQ appliance because the speed and performance are superior when compared to traditional ways of using the product.

If IBM were to release as least some limited features for MQ as open-source, then it would be great because people will migrate to this solution instead of choosing open-source products like Apache Kafka or RabbitMQ.

I have been working with IBM MQ for almost 13 years across different organizations. I began working with version 5.3 and am currently using version 9.

The stability is absolutely perfect when it is running on AIX. However, I have experienced some issues with certain Linux distributions. With AIX, I have not had any problems with IBM MQ. With other flavors of Linux, there is some instability whereby the MQ configuration parameters are not giving the proper information. From this, I have concluded that the stability of MQ depends on the Linux distribution that it is running on.

The number of users in my current organization is six or seven. This is the number of applications that we have. This is not an extensive use of the product but we do plan to increase usage in the future.

In my previous organization, our use was more extensive. We had between 700 and 710 users.

This product scales and the number of users depends on the industry, as well as the financial strengths that the organization has.

The technical support from IBM is always reachable.

Internally, we provide technical support to our users. This is possible because our team is only six or seven users.

This initial setup is not complex at all. Deploying it was very easy.

Limited staff is required to maintain this solution because of its stability.

The licensing fees are paid quarterly and they are expensive. This is something that I have heard from all of the organizations that I have worked with.

I have evaluated Apache Kafka and RabbitMQ because of the open-source features and benefits. The open-source aspect is an advantage. I have found that not many users choose IBM MQ, even though it is stable, because of financial constraints.

If IBM were to release MQ or at least some limited version as open-source, it would become more popular. People would choose it instead of implementing other products, or other streaming solutions. This is what people are trying to do with DevOps.

IBM MQ is much more stable than these other products, although the rest of them work well with cloud providers such as AWS.

Overall, this is a good product. The only thing that I found complex was to build the user interface with the latest versions of IBM MQ. It was a little bit tricky to do.

I would rate this solution an eight out of ten.

There were some long-running processes where it was timing out. We got the request from this source application, and we put the data into IBM MQ. Then, we read the data from IBM MQ before doing the rest of the processing. Especially for real-time processes, we have just decoupled it into two different ways to ensure there is no time-out.

The publish and subscribe features are the most useful aspects of the solution.

It's not too difficult to set up the solution. 

It's stable.

Technical support is quite helpful. 

The moment you send the data, there is no latency there.

We haven't experienced any data loss. 

If they could have some front-end monitoring tool that could be easily available for the team to use, that could be great. While you may not be able to edit your messages, at least if you could look at them, see the queue, and what's inside, et cetera, that would be helpful. We'd like visibility on the health of the environment. 

I've used the solution for two years. 

The stability is good. In fact, we have not seen any issues. Only recently have we observed an issue. There was a limit on the number of messages it could contain. We are having an issue now, however, we have not usually seen any issues related to IBM MQ. Therefore, in general, the solution is stable. I'd rate its reliability eight out of ten. 

I haven't seriously explored the scalability of the product and therefore don't know the full scope of scalability.

We handle about 300 to 400 transactions per day. 

Technical support is very helpful and responsive. We are satisfied with the level of support we get. 

Positive

I have previously used TIBCO EMS as well. 

The initial setup is pretty easy. It's not that complex. I'd rate the ease of implementation at a seven or eight out of ten.

The deployment time is pretty short. It's not a long process. 

In an integration scenario, like payment processing, where the payment has to go to the backend system, SAP, or talk to multiple applications, due to the fact that it's a lengthy, complex business process, we just decouple it. Some of the information we get immediately after receiving the request, and we pass on the information to the customer. Then, we put the payload into the IBM MQ, and then we started processing from IBM MQ. So there are integrations that sometimes need to be done or worked with. 

We have an admin team that does the configuration and setup of the solution. They can do it in one or two business days. 

We have witnessed an ROI while using this product. For example, we've had no data loss since using the solution

A different team handles the setup, and likely they also handle the licensing. I don't have any visibility on the cost of the product. 

I'm a user and customer. I'm not a core developer of IBM MQ. However, I'm a user of IBM MQ.

I'd recommend the solution to others. I'd rate it seven out of ten overall.