IBM MQ Reviews

The major thing we like about it is zero transaction loss. The other thing, which is a plus point, is first in, first out (FIFO). You can be pretty sure that if MQ goes down for whatever reason, the transactions will still sustain; they won't be lost. There is a drawback when, once a transaction touches the other point, it is lost, in the sense that if you don't process it, but that is fair enough.

There is a good user interface. It is a very good way of interfacing two systems. For example, in our case, the central bank clearing systems interface our systems using MQ. It is seamless. I did not face any problems. Initially, when you do the setup, you have to be careful and configure it properly. Once you do that, it is OK.

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.

We never had stability issues. The issues are there only when you are configuring for the first time. Once you get the right configuration, then you can actually forget about the fact that there is MQ.

We have not had any scalability issues.

I have used technical support once in a while, such as when we are upgrading or when we are going to change the server or something like that. They are pretty good. In our part of the world, it's pretty good support.

Interfacing is required in any situation when you have two systems talking to each other. So, there are not too many options. One, is that you can have a file handoff. You can have MQ messaging. Or, you can have an API. So, we currently prefer API, so MQ is slowly losing its position.

Sometimes I am involved in the setup. But, now my people have become experts setting it up. There are issues that happen once in a while. For example, last year it happened when we changed the server. For whatever reasons, the configurations were in fact reset. So we brought IBM in. Those were complex configurations. For whatever reason, a couple of parameters could not be reset. Or, they didn't remember which parameters to reset.

As far as MQ, we only looked at IBM. There are many open-source products available now, like IBM MQ Plus. IBM is coming out with something called IBM MQ Plus Plus. Obviously we have not gone for it, but those are the competition.

MQ is also closely integrated with the broker; internally, it is now an API. There is a close connection.

When selecting a vendor, full scale support is important and technical acumen. If I'm asking a new question, he should be able to resolve it or at least give me direction. I also want timely support. If my production goes down at 12 o'clock in the night, there should be someone to talk to me. I think IBM has very reasonable support, so it helps. Worse-case scenario, you could call and expect an answer within the next one or two hours.

Do the first configuration really well. Maybe involve IBM right from the beginning.

Our primary use case for IBM MQ is as an enterprise messaging between applications. So when applications need to transmit data from one to another, they use a messaging broker, the IBM MQ, RabbitMQ and ActiveMQ.

We have found the MQ messaging topologies valuable mainly the published, subscribe and direct messaging. A feature that no other market could offer at the time was data-addressed encryption.

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.

We have been using the solution for approximately nine years, deploying it on public, private cloud and on-premises.

The solution is stable.

The solution is not easily scalable. 

Technical support is tough to connect with because the training and documentation from IBM are awful and the technical support from IBM is also poor. So it's easier to solve your issue using Google rather than calling support at IBM.

The initial setup was a bit complex. The installation itself can take anywhere from half an hour to four hours, and the configuration could also take a couple of hours, depending on the complexity of the design.

The solution is expensive.

I rate the solution an eight out of ten. The solution is good, but the clustering model can be improved. My advice to others considering the solution is to check other products on the market and ensure their product of choice complies with everything they need. They should go for IBM MQ but ensure they carefully read the terms and conditions and view the price beforehand. Alternatively, if they want to go with a more lightweight solution that is just as reliable, they should review RabbitMQ.

We are a solution provider and this is one of the products that we implement for our clients.

The primary use case for IBM MQ is handling the transportation of messages between applications.

This is being used in a mainframe environment.

Our clients complain about the price of this solution but otherwise, they have not had any problems with it. They are very happy with the quality of the product.

This product has good security.

There is no data loss while transporting messages.

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 have been working with IBM MQ for fifteen years.

This product is used on a daily basis and it is quite stable. In terms of reliability, I would rate it a five out of five.

I have not found any issues related to scalability.

We have multiple clients that use IBM MQ.

We handle the support that initially comes in from our clients. If we have any problem, then we take it to IBM using a PMR (Problem Management Report). When there is an issue then we feel that we can go to them.

We did not use another similar solution prior to IBM MQ.

IBM MQ is not at all difficult to set up.

There is no deployment, per se. A broker will handle the deployment.

We handle the implementation and maintenance in-house. The number of people required for maintenance depends on the team. Our team members support multiple accounts.

The problem with this product is that it's a little bit expensive. This is one of the main challenges that we face with our clients. The charges are high and there should be a less costly solution available. This is especially true when you consider it in comparison to open-source tools that are available.

Overall, I am very happy with this product and my only complaint is that the price is high. I definitely recommend it.

I would rate this solution an eight out of ten.

Enterprise messaging with international clustering in 120 data centers in 82 countries around the world. 

It is the most reliable product that we have ever used.  

