IBM MQ Reviews

• Guaranteed message delivery
• Easy to use
• Works for both distributed and host applications

It allows us to do real-time claims processing through a non-host platform into the host platform.

A better user interface; right now, it's technician dependent, so it's a tech support role. It would be nice if we could provide better interfaces to see the queues, the channels and how they're used, and the queue depths.

We've been using it for 25-30 years.

It is solid. We have no stability problems with MQ.

It's solid, and it scales.

I personally have not used technical support. As a corporation, we have, and it is solid.

If you have the right technologist, it's a good tool.

It works. It scales. It does what we need it to do. It's stable. It's a technology that, again, is platform agnostic.

The most important criteria for me when selecting a vendor to work with is: Is it a partner or is it someone that's just looking to get paid?

We are not using MQ to connect across cloud, mobile, and devices as part of the internet of things, so much. It's more for internal.

The barrier to success is that I haven't had a business need to use MQ. We use DataPower instead.

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.

Scalability and guaranteed delivery are the most valuable features. It's pretty straightforward to scale out. We use MQ to back our enterprise service bus. Guaranteed delivery is very important for most of the data that we send. Having a product that enables that is very valuable to us.

My organization has used MQ for a long time. It is a very scalable, common platform that we can use for sending messages. We use MQ in terms of messaging, MQTT, and MQ FTE for file transfers. It's versatile; it's very functional; and it provides us with a common messaging platform. It eases our integration.

With the introduction of MQ FTE, we've been moving away from other file transfer options, and standardizing the actual large file transfers with MQ FTE versus the previous product that we had. We've standardized on MQ FTE, in terms of shutting down basic transfers like FTP and other basic ways of transferring large files. Adding the MQ FTE functionality, on top of the MQ backbone, has been nice.

The product itself is not difficult to use. I guess you could always ask for a little bit better GUI admin console. All in all, it's not hard to use.

In a large organization like ours, sometimes we have a large MQ installation base; lots of connection points. If there was a more graphical representation, in terms of looking at the overall landscape of where we have MQ implemented, that you could drill in and out; that would be nice. A picture’s worth a thousand words, a lot of the time; if it was more graphical in terms of displaying the overall topology and layout of the MQ infrastructure we have; just from a high-level, admin-type view; just an easier way of looking at things.

It's very stable. It's been around forever. They have functions and features that are useful. Core-wise, it's a very stable product.

I'd probably recommend going with MQ. Don’t waste time with some of the other products out there. We constantly re-evaluate our portfolio and solutions; test things; and do comparative work. We've had other vendors come in, and we've run tests with them or even done limited deployments. Sometimes we buy a package and it comes with either Oracle's OSB, webMethods, or another integration platform, if you will, with their own version of their bus and messaging. Those mostly stay point-contained solutions, and that's for a reason. For the cost and everything you factor in, MQ is a pretty good product.

It's a great product. The only bad thing I could ever say about MQ is sometimes finding the right talent to administer it. It's a bit of a specialized skill set. Sometimes you can have challenges finding somebody that's really a competent admin. Other than that, it's a great product.

The most important criteria for me when selecting a vendor to work with depends on the product. The company's financial stability, their ability to scale to an organization of our size, is very important. Depending on the project, when you're reaching into new territory, sometimes it is looking at and evaluating who does have the best or most innovative approach to solving a problem.

We use MQTT, which is an open standard but works with MQ for the smaller messaging, for a lot of our messaging across the enterprise service bus that connects our digital or customer-facing activities back to our older, more legacy-based systems. It gives us a good interface.

We don't really have any barrier to success; we're pretty successful with it.

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.

We use it right now for transferring a lot of big files. Sometimes, for some reason, the file doesn't get all the way to the other side. We do it between different cities. MQ keeps track of it and gets it all done. We at least know if it was half-done or not. We also have scheduled jobs through ESB, but it doesn't send that kind of notification to us. It says whether the script has run or not run. That's all we get. This has been a better product.

Besides that, we do a lot of our jobs through it. We queue them and run them.

These files are critical. They have to reach the whole file. Sometimes, a half file gets the same name and gets processed as a half file. The result is like replenishing all those files. The results are really screwy if you get half files. Since started using MQ, we haven't seen this.

In some cases, when a file got transferred, it has same name on both sides. That could have something to do with the product or it could have to do with something else. We are working on it. That's confusing. I would like that improved. If it didn't appear with the same name, that would definitely be better.

We've been using it for 8-10 years.

It's very stable. We've been using it for quite some time now, 8-10 years.

We started with very few. Stability’s good. It's scalable all the way. It meets our requirements.

Technical support is very good. Whenever we have a question, they are very responsive.

We've been using MQ for so many years. It's been really, really working great for us. I recommend it rather than looking at other solutions.

The most important criteria for me when selecting a vendor to work with is that the product has to be good. Second, the support has to be really good and the people working with it should be genuine, and not just come up with what you want to hear. They have to be genuine. Sometimes the product is good, the support is good, but the people are not.

For us, the most valuable feature is the fact that we can move data from disparate systems quite easily. It's not a mountain of data for us, because of the nature of our business, but it's critical that we move information through the queues, from many varying different systems.

It makes it much easier to have people from different experience levels be able to interface with one another, without having to be cross-trained on many different platforms. A business benefit is, it can take somebody who's a Windows guy or a Linux guy, and he can fully communicate with the z/OS system, or vice versa, without having to have that extra knowledge of those other systems.

