I would recommend it, but it's important to be aware that many users are shifting towards cloud-centric solutions like Kafka.

Overall, I would rate the solution a seven out of ten.

I would rate this solution 9 out of 10.

If you want to route messages through a queue-based app, definitely take a look at this solution and research the cost. 

Overall, MQ is good, capability-wise. You still need a messaging platform and MQ is quite a reliable messaging platform. I have not seen hiccups using MQ across multiple environments in the bank. I have been using it since 2006 and I have never experienced any issues with the product itself. The guidelines of the product, the way it is used, the way things are done, are pretty self-explanatory. There are multiple blogs/ online helps available and there is a lot of help available from experts around the world.

Have a look at the features. If they complement the requirements you have, go ahead with it. If you are very technical and want to understand more about the open-source tools and features, that may require a notable learning curve.

The product has been around for a long time. It's probably time to see what MQ is going to add to its features. We have not started using IBM Cloud Pak with Red Hat OpenShift yet. We are also looking at using containerization but probably it may take some time.

IBM MQ streamlined our company's application-to-application communication since it is a rigid and robust solution that allows you to transfer data from one system to another system using the tool's adapters. In general, the product is very robust.

A scenario where IBM MQ reliability was critical for our company's operations includes an incident involving three to four of our clients who use the product, among which a few are airports situated in regions like Delhi and Bangalore in India. All the big airports use IBM MQ as an integration platform, so it is considered a tier-one application. In the aforementioned areas, there is a need for a tool that offers scalability and robustness.

The feature of IBM MQ, which I found to be most instrumental for our messaging needs, stems from the fact that my company never lost messages when we were using the product. The product has a queue manager, and the message doesn't go anywhere until and unless you read it. The best part of the product is that it ensures that there is no data loss.

IBM MQ's security features have enhanced the data transmission process in our company since it functions in a very secure manner. Nobody can get unauthorized access to the product.

The product offers very good scalability to support business growth.

IBM MQ's integration capabilities with other systems are beneficial since we have developed many interfaces for many airports. Many systems use IBM MQ to send data from one system to another, so it has helped in a great way when it comes to the integration part.

I rate the overall tool an eight to nine out of ten.

I rate IBM MQ seven out of 10.

If you want a robust enterprise application that you know is going to be around that you can trust and you are very comfortable with the concept that you are going to pay for that stability and robustness, then IBM MQ is the best choice. If you are on a lighter throughput or you do not need to worry about the robustness as much then Rabbit MQ could be the better choice. It is a fairly stable application, and it works very well but you do not have that industrialization and long-term code benefit that you receive from IBM WebSphere. If your use case and budget fit then this solution would be a great choice.

We have used the application for a long time. I understand it, how it works and therefore I feel comfortable with it. From a pure usage standpoint, it is great. It will handle anything, but you have to be willing to understand that you are getting into something you cannot go backward on very easily. You cannot easily swap another suitable or similar application out without a lot of work involved. You have to be very careful what you are trying to accomplish with your software.

I rate IBM MQ an eight out of ten.

It is a very stable and scalable product and is a market leader in its appropriate sector. I rate the overall solution an eight out of ten.

We're IBM partners. 

So far, I am satisfied. I'd rate the solution eight out of ten. 

I'd recommend the solution to others. 

We are customers and end-users.

We have various versions that we use, including versions 7 and 9.1. We have both cloud and on-prem deployments and mainly deal with on-premises. 95% is on-premises. 

If you're looking for a guaranteed messaging platform, MQ is quite good. That said, it might be expensive for new organizations. If you're looking for a cheaper option, maybe you may need to look for other MQ open-source protocols or open-source products. You may not get the same guaranteed message delivery experience that you have with MQ. However,  it might be more affordable. With MQ, from a reliability perspective, you see very few bugs. It's been running in the bank for a long time. We have very few cases where we had to reach out to IBM support. It's just too bad they do not have CI/CD capabilities.

I'd rate the solution nine out of ten.

I'm a user and customer. I'm not a core developer of IBM MQ. However, I'm a user of IBM MQ.

I'd recommend the solution to others. I'd rate it seven out of ten overall. 

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

We're just a customer and an end-user.

I'd recommend the solution to any organization.

I'd rate it ten out of ten. It really provides everything we need.

