IBM MQ Reviews

With IBM MQ, the main use case is for applications in online banking. We use it within the banking industry. IBM MQ is a choice to create a relation between the Mainframe and distributed servers, allowing applications running on Linux or Windows to interface with Mainframe applications and enable more development of easier and open applications in a distributed environment. This means we can develop more applications that are easier to use.

I work with CICs, Workload Manager, and DB2 mainly. I have experience with IBM MQ. We mainly use clusters at the Windows level or Linux level, and in the Mainframe, we have multiple paths and different lines of connectivity transmission to assess the impact of IBM MQ's high-availability configurations on our system's resilience.

We use advanced security features such as SSH for encryption and authentication mechanisms. The security features help protect our messaging data by encrypting the transmission and ensuring authentication for connection.

The customer service or technical support from IBM is not as good as we expected; it could be better. They don't meet our standards due to the timing to get a person with knowledge.

We use some IBM solutions hosted on AWS as a cloud provider.

The initial setup of IBM MQ is reasonable, just as we were expecting, and we were on time for that project.

The maintenance for IBM MQ is good to be once a year; that's the best.

We mainly use clusters at the Windows level or Linux level, and in the Mainframe, we have multiple paths and different lines of connectivity transmission to assess the impact of IBM MQ's high-availability configurations on our system's resilience.

The customer service or technical support from IBM is not as good as we expected; it could be better. I rate them a 7 on a scale of 1 to 10. They don't meet our standards due to the timing to get a person with knowledge.

Positive

I don't really know the main differences between IBM MQ and other messaging queue solutions because it has been my natural choice, coming from Mainframe z/OS.

The initial setup of IBM MQ is reasonable, just as we were expecting, and we were on time for that project.

In the setup, there are mainly two persons involved, but others from different areas are also involved, making it more than just those two.

I currently work with IBM, but we are also using other vendors such as BMC and Logon for specific backup solutions from Mainframe.

My main experience is with IBM Mainframe. I do not have experience with their IBM QRadar. AWS is not our main cloud provider for IBM solutions. I am not very experienced with cloud, but we do use object storage, which is cloud or on-prem for example.

I don't remember specific examples at this moment, but if you contact me in two days, I will probably be able to refresh my memory as I'm currently focused on the capacity and performance issues of the system. I don't have thoughts on IBM MQ's pricing since I work in the support area and I'm not related to the purchasing process.

My company mainly provides services to the banking area but also sells many products, including IBM and open system solutions, such as storage. My company's name is Telcos, spelled T-A-L-C-O-S.

I am very interested in providing a review for the IBM Workload Automation based on my recent experience with it. I am still working with Workload Automation and probably have a project related to this support, but I have switched to focusing more on performance issues at the moment. I used to be more focused on Workload Automation, but now I have shifted my project to banking application performance and capacity.

I still work with IBM solutions in the other area, maintaining contact with AWS that relates to Workload Automation. I deal with banking services in general performance, mainly related to recovery, backup solutions, and CPU utilization. I have experience with IBM ProtecTIER, specifically the ProtecTIER, and not Tivoli. I do not remember experiencing Spectrum. I do not have experience with Spectrum Protect.

I have experience with backup and recovery, particularly on the Mainframe side, but not with HSM. HSM is more related to the Mainframe, and while I don't have recent experience, my focus has shifted to performance areas in z/OS, especially solutions relating to backups and disaster recovery.

We move data from Mainframe to the cloud. BMC is one of the companies I refer to, along with Logon. Logon is spelled L-O-G-O-N. Logon is based in Israel.

Overall, I would rate IBM MQ an 8 out of 10.

Positive

I usually recommend IBM MQ for financial, government, and large enterprise companies. It is beneficial for handling high volumes of messages.

Using IBM MQ ensures the guaranteed delivery of messages, which is significant for my clients. It is also known for its security.

The most valuable features of IBM MQ are its guarantee of delivery, ability to handle high volume while maintaining high availability, and robust security measures such as SSL, TLS, and RBAC.

There are no improvements needed at this time.

I have been familiar with IBM MQ for roughly 20 years. It's been essential for many sectors during this time.

I rate the stability of IBM MQ as ten out of ten.

I give the scalability of IBM MQ a rating of eight out of ten.

The technical support from IBM is good.

Positive

Before IBM MQ, I was not using similar products. For comparison, I have used Kafka.

