IBM MQ Reviews

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.

I use the solution in my company since our clients always go for a middleware solution. IBM MQ is a part of the middleware solution category. When I design a middleware solution for our clients, I use IBM MQ to basically store the message.

The most valuable feature of the solution stems from the fact that it offers guaranteed delivery of messages to users. One good thing about the product is the guaranteed delivery since it guarantees that the message won't get lost. My company uses IBM MQ since we handle a lot of asynchronous modes of the design flow, and that is why we choose to use the solution to host the message before we proceed with the other sub-processes. The tool is effective in areas like message delivery and managing large message volumes. It is a very good solution.

In IBM MQ, the channel connection is an area where my company faces some limitations. At times, we hit limitations on the connection, meaning the connection is fully occupied.

I have been using IBM MQ for more than ten years. My company is a reseller of IBM tools.

Stability-wise, I rate the solution a nine out of ten.

Scalability-wise, I rate the solution an eight out of ten.

I rate the technical support a nine out of ten.

Positive

The product's initial setup phase is very easy.

The solution can be deployed in an hour.

The tool saves on development, implementation, and operation costs. The product is quite easy to maintain.

If one is cheap and ten is expensive, I rate the tool's price a seven. The product is expensive.

Maintenance is quite easy when there is an upgrade of any version. You just need to migrate the configuration to the other platform, and it is quite easy.

I rate the tool a nine out of ten.

We're using the IBM MQ series in development, integration, UAT, and production areas.

What I found most valuable in this software is its reliability because messages that are sent into the queues are consumed by the other end of the connectivity. It has helped us maintain integration between two different systems, so that has been part of one of the layers of our architecture that communicates, for example, a back-end platform and back-end core system with a front-end platform. In our case, we are using the backend as a 224 banking system and the frontend we are using the Wall Street front office system. Those two systems are interconnected via the IBM MQ series.

An area for improvement for this software is that sometimes, messages are not consumed in the queues. We have seen queues where not all messages are emptied. That issue has been solved by our IBM team located in Spain, but we haven't received detailed technical information as to why those queues are not totally consumed. A probable reason could be some service and availability issue because of server updates in IBM MQ itself, or server updates related to the operating system, which in our case, we are using Red Hat Linux.

I have seen a lot of problems with the file transfers, e.g. using FTP or SFTP or LFTP. Normally with all these kinds of transfers, they are not on a transaction boundary, meaning a transfer can fail during the execution. We are not certain why it hasn't reached the destination as these protocols are not transactional which you normally have in MQ messages. What I would like to see in the next release is a solution for the MQ file transfer. I saw some literature about it, but I am not sure if the feature is available, or if it will be easy to configure and maintain in the bank.

We've used IBM MQ within the last year. We've being using it on a continuous basis because it is the secure platform we have in our banking system.

IBM MQ is very stable. It's the best server in terms of interconnectivity. The reliability that the MQ series has, I haven't seen in other servers that are also based in MQ.

My impression of the scalability of this software: We started with a very easy installation where we have very few queues defined. Then, we had a huge integration where we applied, pulled, and observed that the scalability is very straightforward. We also found an easy way: making an active-passive configuration automatic. For example: If you have one active server going down, the passive server is switched on automatically, without us needing to do anything from our end, which means the active-passive configuration works properly.

I haven't been involved in contacting IBM's support, but in general, we didn't have any vendor issues.

The setup for this software was very complex, particularly with the integration between the two systems I was talking about earlier: on the core backend and on the user frontend that is the Wall Street system. It has a lot of different types of flows, and all those flows are defined into the server that is called TTI that is working under the MQ series. That contains a lot of complexities because the vendor of the front-end system has included in the MQ side the server functionality for the application, instead of doing it directly in either the backend or the frontend. This means the MQ part is also helping with the logic for processing messages, and the logic is maintained in a layer: the MQ layer in the server that's called TTI. This is the first time we have faced such complexity, but regarding the MQ as is, meaning the vanilla version, it is quite straightforward. That server works the proper way.

We used consultants for the implementation and those were consultants from the vendor who were already experienced in the TTI server.

The licensing for this software is on a yearly basis, but the bank is holding just one license for the entire bank: a corporate license. As for additional costs, it's a standard fee that includes the maintenance and updates that are released periodically.

I didn't download Active MQ and IBM MQ. I was checking on the website because I wanted to know certain functionalities about those two series. So what I downloaded was the literature about their functionalities.

Regarding IBM products, the only one that I was working with was the MQ series.

All products in our organization, particularly the banking systems are on-premise. We are not yet ready to do cloud deployment.

Deployment of this software in the TTI part took three months. For the core part, deployment took approximately one month. The time that it took for deployment is also associated with the number of servers that we had.

We have four groups: development, integration, user acceptance test, and production. In each of these groups, they have their own MQ servers. We started with the installation for the development group, then going forward and solving the issues we found at the beginning with the installation instructions. We continued with the other areas until we reached the production server recently, back in mid-October.

We currently have 200 users of this software.

Deployment of the IBM MQ at core requires two people in our organization, but for the personalized application or the customized one, we have 10 people.

I'm rating this software a five because it is quite expensive and complex. I'm giving this a five over ten rating not just because it runs, but because it has a lot of features.

We use the solution as a messenger software, in order to send messages to various applications.