Before joining this company I was mainly consulting for various companies in Germany, and I noticed the core problem was always that in projects where MQ was implemented, they were targeting too low on the management food chain. You need that to go as high as possible because it changes the whole paradigm, your ways of thinking. A lot of the implementations were bad because they were partially patching some problems at the bottom level. The whole strategy was never oriented to messaging. My suggestion would be to be aware of that. Go global from the start. Don't address things partially.

There is a team of four people who supervise all MQ activities here.

I would rate IBM MQ at 10 out of 10, but ACE or Broker are between eight and nine, because of the lack of transparency.

It is important to understand how to implement it and for what exactly you want to implement it. Sometimes, we get into a situation where you may not be choosing the right solution and may not really need MQ to support your product. You may be expecting something that MQ doesn't offer, so it is important to understand your business requirements and the features that MQ offers, in order to see if it is effective in implementing the solution.

The important thing while selecting a vendor is to help the customer go through the implementation phase. One of the typical situations that we run into are the people who you're interacting with, i.e., from a customer's standpoint, the vendor may or may not have the comparable knowledge that is required to make them move to where they want to go. That's the challenge we face across all our vendors. It doesn't have to be an escalation all the time so as to get what you want. The person you're working with should be knowledgeable enough to take the customer from the start to the end.

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.

It may not have all the APIs, features, or protocols that the newest systems have, but in performance and reliability, it is the best.

The amount of people needed to maintain the solution depends on the company and how they want to maintain it. When I was working for a bank I supported 300 MQ managers with approximately 150 systems running. However, for the basic use of the solution, you do not need many people. If you add more features, such as broker and clustering you will need more people for maintenance.

My advice to others is this solution is the best there is. For maintenance, you will probably need fewer people to maintain it than other solutions because of its reliability. The features are probably the most extensive in its class.

I rate IBM MQ a ten out of ten.

I am using the latest version of IBM MQ. I would recommend IBM MQ to other users.

Overall, I rate IBM MQ ten out of ten.

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.

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.

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.

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.

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.

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 would recommend this solution to others. I would rate it an eight out of 10.

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.

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.

Well, I think you should try to use MQ. It's a great solution. I like it.

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.

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.

I rate IBM MQ seven out of 10. It's a good option for anything banking-related where you need secure communications. There are some other similar products out there, but I'm not about other servers. But I'm aware of our BME. So if you're doing banking or anything that requires secure channels, I would recommend IBM MQ. 

I would advise, if I was the person in charge, I would tell my architecture team, "Bring me three other MQ-type solutions and do a POC to see if we can get better performance, resiliency, and reliability at a lower cost."  I guarantee there are solutions out there that can do just those three things.

I rate IBM MQ a six out of ten.

It's expandable but it will add costs that should be taken into consideration. 

I would rate it an eight out of ten. 

In the next release, I would like for there to be easier monitoring. The UI should be easier for non-technical users to set up appliances and servers. 

If you want high availability with little maintenance, choose this solution.

We don't use containers yet.

I would rate the solution as a nine (out of 10) because it is not perfect.

You should read the manual.

The way we use this solution, there is nothing else that even comes close to it.

What's important is that we can team up and work together because we tend to drive the products really hard. So, that relationship with the vendor, at the technical side, is really important to us while selecting a vendor.

Look at the use case and verify that this product, i.e, the IBM MQ, can meet all of those requirements. If not, then go back and say that this is the feature that we probably may need, because every company may be different in terms of requirements for the product. If they have something that is beyond what this product is capable of delivering, then go ahead, open up a price quote for it.

It has always delivered and met all of our application requirements. Due to this, it has no shortcomings that I've experienced.

The criteria we look for while selecting a vendor are stability, where they are in the market place, what other research firms have placed them for the area we are looking for like Forrester and RAD group. We depend on them a lot to narrow down the number of vendors that we are looking for.

I rate this solution a ten out of ten because we have no issues with it. The solution is good, but improvements could be made to the dashboard.

IBM MQ was the first product that I got introduced to when I started my journey with IBM. This is my 14th year in this industry, and I see that this application is still very much useful and applicable. So I always recommend IBM MQ, and this is one of the most popular IBM products.

I would rate it at seven on a scale from one to ten.

We are happy with it. I would give it an eight (out of 10). 

We are not using containers.

I don't think I'd give anyone any advice at all. It's pretty straightforward to go and implement. The only thing that I would say is that perhaps if you're - depending on what you need to do - like deploying some of the IBM CLM tools, you might look maybe for a lighter-weight solution because of those various menus.