For our internal systems and connecting things together, it works really well. If we're trying to connect to something in the web or other things, we don't use it, because we feel that REST or other APIs are more easily adaptable to that environment. Perhaps; I'm not even sure how MQ could do that.

For instance, one of the things we do is, we collect social media data; the public APIs. We're doing a REST call; we're getting back a JSON object. If there was a way that we could do that, perhaps with MQ; set up a way that it could go out, collect the information that we need, and bring it back as a queue, as opposed to a JSON object. That might be something beneficial.

Stability is a hallmark of the product. It's extremely reliable. We set up a queue and we say, “Go,” and we have virtually zero issues with it. Considering that it's interfacing with multiple different products, it's remarkably reliable.

It's one of those things where, if somebody says there's a problem, you're like, "What? That can't be possible." We really haven't really had any outages to speak of.

We don't have a tremendous transaction volume, but obviously, the scalability is a factor that many large organizations would have to work on. I think that the transaction volume, in some of the testing we've done for performance and things like that, have shown that is a very, extremely reliable product at scale.

I'm not sure that we've really had to use technical support for WebSphere MQ. We’ve figured out how to do it. We've known how to use MQ, set up queues and so on, for a long time. They interface well with our products. We really don't need the support, which I guess is a hallmark of how simple it is to use the product.

We might have had some issues with installation, or some initial setup calls. Once it's gone live, we've really not had to ask for help, had a queue break, or had transmissions not happen.

We've had MQ for a long, long time. It was something that we've always supported.

The people on my team were involved in the initial setup, absolutely. There was a little bit of complexity involved with the mainframe section, around some general ways that the thing is implemented in the system, and things that have to happen early on during the IPL and some other processes that we have. That's the part I'm most familiar with. The other platforms it's run on, I'm not sure.

In general, once we got through some of those issues, it was pretty straightforward.

If you have a lot of internal systems that you rely on passing queue transactional data, and queuing data back and forth between a lot of systems, it's definitely a very reliable, very robust, very easy-to-use product. It's a very eloquent way of providing a solution to the problem of having disparate systems talk to each other.

I think it's a very stable product. It works well. It does exactly what you think it's going to do. It scales well. It's easy for the application people that use it to identify with it, and know what they're doing. My rating is primarily based on all those things, and the reliability.

Honestly, selecting a vendor to work with is different than how we chose a product, in general. Pricing is always an option, but stability, support, the willingness of the vendor to cooperate if you need help, and other things like that are important. It's different than it was a long time ago. Most of the time now, you deal with the fact that companies have only been around for a few years.

It used to be that somebody had to be around 10 or 15 years before you would invest in it and believe in it. Now, very strong companies have only been around for one or two years, and have very vibrant products. When dealing with a vendor, it's how willing they are to listen to the customer; how dynamic they can be in enhancing their products; how quickly they can implement features and functions into their products; how strong their support is if you do have problems; and how well the product operates without having an intense learning curve, or a lot of training necessary. It's how elegantly the vendor delivered the product, the documentation; all those things kind of speak to the vendor themselves.

We don't directly use MQ for cloud, mobile, and devices as part of the internet of things. We use direct REST calls. We use z/OS Connect and other mainframe-related REST services. We're generating APIs in order to connect to the internet, and to connect to cloud-based services.

Integration with my vendor product is the most valuable feature. The vendor strongly prefers MQ. We had a lot of configuration issues when we tried other products. The second-most valuable feature is the stability.

The reliability is a benefit. We rely on it to operate our business. The fact that it's stable enables us to run our business.

With the tooling around being able to see what's in the queue, we found third-party products to be friendlier than the out-of-the-box products, as far as, "Let me see what the content is of the object that's on the queue." I want to actually be able to see what's on the queue, and the tools we were given from IBM or from the representatives were terrible. I guess that would be the thing I’d like to see. I've got the third-party products that I use now and it’s at the operating-system level, but that would be the suggestion.

It is very stable. We’ve had outages and downtime but, out of about 9,000 servers, we'll have a couple go down a month. Overall, that's pretty good.

Scalability hasn't been a problem. We have a highly distributed environment. We run it across a large server farm. Each server has its own instance. I don't try to scale it vertically, so I don't have a vertical problem with it, and it scales fine across.

Technical support is very disappointing. They didn't respond. Then, we nagged them a lot. We basically got, "That's why you should just upgrade to the latest version of IBM. That's a known problem with the stack. You should just upgrade. Why are you still so far behind?"

We had some trouble when we tried to get the vendor product working with the open-source products; that didn't go well. We tried HornetQ, maybe ActiveMQ. (It was eight years ago.) We liked it better than the embedded WebSphere MQ one; better than the one inside the app server.

The vendor had a dependency that their product worked better with IBM MQ. Also, we have an extensive relationship with IBM, so that made the decision straightforward. If you're having trouble with the alternatives, just go with the existing vendor.

Initial setup was complex because of what we were trying to do, as far as the distribution of a number of clones. With the IBM team, there was more internal drama and relationships – more personal problems – than there were technology problems.

We considered other solutions. It was, "Do we really have to?" with this vendor, or could we look at other things? So, we tried other things, and then came back full circle. We picked MQ because we struggled with the other ones. There's a lot of money on the table, so we actually looked at it, we did try it.

Reliability is the most important criteria for me when selecting a vendor to work with.

Look at which features you really need.

It works fine. It does what it's supposed to do. As far as being the best product in the universe, it's a plumbing product; it doesn't have a huge range of functionality; it has a very specific functionality. But it's reliable, so it's a good product.

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.