IBM MQ Reviews

Its integration capabilities and the security features are the most valuable features of this product.

We are using it to integrate systems. It's an asynchronous system and there are a lot of benefits of this method for us, so we are using IBM MQ.

If one of our servers or systems fail, MQ will store the messages for a long time, so we do not lose any information or messages. That's why we are using MQ.

• Security enhancements
• Active-active clustering: IBM MQ does not support active-active clustering, but we need that.

It is very stable.

It is very scalable, and very expensive.

We have used the technical support once or twice; it's good. We opened some tickets and received responses within a short time; so it was okay.

I did not previously use a different solution at my current firm but I have also used Microsoft Queues. However, there were a lot of issues with it in terms of the performance, stability and security. IBM MQ is better.

Initial setup was quite straightforward.

If you have money, then you can use IBM MQ. It is very expensive.

We are using almost every vendor such as Oracle, Microsoft, HPE, Solaris, etc. Our core systems are running on WebSphere, i.e., developed in Java code, so we are using most of the IBM tools. But, the most important issue when selecting a vendor is the support.

It allows us to process online transactions for our customers and we can connect between open system platforms and CID platforms. I think this is the most important.

This is the main component of our systems for delivering service to our customers. Without MQ, we would not be able to work or offer our services.

I am not working on the solution directly, but my team does, so technically I don't know the solution at the level where I could provide information about areas with room from improvement.

I'm satisfied with the stability.

Sometimes scaling is not easy because we are trying to connect open systems with mainframe and it's not easy. It is difficult sometimes. I'm not sure about that.

Technical support is great. We are satisfied. We call them every time we need. I would rate them a nine on a scale of one to ten.

Our support from IBM recommended the solution from the beginning, so this is what we use.

In some places, setup is very easy and in others, it is a little bit complex. When we are trying to deliver all of our transactions from web to system CID, it's a little bit complex because the workload is not the same in both platforms. To make this work is sometimes difficult.

We did look at alternatives, but our main platform is from IBM. We were thinking about other vendors but they are smaller, such as Compuware.

Well, I think you should try to use MQ. It's a great solution. I like it.

Helping us with speed to market; that's really what IBM's solutions are helping us do.

Again, we're trying to streamline factory-based speed to market. So, it's improved that.

The solution is very stable.

Scalability is there, as well.

We always rely on technical support; it is very good.

We were previously using a different solution.

There were other vendors that were on our shortlist. We work with other vendors as well, but IBM is one of our premier vendors. The reason why we chose IBM was because of its stability and they've got the products that we are looking for. They partner with most of the partners that we're dealing with.

When selecting a vendor, the most important criteria are it's stability, helping us to grow forward and how can they help us get to the market faster.

Looking at this is important for any company that's looking for a solution. So, this needs to be one of your primary players.

Specifically for MQ, the most valuable feature is the ability for us to deliver messages between applications using the MQ message queuing.

It's more of a guaranteed delivery. So, even if some of our systems are down at that time of delivering messages, when our systems come back up, it goes ahead and resends the messages, so we ensure that the messages are guaranteed.

I haven't seen any features that we could exploit today that's not currently available. I think everything that's in there today in terms of features; it meets all of my requirements. Everything that were shortcomings in the past, they've already been addressed from different users. The current version 8 is very stable and contains everything that we need to run our operations.

It's one of our more stable products on the CMS platform. We really haven't had any issues with that in terms of severity incidents, at least of what I'm aware of for the last three years.

It's very stable; we've not had to dedicate a lot of resources to support the product and that's a plus.

We have always had some unexpected workload coming in and we haven't had any issues of scaling up or down as and when we need to, so as to handle larger message workloads.

The only time that we have used support is when we do upgrades. We'll talk to IBM and maybe resolve some of the discrepancies in the product. IBM is very helpful. They are very responsive and if they can't answer the question, they find the person that can.