I know there are other IBM products and there are various lighter-weight solutions that are provided as part of the IBM MQ family. Going with something that's not full IBM MQ but maybe one of the other IBM products that's much more suitable for your organizational needs would be a good choice.

It's a good solution and you should go for it!

When selecting a vendor, mainly the support part is very important, especially when something goes wrong in production; you don't want to leave the system down. This could cost the customer a lot of money, so having that level of support is important. Sometimes, we run into an issue where the support is not able to help, then we always reach out to our self-service representatives. After which, the ticket gets escalated and addressed pretty quickly, so that's the kind of attention required.

Every application could always use improvements, but it's a very stable application and delivery solution tool that we are able to implement quickly and add applications to it quickly; keep us going in an ever-changing environment.

Partnership with the vendor and stability of the product are most important when selecting a vendor. I mentioned AMQ earlier, and there's no guarantee that AMQ will be around next year.

Stability is key to the product and the performance of it, you can get high availability, high performance too, but we talk about tens of thousands TPS through the product so, from that perspective there's no other competitor on it.

When it's too difficult to have what we want with IBM, we develop our own, better solution and we try to integrate our own solution with IBM.

When selecting a vendor, we look for the confidence, the relationship. We have to share the same objectives and to agree in order to deliver the same value to the client.

Make sure that whatever solution you have is going to scale to meet your needs and that you have the tooling infrastructure available to you, as well.

The most important criteria for me when selecting a vendor to work with is, obviously, quality. Reliability of the product is number one but it needs to be cost effective, as well.

We haven't really moved into the cloud with MQ at this point.

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

You must be careful in that it must fit what you want it to do. A few years ago, we had a silo approach where everybody had their own IBM MQ and their own application support with their own teams. That got out of control. In the last few years we realized that you need to be careful about the deployment model you're using. And you need to make sure it's used for the proper use cases.

That's really the biggest lesson I've learned from using IBM MQ: You need to be very sure about what you want it to do.

I would advise that you talk to someone who knows about the solution and who is not biased. Set up a call with someone like me to look at the solution before you decide to go down this path and, similarly, before you decide to throw it out. Talk to someone who has at least seven years of experience with it and who can give you an unbiased opinion about how it works, and then make up your mind. People have come to us and we have said, "Based on what you are doing, we don't think MQ is the best solution for you. You should be looking at other solutions." And other times, we'll tell them that this is the perfect solution. 

The way MQ works is very good from a messaging point of view. There is very little that needs improving. MQ is very flexible and very tunable. We use it to transport hundreds of thousands of messages every day with absolutely no problems.

At the moment the solution is on-premise. But in the last two years, the bank has decided that it needs to go with the public cloud. So in the last two years, most of our development has gone towards decoupling MQ because a lot of the vendor applications were on the box where MQ was. We're working on the solution and decoupling everything so we can push toward the cloud itself. The solution's built-in connectors are more applicable to when we talk about cloud solutions. 

As for containerization, eventually we will go for it but, at the moment, we don't use it. It's difficult to work on a mainframe because of the way it's set up. But it's definitely something the guys will be using when we look at the Unix servers and other boxes.

For deployment and maintenance we have a team of eight people. We have three people on the mainframe and another three to four people for the appliance. They work with each other as well. On the Unix solution, which includes Linux, AIX, etc., we have another team of four, but all these teams overlap. The average upgrade won't take less than two people, but on the Unix box, upgrades are straightforward and someone can do it on his own.

Don't hesitate. Call IBM and get them in there tomorrow.

It's very easy to set up, it's very stable and it's trackable. MQ is a really good tool to be able to send messages back and forth between multiple platforms. If they're looking for a solution for sending files across, they can actually use MQ to send the messages across.

I haven’t given it a perfect rating because there's always room for improvement.

The most important criteria for me when selecting a vendor to work with is being strong and supporting it, and being there for a number of years, so I don't have to worry about an unsupported product.

We use it mainly on iSeries and mainframe, so I’m not really involved in using MQ to connect across cloud, mobile, and devices as part of the intranet of things.

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.

I would definitely recommend this solution, but it also depends on your needs and business case. I have been using IBM MQ for the last 14 years. I am very much used to it, and I like it. I have used other products too, such as RabbitMQ and Kafka, but not that much. 

I would rate IBM MQ an eight out of ten.

