IBM MQ Reviews

The most valuable feature is the fact that it's guaranteed delivery; it's conversational. A lot of our transactions are basically transactions back and forth between either rewards members, reservations and even between our databases. MQ gives us guaranteed delivery.

We're an IBM mainframe user. It folds into our hardware very well. Our support is covered that way. It's kind of an end-to-end type solution. It works well with the distributed partners. We use WebSphere, so we can go ahead, plug things in and they work.

They might be able to improve the monitoring features. When you're looking at distributed platforms, you're looking at different breakpoints to it. MQ has a good support structure, but it would be nice if they could kind of fold MQ into other tools to make it more resilient for other tools, other relationships, and other non-IBM platforms.

That's probably the strongest piece: being able to support the other customers. Eventually, if we can support them end-to-end and tell them where their problems are, we can bring them into our fold and make it an IBM fold.

Stability is unrivaled. We've got no problems with it. It's like the mainframes. When you're looking at five nines for availability, it's there all the time. MQ is there all the time. If we have a problem, it's not part of the conversation. It's more of a case of a database on the other end that we're using as a repository is having a problem. You can go out there, store the messages, and guarantee delivery if there are any interruptions. It just works for us.

It's plug and play. If you need more, you can figure it out on the fly; you can add end points to it. The fact that you can add connections makes it very easy for us, because a lot of times we'll run into an issue where we get spikes in connectivity. We can go ahead and define something on the fly. We can go ahead and throw in the extra conversation, and queues aren't a problem at either end. The fact that we can reduce queues by adding extra channels is a great plus for us.

We have only rarely used technical support, because you don't really need it. When we have used it, it's been very good. The SLAs and everything that we've got for tech support is being met. We've also been using it long enough that we've got some very solid support, as far as, we know who to talk to and when to talk to. It's been great for us.

I was not really involved in the initial setup. I was probably around for it, but I had an applications background. I went from the systems side to the applications side, and back to the systems side. It was kind of the interim period. I'm not really responsible for the MQ right now. I'm more of a user of MQ and a supporting group. As a mainframe user, we basically have that relationship with them.

It's actually not a decision to use MQ, but maybe to expand MQ in some cases. It also is one of those places where you can't really go wrong by saying, “We're going to use MQ,” because it's proven.

The most important criteria for me when selecting a vendor to work with is probably stability. Relationships are important, but we're looking at up time. The better the up time is, the stronger we are, the better our product is, the better we are in front of customers. It used to be, when you were basically just facing other employees in the company, that's one experience. Now that you're facing the user with the dot-com boom, the world out there, everybody's on the end of a phone, our transaction counts have gone up exponentially. To have that relationship, and to have MQ being able to service what they service and support that expansion has been fantastic.

Consider the pros and cons. For us, it’s reliability; it’s stability; it’s reputation. Do not get hung up on the fact that it is one of those "legacy"-type connectivities. A lot of people might not want to look at MQ, look at IBM or look at something because “that's the old way of doing things.” It's the current way of doing things. It's a leading-edge way of doing things, and the fact that it's there 100% of the time.

I'm not sure anybody’s perfect. They're very good at what they do. If they can play well with others, that's the real part of it right now. We're using WebSphere; we're using the mainframe; we're using the distributed side. As long as they can play with everybody, they're going to be a strong player. We'll be a strong proponent for them.

The solution has many use cases from the middleware like IBM WebSphere, Message Broker, and payments.

All the features are valuable.

When comparing the solution to the new age of streaming in messaging technology it is so large, that there are complexities dealing with multi-cloud, multi-deployment, or high availability models. The use cases and APIs can also use some simplification.

I would like to see a dashboard that shows the application's performance.

I have been using the solution for ten to fifteen years.

The solution is rock-solid and stable. 

The solution is scalable in a vertical sense however when considering the available modern cloud technology, horizontal scalability is not a viable solution. It is not worth the additional resources, time, and cost required.