The main issue we are having with the solution is due to the connection dropouts which have been going on for a long time now. Sometimes randomly the connection gets disconnected and we try to send a message, we get a failure. We then need to manually take an action on the message, which is happening quite a lot in production. We have been working together with the MQ team trying to increase the connection and some channel upgrades. We are taking steps in the right direction but the issue is not completely fixed.

Additionally, there is not any statistical messaging information being captured. We are not able to pull up any reports to determine when a message was sent. For example, how many messages during the day or during five minutes.

I have been using the solution for 13 years.

The solution is very stable. We have not had issues, except for the connection dropouts which could be related to the machine we are using.

The solution is scalable. It is flexible because, for us, we used the solutions adapter to provide the connection parameters to send a message. This has been quite easy.

We have previously used and still do, Rabbit MQ, which is open-source. It is getting quite popular because it is also stable and it has a good UI. This UI allows us to check the messages with some statistical data.

This solution requires a license and we have purchased an enterprise license.

I would recommend this solution. However, there are some emerging competitors on the market that provide a competitive alternative.

I rate IBM MQ a seven out of ten.

The most valuable feature of this product is that it provides guaranteed message delivery. This is important for us because we want to have guaranteed message delivery and integrity; we cannot lose that message.

The reliability that it provides is the most beneficial aspect of this product for our organization.

One thing that I'd like to see is that queue-sharing should not depend on DB2. It should have this feature by itself, instead of depending on DB2.

In order to set up IBM MQ queue-sharing, DB2 data sharing is required in multiple LPARs. Thus, to make the implementation easy and straightforward, it will be nice if DB2 is not required for queue-sharing.

In regards to the stability of the product itself, it's pretty good. However, it depends on the configuration as well. Overall, the stability is good.

Scalability is pretty good as well and on the mainframe, we can expand it. That way, we're looking to carry out queue sharing, on the mainframe as well.

The technical support is fine. MQ is very predictable product and it's good.

I was involved in the initial setup, but not in this company; at a different company. I found that it was easy to install.

This product is from IBM which is a very well-known company.

MQ is a reliable, easy to understand and install solution.

The most important criteria while selecting a vendor are that they should be well-known and the product's reliability. These are the main reasons as to why we chose IBM MQ.

MQ is a very affordable and easy to use messaging product. I like how fast you can write an API and send a message. Thus, its versatility, portability and easy to use functionality are valuable features of this product.

We use MQ for our insurance claims and use it heavily for CICS in the IBM Mainframe and use the IBM IMS for our applications.

Right now, with the new functions such as z/OS & distributed, I don't see any need for additional features as such. This is because everything that MQ provides, we do it. It's okay right now. Things are working fine.

The migration aspect is different and it depends on who is doing it, i.e., whether a person is doing it for the first time or a person who has done it for 18 times. I have done a lot of migrations in MQ, starting from this product version 2 and now it is on version 9. I have done a lot of migrations, so it all depends on how much experience you have, how you set up your migration task and so on. Migration is fine. I don't see any problem there.

If IBM develops a tool inside the MQ product for monitoring, then that will be better for the other IBM products available.

We have been using this solution for 17-18 years.

It's a very stable product. Being one of IBM's high-end messaging solution, it's a very robust product.

We have not had any issues. It is scalable.

I use the technical support from time to time in Hursley because MQ is developed in Hursley. I keep in contact with Hursley developers because in my organization, we use MQ a whole lot for our messaging. I am very happy with the support.

It is a good messaging product from IBM and is easy to use. It is very affordable and flexible, so I will advise other customers/companies to look into this product and use it.

The most important criteria while selecting a vendor are the customer support and easy to use the product. It is also important if the vendors can provide training to the staff and always be behind the customers to help them.

I think the whole product is useful. Their database and all is very good, and the product is fine. The fact that it ensures message delivery is probably the most important thing. I also like that you're able to trace and track everything. If it doesn't arrive at the destination, it will go back to the queue, and no message will be lost.

They probably need to virtualize the MQ flow and allow us to design the MQ flow using the UI. It would also help to migrate to the cloud easily and implement AWS Lambda functions with minimum coding. If you have to code, then just with NodeJS or Java. 

Many things should be done out of the box, like MQPUT directly to databases or MQGET to link to the main database. MQ should be able to connect to any language and just do it whether you're using mobile apps or web apps. It should be possible. 

The other probably more key thing is that to get IBM on-premise is hard because there are no freely available videos and courses. Technical support in Australia could be better.

I used to be an MQ specialist 20 years ago, and now I'm a solutions architect and consultant who sometimes recommends this solution to clients.

I think IBM technical support isn't too bad. IBM support can be a bit slow. Someone should be able to check on the problem straight away. 

I know that IBM in the States is very good. You can get good IBM staff and engineers and architects 24/7 or from 09:00 to 05:00. They have highly skilled and highly experienced staff there. Here in Australia, it feels like it's run by an account manager and run by salespeople. It should be run by architects and engineers and not by the account managers and sales teams.

I think IBM needs to look at its pricing. The prices of IBM products should be simple. The old way of pricing should now be moving on to the cloud to be pay as you go, a plan-based kind of pricing.

To become competitive, they actually need to move to AWS and Azure. If they really want to be highly available, they can have a highly available location, and charge another price.

On a scale from one to ten, I would give IBM MQ an eight.

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.