My advice would be to rethink the cloud strategy. Make sure to have certain components that you can put into the cloud. Think about cloud-first properly so that it scales automatically. It knows how to work with some of the container services that are out there so that it scales better. It has some cloud components that are good but you still have quite a strong on-prem infrastructure to support it.

It's quite a complete solution. They have modules and stuff that they acquire and may add on as features and modules, additional modules, which is a very complete solution. It's been expensive to keep going the way we're going. And the turnaround is a bit slow, slower than we want. The business is changing quite rapidly, being in retail so we need to pivot quite quickly. And so that's why we're looking at seriously moving towards the cloud where we can simplify some of our processes and actually even our maintenance in it and the way we operate.

I would rate IBM MQ a seven out of ten.

For the most part, this solution serves our purpose. It is not difficult to manage and the only challenges we have really had were to deal with some of the messages manually.

My advice to anybody who is researching this solution is to consider costs first. It is expensive and you have to ask what value you are going to get from it. You need to consider factors like how many messages you are sending per day. If your budget is sufficient then IBM MQ is your choice, otherwise, you should look into a cheaper option. Also, if stability is the most important thing to you then IBM MQ is the choice that you want to make.

I would rate this solution an eight out of ten.

Get a good MQ expert to get it right from the beginning.

MQ is awesome.

Do the same thing we did. Make sure that you give it a small test first to make sure the solution really works well. Then, make sure it scales.

From an analytics perspective, it's a good tool but you have to have the resources to own it. It's not only about buying it, nor is it about the capacity, but somebody has to care and feed it. It's not one of those you put it in and you can walk away and just consume the data. If you don't care and feed it, you won't get what you need out of it.

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.

I would rate IBM MQ seven out of ten.

It's stable and they keep on just increasing the facilities they are providing in regards to clustering and the public supplied options. They're really doing good there.

IBM is doing really good and they're still growing. IBM should keep the work up in the same way and eventually they'll get there.

We have multiple offers out there from competitors, to beat out the open-sources and the competitors comparing with the license cause and the product-support cause. However, they aren't competitive enough and IBM is way above. In the end, you will get what you pay for.

It all depends on the budget. If you have the budget, then I always prefer IBM.
IBM is the more expensive solution out there, but it's worth it.

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.

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.

We solely make use of IBM MQ and are an MQ customer. 

I rate IBM MQ as a nine out of ten. 

I would recommend this solution for similar companies. I am very fond of IBM MQ because of the reliability and throughput part, at least on a single server. On the consumer and application side, RabbitMQ seems a bit easier to consume. It is a bit ahead in terms of the scale-out feature.

I would rate IBM MQ an eight out of ten.

Definitely it's a great product. But, I think we need better interfaces.

I think it all depends on the business need or the price. If the budget is strict, then they go with other solutions. They compromise on the business need. If they are OK with the budget, then they just go with it.

From our perspective, we use the IBM suite. They provide great support when we need it. They're always evolving and are very stable, so all around it is a very good suite from IBM.

If you have money, then you can use IBM MQ. It is very expensive.

We are using almost every vendor such as Oracle, Microsoft, HPE, Solaris, etc. Our core systems are running on WebSphere, i.e., developed in Java code, so we are using most of the IBM tools. But, the most important issue when selecting a vendor is the support.

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.

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.

I am satisfied with the solution overall.

We have five to six people for the maintenance of this solution.

I rate IBM MQ an eight out of ten.

I would absolutely recommend IBM HQ to others as a very robust, reliable, responsive product. I would give IBM HQ a rating of nine out of ten.

Overall, I am very happy with this product and my only complaint is that the price is high. I definitely recommend it.

I would rate this solution an eight out of ten.

I recommend others use a more cloud-native approach to messaging.

I rate IBM MQ a seven out of ten.

I would recommend the solution, but it is very costly.

I would rate the product as a seven (out of 10).

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.

I would recommend IBM MQ to others that are using major transaction processing.

I rate IBM MQ an eight out of ten.

I would recommend this solution to others.

I rate IBM MQ a nine out of ten.

Middleware family of products such as WebSphere MQ, MB, TIBCO ESB, IBM ESB, and MuleSoft ESB offer excellent choices in architecture and re-engineering of software architecture, and should be the first choice, instead of building from scratch. If anyone recommends rebuilding from scratch, such an architect should not be working for your organization.

IBM needs to protect its products, as well as the engineers and architects who recommend those products.

