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.

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

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

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

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.

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.

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

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. 

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. 

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. 

They probably need to virtualize the MQ flow and allow us to design the MQ flow using the UI. It would also help to migrate to the cloud easily and implement AWS Lambda functions with minimum coding. If you have to code, then just with NodeJS or Java. 

Many things should be done out of the box, like MQPUT directly to databases or MQGET to link to the main database. MQ should be able to connect to any language and just do it whether you're using mobile apps or web apps. It should be possible. 

The other probably more key thing is that to get IBM on-premise is hard because there are no freely available videos and courses. Technical support in Australia could be better.

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

One of the features to pinpoint is migration. When we want to migrate from one version to another, it takes years. So, definitely, we want to see some solution for IBM's standpoint, in order to make it easy for the customers to migrate from one version to another.

There are some operation challenges; however, it could be not because of the product but instead in terms of how we use it. We might be looking for improvements by adding some self-service capabilities, in order to go through the hoops of different teams to get the objects created. Thus, this will make it easy for the developers to access some of those things.

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.

IBM MQ may not be as convenient for Java programmers as Active MQ, for example, because Java programmers prefer Java, even though it is slower.

IBM MQ could improve by adding more protocols or APIs for a standard application, such as MuleSoft.

I would like less updates from IBM MQ.

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.

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.

One thing that I'd like to see is that queue-sharing should not depend on DB2. It should have this feature by itself, instead of depending on DB2.

In order to set up IBM MQ queue-sharing, DB2 data sharing is required in multiple LPARs. Thus, to make the implementation easy and straightforward, it will be nice if DB2 is not required for queue-sharing.

Right now, with the new functions such as z/OS & distributed, I don't see any need for additional features as such. This is because everything that MQ provides, we do it. It's okay right now. Things are working fine.

The migration aspect is different and it depends on who is doing it, i.e., whether a person is doing it for the first time or a person who has done it for 18 times. I have done a lot of migrations in MQ, starting from this product version 2 and now it is on version 9. I have done a lot of migrations, so it all depends on how much experience you have, how you set up your migration task and so on. Migration is fine. I don't see any problem there.

If IBM develops a tool inside the MQ product for monitoring, then that will be better for the other IBM products available.

They might be able to improve the monitoring features. When you're looking at distributed platforms, you're looking at different breakpoints to it. MQ has a good support structure, but it would be nice if they could kind of fold MQ into other tools to make it more resilient for other tools, other relationships, and other non-IBM platforms.

That's probably the strongest piece: being able to support the other customers. Eventually, if we can support them end-to-end and tell them where their problems are, we can bring them into our fold and make it an IBM fold.

When comparing the solution to the new age of streaming in messaging technology it is so large, that there are complexities dealing with multi-cloud, multi-deployment, or high availability models. The use cases and APIs can also use some simplification.

I would like to see a dashboard that shows the application's performance.

It could always be more stable and secure.

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.

One of the things we did not see meeting our need was the lack of integrated monitoring for both IIB flows and MQ's. You have to use different tools for that, i.e. - MQ Explorer for the queues and IIB toolkit/web viewer for IIB apps and flows. If we could integrate the monitoring of both the flows and the queues in one product, that would be great.

Similarly to deploy the flows we need to use IIB toolkit and then to run MQ Scripts – we need to use a different tool. Since IIB and MQ goes hand in hand – it would be nice if the tools were integrated as well.

I am not working on the solution directly, but my team does, so technically I don't know the solution at the level where I could provide information about areas with room from improvement.

At a recent conference, I went to a presentation that had the latest version and it has amazing stuff that's coming out. So, I am excited to use those, specifically surrounding the web console and the fact that it's API integrated.

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.

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.

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

We are looking for another solution that is less expensive.

There is room for improvement. The live and portal monitoring needs improvement. 

I really need more of the API management. It's perhaps the biggest thing. I don't really care that much for the analytic side but in terms of monitoring, we have everything tied in the way we need. However, that involved a lot of work on our side, but more importantly, it is really some of the APIs that allow me to do administration and provisioning the whole time.

The migration from different versions can be very different and difficult. We build a lot of our code around it. For example, we wrap it with the APIs and we embed a lot of things into our environment. We have close to 400,000 lines of code just around that and it has to be a reviewed with every upgrade.

