IBM MQ Reviews

We are using version 9.2. The solution is deployed on the cloud and Azure is the provider.

There are four people in my company who are working with IBM MQ.

IBM MQ is robust compared to other products in the market. It also gives you support from the IBM team. We can connect to the IBM technical team in case of any production fault or errors.

For security, we have IBM MQ instead of any other products.

IBM support team is really only concerned with the IBM cloud. They're not supporting any other cloud platforms or suggestions. It would be nice if we could get support for Azure.

MQ supports more than 4MB of data transmitting. That is not supported by ASB. Because of this feature, we are using MQ. Otherwise, clients will be motivated to use Azure Service Bus. IBM MQ should think about how the cost can be minimized and how to provide better service for users. MQ could provide more incentives or services that are better than Service Bus, so that our users will be motivated to use IBM MQ.

I have been using this solution for about seven years.

It's very reliable and stable. We haven't received any frequent challenges.

We have sufficient memory and storage. From a network point of view, the TCP/IP protocols are challenging.

It's easy to expand and easy to scale.

We would like to see the IBM technical support team extend their hand to providing support for other cloud vendors like Azure, Google Cloud, and AWS.

I also have experience with RabbitMQ. IBM MQ has more valuable features and is more reliable in comparison when it comes to servers and applications.

Initial deployment is very simple. You don't need someone who is very technical to configure it, unless you are establishing a new environment or a server, or infrastructure as a service. If you're upgrading things, it's very easy.

We use one support engineer for maintenance. They monitor the server and infrastructure.

Deployment was done in-house. We've had some challenges, but that can be fixed while we are connected with our IBM MQ support team.

The length of deployment depends on if there is a huge queue manager and on the type of integrations that need to be done. If it's a simple integration or there are less than 100 or 200 applications, deployment will take four to five hours.

Small-scale companies may not want to buy IBM MQ because of its high cost. There are freeware in the markets, and many users are motivated to use those.

I would rate this solution 9 out of 10.

We use it in a number of our applications for message queuing. As a broker dealer, it gives us the ability to queue things up and to send them out at a different time; and it works really well. We go to different reports, and get options and other features from other areas, so we need to queue up the MQ piece of it, have it wait, and then release it when we're ready to release it. That's a great feature.

It gives us flexibility when it comes to offering different projects or different types of solutions to customers. Instead of somebody having to sit back and wait for something, we give them the option now to be able to say, "Hey, we can give you these 10 things, and you can get all 10 back," without having them get six now, and come back later to get something else. They can get everything at one time and it looks like one portfolio of stuff versus it being six or seven different things at one time. MQ gives us that feature.

It's probably more like everything else. We're running into this world where everything – MQ, mainframe – is looked at as legacy. I know that it's not, but if it could be a little more GUI-based; if it could be a little bit easier to manage.

I hire people who work for me who are in their 70s all the way to people who are in their 20s. For people in their 20s, when they're working on the mainframe, when they're working on those kinds of MQ solutions, they don't really get it. Sometimes they want to run to something else or use something else. If it was a little bit more user friendly, or more gen-x friendly maybe, that would be the best benefit. The tools work. All the tools on the mainframe, all the tools that are considered legacy or dinosaur tools, they do a great job. They stay up; they run. They're very reliable. They're very scalable.

The amount of work that these things do is just amazing. You don't have to reboot them every time there's a problem. You don't have to have 20 people look at 20 different things. It's usually two or three people, "This is what the problem is", and you fix it and you move on. It's a very good toolset. But having somebody younger be able to work on it would be really, really helpful.

We've used it for many, many years. We use it on the client, a regular Windows platform. We also use it really, really heavily on the mainframe side, and it's very stable. We've had very few problems with it. When we do have problems with it, it's usually the application, not the actual MQ solution.

I haven't had any scalability problems. Most of the things, if there is a problem with scalability, it's because we haven't turned it on or we haven't done it ourselves. When we actually promote the features that are there, when we have the time to dig down and turn those things on and release those things, we don't have any problem scalability-wise.