Customers need to look at their design and carefully select the product. They should look at the product capabilities and change the design accordingly to work with the product.

Don't expect a lot of things from the product. You need to trust your design, your solution, and your app. This product just helps you to move around and navigate your data.

Your product has to be solid to process those elements. If I am unable to put the message in a queue, then if MQ sends me a message and I'm unable to pull the message and process it, then I would not blame MQ. It is my product or app that is not working. The solution is just an interface. It's just messaging. It's sending and retrieving messages, and that's it.

It's very stable and it's pretty straightforward. It just needs some more integration features to make better.

The most important criteria for me when selecting a solution is that it meets the needs.

Definitely read the manual before you do anything.

Implement it. It's pretty easy and straightforward.

I don't do the vendor selection, but I get involved a little bit. When selecting a vendor, I would want ease of administration and installation.

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.

I rate IBM MQ nine out of 10. It's a good solution.

I'm not following the versioning part. I'm not sure which version we are using currently. 

I'd advise new users to try it out as it is easy to integrate, scalable, and stable. 

I'd rate the solution, in general, at a seven out of ten.

I recommend this product and rate it a nine out of 10. 

If you have mission-critical applications that rely on an exchange of data, and the data is very valuable, then I would suggest using MQ.

We have a team of people of 50 to 60 people using it, in middleware admin.

You should take a look into this solution.

If they're thinking about a solution similar to this, I would say, look at your requirements and not just the business requirements. People often stop at that point. Look at your ability to support and run the platform, and the cost of running the platform, because, depending on your need, it could be very expensive to run a large messaging infrastructure. Also, think about what non-functional requirements you want to support now, but what you might have to support three, five, or ten years down the road. Think about it from the bigger picture perspective. And don't implement the solution for one small single requirement. People often make that mistake. They commit to a big licensing and support cost but what they're running is very small and there is not very much value added. That’s a problem there. So look at whether can you put a lot of solutions on it. Can you use it as a platform rather than a points solution is what I would look for.

Go for MQ. It will solve your problems for interconnectivity and just whatever you need to do; scalability wherever you need to go.

It works well, but I think that the overall scale of what you can do with this product adds, again, to the level of complexity, as to what you need in-house for support.

Definitely, you should go out and really try and define your requirements before you actually go out to look at other products. You should know exactly how you're going to use it, and what you hope to get out of this product. Thus, you will have better information to actually go out and compare different products.

I would go back to the rock solid performance. If you can get through the setup and the learning curve with the product, it will just run and work for you. That would be the advice I would give.

In a financial institution, for very critical applications, when you invest, you have to invest one time. You don't have time to redo the work over and over. When you build your setup, your infrastructure, to do your service and your financial service for mission-critical applications, you have to choose the best-of-breed application that supports you. This is why we choose IBM without any hesitation.

We have never faced any problem. It works fine.

We are a bank, and regulations restrict us from using the cloud, at this point. We're using MQ only on our data center.

Take a look at it. It's well worth the effort to play with it and to understand it.

I highly recommend it, but I also highly recommend getting services with the actual product to make sure it's implemented correctly.

The most important criteria for me when selecting a vendor to work with is truly being a partner; taking a little bit of the ownership; not just reading from the book of suggestions – because we can read that same book – but really understanding all of our environments, how we do business, make recommendations and implement them. That is important: not just making recommendations; doing it.

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.

I rate the solution an eight out of ten. The solution is good, but the clustering model can be improved. My advice to others considering the solution is to check other products on the market and ensure their product of choice complies with everything they need. They should go for IBM MQ but ensure they carefully read the terms and conditions and view the price beforehand. Alternatively, if they want to go with a more lightweight solution that is just as reliable, they should review RabbitMQ.

I would rate IBM MQ an eight out of 10.

I'd recommend the solution. It's a very stable solution and very resilient. 

If there is not essential data that needs to be transported between services, then I would go for a RabbitMQ, because it's easier in style, and it's free to use. On top of that, you can have it to wrap around everything in a straightforward way.

That said, I'd rate the solution nine out of ten. We've used it for a number of years and it's always worked very well for us.

I would rate it an eight out of ten. Not a ten because of the pricing.

Use the new and lightweight version (Liberty) to lower licensing costs. It is also easier to upgrade/maintain.

Just do it.