I haven't seen any features that we could exploit today that's not currently available. I think everything that's in there today in terms of features; it meets all of my requirements. Everything that were shortcomings in the past, they've already been addressed from different users. The current version 8 is very stable and contains everything that we need to run our operations.

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.

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.

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.

I think one of the things to improve on could be more administrative profiles which might simplify the experience. IBM MQ has a lot of settings. We're only using probably a fraction, maybe 10%, of the overall settings. Working for a large aerospace/defense firm, we have pretty tight security. There are a lot of settings that we do have but we're still only just scraping the surface of what's there. Being able to get to those sub-menus can be a bit challenging.

So there's the fact that there's a lot in IBM MQ presenting only the options that maybe somebody might do, such as a web application administrator might have to do. They don't need to see all the other bindings that are there, so it could be a little overwhelming trying to find it. So, I think if there's anything, that would probably be it.

Presenting and maybe having some different options for different user experiences based on the administrative duties that you have to do as an app manager or configure the server or security would be an improvement. For instance, in our information insurance organization, we have folks that go in and look at the security bindings that we have with our applications. Having those different roles mapped would be an asset, so you're not having to go through all the various sub-menus to find it would be something that would, I think, take it over the edge.

One of the bottlenecks for us is owing to the industry that we're in, we sometimes get the large payloads and the MQ queues that we can increase. But, the maximum payload size allowed is only 100 Mbps. So, I wish to see if it bumps up because sometimes we hit that ceiling and the message won't process. We have to find another way to mitigate one or two instances like that. It's critical, so I don't know if there are any future plans to increase that size to unlimited or at least where you can set it based on your business model, i.e., if your payload is higher, then you can set it higher.

I think the cloud is our next solution. Because we’re in the healthcare industry, I want to make sure the security is really strong and capable of keeping our members' data secure.

Some of the new features that their competitors are coming out with. Things like AMQ are coming out with - transformation of messages with the security aspect of it and even scalability with AMQ, it's scaled at the microservices level and MQ is not quite there yet.

It would be nice for the next release to have better reporting. For example, elasticsearch or ELK. We don't have that with IBM. So we have implemented our own solution.

We have a major application based on DataPowers and WebSphere servers.

We had an main issue to visualize efficiently the utilization of our WebSphere applications (load, who is using, when, how). It’s critical in defining our “capacity planning”.

Actually, we’ve developed our own reporting solution based on Kibana/Elasticsearch. Kibana analyses ours logs in real time. We have done a portal with several graphs. It is really impressive. We are very happy with our solution.

IBM doesn’t provide, by default, a reporting item as efficient as Kibana. DMGR is not as powerful and flexible.

I think some of the management tools could be improved. We've got a variety of different management tools, that we have in place. Having them be more a core part of a product, rather than being add-ons from either other solutions or open source, would be good.

The barrier to success is basically the engine behind the collection of the data.

I also think the administration could be a little more straightforward. Right now, we have to develop our own truly distributed administration system. There's a GUI that's really not manageable; not that easy to use.

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

Honestly, the features they just recently released are what I wanted to see. Like I mentioned elsewhere, the appliance device was fantastic. It's MQ in a box, and you just plug it right into the network. I'd like to see improvements around that area, so we can take our z/OS systems into our distributed environments even easier.

It's pretty good right now the way it is.

I don't know whether it is available with the new features, but in the older versions, I remember, to test a queue, you actually had to call an API to send messages back and forth. If that would be a one-command scenario like on the iSeries, instead of me calling the API, sending a message and receiving it, I would like to have something like that. I don't know if MQ’s new features support something like this.

The product itself is not difficult to use. I guess you could always ask for a little bit better GUI admin console. All in all, it's not hard to use.

In a large organization like ours, sometimes we have a large MQ installation base; lots of connection points. If there was a more graphical representation, in terms of looking at the overall landscape of where we have MQ implemented, that you could drill in and out; that would be nice. A picture’s worth a thousand words, a lot of the time; if it was more graphical in terms of displaying the overall topology and layout of the MQ infrastructure we have; just from a high-level, admin-type view; just an easier way of looking at things.

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.

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.

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.

It needs a User Interface which is better than the aging MQ Explorer. The existing solution MQ Explorer is outdated.

So we're on MQ version 8, and I was at a recent event for MQ 9 and it looks like they've already added some of the features I was looking. For example, a better monitoring system, and a GUI to display messages, which I think they've already done.