We've had times where we've had to actually open up PMRs and things like that. But for MQ, it's very, very rare. We use CICS; we use WebSphere itself; we use DB2; so, we use a ton of other IBM features. With MQ there are very, very, very few problems.
When we do use tech support, they're very responsive 99% of the time. There might be one or two times where maybe something new will come out and they might have to come out with an actual fix or something, and develop it. It might take a little time to do that but usually, it's very responsive; very good thing.

I was not involved in the initial setup. I was a DB2 engineer, a systems programmer, for many years. Then I moved into management, into the middleware area, which had CICS, MQ, and other products. Then I actually moved up into a director and now, I'm director of mainframe services. I wasn't involved in the actual initial setup.

Some of the things have been around for 20 years or so, but I've been involved in probably five or six upgrades, other deployments and other feature turn-ons that MQs contributed to. I was heavily involved with that, but not as far as bringing it up and installing it from the beginning, no.

It was already there when I came to the company some 13 years ago; already in place. But I've managed it for probably 8-9 years.

I know open source is a big thing these days. I know a lot of people are talking about going out and buying open-source things or trying open-source things. I say, “Stick to products that have been around, that have been proven, and that you have the support of a vendor behind you who's willing to look at these things and develop around you.” IBM isn't a perfect company. It's got a lot to deal with, when you talk about other startups and other people trying to do the same things that it's been doing for a number of years, but in the long run, it's a good company, and I would say "stick with it".

For MQ and products that have been proven, people need to take the leap and use some of these things in the cloud, use it with Linux, and use some of the new features that IBM has. I work on a mainframe. It's a powerful machine. It does millions and millions of transactions every second, and it just doesn't miss a beat. If it has enough CPU, enough power behind it, it will just crank out, and it just does it day and night. I'd say stick with the true, hard-driven, really dedicated solution.

I have worked in the industry for many years. I worked on the mainframe side when I first started. I went into the distributed side years after that. I'm talking 20 years, and then another 13 or 14 years after that, and I went back into the mainframe world. I've dealt with a lot of products, a lot of different solutions, and there have probably been three or four that do what they're supposed to do and not have a lot of problems. MQ's probably one of the quieter ones.

Sometimes you put something the wrong platform. Sometimes it's not configured right, and you hit some bumps in the road in that way. I did it with WebSphere; I did it with DB2; I've done it with CICS; I've done it with SAS; I've done it with a lot of solutions; Windows, networking, storage. I've managed all those different areas and MQ's a very quiet product. It does what it's supposed to do.

When it hiccups and has a problem, it's usually because someone did something wrong or wrote something wrong, and now it's more of a victim, and it needs to get corrected. Once that gets corrected, it does what it's supposed to do. I don't want to give anything a perfect rating because nothing is perfect, but it's a really great product. It doesn't do a lot of stuff, but it does what it's supposed to do, and that's the main thing.

In general, when I’m looking to select a vendor to work with, I need a vendor who really understands my customers and my needs. I know it's hard sometimes to build a solution that fits everyone's needs, but when I buy something I want someone to be able to couple with me and help me through this process. Every problem that I have, every little road bump that I run into, I want someone there to hold my hand. Engineers are good; administrators are great. These guys will come up with solutions but when there's a problem, I want somebody there to help me; to take responsibility.

During my tenure, there was a transition to using IBM MQ due to its compatibility with IBM mainframe systems, which was beneficial for projects involving message queuing systems, particularly for clients like Volkswagen. I've handled various tasks related to IBM MQ, including testing connections, configuring and installing the system, setting up high availability and disaster recovery solutions, and providing administration support. Additionally, I've conducted training courses on IBM MQ.