The initial setup is generally straightforward.

Part of our work is to assist customers during the installation and configuration of IBM MQ.

For an enterprise solution, the pricing of IBM MQ is very reasonable.

I have also used Kafka before.

IBM MQ has been in the market for over 20 years; it is an essential solution for most banking, financial, and government sectors.

I'd rate the solution nine out of ten.

I use MQ MFT for asynchronous communication – file and message transfers. I also frequently use IBM MQ for its queuing mechanisms and queue management.

IBM MQ is good for system integration within our organization. 

If we need to do batch metadata transfers – involving APIs and MQ – we can do that as long as the source and target systems support MQ. 

However, for anything without MQ, especially when we need asynchronous communication, we have to rely on custom-developed services. It's like that.

The performance is good.

I appreciate the level of control we have over queue managers, queues, and the messaging itself. That provides good security.

So, the control and scalability of messaging are important to me.

Moreover, it is more reliable than other queuing mechanisms we've tried – things like ActiveMQ, RabbitMQ or embedded queues. We have more confidence in not losing data with IBM MQ.

So, I find IBM MQ to be a reliable solution.

We find it scalable for internal applications, but not so much for external integrations.

It should support a wider range of protocols, not just a few specific ones. Many other products have broader protocol support, and IBM MQ is lagging in that area.

IBM MQ needs to improve the UI for quicker logging. Users should also have a lot more control over logging, with a dashboard-like interface. That's something they should definitely work on.

It's been about three to four years.

It is a stable and reliable product. I would rate the stability a nine out of ten.

It's very scalable. We can allocate more queue managers based on our use cases.

I would rate the scalability a seven out of ten. There are around 20 end users in my company. Their job roles include developers, consultants, and architects.

However, we don't use it extensively, so no plans to increase usage.

There is room for improvement in the customer service and support. 

IBM MQ should offer more extended support to users, and their response time could be faster. They have a community forum, but the official support channels could be improved.

Neutral

We have it on-premises. We're not using it on a public cloud currently, but it can be deployed there.

The initial deployment takes hours. There's a lot of manual scripting involved. So, Ideally, some kind of automation for that process would be helpful.

IBM's licensing model seems more reasonable than some competitors. They charge based on usage, which is good. 

However, the pricing could still be a bit lower. Their installation-based licensing model is acceptable, but other products might have an edge in terms of cost.

I would recommend it, but it's important to be aware that many users are shifting towards cloud-centric solutions like Kafka.

Overall, I would rate the solution a seven out of ten.

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.

We are an integration company, so we deal with many software systems that aren't necessarily online all the time. Using MQ helps us by keeping a storage of the messages sent from one party to another so that once the second party comes back online, it will take from the queue. It is used for integration and middleware purposes.

I really like the SSL support in MQ, which allows us to include certificates so the queue is fully secured and prevents man-in-the-middle attacks. It is easy to create a new queue, and the queue manager connecting to the remote queue works smoothly once the IP and port are included. These features benefit us by ensuring integrity and security.

The software has many complications, especially with authorization on the queue. I had many issues with unauthorized errors and editing this authorization and giving users the right authorities on the queue was really hard. 

Another improvement could be the inclusion of more advanced queue features where you can configure a queue to push messages to consecutive queues automatically. 

Better error handling, such as a default dead message queue for errors, would be beneficial.

I have been using it for about three months now.

I have used IBM MQ with IBM ACE, and sometimes there are issues with messages in the queue not being taken by the message flow. I am unsure if this is a problem with ACE or MQ, however, it sometimes affects stability. Thus, I would rate stability at six out of ten.

It is very scalable since it handles the concepts of message queues, the most scalable technique in integration development. 

It allows for scalability and reliability by adding multiple queues and ensuring messages don’t get cluttered. It is very scalable, ten out of ten.

I didn't need to contact technical support. 

Positive

The usual solution was HTTP requests, and MQ is much better. It is more complex, however, we get persistent storage and the messages don't get lost if the other party is not online.

The pricing is very high, but if it's going to be used by an enterprise or a large company with thousands of users, it will be very convenient. However, for personal use, it's not a good idea.

I would recommend IBM MQ for companies. If we get a new IBM client, we will definitely recommend MQ because it will facilitate a lot in its request handling. For a legacy IBM client who is not using MQ, we encourage its use because it will improve architecture significantly. 

Overall, I rate IBM MQ at nine.

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