We would like to see more capabilities with MQ over the internet. It would be very helpful to us to expose our API and web services. We want to see that a little bit more and we want to continue to see that it's a secure means for us to protect our data.

I want to see a three-dimensional perspective to the data. I don't want to see just an event perspective to the data. I want to be able to identify a user and within clicks, know the whole activity of the user. I don't want to see it in events. I want to see it in the relevant information.

There needs to be a little bit more of investment for enhancing the user interface. That is the main thing, i.e., to make it represent the state of the actual incident response and how you would troubleshoot an incident. It was a major position by IBM when they bought it. But, we see a lot of things being done around the Cognitive side, around the Watson side, but what we're not seeing growth in, is the actual tools interface and usability.

We wanted to be able to see seamless identification of log sources, seamless categorization, normalizing of log sources and seamless alerts. All those things that are required for solution maturing, it has to be able to take data and make sense of it by itself, without a lot of input. Those are the areas that they can really improve it.

Maybe the administration interface could be improved. Right now, it's very command-line driven. My guess is that if the GUI interface was a little bit better, with more of a singular interface across platforms, that would be helpful.

I must check this in depth. I can't really comment on areas with room for improvement, because they already introduced a lot already. I'm still new and need to explore what exactly the latest version has in it. So, only after that I can say what more we need exactly.

I have not had any issues but I'm looking for more collaboration with the Message Broker and DataPower. I feel that the MQ takes a longer time when DataPower is trying to connect to the MQ part, so I'm looking for that. But, I don't have a really good point to bring out right now.

In some cases, when a file got transferred, it has same name on both sides. That could have something to do with the product or it could have to do with something else. We are working on it. That's confusing. I would like that improved. If it didn't appear with the same name, that would definitely be better.

With the tooling around being able to see what's in the queue, we found third-party products to be friendlier than the out-of-the-box products, as far as, "Let me see what the content is of the object that's on the queue." I want to actually be able to see what's on the queue, and the tools we were given from IBM or from the representatives were terrible. I guess that would be the thing I’d like to see. I've got the third-party products that I use now and it’s at the operating-system level, but that would be the suggestion.

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

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

Using it as a service, as a platform on cloud, would be an improvement. I think it's always had room for improvement, so I would definitely put more on the cloud-based services than on what we currently use.

Also, ease of use isn't that great, as it's still considered enterprise class, whereas the more modern applications or platforms do offer modern interfaces and a way to integrate with those systems. Still, I feel its very legacy-natured.

We are moving toward the cloud. How can we migrate the existing customers to a private cloud? That's what I'm trying to figure out. Maybe it's already there. I need to know.

From what I understand from the team, mainly just the security piece needs to be improved, but it sounds like they already have that resolved.

Obviously, there's always a bug or two here and there that could be fixed, but they're constantly evolving and improving it.

• Security enhancements
• Active-active clustering: IBM MQ does not support active-active clustering, but we need that.

For our internal systems and connecting things together, it works really well. If we're trying to connect to something in the web or other things, we don't use it, because we feel that REST or other APIs are more easily adaptable to that environment. Perhaps; I'm not even sure how MQ could do that.

For instance, one of the things we do is, we collect social media data; the public APIs. We're doing a REST call; we're getting back a JSON object. If there was a way that we could do that, perhaps with MQ; set up a way that it could go out, collect the information that we need, and bring it back as a queue, as opposed to a JSON object. That might be something beneficial.

The very mainframe-centric zIIP offload is very critical to me. I appreciate any and all work IBM can do to offload work onto a zIIP engine to reduce my operating costs. I always tell every vendor that answer. It doesn't make a difference if it's IBM or any other vendor. Exploitation of zIIPs is absolutely critical. I'd say that's probably the biggest thing for me right now. That really impacts my price on my total cost of ownership.

Also, and I think IBM's addressing this in the newer versions of MQ, I would like to see improved MQ data sharing. Again, I'm a mainframe guy. MQ in its original flavor didn't lend itself particularly well to data sharing. There was too big of a chance for data loss. With the new version, where they're using more pointers to the data than data itself, I think that's very promising.

IBM MQ could improve capacity, monitoring, and automatization.

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.

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.

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

Sometimes the applications people don't really understand MQ. For example, we had somebody set up a call through MQ and they ended up making dozens and dozens of calls when they only really only needed to do one. They don't understand how MQ really works, and how it pulls the data and then distributes it back to them, etc.