Look at the use case and verify that this product, i.e, the IBM MQ, can meet all of those requirements. If not, then go back and say that this is the feature that we probably may need, because every company may be different in terms of requirements for the product. If they have something that is beyond what this product is capable of delivering, then go ahead, open up a price quote for it.

It has always delivered and met all of our application requirements. Due to this, it has no shortcomings that I've experienced.

The criteria we look for while selecting a vendor are stability, where they are in the market place, what other research firms have placed them for the area we are looking for like Forrester and RAD group. We depend on them a lot to narrow down the number of vendors that we are looking for.

For us, it's basically just our messaging bus. We pretty much use it just for events that are limited to various applications that we have in our company. That is pretty much the use case that we have with respect to the IBM MQ.

Also, the stability and reliability of the tool system is what makes it really easy to be able to work with.

Technically, it has made our lives a lot easier. Prior to having MQ, we were basically developing these custom in-house solutions, where we were running into a lot of issues. After bringing MQ on board, along with its integration and flexibility that it has provided us with, it has basically shortened the amount of work we had to do in order to get it set up and to get the communications happening in between.

Maybe it should have something with respect to being able to provide a graphical view of the data elements that we are processing. For example, how many messages are being processed by a certain queue or for how much time each message is staying in the queue, and so forth. If there's a way that IBM can provide this tool that can have this out-of-the-box dashboard feature, it would be helpful.

Right now, we are trying to build custom solutions so as to gather that information. We are using Dynatrace, which is one of our monitoring solutions. We try to use it to analyze how many messages this queue has processed today and then we are trying to calculate the data for how long did the message stay in the system before the application picked it up. If there is a tool that can actually provide an out-of-the-box solution of this kind, then it would be really efficient for us.

We have not experienced any stability issues. We have been running this for almost about five years now. I don't think, up to this day, we've had any server down issues primarily because of MQ, i.e., the product itself. It's very stable.

With respect to scalability, we're not such a big shop where we are continuously scaling up, but it's a pretty standard system for us. We did not really have to do a whole lot. It runs on very bare resources; it's pretty good.

We have had a few scenarios where we were trying to develop some custom security solutions that required MQ to be authenticated, when they are trying to push our consumer messages out. It was not really an issue but more of an enhancement that we were trying to do. That's when we tried to approach IBM and get their inputs on the best way to do this.

They certainly were very helpful. They provided us with the necessary guidance and showed us some technical documents that were available for our reference and basically, to get the project completed.

Actually, when I joined this company, they already had the solution.

First, assess your requirement. Basically, understand what you want to do and that's where it all starts. Doing the right analysis, finding the right solution; that's where success and failure happens.

I like its ease of administration. We just recently moved to the MQ appliance and the high availability (HA) feature is outstanding. We're really, really pleased with it and the power of the appliance itself. When you throw more work at it, the faster it goes.

For example, when you're doing maintenance, you can fail over the entire group of queue managers in that HA group or you can fail them individually if you'd like. So, it's very helpful that way. But that's the manual fail over. The automatic fail over is what we are really interested in. We did have an appliance go down. Everything failed over and none of our clients knew of it. So it was very good. We were very pleased with that.

The user interface is good. The command line version of it, MQ CLI, is good. The web user interface is really handy; really a good feature.

It updated everything. We started with Version 7 with Linux and now, with the appliance, it seems to be bringing us more into the 21st century so to speak.

We have an M2000. The M2001 has a 3 TB SSD, which is a good feature. I wish they had had it when I started. But as we upgrade, in the future, we'll probably move to that. Everything is working properly with the current version.

The reason the migrations are an issue is, we came from Version 7.01 and Version 7.5. The security in Version 8 was a little tighter. So, there were a few things we had to learn. Be sure that we were up to speed, so that's all.

We haven’t had any stability problems at all. Stability has been outstanding. We went from multi-instance queue managers, which worked fine, except they worked often. That wasn't good for us. So it was a perceived outage for our clients. The availability has been outstanding with the MQ appliance.