It runs everywhere, from the mainframe in the US to the PCs in the Gobi desert attached to an analog modem. 

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

99.999 percent availability for less than a penny per message over the past 25 years.  IBM MQ is the cheapest software in the IBM software portfolio, and it is one of the best.

IBM MQ is one of the oldest, most underrated products in history. 

We use MQ as part of the core of our enterprise information bus. We started that journey in 2009. We have it both on the mainframe and in the mid-range. For us, by allowing messaging to integrate with some of our third-party solutions, like for web banking and so on, we are able to create an information highway that took in the legacy events, captured ATM and credit card transactions, and integrates that into a digital web dashboard.

It provides a better customer experience and more timely access to data.

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

Stability is rock-solid.

It is highly scalable.

Technical support has been good.

I was not involved with the initial setup.

You need to have the right use case to support that type of data and flight paradigm. If you do, there are third-party open-source solutions that a lot of vendors have embedded into their products that you have to integrate with. This gives you a really good platform to do that. So, if you don't want to put something in that isn't as robust or scalable, you don't have to. You can rely on this to be the conduit and the glue for your messaging fabric.

It's also really good at asynchronous logging. A lot of times, when you buy these turnkey solutions for whatever vertical, they often don't have robust logging and security. So, we use MQ as an underpinning to get that for us and we have written services within our system that take advantage of those capabilities. So, even if the vendor doesn't provide it, we have it.

When selecting a vendor, stability and security are the most important. Price is also important. But, in banking, because it's mission critical and highly sensitive, stability is probably way up there. If messaging fails, we don't make money.

Most valuable for us are the queue depths and creations for the installations. Being a business in financial solutions, we depend on it more for those things, so it's very valuable for us. For most of the applications like JBoss and others we use IBM MQ.

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

The stability is good. I mean we do have some issues but we always contact IBM whenever we have performance-based issues and we get solutions quick and fast.

Scalability is great.

The technical support is great. Normally, whenever we have an issue, within 24 hours we will get a resolution, so we can close it and leave it to the IBM technical support guys. We get a solution mostly within 24 hours, so that's great.

We didn't have another solution previously, we have always been with MQ.

I would say it was both straightforward and complex, but not that complex. I mean the installation normally would take some time and with all of them open, it's just a button click and you're done.

I wasn't involved in the selection of the vendors.

Go for it. You should always check out the performance and trust for a good solution.

So far, it's helped us with our Maximo integration between the users and the database administrators. I know we kind of lagged behind on some updates, which caused us problems. We recently upgraded, which had made things a lot easier, got rid of some of the issues we had with the older versions.

It helped us with some of our security, on some of our roles, if I remember correctly. It helped us integrating; we’re trying to move a bunch of different things, like trying to move EZMaxMobile into our Maximo and a few other things. Part of that was bringing up WebSphere to the newest version for all the integration.

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.

With the newest version, we haven't really had any stability or scalability issues. I guess that's a good thing.

With the previous versions, it was just that we were a version behind on what the version of Maximo and everything we were using, so it was causing a few little glitches and buggy issues.

We frequently use technical support. They have been pretty good, so far.

We knew we needed to invest in a new solution mainly because of the issues we were having with the old version; it was pointed out that they were going to be fixed by the new version, so that was kind of a simple thing.

I was not involved in the initial setup with this current version.

We were already using WebSphere MQ, so we didn’t look any other solutions.

Don't be afraid to call. If you're worried about tackling it all on your own, don't be afraid to call IBM or call somebody that's already gone through the process and get some help, because we're all willing to help; you just have to ask.

I have not given it a perfect rating because there's always room for improvement. I can't give them the improvements; they have to figure that out. It works really well but like I’ve mentioned, with the way everything's changing and developing every day, you always have to be on the lookout for what's coming up next.

In general, when I am looking at vendors, the number one criteria is responsiveness. Number two is time frames and that they meet the schedules. Those are our two biggest things. We've had issues with other vendors in the past with those same things.

The scalability of the environment is the most valuable feature. We also like the speed and the manageability of this tool.

It keeps all of our large systems interconnected, so the MQ is at the base of all of our system integration.

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.

Stability is very strong. We haven't had any issues.

We really like the multi-channel queue manager that allows us to have different entries into the queue and manage that traffic; kind of splitting it out. That gives us an immense amount of scale as we add new applications.

We have used support. They are okay. Opening a PMR is a pain in the neck. When you're in a critical event, you don't want to go open up a web ticket. You want to get somebody on the phone, it could fix the problem now. We get that it all goes with the support level and we are pretty high.

We had a mainframe that had MQ associated to it, so we just kept it going forward.

I was not involved in the initial setup.

Study hard, and implement small, and then scale.

Responsiveness, the tool, and price are what I look for in a vendor.