I think the application people understand that MQ can do it, but they don't really understand the mechanics behind it. They need to be better educated; how to use MQ, get the data that they need, and not cause conflicts.

At the level of the application development people, there needs to be more communication, more information that they have so they understand, because, in essence, what you're using MQ to do is to go to the mainframe and get things. They're so used to their Windows environment, and they don't really understand how MQ grabs that data, and what the mechanics are behind the scenes. And I think that the applications people need to better understand it. Or else something put into MQ so that it is more obvious to them. They don't know what to ask for. They just know, "We're going to go against this data" and they don't know the difference between the different types of security they can set up. The different access and the different classes. We use different classes in RACF; they have no clue what a class is.

There either needs to be better education on there, and or some tools built into MQ that helps them know what to ask for.

Many customers are gravitating towards open source products such as RabbitMQ, or going for a web-based package.

Also, the level of training as well as product marketing for this product are not that great. You rarely find a good training institute that provides training. Many of the architects in several organization are neither aware of the product nor interested in using it. IBM should provide good training on products like this to me and other candidates and post us to the US or UK where we can provide excellent support to the clients using the product.

The way that we are using the solution may not be utilizing the full version of MQ. However, what is available right now works well for us. We are not looking to expand.

I would like to see more integration into the security back end.

I'd definitely like to see a more-stable high availability feature.

There is a feature that is in beta right now which synchronously writes messages to another server. That's something that we'd like to see, just for the stability.

I really can't think of anything that needs improvement. For our company, it does what we need it to do.

The price is always an issue. Like anything you buy, you want the best deal. We are retailers, so we are always looking at costs. I am sure every company does. It would be nice if the message security and file transfer weren’t an extra cost. But I suppose if you want a deluxe of anything, you will need to pay.

It would be nice to see it outside of the z/OS environment, I think. If there was any other type of standalone client application, that's something that I would be interested in.

It's within z/OS, so it's green screen. It's not user friendly, but I can understand that. I've had the training to be able to look at it. It definitely could be improved, but within z/OS, you know you're not going to get any type of color graphical interface. I don't know what else you could do with it.

The integration capabilities could be even easier. 

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

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.

Maybe, there should be a containerized version of the application, that can be deployed on the enterprises. So, there is need for a Docker container version of this product.

They need to do a better job of getting it into the open-source world, so that other people, who are more dependent on open-source technologies, start using it as well.

I would like the ability to connect with some of the more recent offerings, such as API Connect; being able to publish our MQ endpoints, the queues, the messaging infrastructure as IT assets. To control them, govern them and manage them and being able to publish non-functional requirements around it. For example, we support this size of the payload, we support this much throughput. Making it known and available to the rest of the organization, because this technology is so technical in nature, business management doesn't understand it. I would really like a business-friendlier or end-user friendly information layer, and some kind of simple ability to communicate what we have with the users.
I want an information layer that I can publish and tell the whole rest of the organization this is what you get.

Right now, I can't think of anything that needs improving.

I'd like to see a more graphical user interface type of configuration for the application.

From an MQ perspective, if they had some built-in monitoring, built-in dashboards, maybe some web-enabled functions so we don't have to load specific tools on our workstations. The training and scalability clustering could be a little bit easier. They could also make it failover- and fault-tolerant. The training aspect is a big part. I think IBM maybe has some work to do on the training side a little bit.

One possible area with room for improvement is some integration with the alert system to alert us in case of any failure of any message to be transmitted from one source to another; maybe that could help. It doesn't do that right now.

We will see how MQ will help us when we go to cloud, one day.

The user interface might be an area with room for improvement, but we use MQ Explorer and that helps solve a lot of our problems there.

On my test systems, I have over 150 queues; maybe a better way to manage those and to see them visually instead of just one long list.

My only thing for improvement would be the way that we've got it configured. I don't know if it's capabilities and using those capabilities. I feel that we installed it a little bit, say, out of the box. There's a different way we could set up some queue management, that we could do better. It's partly us, but probably using some outside resources to look at our transaction volume and flow. We set it up probably eight years ago and we haven't really changed it since. Our business has changed.

I would just like it to be more resilient. In that area, if there is something that happens, it would alert us better or reset itself automatically, which is the greatest thing, where it tells you, "Hey, there's a problem, but by the way, I've already taken care of it. Just so you know. " That's where I see we've had to do more application monitoring around that to do the actual queue management; understanding that something is wrong. It could help us do that. I lose sleep at night, because of, if we have issues.

