What needs improvement with IBM MQ?

IBM MQ should have more extensive documentation because I couldn't find a lot of information on the system API side to help us monitor the message queuing. I would like to see more documentation.

In IBM MQ, the channel connection is an area where my company faces some limitations. At times, we hit limitations on the connection, meaning the connection is fully occupied.

The pricing needs improvement.

The tool is expensive.

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.

The product does not allow users to access data from API or external networks since it can only be used in a closed network, making it an area where improvements are required.

More documentation would be good because some features are not deeply implemented.

I started using MQ on a mainframe, so I understand the thinking behind it. However, there's a lot of legacy stuff lagging behind. I think a start-up company might find the approach to be outdated. IBM could revamp the interface. The API is huge, but some developers find it limiting because of the cost. They tend to wrap the API course into the JMS, which means they're missing out on some good features. They should work a little bit on the API exposure. Support utilities are almost non-existent. MQ is dependent on third-party companies. I write everything I use, like a Linux-based command line interface for all admin stuff.

Customer support response times could be improved.

The clustering model can be improved to allow consumers to consume from all brokers simultaneously. Currently, the issue is that they're using a very old clustering model where several of the individual brokers in the same cluster still behave as individuals rather than behaving like a cluster. They call it a cluster, but it's just a group of brokers not working as a cluster. It doesn't properly share the resources between all of the member clusters. Compared to other solutions like Apache Kafka, or RabbitMQ, this is a huge drawback.

IBM MQ could improve capacity, monitoring, and automatization.

The monitoring could be improved. It's a pain to monitor the throughput through the MQ. The maximum throughput for a queue or single channel isn't clear. We could also use some professional services by IBM to assess and tune the performance.

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.

The dashboard is handy because we use it to monitor the messages and know how many messages are delivered to parties' dashboards. For example, we can notice how many letters are delivered, how many messages are undelivered, and how many messages are brought incorrectly by the dashboard. However, it would be great if the dashboard had additional features like a board design or picture management features.

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.

It could always be more stable and secure.

The licensing fees should be more cost-effective so that we can better pitch the product to our clients. With the pricing as it is, they tend to move away from IBM products. They look for other solutions, such as open-source products.

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.

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.

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.

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.

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'd very much like to see more integration in the monitoring tools.

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 would like to see their cloud feasibility with other vendors. I know that they are very much tied to their own cloud right now, but I don't know how they are supporting AWS and Azure. With IBM products, there's less marketing. If they do more demos and more seminars on their products, it will be very useful. On a given day. I get seminar invites for many vendors and products, but for IBM, I may get an invite once or twice a year. Documentation is easily available to people who know about IBM products. However, if you're not familiar with the products and because there are no popups about seminars and product news, you will not be able to easily find the documentation. So, I think that there's a gap in IBM's marketing, which needs to be improved.

The way the solution provides us with the product and the way we use it gives us what we need. We don't actually have any issues with it. There could be a better front-end GUI interface for us, where we can see things more easily. However, apart from that, it works well. The pricing is definitely could be cheaper. Also, the support model, even though it's very good, could be cheaper as well.

The main issue we are having with the solution is due to the connection dropouts which have been going on for a long time now. Sometimes randomly the connection gets disconnected and we try to send a message, we get a failure. We then need to manually take an action on the message, which is happening quite a lot in production. We have been working together with the MQ team trying to increase the connection and some channel upgrades. We are taking steps in the right direction but the issue is not completely fixed. Additionally, there is not any statistical messaging information being captured. We are not able to pull up any reports to determine when a message was sent. For example, how many messages during the day or during five minutes.

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

I would like to see message duplication included. We don't have a mechanism for duplicating a message. There is a different model where you can have multiple subscribers and not publish the stored data to multiple subscribers. Duplication is the most important for sending the same data for different applications.

It would be an advantage if they can include streaming in IBM MQ, similar to Kafka. Kafka is used mainly for streaming purposes. This feature is clearly lacking in IBM MQ. If they add this feature to IBM MQ, it will have an edge over other products.

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.

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.

We have had it for a long time now - version 7.1, which is not the latest. The admin interface of MQ Explorer that is used to interact with the server seems a little bit dated. It makes it somehow difficult to interact with it. It needs a major update to make it more modern and easy to navigate, maybe a web version. The solution isn't free. There are other solutions, like RabbitMQ, which are open source and absolutely free to use. This open source solution we use it for non-critical processes. IBM offers a special version that you need to get if you want to transfer files, especially large files. Maybe it should be included in any version.

It's hard to put in a nutshell, but it's sort of developed as more of an on-premise solution. It hasn't moved much away from that. But we want to use the auto-scaling and scalability of some of the cloud services. It has developed a fair bit in terms of even the database of the board and stuff like that. Over the next three to five years, we want to move totally into the Azure.

We are looking for another solution that is less expensive. There is room for improvement. The live and portal monitoring needs improvement.