One of the most crucial aspects for us is ensuring no data loss, and IBM MQ excels in this area, especially in banking environments where reliability is paramount. The feature I find most effective for ensuring message delivery without loss is the backup threshold. This feature allows for automatic retries of transactional messages within a specified threshold. For instance, if the backup threshold is set to five, IBM MQ will automatically retry sending the message up to five times. If unsuccessful, the message is then sent to the backout queue, indicating that it has been attempted multiple times. This flexibility allows us to handle message delivery failures by either discarding, logging, or retrying the message using mediation patterns.

The security features of IBM MQ have met our data protection requirements well. We utilize encryption with SSL keys to ensure data encryption. Additionally, many companies prefer using MQ connections with SSL challenges for added security. The integration with operating systems like Linux and authentication with Active Directory or Open Endpoint of Microsoft has made security configuration straightforward.

IBM MQ could streamline its complexity to be more like Kafka without the channel complexities of clusters, making it more straightforward. Migrating to IBM MQ from another messaging solution has not impacted our operational efficiency as we always build our messaging solutions from scratch.

I have been using IBM MQ from 17 years.

Regarding stability, IBM MQ itself is stable, but issues can arise from the surrounding infrastructure or configurations. Technical support from IBM can be hit or miss, with varying levels of expertise and dedication among support personnel.

In terms of scalability, IBM MQ has supported our growing transaction volumes effectively. We use telemetry and performance tools like Mehdi, Nessus, Zavix, etc., to monitor and manage scalability. While some tools like Cisco AppDynamics offer proprietary solutions, we often create or customize performance monitoring tools within MQ for scalability monitoring.

The initial setup of IBM MQ can be quite complex, often leading to mistakes during configuration. The documentation, while extensive, can be challenging to navigate. The deployment is typically on-premises, and the actual deployment time can vary based on the complexity of the configuration.

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. 

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.

I like its ease of administration. We just recently moved to the MQ appliance and the high availability (HA) feature is outstanding. We're really, really pleased with it and the power of the appliance itself. When you throw more work at it, the faster it goes.

For example, when you're doing maintenance, you can fail over the entire group of queue managers in that HA group or you can fail them individually if you'd like. So, it's very helpful that way. But that's the manual fail over. The automatic fail over is what we are really interested in. We did have an appliance go down. Everything failed over and none of our clients knew of it. So it was very good. We were very pleased with that.

The user interface is good. The command line version of it, MQ CLI, is good. The web user interface is really handy; really a good feature.

It updated everything. We started with Version 7 with Linux and now, with the appliance, it seems to be bringing us more into the 21st century so to speak.

We have an M2000. The M2001 has a 3 TB SSD, which is a good feature. I wish they had had it when I started. But as we upgrade, in the future, we'll probably move to that. Everything is working properly with the current version.

The reason the migrations are an issue is, we came from Version 7.01 and Version 7.5. The security in Version 8 was a little tighter. So, there were a few things we had to learn. Be sure that we were up to speed, so that's all.

We haven’t had any stability problems at all. Stability has been outstanding. We went from multi-instance queue managers, which worked fine, except they worked often. That wasn't good for us. So it was a perceived outage for our clients. The availability has been outstanding with the MQ appliance.

I have used support on several occasions. We were an early adopter, and there are always a few bugs along the way. We did use technical support and we went all the way up to the lab a couple of times. It was outstanding as usual.

We have been an MQ adopter since 1998. We were using z/OS, so we have been using MQ along the way. Then we went to Windows, to Unix, to Linux, and now the appliance.

Actually, setup was straightforward. I'm not a hardware person and it was a first-time setup. It was what they said it was. It wasn't a 30-minute setup, but it was pretty easy.

Plan your file systems. Plan your messaging names and your network routes. You want to be ready with everything before you start and once you do that, you're in good shape.

When choosing a vendor, I want knowledge and availability. Those are the two things that are most important.

I was part of a small team that tested and used the IBM infrastructure in a QA environment. My activities included configuring and creating test environments and finding solutions to monitor the infrastructure.