Customer support is good but there is room for improvement in their process. Their support is 24 hours so if you are dealing with support in the U.S. and it is passed over to a support person in the UK for example the person in the UK will not be provided with a detailed log of what has transpired. A lot of time is wasted waiting for them to catch up by reviewing the information each time the case is passed to a support person in a different country.

Neutral

If it is a standalone implementation, it is straightforward. If the implementation is the higher availability mode, XM mode, it becomes a complicated process because it comes with a shared disk resource where one instance goes down, and another instance comes up. This means it can not always be an Active mode, you require an Active-Passive mode all the time. This can increase the setup cost and complexity.

Implementation was done in-house and it took a couple of hours.

Within the first two years, you will see the initial cost returned. 

The fee for this solution is on the higher end of the scale. The licensing fee is high.

I rate the solution nine out of ten.

We currently use the solution with 30 to 40 applications across the organization. It requires four to five people to maintain the solution including engineers, application support, an architect, and integration engineers.

For all the cases where IBM MQ is no longer required, we are migrating to a different solution (Kafka). 

The solution requires a lot of work to implement and maintain. I would suggest looking at other more modern solutions depending on what your organization requires.

I am an integration developer at a bank, and we use IBM tools to develop our solutions. We use IIB (version 10), IBM App Connect (version 11), IBM MQ (version 9.1), IBM web servers, and IBM ODM. We use IBM MQ for exchanging messages between applications.

It is useful for exchanging information between applications. 

It could always be more stable and secure.

I have been using this solution for about three years.

I didn't use anything before IBM MQ.

It was straightforward. It took less than a minute.

We didn't use any integrator. We have a team of about five people who work with this solution. We have developers, a team lead, and a project manager.

I would recommend this solution to others. I would rate it an eight out of 10.

The primary use case of this solution is for the general merchandising and retail market.

From the infrastructure point of view, it's a great improvement and it's more flexible to the latest hardware. Also, it is flexible for whatever is coming or whatever is available for on-premises and cloud integrations.

The most valuable features are RDQM and queue sharing.

There has been a lot of improvement in architecture. It handles better with the new architecture such as Cloud, and Cloud-on-premises integrations.

Also, how Kubernetes can be deployed is helpful.

I would like to see message duplication included. We don't have a mechanism for duplicating a message.

There is a different model where you can have multiple subscribers and not publish the stored data to multiple subscribers. 

Duplication is the most important for sending the same data for different applications.

We have been using IBM MQ for 15 years.

We are using 9.0.0.6 and in the process of upgrading to 9.02.

In terms of stability, IBM has proven to be very rare. It's a very stable product.

We test in very large volumes.

We tested ActiveMQ and it's nowhere close to IMB MQ.

Scalability is an area that has improved a lot. The scalable data is different. 

The way the cluster handles and cluster load balancing is different than what it used to be.

Now with the uniform clusters, it's much better. There is a lot of competition especially with messaging. With streaming, people are using it for messaging also. 

It's very flexible to scale.

We have been using it for a long time. We have a team of 15 people who are using this solution. There are more than 5,000 integrations that are using this solution in all platforms, such as Mainframe, Windows, and Cloud environments.

Tech support is very good. I guess other support groups if someone is looking for ADP accounts it lacks but in general technical support is good.

I would rate them a nine out of ten.

Previously, we did not use any other product. I am not familiar with other technologies.

I'm learning and doing some experiments, but we have found a  product for the volume we have.

The initial setup is straightforward, it's easy.

If someone knows its basic structure, it is easy, but the open-source is much easier than IBM MQ because you just have to install it and start working on it. With IBM MQ you have some installation procedures.

The open-source version needs route access which could be security compliance and could be complex.

IBM is expensive.

I would recommend this solution and suggest you start using it if you have the budget. It's very stable and robust. It's a proven technology, so no one needs to worry about that.

It all relies on the budget, that where all of the problems are. People want to use open-source, and businesses do not have a budget.

It's a good product to use.

