IBM MQ Reviews

• Guaranteed message delivery
• Easy to use
• Works for both distributed and host applications

It allows us to do real-time claims processing through a non-host platform into the host platform.

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.

We've been using it for 25-30 years.

It is solid. We have no stability problems with MQ.

It's solid, and it scales.

I personally have not used technical support. As a corporation, we have, and it is solid.

If you have the right technologist, it's a good tool.

It works. It scales. It does what we need it to do. It's stable. It's a technology that, again, is platform agnostic.

The most important criteria for me when selecting a vendor to work with is: Is it a partner or is it someone that's just looking to get paid?

We are not using MQ to connect across cloud, mobile, and devices as part of the internet of things, so much. It's more for internal.

The barrier to success is that I haven't had a business need to use MQ. We use DataPower instead.

The most valuable features are messaging between applications; sending messages. We use it a lot to communicate with the IBM SIS service.

Actually, we didn't have a choice. If we wanted to speak with IBM SIS, it was the way to do it, so we had no choice there. We had to do it.

There are some part of the business side that couldn't be done without it. It's an integral part.

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.

Stability is good. It's okay.

Scalability is okay but it can get a little complicated. The application should really be aware of the way it works. We had quite a few issues where the app wasn’t able to talk to many queues. We didn't know that much about MQ; the dev team didn't know a lot about MQ, we did not know a lot about how to code for MQ. It was kind of difficult conversation there.

I strongly suggest taking good training first, so you will really know the product and know how to implement it. Then, everything should be fine.

Stability and support are the most important criteria for me when selecting a vendor to work with.

It's one of our core parts of a middleware platform for integrating our CRM billing application and our online transaction application as well. That's the key usage for day-to-day activities.

Integration is a key benefit; it integrates easily. Management is easy. Queue management is one of the key features of it; how easy it is to get set up, get started, get running, look at your queues, look at your workloads, etc., and see what's going on.

We’re not using MQ to better connect across cloud, mobile and devices, or part of the internet of things. It's something that we're looking at for IoNT. We're looking at doing mobile parking, our parking meters. It's something that we're looking at, but we're just doing the road mapping. We haven't deployed that yet.

Currently, it's our connection between our web front end and our back end billing, but that's the next step.

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.

Stability is pretty good. We haven't had issues from a stability perspective. It seemed to always be running. Everyone seems to say, "Hey, it's an MQ issue." Once you look at it, though, the bottleneck is always somewhere else.

Scalability is great as well. You can create your queue managers or you can add a node if you need to and just grow your platform.

I personally haven't used technical support, so I can’t comment on that. Once it's deployed, the support team manages everything into it.

I was not involved in the decision to invest in MQ.

I was in the initial setup; I was involved in the design of the environment for MQ and the rollout of that platform.

It was midway between straightforward and being complex. Our environment is quite complex. We have to integrate the different systems; we have MQ on z/OS, we have MQ distributed. It's right across the platform. The setup of MQ was not complex, but the integration with our environment had some complexity. Overall, with the MQ platform, I don’t think we could have done it any easier.

It's a great tool. It's a great integration middleware tool. Once you have your requirements set, MQ should meet it, but review: Make sure that you understand what you need, what you're setting up, and how you're going to deploy it.

The most important criteria for me when selecting a vendor to work with is how easy it is to get the information from that vendor. Usually, when we get a project, it needs to be deployed yesterday; very tight timelines. If a vendor can come to the forefront, come with all the information, show that their product will meet our needs and it's above any other product on the market, or even on par, but you get a little bit of extra service or support, that's what we look for.

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. 

There are a couple of projects where we are using MQ heavily.

It is on-premises right now. We are looking to move to the cloud in the future.

• Offers better reliability and monitoring compared to other tools.
• Integrates well with other IBM solutions. Therefore, it makes sense to use this product when a company has a large IBM solutions portfolio.

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

We have been using it for three to four years.

It is a stable product. The reliability is better than open source software solutions. MQ performs even in extreme conditions.

Scalability is lacking compared to the cloud native products coming into the market. However, IBM is working to move their products into the cloud.

The software is more suited for medium to large businesses.

The support is good. They try to resolve problems as quickly as possible.

The setup and configurations are very easy, not complex. I would give the product plus points for this. This is compared to readily available, open source products that make you scratch your head when you go to set them up because they don't have documentation.

It takes a couple days to deploy the product to production.

We are a software development firm working with medium to large businesses.

It is a very expensive product compared to the open source products in the market.

We are also using Kafka, which is an open source tool, extensively in our projects. 

This is a good product if you are looking for 100 percent stability and reliability, as opposed to implementing an open source solution.

I would rate the product as a seven (out of 10).

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