IBM MQ Reviews

Stability and reliability are the most valuable features. It's very reliable and very stable. You can do a fast recovery in case of any failure. It's a very consistent and stable system.

The whole integration channel between PowerVM and third-party applications goes through MQ. This is why MQ plays the role of middleware, of integration, and it helps us to quickly integrate all applications around PowerVM.

One possible area with room for improvement is some integration with the alert system to alert us in case of any failure of any message to be transmitted from one source to another; maybe that could help. It doesn't do that right now.

We will see how MQ will help us when we go to cloud, one day.

It’s very stable.

We have never faced any problem with upgrading or scalability between MQ series and the IBM the PowerVM. It's good.

Once you install MQ, you don't need a lot of support. Of course, we have support with an IBM partner in our country, but up until now, we have never faced a major issue that could impact our business.

Implementation was very straightforward.

Our environment is 60% IBM. We did not shop to search for another solution.

In general, though, the most important criteria for me when selecting a vendor to work with are support, response time, credibility, to be near to us, and that they are not working from the cloud.

In a financial institution, for very critical applications, when you invest, you have to invest one time. You don't have time to redo the work over and over. When you build your setup, your infrastructure, to do your service and your financial service for mission-critical applications, you have to choose the best-of-breed application that supports you. This is why we choose IBM without any hesitation.

We have never faced any problem. It works fine.

We are a bank, and regulations restrict us from using the cloud, at this point. We're using MQ only on our data center.

It's fairly easy to set up and configure. It's very effective as far as what we need to do with the type of processing that we're trying to get done, message-based processing. It is easily replicate-able. We have tons of servers that actually handle different queues; it's very helpful with that.

In conjunction with some other products we use, such as IIB, it does a lot of the transformation. It cuts out a lot of programming that has to be done for transforming data from our carrier customers into the format that we need it to be. That's really one of the big benefits.

There is room for improvement with the price. It's actually not really one of the high-priced items, but everything's relative.

I'm not really sure that there's a lot that we could really think of that we would need above and beyond where we are today, and the way we use it.

What would be nice is some kind of a built-in monitor. That would be something that'd be really helpful; some kind of a performance-type monitor. I know there is one, but it should be built-in. It should be automatic.

Or, a particular queue manager; that would be really helpful, I think.

It's extremely stable. We very seldom have any issue with it. We have it clustered between z/OS and zLinux. We've never had any serious problem with it.

It is easily scalable; very scalable. We can scale both internally in a virtual machine – the size of a queue or a number of queues – and it's also across multiple virtual machines. We use it both ways to scale up.

On z/OS, queue managers are very easy for us to generate and build new ones if we need to or multiple queues on the same queue managers; it’s a very effective tool.

We have occasionally used technical support for MQ, if we really run into an issue. That has worked out pretty well. As a matter of fact, most of the time, for any kind of an issue, we've usually had it resolved within a day. That's the way we want it.

The decision to invest in MQ was made prior to my starting at the company I'm at. I can't take claim for that. I was at another site, and we weren't using MQ at that other site.

I'm a director and me and my team were involved in the initial set up of MQ. It was very straight forward. We had people that were familiar with it. Some of the people that I worked with, or that worked for me, really had a good background, so it went very quickly, and it was very straight forward.

One of the things that we've been asked about is using open-source message queuing alternatives. One of the things we've always fallen back on is that we like the IBM support; we like the release. We don't want to have to worry as much about the levels of software; IBM already takes care of that. It integrates with the other products that we're using. All of those things kind of play together, especially in our case; we're a very big WebSphere Application Server, and as I’ve mentioned, a very big IIB server as well. It's really important that they all work and play together.

I’ve had really very little trouble with it. It's very effective. I don't think on either side, z/OS or zLinux, we've really had any trouble with it to speak of. Sometimes when we do some of the clustering things, we've run into questions or we run into things.

In general, it's been very, very solid.

The most important criteria for me when selecting a vendor to work with is that they're established; that we're not going to be concerned with, "They're here today, and gone tomorrow."

Probably one of the bigger criteria, nowadays, is the ability to support the software. We know we're going to run into trouble. We know we're going to have problems. We know we're going to have questions. We want to make sure that we have a vendor that can support us at that point.

The most valuable feature is primarily seeing the messages as soon as I log in; being able to see in real time that information.

It allows us to observe the status of our applications in real time; basically, very quick.

I would say it makes the organization more efficient, more reliable; and whenever there is an error, I guess resilient is the word I'd use.

It would be nice to see it outside of the z/OS environment, I think. If there was any other type of standalone client application, that's something that I would be interested in.

It's within z/OS, so it's green screen. It's not user friendly, but I can understand that. I've had the training to be able to look at it. It definitely could be improved, but within z/OS, you know you're not going to get any type of color graphical interface. I don't know what else you could do with it.

It's pretty stable. I don't work with the support of it much, so I'm a general user.