I have used support on several occasions. We were an early adopter, and there are always a few bugs along the way. We did use technical support and we went all the way up to the lab a couple of times. It was outstanding as usual.

We have been an MQ adopter since 1998. We were using z/OS, so we have been using MQ along the way. Then we went to Windows, to Unix, to Linux, and now the appliance.

Actually, setup was straightforward. I'm not a hardware person and it was a first-time setup. It was what they said it was. It wasn't a 30-minute setup, but it was pretty easy.

Plan your file systems. Plan your messaging names and your network routes. You want to be ready with everything before you start and once you do that, you're in good shape.

When choosing a vendor, I want knowledge and availability. Those are the two things that are most important.

There are a lot of valuable features, such as high availability, and workload balancing. Those are the main two.

It allows different applications to communicate with each other.

I'd definitely like to see a more-stable high availability feature.

There is a feature that is in beta right now which synchronously writes messages to another server. That's something that we'd like to see, just for the stability.

It's been there for a while. We've had it for over 15 years.

Lately, it hasn't been that stable. We're using multi-instance queue managers and we're having a lot of issues with storage and that affects the availability of the queue manager.

Scalability is pretty good.

Support has been good so far. We submit a lot of PMRs and we usually get pretty good response.

I didn't make the decision to invest in this product. There was someone before me that decided.

The initial setup was straightforward.

Definitely read the manual before you do anything.

It allows us to do point-to-point integration in an easy manner. It allows different applications to talk to each other; applications that may speak different languages. You have mainframe technologies, Java-based apps, .NET, things of that nature, and MQ allows you the ability to share the data between those different types of systems.

The thing that I like about MQ most is its reliability. It's one of those types of products that just works. You don't have to tinker around with it too much. One of the biggest things that I really look for in a product is from a reliability perspective. Can I count on this to be up 24 hours a day, and do I have to keep hacking around with it? MQ is definitely something that is really reliable, so it's something that I really appreciate it.

I would just like a more user-friendly experience to do common administration tasks. I know that you can use MQ Explorer, but having something that's already built in would definitely be useful.

We haven't necessarily experienced any issues from a migration perspective. Typically, where we see the majority of our issues at is when we're doing upgrades to the Message Broker, or IBM Integration Bus is what it's called now. Those two products are typically married together. Most of our issues ... I wouldn't even call them issues. We see some issues when we migrate from different versions in regards to like, IIB. I think that's just because this is a more complex product. You have customized code in there. From an MQ perspective, everything's pretty straightforward.

I haven't had any stability issues. I think the biggest thing, when there are issues, is having an easy way to figure out what's going on. I think one of the things that I'm looking forward to, from a MQ perspective, is just having more of a user-friendly experience. MQ has traditionally been somewhat of a command-style solution, so anything that they could do to improve that would definitely be helpful.

We have not had any scalability issues.

We have teams that usually interact with IBM. My team doesn't necessarily do that that often but when we do, it's a fairly pleasant experience.

From an MQ perspective, it's something that we've been using for a long time. Unfortunately, when you're dealing with very large companies, it's difficult to transition away from stuff that you built a long time ago, so you have a lot of this stuff that's just hanging around, that's been built a long time ago, and you still have to maintain it. Once something goes into production, it's typically very difficult to get money to update that service five, ten years down the road.

Setup was pretty straightforward. MQ has been around for a long time. It's a reliable product. It doesn't change that much, so I think everybody, at least in my organization, is fairly comfortable with installing and implementing MQ.

MQ was, to me, pretty much the gold standard in regards to what it does. To me there's really no point to look at other vendors.

Have a common understanding of why you feel that you need MQ. MQ was something that we implemented years ago, so there may be new technologies out there that you may be able to utilize to make the project you're trying to do easier, and make your implementation a little easier.