IBM MQ Reviews

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.

One of the most valuable features is the standardization in terms of messaging; if you have MQ, you probably can talk to anybody. That's one thing: its compatibility. The other one is its stability.

It has improved my organization in many ways. As I’ve mentioned, it's sort of the standard in the market. If you use MQ, you probably can talk to anybody in the market. We also use IBM Integration Bus and they integrate well.

I would like to see them continue to improve the security features to make sure messages are both posted and delivered properly.

For the most part, it is stable. Sometimes, we have issues, but they are internal issues.

On the mainframe, it scales quite well. We're happy because it uses the mainframe's best qualities.

Technical support is average. In terms of efficiency and response time, it's average, comparable to any other vendor. It isn’t better than anybody else that we know.

It's a good product. Don't complicate things. Try to stick to the, let's say, out-of-the-box solutions. Don't be too creative. MQ is about sending messages; it doesn’t incorporate any logic at all.

When selecting a vendor to work with, the most important criteria is that it has to be a strategic vendor for my company to begin with. We have had a mainframe for a long time, so that's quite natural.

The most valuable feature is its stability because we're in the financial services; message persistence and reliability, speed, performance. Those are probably the key attributes that we appreciate.

It's incredibly flexible. It's not software that people get into a religion over; where it’s mainframe or distributed. MQ runs; you don't have to worry about what platform it's on. I find that to be very, very useful. It recovers extremely well in disaster recovery, which is very near and dear to our hearts. High availability options are outstanding.

Support is excellent. The team in Hursley are outstanding, very responsive. They listen to suggestions, and they deep dive into problems.

The very mainframe-centric zIIP offload is very critical to me. I appreciate any and all work IBM can do to offload work onto a zIIP engine to reduce my operating costs. I always tell every vendor that answer. It doesn't make a difference if it's IBM or any other vendor. Exploitation of zIIPs is absolutely critical. I'd say that's probably the biggest thing for me right now. That really impacts my price on my total cost of ownership.

Also, and I think IBM's addressing this in the newer versions of MQ, I would like to see improved MQ data sharing. Again, I'm a mainframe guy. MQ in its original flavor didn't lend itself particularly well to data sharing. There was too big of a chance for data loss. With the new version, where they're using more pointers to the data than data itself, I think that's very promising.

I'm a little concerned about scalability. We're still on the older version of MQ. On the mainframe, we're on the older version. I'm not sure where we are in distributed. Page set expansion is a problem for us. We deal a lot with U.S. equity markets. When we're dealing with a lot of message traffic, a lot of market fluctuation, if we reach a page set expansion and MQ basically goes into a halt to expand the pages, that slows us down immeasurably. I know there are larger versions that have larger buffers, larger page sets; we just have to get there.

We're not using MQ to better connect to mobile. The type of business we are doesn't really lend itself to mobile. On the other hand, it is deeply entrenched in our cloud strategy. In terms of the internet of things, I'm going to steal a comment a heard: It really is becoming part of our nervous system. It makes pretty much everything go. We do billions of messages every day. We'd be in a lot of trouble without MQ.

Right now, I'm not seeing any barrier to success. I don’t have anything on that.

The most important criteria for me when selecting a vendor to work with are that it has to match a business need. Stability, for me, is incredibly important. Ease of use, installation, and maintenance; I don't want to purchase anything from any vendor where they have to send a team in to install it and get it running. If they have to send in their engineers to install it because they don't think my engineers can do it, I don't want the software. I guess those are big ones.

It's an incredibly reliable, stable product for us. I think there are things our firm can do better. I think we're going to get better at them. Right now, I don't see that as being IBM's challenge, I see it as ours.

As far as specific advice, I would make sure you stay current with the maintenance cycles and the patching. This is one of the things we're looking to improve on. We inevitably seem to get caught being a version behind or a few patch levels behind. Because it is such a rapidly evolving technology, you have to stay on top of the patch levels.

The most valuable features are content security and content delivery, from a whole network protocol perspective.