Have a common understanding of why you feel that you need MQ. MQ was something that we implemented years ago, so there may be new technologies out there that you may be able to utilize to make the project you're trying to do easier, and make your implementation a little easier.

We're just a customer. We don't have any business affiliation with the organization.

On a scale from one to ten, I'd rate this solution at a nine.

My advice to someone who is looking into using IBM MQ would depend on their budget, the application criticality, etc. If applications are less critical, you can go with open-source products. 

Apache Kafka is growing quickly. People are using it on almost every project. The future will be Apache Kafka only and there might be some RabbitMQ use as well. But I see that Kafka is gaining the most. IBM MQ won’t support large streams of data but Kafka will support large streams of data. For example, for Big Data projects, will only go with Kafka.

Use it.

It's a very stable product. It's been out in the industry for years. Many industries use it, so it fits into any commodity that you have. It's a very solid product. Give it a try, look at it and understand what it's used for.

The most important criteria for me when selecting a vendor to work with are reputation, post-support, reliability, and improvements on the product.

They’re not really using MQ to connect across cloud, mobile, or devices as part of the internet of things.

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.

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.

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.

If you use it for evaluation purposes, it's good but if you're using it for freeware, it's not so good. 

Multiple fault tolerance and partition tolerance are great. 

I would rate it a seven out of ten. 

This is a good product if you are looking for 100 percent stability and reliability, as opposed to implementing an open source solution.

I would rate the product as a seven (out of 10).

IBM MQ is one of the oldest, most underrated products in history. 

IBM WebSphere MQ is robust, scalable, and reliable. You just have to clearly articulate your requirements and understand your needs so that you can realize the benefits of using the product. Our lesson learned is to always plan wide and implement narrow. This is the "phase approach."

It's a worthwhile product. If it's priced accordingly and does everything for you, go for it. It's a good product.

I haven’t given it a perfect rating because I haven't had enough experience with it to say, "This is where it's lacking something." As I’ve mentioned, it seems to be really solid and just works.

The most important criteria for you when selecting a vendor is probably the durability of the vendor. You can get into these relationships that look good, with all good intentions from them, but they're not around. With IBM, obviously, we've invested heavily in the company for a long time. We have a good relationship with them. I think durability, and then going with that is innovation. Those are probably the two biggest characteristics.

I don't know that much about our mobile and cloud initiatives. I think we have some. They're probably beyond the infancy stage but certainly not mature at any point. I'm not sure how this technology is driving any of that. I'm not sure.

It's a good product but I think it's too costly. That's one disadvantage because there are already many open-source products, like RabbitMQ, Kafka, and ActiveMQ. If you really need a solid MQ solution then go with IBM MQ. If you don't need such a robust solution then you can go with any of the other solutions.

I would rate IBM MQ at seven out of 10. It has less throughput.

It's a good product. Compared to the other products on the market, it's a very good product. Based on your company needs, you should give it a try and it should work.

Study hard, and implement small, and then scale.

Responsiveness, the tool, and price are what I look for in a vendor.

I would advise the potential user to read about security considerations and compliance with security standards.

I would tell people to use this, except that the pricing and support costs are too high.

I would rate MQ at eight out of 10. 

You need to have the right use case to support that type of data and flight paradigm. If you do, there are third-party open-source solutions that a lot of vendors have embedded into their products that you have to integrate with. This gives you a really good platform to do that. So, if you don't want to put something in that isn't as robust or scalable, you don't have to. You can rely on this to be the conduit and the glue for your messaging fabric.

It's also really good at asynchronous logging. A lot of times, when you buy these turnkey solutions for whatever vertical, they often don't have robust logging and security. So, we use MQ as an underpinning to get that for us and we have written services within our system that take advantage of those capabilities. So, even if the vendor doesn't provide it, we have it.

When selecting a vendor, stability and security are the most important. Price is also important. But, in banking, because it's mission critical and highly sensitive, stability is probably way up there. If messaging fails, we don't make money.

Definitely, you should use IBM MQ because it is a stable product and provides a wide interface with different systems. You can talk to mainframes on other systems as well, so I would highly recommend this product.

Don't be afraid to call. If you're worried about tackling it all on your own, don't be afraid to call IBM or call somebody that's already gone through the process and get some help, because we're all willing to help; you just have to ask.

I have not given it a perfect rating because there's always room for improvement. I can't give them the improvements; they have to figure that out. It works really well but like I’ve mentioned, with the way everything's changing and developing every day, you always have to be on the lookout for what's coming up next.