I would rate IBM MQ a nine out of ten.

One of the most important features is data persistence. Anytime there is a failure or an unexpected outage, the data is still there. That is one of the biggest benefits of MQ on WebSphere.

One of the things we did not see meeting our need was the lack of integrated monitoring for both IIB flows and MQ's. You have to use different tools for that, i.e. - MQ Explorer for the queues and IIB toolkit/web viewer for IIB apps and flows. If we could integrate the monitoring of both the flows and the queues in one product, that would be great.

Similarly to deploy the flows we need to use IIB toolkit and then to run MQ Scripts – we need to use a different tool. Since IIB and MQ goes hand in hand – it would be nice if the tools were integrated as well.

3 years.

The stability is pretty good, so far. We had some challenges with some of the clustering during initial setup. But once that was done properly, it was quite stable.

That's one of the shining features of MQ, that scalability. It is very scalable.

Technical support is good.

This is something that I inherited. There was a legacy system that was already using MQ.

There are a lot of things that MQ can do, so the configuration setup needs some involvement.

Engage IBM and MQ experts from the beginning on the architecting and the proof-of-concept. There are a lot of configurations and a lot of things that IIB can do. If you do not do properly early on, then it's going to be difficult to find those things, go back, and make those changes.

One of the most important things when selecting a vendor is definitely their ability to meet our functional needs. On top of that, we are looking for partners that are going to be around in 10 years, 20 years, 30 years. We want dependability, longevity, and somebody who's going to be around when we need them.

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.

It provides scalability and it also provides secure messaging.

It is very robust and very scalable.

At a recent conference, I went to a presentation that had the latest version and it has amazing stuff that's coming out. So, I am excited to use those, specifically surrounding the web console and the fact that it's API integrated.

We have stability in our environment because of the product. We can keep adding solutions to the mixture and it still performs as is, which is again a more stable process.

It provides scalability.

I usually deal with level three support and they're pretty awesome; so, they're very good. I rate them 5/5.

There was not a previous solution. I know because of experience with my other jobs that this is a more robust technology to invest in.

Setup was straightforward. I had experience from my previous work, so I was able to bring that experience and implement it here. I was fully versed with it, so it was easier for me.

It's super expensive, so ask them if they can consolidate some other licensing costs. But, IBM is IBM, so I guess we'll pay for it.

IBM was on the top of our short list. I didn't even look at the others, because I am biased.

I would do a PoC with IBM and there's a lot of technical help out there and people who would come to help you. So, use them and also look for other customers who have used the product. Then, you will be able to see the benefits of it and try to fit it in to your department.

We use it in a number of our applications for message queuing. As a broker dealer, it gives us the ability to queue things up and to send them out at a different time; and it works really well. We go to different reports, and get options and other features from other areas, so we need to queue up the MQ piece of it, have it wait, and then release it when we're ready to release it. That's a great feature.

It gives us flexibility when it comes to offering different projects or different types of solutions to customers. Instead of somebody having to sit back and wait for something, we give them the option now to be able to say, "Hey, we can give you these 10 things, and you can get all 10 back," without having them get six now, and come back later to get something else. They can get everything at one time and it looks like one portfolio of stuff versus it being six or seven different things at one time. MQ gives us that feature.

It's probably more like everything else. We're running into this world where everything – MQ, mainframe – is looked at as legacy. I know that it's not, but if it could be a little more GUI-based; if it could be a little bit easier to manage.

I hire people who work for me who are in their 70s all the way to people who are in their 20s. For people in their 20s, when they're working on the mainframe, when they're working on those kinds of MQ solutions, they don't really get it. Sometimes they want to run to something else or use something else. If it was a little bit more user friendly, or more gen-x friendly maybe, that would be the best benefit. The tools work. All the tools on the mainframe, all the tools that are considered legacy or dinosaur tools, they do a great job. They stay up; they run. They're very reliable. They're very scalable.