At the moment we're very limited in the way we can interface with the cloud.

IBM MQ has a lot of room for improvement. It's an older solution but they are improving the product. It's wider and it's a heavy application so it supports clusters also. It is expensive. The cost is high. There should be more improvement in the new age of technologies.

The monitoring could be even better by building it into the product. The disaster recovery mechanism could also be built-in. I would like to see them not rely on third-party tools for everything. Finally, they have provided a Liberty Profile in the Web Console for administration, and that could be further enhanced. It is not fit for use by an enterprise. They have to get rid of their WebSphere process and develop a front-end on Node.js or the like.

It could provide more monitoring tools and some improvement to the UI. I would also like to see more throughput in future versions.

We have had an issue with the migration. Most of our applications are running on Java and WebSphere. We have a project to get rid of an old .NET application since we are experiencing a loss in connection during the migration to 9.1. The problem appears to be more on the .NET side than the MQ side though. The technical user interface is outdated in terms of the language used. I think this is inherited from the mainframe. This is more of an engineering issue. It is running on a Windows platform, and I don't like having Windows being the backbone of our company. I don’t like legacy view of MQ.

The worst part is the monitoring or admin, especially in the ACE or Broker. There is always a problem of transparency. In MQ you can observe any process and you know exactly what's going on behind the scenes, but with the ACE or Broker, it's a problem monitoring the HTTP inputs. It's like a black box. The reason that I'm emphasizing monitoring is that I used to work for the company that produced the administration and monitoring tools for IBM. There was a lot of competition and a lot of confusion in the market. When I moved to this company I actually used my previous experience and wrote my own tools. I am not much of a C# programmer, so I was struggling a bit. I know the concepts, but I was missing some straightforward support from IBM. They were selling it as a part of Tivoli, but you needed to implement the whole Tivoli infrastructure. If you had some other monitoring provider it was a bit of a pain. That is my concern here.

I can't say pricing is good. It is a popular and reliable solution. IBM can be integrated with other products which is why it gets sold. People also like Oracle. They can be integrated with multiple systems. That is a selling point for these solutions.

I would like IBM to improve the performance. Right now, it is lacking and can be bulky.

You should be able to increase the message size. It should be dynamic. Each queue has a limitation of 5,000. Also, the maximum message length defaults to 4 MB. If it is more than that it should be able to increase and allow whatever the particular size of the message is into the queue. In terms of additional features, I would like to see it be lightweight and go to the cloud easily, and dynamic scaling should be added.

I'm not sure that current version has event-driven mechanism requests that people go for. I would like the latest version to come with both type of event-driven mechanisms: an email server and a POP server. If that is not there, then that would be a great addition.

It could be easier to use.

I had some issues earlier, two, three years back. I don't exactly remember them now.

They could integrate monitoring into the solution, a bit more than they do now. Currently, they have opened the REST API so you can get statistic and accounting information and details from MQ and build your own monitoring, if you want. IBM can improve the solution in this direction.

I am not involved with it at the architect level. I am providing entry-level support for the product. But perhaps if they could come up with monitoring dashboards that would be good. We are using external monitoring tools, apart from our IBM MQ, to monitor IBM MQ. If we could get monitoring tools or dashboards to keep everything simple for the user to understand, that would be good.

What could be improved is the high-availability. The way MQ works is that it separates the high-availability from the workload balance. The scalability should be easier. If something happens so that the messages are not available on each node, scalability is only possible for the workload balance. That's a big difference. And the application must be prepared to consume from each node so that it doesn't lose a message. Otherwise, you lose the ordering of the messages.

Day-to-day, I don't really see anything much that we are lacking, but I have never really compared MQ with other products to see what it lacks. I am well aware of the way that IBM sells the suite of products. But I would like to see it integrate with the newer ways of messaging, such as Kafka. They might say that you have IBM Integration Bus to do that stuff, but it would be great if MQ could, out-of-the-box, listen to public Kafka. One of the other improvements that I would like to see from MQ is for it to be containerized. It may already have that functionality.

The memory management is very poor and it consumes too much memory. We have 24 gigabytes of RAM and almost every day, we had to free up processes so that it can run. Some of our messages were not being transmitted so we had to manually look at the MQ server to cut and paste them. That is supposed to be fully automated. The problem is normally a routing issue but it is compounded if there are connectivity troubles. For example, if 3,000 messages are supposed to be sent but 1,000 were not then you have to do it manually. The solution is not very lightweight and if it could be decentralized, then put into three or four containers, it may be an improvement in this regard.

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

* Better testing by the supplier is needed * Ability to send to a group of queues without the need to use pubsub and without the need to write one's own programmes.

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

MQ needs instruments for connection with new modern queues like Kafka or RabbitMQ.

There is not much room for improvement, except it could get a face lift with a modern marketing campaign.

SonicMQ CAA (continuous availability architecture) functionality on auto failover and data persistence should be made available without a shared drive, as it exists in multi-instance queue managers.