In general, when I am looking at vendors, the number one criteria is responsiveness. Number two is time frames and that they meet the schedules. Those are our two biggest things. We've had issues with other vendors in the past with those same things.

Do the first configuration really well. Maybe involve IBM right from the beginning.

First, assess your requirement. Basically, understand what you want to do and that's where it all starts. Doing the right analysis, finding the right solution; that's where success and failure happens.

Stick with the out-of-the-box requirements, unless something tells you to go in another direction. And if so, definitely work with the vendor to make sure that they give you the adequate tools to do that, or help you scope that out.

When selecting a vendor, support is the most important criteria.

Give it a try. It's not hard to do a proof of concept, get something going and build on that. You'll find that it's pretty easy to work with and it does a lot for you.

The only reason I haven’t given it a perfect rating is probably because I don't know everything it can do. I probably could take better advantage of it, but I might not be doing that right now.

The most important criteria for me when selecting a vendor to work with is reliability. I've got to trust that the product will do what they say, that they'll be able to support it, and that they'll be around in 5 or 10 years when I'm still using it. I kind of lump that into reliability. When I invest in something, I want it to be there and still working later on.

We are not using MQ to connect across cloud, mobile and devices as part of the internet of things. We don't do that on this project. The barrier to success is that nobody's interested. It's that blunt.

Overall, this is a good product. The only thing that I found complex was to build the user interface with the latest versions of IBM MQ. It was a little bit tricky to do.

I would rate this solution an eight out of ten.

I would recommend it to other people. When somebody wants to do colocation with us, we force them to buy IBM MQ.

If you have a lot of money then I would, of course, recommend IBM MQ.

If you're looking for stability I would recommend using IBM MQ. But people, these days, are starting to work with Kafka, which is an open system. I don't have enough knowledge about Kafka to comment on it. I just work with MQ.

There is quite a good amount of documentation that you can get either from the IBM Redbooks or from the IBM support websites. Also, if you are partners with our company, then you will get the required support.

Before installing, I would request you to do a quick analysis and go through the end-to-end process, as to what are your requirements and how to configure this product up-front, i.e., instead of directly installing it and then, trying to configure it on the fly.

In general, when selecting a vendor, we look for more and more support.

Go for it. You should always check out the performance and trust for a good solution.

I definitely recommend them.

When selecting a vendor, we are looking for timely interaction. In case there any issues, we need to get support immediately.

Just go ahead and do it.

We are an IBM partner. 

I'd rate the soluton at an eight out of ten. For the most part, I've been pretty happy with its capabilities. 

We look at all the tools and then we compare them to WebSphere. We can then understand which tool we need.

IBM is a leader, but there is always room for improvement.

The most important criteria for me when selecting a vendor include:

• The support that they provide
• The knowledge they have of the tools that we need to purchase

We also considered Apache Kafka as a solution. The main difference is that Kafka is an open-source platform. 

Looking at this is important for any company that's looking for a solution. So, this needs to be one of your primary players.

I recommend this solution and rate it eight out of 10. 

It is an excellent solution.

I would definitely recommend IBM MQ to other people who are looking to implement this solution. They are going in the right direction. Everything is really in place and can be fully obtained. For me, the solution is a perfect product.

I would rate this solution overall as a nine (out of 10).

Apart from IBM MQ, we are using IBM Integration processor. We are pretty satisfied with the product.

I would strongly recommend the solution, depending on the elements and architecture you're using. If you want to keep your data safe, I would definitely recommend using IBM MQ. We are satisfied with the service provided by IBM MQ. We don't have any issues.

I would rate it at 10 out 10. It's the best.

I would advise them to go ahead and use it.

When looking for a vendor, I look at stability, their prevalence in the market, other companies using it, and the ability to get support for the product.

When choosing a vendor, stability and reliability are most important to me.

The best advice I can give is that it provides stability and performance and there's no loss of data. That is most important for our customers. The data will never be lost.

It is used by large enterprises.

I would recommend it. If you're looking for a traditional queuing system, IBM MQ is the right choice because of the stability and the performance. And from the support perspective, it's enough to have a really small team. It depends on the number of instances, of course. But MQ is not difficult to support. It's mostly to solve communication issues for applications and to determine what type of communication you prefer: the traditional MQ or via JMS, where you have to put it into the headers. But if you pass it, it is very stable after that and has very good performance.

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.