IBM MQ Reviews

I have installed a cluster MQ in a bank using HACMP for the failover solution on AIX. I have also configured the product accordingly.

It improves reliability and guarantees that messages are not lost. This is a prerequisite for the online payment process.

Asynchronous messaging processing between the front-end and our legacy system using an enterprise service bus (ESB).

To implement such an IBM solution, a company has to pay a lot in term of licensing and consultancy.  A pricing model might be a better option.

It makes it very easy to update and define queues, look at messages, queue depth, and queue properties. We use it in conjunction with the integration bus for testing and development.

It's very handy, graphical, easy to use, pretty, and intuitive.

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.

I've had very good luck with it. It's a little bit slow when you open it, but once you're inside, it seems to respond very well.

It handles everything we have. We have multiple queue managers and broker managers running on different servers, and you can connect to multiples of them. I haven't had any issues with doing that.

I haven't used technical support, but my group has.

I was not involved in the initial setup.

I would advise them to go ahead and use it.

When looking for a vendor, I look at stability, their prevalence in the market, other companies using it, and the ability to get support for the product.

Ease of use and ease of setup. I'm an admin type, and I can set things up from the command line, and I can set things up through a GUI. It's easy to work with.

We really haven't had any problems with it. I don't have too many positive things to say because usually, I'm in it when things break, and that's when I form my opinions. And I haven't really had to form too many opinions on MQ because it's been really stable.

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

Good stability.

Good scalability.

We've had good luck with the MQ people at IBM, in helping us resolve problems.

It helps to plan, and it helps to understand the product. Sometimes management doesn't understand the project, they just go, "Oh hey, it sounds nice. Let's use it." Then they try to slap it on things they don't understand.

When choosing a vendor, stability and reliability are most important to me.

• Clustering
• Multi-instance

I have worked with IBM MQ for three to four years.

The stability and performance are good and our customers are happy with these aspects. In my years working with it I haven't seen many issues, and with the type of support IBM provides, it has been fine.

I have been in contact with IBM support many times. I am satisfied with the support.

The initial setup is straightforward. It's not very complex.

Most of our customers are quite happy with the solution but they have an issue with the cost. They want to move to cheaper solutions.

The best advice I can give is that it provides stability and performance and there's no loss of data. That is most important for our customers. The data will never be lost.

It is used by large enterprises.

We use it for message transfer, mostly for a queue of the messages. Sometimes, we also consider using the topic space solution. But it is mostly for transferring messages between two applications. The applications are located in a different country, so it is also used for communication of MQ to MQ. 

What I like the most about IBM MQ is the 

• reliability
• robustness.

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've been using IBM MQ for more than five years. We're currently using version 8 and we are switching to version 9.

MQ is known for its stability.

The technical support depends on the kind of request you have. IBM is a big organization, and sometimes it takes time, while other times it's very quick. But what is great is the documentation and they even define some bugs. They have a willingness to describe these as an APAR (authorized program analysis report) on IBM pages and they're easy to find for the solution.

The installation is easy but the configuration could be complicated because you have to specify a lot of stuff, like queues. It could be a little bit complicated to configure if you have some specific scenarios. For a simple scenario it's easy, but when you have somewhat more complicated scenarios — for example, when you have a hybrid or you need to support some specific security requirements which you use to implement custom components — then it's not easy.

The time it takes to deploy depends on what type of clusters you need. For deployment for testing purposes, where you do not need any cluster, it can really be done in one day, maximum. It's not that difficult. But if you need to deploy a cluster, like a Veritas Cluster, and to prepare the workload balance, it can take days, with system testing etc. You have to combine a lot of other components.

I would recommend it. If you're looking for a traditional queuing system, IBM MQ is the right choice because of the stability and the performance. And from the support perspective, it's enough to have a really small team. It depends on the number of instances, of course. But MQ is not difficult to support. It's mostly to solve communication issues for applications and to determine what type of communication you prefer: the traditional MQ or via JMS, where you have to put it into the headers. But if you pass it, it is very stable after that and has very good performance.

One of the most valuable features is the standardization in terms of messaging; if you have MQ, you probably can talk to anybody. That's one thing: its compatibility. The other one is its stability.

It has improved my organization in many ways. As I’ve mentioned, it's sort of the standard in the market. If you use MQ, you probably can talk to anybody in the market. We also use IBM Integration Bus and they integrate well.

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

For the most part, it is stable. Sometimes, we have issues, but they are internal issues.

On the mainframe, it scales quite well. We're happy because it uses the mainframe's best qualities.

Technical support is average. In terms of efficiency and response time, it's average, comparable to any other vendor. It isn’t better than anybody else that we know.

It's a good product. Don't complicate things. Try to stick to the, let's say, out-of-the-box solutions. Don't be too creative. MQ is about sending messages; it doesn’t incorporate any logic at all.

When selecting a vendor to work with, the most important criteria is that it has to be a strategic vendor for my company to begin with. We have had a mainframe for a long time, so that's quite natural.