There is room for improvement with the price. It's actually not really one of the high-priced items, but everything's relative.

I'm not really sure that there's a lot that we could really think of that we would need above and beyond where we are today, and the way we use it.

What would be nice is some kind of a built-in monitor. That would be something that'd be really helpful; some kind of a performance-type monitor. I know there is one, but it should be built-in. It should be automatic.

Or, a particular queue manager; that would be really helpful, I think.

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.

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.

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.

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. 

The installation of product upgrades and patches is very difficult. It requires the use of the IBM Installation Manager (IM). The original IM data location used for installing the base must also be used for the installation of product upgrades and patches. In the Network Deployment edition, upgrades and patches need to be installed in the deployment manager and node agent profiles. I would improve this area by eliminating the need for the IBM Installation Manager.

For me, there are no areas with room for improvement. We are happy like it is. I don't think we have any special additional needs. I think it does what it's supposed to do and it caters to the requirements we have at this moment.

We would actually like some dashboard improvements, because we've set up some manual dashboarding. We use other tools to monitor MQ. But, if that would be a part of MQ, then we're looking at a TCO reduction again. So it would be interesting if we could get rid of these additional tools.

For me, the management is lacking. It's doable, but it's not graphical. Almost everything you need to do in command line mode. It's pretty technical.

I would just like a more user-friendly experience to do common administration tasks. I know that you can use MQ Explorer, but having something that's already built in would definitely be useful.

We haven't necessarily experienced any issues from a migration perspective. Typically, where we see the majority of our issues at is when we're doing upgrades to the Message Broker, or IBM Integration Bus is what it's called now. Those two products are typically married together. Most of our issues ... I wouldn't even call them issues. We see some issues when we migrate from different versions in regards to like, IIB. I think that's just because this is a more complex product. You have customized code in there. From an MQ perspective, everything's pretty straightforward.

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.

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.

We're moving to the next version. I really don't have anything I want improved. There are unknown bugs that we run across where we don't know where they are from, and the next fix pack will fix it.

Price is one thing that could be improved.

Probably because I don't know how it interfaces with the cloud, I would like to see more of that functionality; get more of the cloud experience and more of the mobile experience back into MQ from the customers. That's something I don't have right now.

I think MQ could go farther in terms of the customer experience.

A better user interface; right now, it's technician dependent, so it's a tech support role. It would be nice if we could provide better interfaces to see the queues, the channels and how they're used, and the queue depths.

It would be nice to actually have something like a dashboard. I've been to a presentation about the PowerHA. They now have something like a dashboard, where you can see the health of your nodes and stuff. It would be great to have a dashboard like this. I think there is MQ Explorer, which does that, but I haven’t found it. I would like to use it more to work with the queues, and less to see the health of the environment.

It’s reliable and it's quite all right to work with, but I would like the tools to be easier to work with on a day-to-day basis. For instance, the logs and stuff. For now, we just use the command line when we go in the log directory for each queue manager. It's not very, very easy to operate.

Everything that we need so far works, so I think I'd have to look at the road map, what we planned for internet of things and see if it meets that, which it should. At that point, we'll have a better understanding of what we need going forward.

My support guys, because they use it on a day-to-day basis, might want to see improvements from a management perspective, the management interface. That's one of the complaints I've heard: modernize to a more mobile platform. It's not modern enough for what they wanted to do with it, from what I've heard. That's one area I would say improvement could be done, but again, that might be a small component. Beyond that, nothing.

The main reasons why I haven’t rated it higher is the management interface, which has been a topic of discussion among some of the users, and some issues we’ve had with MQ for z/OS; that's probably because we were on an older version. I haven't looked at the newer version. Those are the two main reasons.

As far as the price point, I don't deal with that; that's somebody else's problem. From a deployment perspective, I didn't have an issue. It's a set up and go for me, from an architect's perspective. These are the requirements, these are the design, you go.

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. 

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

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.

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

I don’t know of any room for improvement.

I didn't know how to get into it. I had to Google how to get into it. Once I got into it, it made sense. It was a green-screen implementation, but it made sense.

I don't know enough about it to really say, "This is where it's missing something."

You can always say price is an area with room for improvement.

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

We would like to see more clustering, high availability, and also monitoring features. Monitoring is a big part. We would like to see if we get back out queues or the queue depth goes high, so that we can be alerted on that.