The amount of work that these things do is just amazing. You don't have to reboot them every time there's a problem. You don't have to have 20 people look at 20 different things. It's usually two or three people, "This is what the problem is", and you fix it and you move on. It's a very good toolset. But having somebody younger be able to work on it would be really, really helpful.

We've used it for many, many years. We use it on the client, a regular Windows platform. We also use it really, really heavily on the mainframe side, and it's very stable. We've had very few problems with it. When we do have problems with it, it's usually the application, not the actual MQ solution.

I haven't had any scalability problems. Most of the things, if there is a problem with scalability, it's because we haven't turned it on or we haven't done it ourselves. When we actually promote the features that are there, when we have the time to dig down and turn those things on and release those things, we don't have any problem scalability-wise.

We've had times where we've had to actually open up PMRs and things like that. But for MQ, it's very, very rare. We use CICS; we use WebSphere itself; we use DB2; so, we use a ton of other IBM features. With MQ there are very, very, very few problems.
When we do use tech support, they're very responsive 99% of the time. There might be one or two times where maybe something new will come out and they might have to come out with an actual fix or something, and develop it. It might take a little time to do that but usually, it's very responsive; very good thing.

I was not involved in the initial setup. I was a DB2 engineer, a systems programmer, for many years. Then I moved into management, into the middleware area, which had CICS, MQ, and other products. Then I actually moved up into a director and now, I'm director of mainframe services. I wasn't involved in the actual initial setup.

Some of the things have been around for 20 years or so, but I've been involved in probably five or six upgrades, other deployments and other feature turn-ons that MQs contributed to. I was heavily involved with that, but not as far as bringing it up and installing it from the beginning, no.

It was already there when I came to the company some 13 years ago; already in place. But I've managed it for probably 8-9 years.

I know open source is a big thing these days. I know a lot of people are talking about going out and buying open-source things or trying open-source things. I say, “Stick to products that have been around, that have been proven, and that you have the support of a vendor behind you who's willing to look at these things and develop around you.” IBM isn't a perfect company. It's got a lot to deal with, when you talk about other startups and other people trying to do the same things that it's been doing for a number of years, but in the long run, it's a good company, and I would say "stick with it".

For MQ and products that have been proven, people need to take the leap and use some of these things in the cloud, use it with Linux, and use some of the new features that IBM has. I work on a mainframe. It's a powerful machine. It does millions and millions of transactions every second, and it just doesn't miss a beat. If it has enough CPU, enough power behind it, it will just crank out, and it just does it day and night. I'd say stick with the true, hard-driven, really dedicated solution.

I have worked in the industry for many years. I worked on the mainframe side when I first started. I went into the distributed side years after that. I'm talking 20 years, and then another 13 or 14 years after that, and I went back into the mainframe world. I've dealt with a lot of products, a lot of different solutions, and there have probably been three or four that do what they're supposed to do and not have a lot of problems. MQ's probably one of the quieter ones.

Sometimes you put something the wrong platform. Sometimes it's not configured right, and you hit some bumps in the road in that way. I did it with WebSphere; I did it with DB2; I've done it with CICS; I've done it with SAS; I've done it with a lot of solutions; Windows, networking, storage. I've managed all those different areas and MQ's a very quiet product. It does what it's supposed to do.

When it hiccups and has a problem, it's usually because someone did something wrong or wrote something wrong, and now it's more of a victim, and it needs to get corrected. Once that gets corrected, it does what it's supposed to do. I don't want to give anything a perfect rating because nothing is perfect, but it's a really great product. It doesn't do a lot of stuff, but it does what it's supposed to do, and that's the main thing.

In general, when I’m looking to select a vendor to work with, I need a vendor who really understands my customers and my needs. I know it's hard sometimes to build a solution that fits everyone's needs, but when I buy something I want someone to be able to couple with me and help me through this process. Every problem that I have, every little road bump that I run into, I want someone there to hold my hand. Engineers are good; administrators are great. These guys will come up with solutions but when there's a problem, I want somebody there to help me; to take responsibility.