IBM MQ Reviews

I use IBM HQ to communicate with subsystems within our plants e.g. the supply chain.

I've been using IBM HQ for eight years.

IBM HQ's stability is great - we send six million messages a day, and we're very satisfied with HQ's ability to handle that volume.

IBM HQ's scalability isn't the best.

IBM's technical support is great.

The initial setup was straightforward and took around half an hour.

We used an in-house team and a system integrator.

I would absolutely recommend IBM HQ to others as a very robust, reliable, responsive product. I would give IBM HQ a rating of nine out of ten.

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.

IBM MQ is one of the biggest message exchanges in our company. We are in the process of migration to a cloud base environment because in some projects we are using RabbitMQ and Amazon SQS. However, IBM MQ is a big part of our technology ecosystem.

Overall the solution operates well and has good integration.

I have been using IBM MQ within the past 12 months.

We have had stability issues using the solution for some of our projects.

We have had scalability issues with some projects in the past.

The technical support has been helpful.

I have used RabbitMQ and Amazon SQS.

The installation can be easy, but it depends on the environment.

I recommend others use a more cloud-native approach to messaging.

I rate IBM MQ a seven out of ten.

Our primary use case for pushing data as a queuing mechanism for all the applications to send out messages. We use it as a pipeline. We also use it to publish data and for the application to extract it all.

In terms of runtime, we just push data. We have reduced the various footprints of the database and for transmitting the data from one location to another. MQ is reliable and more structured and it's helped us a lot in pushing the data. The data can be pushed and it will be persistent. It helps us and the connectivity between the data as two separate applications and our middleware interactions are much faster and more reliable.

IBM MQ deals mainly with the queuing mechanism. It passes the data and it publishes it. These two abilities are the most valuable features. 

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 have been using IBM MQ for ten years. 

The stability is good. 

The scalability is high.

Their support is very good. IBM MQ is around 20 years old. The technicians have a lot of expertise with it.

MQ is has a straightforward implementation. There is not much configuration required. It is more complicated for a cluster implementation and the active-passive implementation. You'll need more technical knowledge 

A regular deployment will take around five to 10 minutes. If it's for a cluster implementation, it will take at least 15 to 30 minutes.

We have an internal team that does the implementation. We asked IBM to do the deployment. 

If you use it for evaluation purposes, it's good but if you're using it for freeware, it's not so good. 

Multiple fault tolerance and partition tolerance are great. 

I would rate it a seven out of ten. 

We use queue managers/concentrators for message flow going upstream and downstream on applications with enterprise licenses.

Adding concentrators was great improvement, but it lacks the SonicMQ CAA (continuous availability architecture). 

The most valuable features are queue managers and CCDT, which is the common purpose of most client applications.

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.

IBM MQ appliance has pricing options, but they are costly. 

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. 

The message queue and the integration with any development platform/language, i.e., NET and Java, are the most valuable features.

We are the Companies and Intellectual Property Commission where our mandate is to register and regulate companies and intellectual property (patents, designs, trademarks, and copyrights).

In South Africa, a company that wants to do business with the government or a privately owned company is required to also register for taxes through the South African Revenue Services (SARS).

We have integrated our registration process with SARS to seamlessly register both the company and the taxes upon registration of a company with CIPC using the near real time concept.

We created an interface between two state-owned companies. We replaced the FTP/SFTP process that was cumbersome and often difficult to synchronize the two databases between CIPC & SARS.

Now that we utilize IBM WebSphere MQ, we are never down. Even if the MQ server crashes, messages are queued and can be recovered.

This extends the use of this product to allow seamless integration with all of our stakeholders for data exchange purposes.

I don’t know of any room for improvement.

I have been using WebSphere since 2013.

We have not had any issues with stability.

We have not had any issues with scalability.

We've never encountered any critical issues that required technical expertise except when the server crashed. We had to get an IBM WebSphere MQ accredited service provider to reconfigure the application. We never experienced any other pressing issues after that.

We used FTP/SFTP before. We switched to IBM WebSphere MQ because we needed a robust, scalable message processing mechanism with the ability to integrate with different technologies.

The setup was straightforward. Network connectivity is easy as long as you understand your solution design requirements.

I had to take over the project with limited knowledge about the product. I can safely say today that I support the solution with minimum assistance from the software vendor. I was not trained, nor did I have skills transferred to me to enable me to support the product

Since this was not the initial direction CIPC was embarking on, we had the minimal license requirement. The cost was less than the value we would be getting out of this product. There's an annual license with support and it is reasonable cost wise.

We did not evaluate other options. This was recommended to us by SARS. This currently is their standard of integrating with SARS.

IBM WebSphere MQ is robust, scalable, and reliable. You just have to clearly articulate your requirements and understand your needs so that you can realize the benefits of using the product. Our lesson learned is to always plan wide and implement narrow. This is the "phase approach."

I inherited it when I took over administration of a platform. It is pretty core in our business. I haven't really dealt with configuration that much. It is used to push transactions throughout z/OS, IBM i, Windows, and Linux. It seems to be pretty reliable. It's one of the few things we have that just runs, almost to a point where you forget to go back and do some upgrades. We're running a couple versions that are a little old, and you just forget that; like, "Oh yeah, it's running." It's pretty solid.

It gives us flexibility to drive a solution on any platform but have a reliable communication network.

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's solid. It's one of the few things that just runs, and runs, and runs.

We've upgraded multiple systems and it's kind of come along. As far as the transaction basis that it's responsible for, it's done a really good job. There might be some lagging Windows versions; that's really been more about operating systems lagging behind because of other applications, not MQ. You might get some spots there, where performance might not be what we would've expected, but that's really not an MQ issue.

We have hardly ever used technical support for it. The last time we did, we found out that we were running an unsupported release. That kind of shows how long it just runs. Sometimes you forget to upgrade a couple of the components.

When I have used technical support, I thought it was very good. They even reached out and helped us a little bit in that situation – when we weren't even supported – to take a look at some of the basic stuff, just to make sure we didn't miss anything. Eventually, we got through the situation. We figured out what it was. It turned out it wasn't MQ at all. It was just a configuration change. I think tech support has been pretty good.

I'm an IBM i guy. I always think IBM support is excellent. I haven't dealt with z/OS in a long time, but they were good there, too. The product support, I would imagine, has been pretty good, too.

It's a worthwhile product. If it's priced accordingly and does everything for you, go for it. It's a good product.

I haven’t given it a perfect rating because I haven't had enough experience with it to say, "This is where it's lacking something." As I’ve mentioned, it seems to be really solid and just works.

The most important criteria for you when selecting a vendor is probably the durability of the vendor. You can get into these relationships that look good, with all good intentions from them, but they're not around. With IBM, obviously, we've invested heavily in the company for a long time. We have a good relationship with them. I think durability, and then going with that is innovation. Those are probably the two biggest characteristics.

I don't know that much about our mobile and cloud initiatives. I think we have some. They're probably beyond the infancy stage but certainly not mature at any point. I'm not sure how this technology is driving any of that. I'm not sure.