It still needs some improvement, in terms of high availability and the clustering needs to be improved. Monitoring is a big piece which is missing.

I would like better control over the depth of messages that go in there from all the learning and notifications, better management tools around queue depth, queue issue, that kind of stuff. If things are backing up in the queue, getting better at learning from a dashboard of how the whole ecosystem of MQ is running, that'd be really nice. Because we're using a third party to get that now.

They need to add the ability to send full messages (header + payload) from the MQ Explorer program, not just the payload.

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

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

There could be better APIs around cognitive analytics, around how the messages are flowing. For example, plugins to Watson. That would be useful.

The response time could be improved because that's our main concern. Once our system is down, then it impacts our business since we have another partner who is dependent on us.

There is need for more integration with cloud. That's what we're looking for, because that's what the company is moving towards.

Off the top of my head, I can't really think of any features I’d like to see in future versions. Right now, I don’t have any improvements to the version we’re using. We just upgraded two or three months ago, and we're still getting it all set up.

The configurations were not difficult, but like I’ve mentioned, again, I believe when they went through the integration, they talked to IBM to make sure that we're going to go through OK. So, there was some interface back and forth during the upgrade.
We’re happy with the user interface, so far.

Getting more analytics coming out of MQ is something we're working with across the board with everything, with our Maximo data, with all the applications we have. We get tired of having to pull reports and somebody has to manually crunch the numbers. We need something behind the scenes tabulating everything and coming up with answers, so we don't spend all our time just collecting everything. If there would be an integrated tool that would give us reports, that would be amazing.

It should be able to keep a copy, so that if there is an accident, we would still be able to record the transactions. Maybe processing could be faster, in terms of EPS.
If you consider migration from one version to another, that is an issue and then initial configuration is challenging; when we change the version or change the server.

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

Maybe it should have something with respect to being able to provide a graphical view of the data elements that we are processing. For example, how many messages are being processed by a certain queue or for how much time each message is staying in the queue, and so forth. If there's a way that IBM can provide this tool that can have this out-of-the-box dashboard feature, it would be helpful.

Right now, we are trying to build custom solutions so as to gather that information. We are using Dynatrace, which is one of our monitoring solutions. We try to use it to analyze how many messages this queue has processed today and then we are trying to calculate the data for how long did the message stay in the system before the application picked it up. If there is a tool that can actually provide an out-of-the-box solution of this kind, then it would be really efficient for us.

With MQ, we always have trouble with the initial priming call failing. It would be nice if we didn't have the little wake-up service. Maybe if it self-monitored, had it's own health monitor, to fire those off upon startup, so we don't have to pay the price for it.

I use the character-based interface for things but a lot of my peers like the GUI. Maybe there's a GUI available that I'm not aware of but that would be something that would facilitate it for some other people. Any kind of GUI; it could be on a phone or a browser or whatever. As far as I know, that is currently lacking, but maybe I just don't know. I primarily use the character-based interface for management when I work with it.

Because you can only put so much information on a text screen, sometimes you have to kind of shift views to look at things. That's something that, I imagine, if there was a GUI interface, you could do that a lot more easily. That would be an enhancement, I guess.

To some extent, it just runs in the background and you kind of forget about it. You don't really think about what else you could do with it. It’s just kind of running there.

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.

It could be easier to use.

They need to provide more and more platform integrations because I'm not sure what are the latest upgrades, in terms of MQ as of today. The latest integrations are going to take place in different cloud environments. So, I am not quite sure as to how seamless it can be integrated with other environments and I need to check that. This is also part of my job exercise, that I need to do every time.

It just needs a better installation. An easier user-friendly installation.

In the next release, we would like to see more authentication capabilities embedded and included in the existing product.

At a recent industry event, I discovered that the future version of MQ would provide more web services, such as API, and the ability to manage MQ using a web application. Those will be very good improvements to the product.

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.

Actually, I am looking to move to the cloud. We need to integrate the databases that are in the company and provide API integration services in the cloud. Thus, we would like to see more cloud integration.

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.

Customer support response times could be improved. 

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.

I'm not sure. I've been working with it for about two years, so I'm still learning, but I like it. I'm pretty satisfied with it. But, the initial launch of the application seems to be pretty slow. Once you're inside, it does respond pretty quickly; it's just that initial load that takes a while.

Can't think of anything right now. There's one little part, but I cannot remember it's name.

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.

I would like to see them continue to improve the security features to make sure messages are both posted and delivered properly.