IBM MQ Reviews

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.

For me, the most important features are its interfaces with RACF and how we can set up the security to allow and disallow who can get to it, who can use it; and then what MQ gets to do on the mainframe and what it does not get to do, basically.

Our organization uses it a lot to interface applications that are outside the mainframe with applications on the mainframe, or to CICS, items like that.

It helps meet that threshold between what do the application people want to do – because they want to do everything now on GUIs and outside applications – and be able to have the security of the data living on the mainframe and how they get to it. It's the go-between between those two worlds.

There are probably dozens of ways we are using MQ to better connect across cloud, mobile, and devices, but it's mostly the fact that they are setting up stuff and then they use the MQ as the go-between between the distributed world and the mainframe. That's mostly what it's being used for.

Sometimes the applications people don't really understand MQ. For example, we had somebody set up a call through MQ and they ended up making dozens and dozens of calls when they only really only needed to do one. They don't understand how MQ really works, and how it pulls the data and then distributes it back to them, etc.

I think the application people understand that MQ can do it, but they don't really understand the mechanics behind it. They need to be better educated; how to use MQ, get the data that they need, and not cause conflicts.

At the level of the application development people, there needs to be more communication, more information that they have so they understand, because, in essence, what you're using MQ to do is to go to the mainframe and get things. They're so used to their Windows environment, and they don't really understand how MQ grabs that data, and what the mechanics are behind the scenes. And I think that the applications people need to better understand it. Or else something put into MQ so that it is more obvious to them. They don't know what to ask for. They just know, "We're going to go against this data" and they don't know the difference between the different types of security they can set up. The different access and the different classes. We use different classes in RACF; they have no clue what a class is.

There either needs to be better education on there, and or some tools built into MQ that helps them know what to ask for.

I have a very high impression of the stability of MQ; we haven't had any problems with it. MQ has been very stable. I think we've had it go down once since I've been here, but it was due to something somebody screwed up somewhere else, not MQ's fault.

So far, we haven't had any scalability problems either, but we're only about a year and a half into this.

I have not had to use technical support. I've had to use IBM technical support because of some issues, but I never had to talk to the MQ people. We have an MQ rep on site and he handles that stuff.

I was involved in the decision process of how we were going to use RACF, and what they were going to set up to do their calls, but they decided they were going to use MQ. I was actually called in as a RACF specialist to help get that interface going.

Before you implement it into RACF, really investigate the classes and how you're going to set those up, and make sure it's clear with the application development folks. Especially if you're trying to test QA and production separately, it's really important how those classes are set up, and how you set up the instructions for those guys.

The most important criteria for me when selecting a vendor to work with are stability, technical support, obviously the more customers they have in a similar type of field; that's probably what's most important to us, generally.

So far, we've had good luck with it. It seems to be working and it seems to be very stable.

It's one of our core parts of a middleware platform for integrating our CRM billing application and our online transaction application as well. That's the key usage for day-to-day activities.

Integration is a key benefit; it integrates easily. Management is easy. Queue management is one of the key features of it; how easy it is to get set up, get started, get running, look at your queues, look at your workloads, etc., and see what's going on.

We’re not using MQ to better connect across cloud, mobile and devices, or part of the internet of things. It's something that we're looking at for IoNT. We're looking at doing mobile parking, our parking meters. It's something that we're looking at, but we're just doing the road mapping. We haven't deployed that yet.

Currently, it's our connection between our web front end and our back end billing, but that's the next step.

Everything that we need so far works, so I think I'd have to look at the road map, what we planned for internet of things and see if it meets that, which it should. At that point, we'll have a better understanding of what we need going forward.

My support guys, because they use it on a day-to-day basis, might want to see improvements from a management perspective, the management interface. That's one of the complaints I've heard: modernize to a more mobile platform. It's not modern enough for what they wanted to do with it, from what I've heard. That's one area I would say improvement could be done, but again, that might be a small component. Beyond that, nothing.

The main reasons why I haven’t rated it higher is the management interface, which has been a topic of discussion among some of the users, and some issues we’ve had with MQ for z/OS; that's probably because we were on an older version. I haven't looked at the newer version. Those are the two main reasons.

As far as the price point, I don't deal with that; that's somebody else's problem. From a deployment perspective, I didn't have an issue. It's a set up and go for me, from an architect's perspective. These are the requirements, these are the design, you go.

Stability is pretty good. We haven't had issues from a stability perspective. It seemed to always be running. Everyone seems to say, "Hey, it's an MQ issue." Once you look at it, though, the bottleneck is always somewhere else.

Scalability is great as well. You can create your queue managers or you can add a node if you need to and just grow your platform.

I personally haven't used technical support, so I can’t comment on that. Once it's deployed, the support team manages everything into it.

I was not involved in the decision to invest in MQ.

I was in the initial setup; I was involved in the design of the environment for MQ and the rollout of that platform.

It was midway between straightforward and being complex. Our environment is quite complex. We have to integrate the different systems; we have MQ on z/OS, we have MQ distributed. It's right across the platform. The setup of MQ was not complex, but the integration with our environment had some complexity. Overall, with the MQ platform, I don’t think we could have done it any easier.

It's a great tool. It's a great integration middleware tool. Once you have your requirements set, MQ should meet it, but review: Make sure that you understand what you need, what you're setting up, and how you're going to deploy it.

The most important criteria for me when selecting a vendor to work with is how easy it is to get the information from that vendor. Usually, when we get a project, it needs to be deployed yesterday; very tight timelines. If a vendor can come to the forefront, come with all the information, show that their product will meet our needs and it's above any other product on the market, or even on par, but you get a little bit of extra service or support, that's what we look for.

The most valuable feature is the ability to connect our different systems fairly seamlessly. Without it, I don't know how we would have connected our mainframe Intel-based systems and Power Systems together. It's the tool that we utilize to make it happen.

It's the transport tier that connects our systems. Without it, we would be very disconnected.

We're using it entirely for our transactional systems right now.

We're not really using MQ to better connect across cloud, mobile and devices, and the internet of things. I imagine that will be the tool that we will utilize that will help bring that next level in. Right now, we're not utilizing it.

Maybe the administration interface could be improved. Right now, it's very command-line driven. My guess is that if the GUI interface was a little bit better, with more of a singular interface across platforms, that would be helpful.

Like most of the IBM products, it's pretty stable. We haven't really had any real challenges. We run it on the mainframe as well as open systems and both are incredibly stable.

It is very scalable; we use it all the time.

I have not personally used technical support for MQ, but my team has. It has been very responsive.

I did not previously use a different solution.

I was involved in the initial set up at my organization from an infrastructure standpoint. We provide the infrastructure tier. On the open-system side, we helped with it and helped the implementation out on the mainframe.

The actual installation is straightforward. The configuration and the implementation of enabling MQ to talk and communicate between the systems can be complicated.

Before choosing this product, I did not evaluate other options.

From our experience with the functionality and the stability of the product, it's going to be difficult to find something that rivals it in the industry right now.

My rating reflects its functionality and its ability to allow our systems, our enterprise, to run the way it does right now. It's purely a function of MQ's ability to allow the systems to talk to each other.

Support and supportability are the most important criteria for me when selecting a vendor to work with. The ability to handle challenges quickly and responsively.

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.