IBM MQ Reviews

We use it to send a notification to our customers.

The clusterization which results in persistence is the most valuable feature. I only use a very small number of its features.

I have been using IBM MQ for about three years. For about one year I wrote adapters for IBM Broker and for two years or more I wrote services that used IBM MQ. This was a Java application by JMS.

The stability is okay.

Scalability is not an issue of IBM MQ. There is no replication of messages and that is very bad for systems. Only persistence can solve this issue.

IBM technical support is good.

The initial setup is difficult. Creating your own cluster is difficult and working with cluster repositories is difficult. Issue management with IBM MQ is difficult.

It's a very expensive product.

I like RabbitMQ more than IBM MQ.

If you have a lot of money then I would, of course, recommend IBM MQ.

We have a diverse distributed environment that includes Z/OS, Microsoft Windows, Solaris, Linux, and zLinux. We use multiple programming languages and different databases.

IBM MQ was found to be easy to implement and operate. It became the defacto standard, and integration problems moved from an operational issue to application solutions.

The most valuable features are the point to point messaging and the MQ API. This solution is simple and very diverse.

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

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.

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.

All our applications run around MQ. We run a backend system working with a mainframe and we distribute records via MQ. We are using it daily.

From the time I joined this company I have been working with IBM MQ. Until now I haven't seen any severe issues related to it. Most of the time it's running. That is the advantage of IBM MQ.

It could be easier to use.

I have been working with IBM MQ for close to 14 years.

It is stable.

It can scale but sometimes, in terms of volume, it is not able to handle a huge volume. We also have limitations of queues related to IBM MQ. We often need to handle a very big volume, but currently we do have limitations. If those kinds of limitations could be relaxed, it would help us to work better.

I'm working on the development side. There is a setup team that is dedicated to working on implementations. I don't have enough hands-on in the configuration of MQ to comment on the setup.

If you're looking for stability I would recommend using IBM MQ. But people, these days, are starting to work with Kafka, which is an open system. I don't have enough knowledge about Kafka to comment on it. I just work with MQ.

We use IBM MQ as a reliable way of integrating different applications. Our transaction service operates using IBM MQ for organizing the asynchronous interaction between different applications and the core banking system. It is easy to organize parallel reading and writing, and you can easily link two IBM MQ servers using the remote queue feature. We also use IBM MQ in web services which are developed using IBM Integration Bus. MQ helps us scale web services and organize parallel execution.

IBM MQ helps us scale our applications and balance our applications' performance. MQ is quite reliable. In some cases, our application became simpler and more reliable simultaneously.

Reliable integration between MQ servers. IT helps us create flexible integration solutions.

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

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.