We do have issues from time to time, but because our environment is so complex, it's hard to say whether it's MQ's fault or the messages coming in and out of MQ. I deal a lot with performance and capacity. When there are capacity concerns, when there is too much taking up the system’s CPU, it's difficult to see where the issue lies, but I would say it's been solid for what I use it for.

As far as advice, I would just say familiarize yourself with MQ as much as you can. The Redbooks are great. The implementation of that software solution is something that anyone should be knowledgeable about.

We have a list of approved vendors so I guess the most important criteria for me when selecting a vendor is just a reliable relationship. That's all approved by a different team. We have a hand in maintaining some of the relationships but not much in the creation of them.

I'm a technical specialist and we are customers of IBM. 

This solution offers good performance as well as scalability and stability. It offers a template that's beneficial for any company.

I'd very much like to see more integration in the monitoring tools.

I've been using this solution for nine years. 

The stability is good. 

The solution offers very good scalability. 

The initial setup was straightforward. It's all about planning because we have multiple application teams involved. Deployment takes somewhere between half an hour to an hour, but for the coordination to check and perform from the application side, takes almost a full day because we have critical, multiple applications. It needs to be coordinated and we need to be sure they are able to connect perfectly with our environment or with the MQ.

We pay an annual license fee. 

I recommend this product and rate it a nine out of 10. 

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.

We use IBM MQ for message transmission between our customers, and their agents or global message service providers, such as SITA or ARINC, for tier one critical applications.

Applications are time critical, and IBM MQ has played a significant role in ensuring fast, reliable message transmissions. With IBM MQ in place, fear of messages getting lost in the case of an unplanned failure is almost none.

• Data integrity, reliability and security are very important to our business.
• No messages are lost, and recovery is good in case of any serious failures.
• No dependency on the end party service's run status.

No technical issues come to mind.

In terms of cost, IBM MQ is slightly on the higher side.

It allows data transmission from multiple platforms in a fault-tolerant manner, that's the biggest feature. It is important for us because we do a lot of data transformation and data transmission between different systems; that's one of the biggest things that we do.

It's the backbone of all our data transformation and integration. Thus, this solution is our main integration platform.

Maybe, there should be a containerized version of the application, that can be deployed on the enterprises. So, there is need for a Docker container version of this product.

They need to do a better job of getting it into the open-source world, so that other people, who are more dependent on open-source technologies, start using it as well.

We've been using it for ten plus years now, so it's been good.

It has scaled to all our needs.

We have used technical support. I can't think of any issues with technical support. We've received the support that we needed, on time.

We've been using it for a long time. We were not using any other solution before.

We probably looked at IBM and Red Hat solutions. The reason as to why we chose IBM is because they are more mature in that area.

Longevity, deep support and technical depth are my most important criteria in selecting a vendor.

You should take a look into this solution.

For the IBM MQ solution, the most valuable feature is the interconnection of data between the different systems. In our company, we use mainframe, Windows, and Unix and it provides communication with different plans like associations and the federal employee plan. That's what we're looking for.

The main feature right now that we're looking for is open source and that is where we see more challenges coming up with the product. This is because a lot of the applications are going with open source such as cloud and providing connection with the cloud. We have Amazon AWS cloud services or Microsoft Azure services and the applications are deployed there, so connectivity with those type of applications is necessary.

IBM MQ has broadened a lot of communication between interconnecting the applications. It's more fault tolerant, since we have the message delivery guaranteed. We have high availability for the application and it's not stateful. It has provided the features such as the application to process messages from the mainframe as well as from the web, so we can increase the throughput of the system.

The response time could be improved because that's our main concern. Once our system is down, then it impacts our business since we have another partner who is dependent on us.

There is need for more integration with cloud. That's what we're looking for, because that's what the company is moving towards.

The stability is very good, actually. In our organization, we saw almost 99.9% uptime for the product.

The scalability is really good, because only your system limits the functionality. We can add more storage / more memory and we can always scale up.

We have used the technical support, but we are more concerned about the response time. For example, we have severity 1 issues and the system is down, but we still see time gaps and they don't respond.

Previous, we were using the Oracle Tuxedo solution and it had a lot of limitations. It was not able to interface with a lot of the other systems, i.e., the interface was only with C-based operating systems/programs that use only Windows. That's why we switched to IBM MQ, since it brought a lot of benefits.

The setup was complicated because when I started and there were around 400 queue managers. We have four companies that we communicate with, so we changed a lot of the architecture, i.e., we went from the local queue managers to centralize and to reduce issues, in order to have a more manageable system.

Actually, we looked at IBM and Microsoft. However, IBM had a wider scope of the product, and compared to it, Microsoft provided limited platform support. That's why we chose IBM.

The factors that we look at before selecting a vendor, are how the product supports integration with other companies and the overall support they provide to us.

Definitely, you should use IBM MQ because it is a stable product and provides a wide interface with different systems. You can talk to mainframes on other systems as well, so I would highly recommend this product.