It's adapting itself to get into every single component throughout the entire world being Java enabled.

We are able to transport data across any platform in a secure fashion, be it internal or external.

From the send and forget perspective, MQ allows you to – on your own – manage your data, collect your data, and manage your data perspective.

The barrier to success is basically the engine behind the collection of the data.

I also think the administration could be a little more straightforward. Right now, we have to develop our own truly distributed administration system. There's a GUI that's really not manageable; not that easy to use.

It's very stable.

It’s very scalable.

Technical support is responsive; it comes out of Hursley, which is their main support and development location. There is a direct line to their development; it's very good.

We were previously using all kinds of solutions, including SCP, SFTP, FTP and proprietary APIs. MQ allowed standardization to port data.

We decided to use WebSphere MQ because we needed data transport from all kinds of systems.

Responsiveness is the most important criteria for me when selecting or working with a vendor.

Initial setup was straightforward and flexible.

We did not really consider any options other than MQ.

My advice is to lay out your infrastructure in a fashion you can support.

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.

Its ability to transfer large volumes of data reliably.

I have seen in many organizations it has helped in designing great architectural solutions by helping transfer messages between different systems.

5 Years

No

No

No

Did not use.

Did not use.

N/A

N/A

Through Vendor Team. Excellent.

Very good.

N/A

N/A

It is an excellent solution.

I usually recommend IBM MQ for financial, government, and large enterprise companies. It is beneficial for handling high volumes of messages.

Using IBM MQ ensures the guaranteed delivery of messages, which is significant for my clients. It is also known for its security.

The most valuable features of IBM MQ are its guarantee of delivery, ability to handle high volume while maintaining high availability, and robust security measures such as SSL, TLS, and RBAC.

There are no improvements needed at this time.

I have been familiar with IBM MQ for roughly 20 years. It's been essential for many sectors during this time.

I rate the stability of IBM MQ as ten out of ten.

I give the scalability of IBM MQ a rating of eight out of ten.

The technical support from IBM is good.

Positive

Before IBM MQ, I was not using similar products. For comparison, I have used Kafka.

The initial setup is generally straightforward.

Part of our work is to assist customers during the installation and configuration of IBM MQ.

For an enterprise solution, the pricing of IBM MQ is very reasonable.

I have also used Kafka before.

IBM MQ has been in the market for over 20 years; it is an essential solution for most banking, financial, and government sectors.

I'd rate the solution nine out of ten.

I worked as an employee for a bank where we recommended IBM MQ, and we used it.

It's for real-time messaging, an exchange between applications.

On the IBM side, we use Message Queue, all the Message Queue products from IBM. For six years, we used it for a bank, an international bank, and we integrated all the applications synchronously using Message Queue.

IBM MQ is highly scalable and has a reconciliation mechanism. These are the two main reasons we use IBM MQ. 

IBM MQ should have more extensive documentation because I couldn't find a lot of information on the system API side to help us monitor the message queuing. 

I would like to see more documentation.

I have been using it for six years. We used it for a bank, an international bank, and we integrated all the applications synchronously using Message Queue.

It has been a stable solution. 

It is a scalable solution. 

The customer service and support have always been great.

Positive

I know there are competitors like RabbitMQ and Dell Boomi. I believe RabbitMQ is built on open source and they have a licensed version as well. I don't know much about RabbitMQ or Dell Boomi at this point.

IBM MQ is highly stable and quite customizable to integrate with our systems.

We definitely installed using a service provider, and it's not that complex. It's easy. It took three to six months to start implementing the first use case. 

Around six to ten people were involved in the deployment. It is easy to maintain and stable.

The ROI is  good, but we only used it for a few use cases like banking customers. It's quite stable, so we got the value out of the installation.

I would rate it an eight out of ten. It's expensive, not cheap.

I would like to rate it as a seven out of ten. It is quite stable, but it needs to have more documentation, and that is why I rate it as a seven out of ten. 

At this moment, we don't see a use case for implementing AI, but it is definitely in our roadmap. We will definitely try to find a use case to implement any new features that get announced.