Using a message queuing solution, we had a banking solution that integrated multiple branches and interbank systems. Different systems for credits, debits, CRM, and others communicated through this message queue solution. It wasn't just about communication; for instance, a CRM application needed to collect information from various banking systems, such as account balances, properties, contracts, and credit cards.

These systems were separate, and the message queuing solution combined information from all of them into one message. When a request was made from a workplace for information about a person or company, the message queue infrastructure routed the request to all connected systems, ensuring the workplace did not need to be aware of all configuration details.

The product's most valuable feature is its ability to work in clusters. This allows for creating a cluster of message brokers, providing horizontal scalability. Another important feature is the extensive command-line interface, which allows for comprehensive monitoring and management of the system. This enables the creation of complex scripts to configure, making it a complete and very powerful tool.

The tool is expensive. 

I have been working with the product for four years. 

The tool is scalable. 

IBM MQ is stable.

The tool's support is not cheap and fast. You can't expect a resolution from support. 

The setup of message queues in an enterprise trade system is complex, especially when dealing with hundreds of message brokers and thousands of message queues. Configuring such a large infrastructure isn't straightforward and requires tools for testing, validating, and identifying missed components.

We manage a large configuration file, likely an XML file containing thousands of lines. Many teams update this file to reflect changes in their systems. It can be split into multiple smaller files to manage this file, but this complicates maintaining a single point of truth and requires validating all combinations. Systems communicate with each other using these components, needing a common protocol.

The benefits of using IBM MQ include buffering your transaction flows, which is useful if you have spikes. For example, it can handle this increased load if you normally have 100 messages per second but expect 10,000 the next day. You can also build clusters of message brokers to scale horizontally.

The license for IBM MQ is commercial and not cheap. You get a multi-platform solution, which is important because it lets you connect systems on mainframes, personal solutions, Unix, Linux, etc.

Applications produced and consumed messages, with the IBM infrastructure serving as the transport and storage for these messages. Messaging was based on IBM MQ, and several other IBM products were involved, though I can't recall their exact names. These products were used for transforming messages, validation, and routing. The infrastructure could route, validate, split, and combine messages.

I rate the overall product a ten out of ten. Our goal was to measure the performance of the integrated system, not just individual components. This involved external systems as well. We used various command-line tools, such as IBM MQ, to collect detailed information about processes and systems. Measurements had to be aligned with configurations, meaning we couldn't use a universal solution. Instead, we had to adjust based on specific requirements and configurations.

We use the solution when connecting with the external system to process messages in a queue-based flow. When the solution receives a message, the flow is triggered to cycle through routing, mapping, and logic to create a pipe delimited, XML, or other formats that send to the end system. 

We created the queue-based flow to receive messages and connect them to end systems using a pop-up concept to classify messages by subscription topics. 

The solution is fast with end data compared to other messaging tools. 

With integration tools, the node is connected with the queue manager so there is some dependency. In the solution's latest version, the dependency was removed which allows us to create servers without any interdependencies.

The solution should offer a freeware version, free vouchers, or certifications for learning purposes and building a knowledge base. When creating an account to download software, you must provide user details like credit card information. If you exceed the allotted hours or days while trying to learn the solution, your credit card is charged for additional time which is what happened to one of my colleagues. 

Learning the solution is not as simple as MuleSoft or APG. Some developers left the market because they didn't know how to learn the solution. Other products provide free vouchers or certifications or learn programs but IBM currently doesn't do that. 

I have been using the solution for ten years. 

The solution is an older product and very stable. Our product teams never have issues with it.

We have experienced some issues with scalability because there is a known lag when scaling.

Technical support is rated a ten out of ten because we receive support very quickly but rarely need it. 

Positive

The initial setup is easy with no huge steps. 

There really isn't any deployment. Creating queues does not take much time and we use them with channels and subscription topics to push and pull messages

The implementation was completed in-house with integration developers doing the important work. 

If you want to route messages through a queue-based app, definitely take a look at this solution and research the cost.