IBM MQ Reviews

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Look at which features you really need.

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

The solution allows one to easily configure an IBM MQQueueManager. It's very easy and demonstrates comparatively better performance than that of other products. It is very good and makes it impossible to lose a message. These are very important advantages of the solution, but the greatest one is its robustness. 

It would be nice if we could use the cluster facilities because we are doing active/passive configuration use. Maybe we could implement them in cluster scenario and use the active/active nodes.

We have been using IBM MQ for around 20 years.

The onboarding processes and setup are very easy. 

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

I rate IBM MQ as a nine out of ten. 

We provide a channel that we call "the link," so we are distributors of numbering services. These links are connected to a simulator, for example, when MQ is related to some application or the scanner. It's a synchronized communication where we first check two-step authentication. So first, we start with the authentication. In the second step, the MQ server provides the connection. Then the system decides if it can make the connection or not. For example, if I'm uploading something, it will check one cluster, not the other five. So next time, I'm just checking to see if we can connect. After that, the other side is also checking. Those clusters are physical connectivity clusters.

We are sending everything. The partner and we create an acknowledgment number and check to see if everything is fine or not. Once everything checks out and we have verified the person with our partner, we establish the connection, sending a message. Then we are also checking the permissions and format. Sometimes there are some errors, so we have to check the login acknowledgment number and figure out what the error code means. We are handling everything for the project, from the code and deployment to support. We are handling everything through an RFP repository. So from there, we are handling every version released in the last two years. Every year, we upgrade according to the guidelines.

There are so many good things with IBM MQ networking. So many complicated issues arise when you're trying to configure your network, and MQ helps by providing the clustering. In our project architecture, we have a cluster that distinguishes between major requests from applications. There is also a centralized cluster. Let's suppose 10 applications are connecting to that cluster. In each application, we add differently. 

If I need to add multiple features to the centralized cluster, we can create another cluster. From there, the GMG is connected. Also, clusters can provide a backup. So suppose this solution faces some failure, like a power outage, MQ can automatically redistribute the load to other servers. 

We are using the synchronizer and another module in our product. We are stepping the connection from the IBM channel. After that, we can send or receive any message. This is synchronizing. We are handling the clustering, and we have created a design for how the NP is built with the partner.

IBM is still adding some features and coding some other systems on the security end. However, it has the most security features I've seen in a communication solution. Security is the most important thing for our purposes.

Sometimes, there are network issues, which means more applications are connected to those messages, so I would like to fix that. For example, suppose there's a new network, and I want to add virtual memory to address a network issue within the cluster. So there is a network issue that needs to be resolved from the cluster. So I need to add the permissions for that particular team or particular time. There are many complications with IBM MQ servers.

I've been using IBM MQ since last year.

IBM MQ is reliable.

We don't use IBM support much. Sometimes partners will come to us with questions, so we just guide them. Sometimes, you need an MQ person because they have access. We guide the customer to ask this question. You have to ask the MQ entity or the entry person. They will help you. And we are not writing any protocols because a separate team does that. And also, if anything goes wrong with the MQ product, then IBM will address that.

From a coding perspective, it's a straightforward process. There are no complications. We cannot directly access the IBM server because there is a separate team assigned to do some security and get some code of conduct from the MQ team. They are handling the MQ server. So we ask them to create these entry servers to discuss that. And also, we are defining everything. We are responsible for handling invalid queries. So they recreate a wrong question or wrong to them. So, whatever is an appropriate question. 

In terms of maintenance, there are three reasons you'll get a maintenance window. On the maintenance window, we are just restarting the epicenter. Nothing else. If it requires any patching or updates, we perform those. But you don't have to restart the application.  The epicenter typically runs continuously.

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. 

We have various strips statements, and we use IBM MQ to pass those strips statements to different systems within our organization.

Encryption and the fact that we have not had any data loss issues so far have been very valuable features. IBM MQ is well encrypted so that we are well within our compliance and regulatory requirements, so that is a plus point as well.

I would like to see their cloud feasibility with other vendors. I know that they are very much tied to their own cloud right now, but I don't know how they are supporting AWS and Azure.

With IBM products, there's less marketing. If they do more demos and more seminars on their products, it will be very useful. On a given day. I get seminar invites for many vendors and products, but for IBM, I may get an invite once or twice a year.

Documentation is easily available to people who know about IBM products. However, if you're not familiar with the products and because there are no popups about seminars and product news, you will not be able to easily find the documentation. So, I think that there's a gap in IBM's marketing, which needs to be improved.

It's been a pretty reliable and well structured solution so far.

It's very good and scalable. Currently, we use it within the EMEA and APAC regions, and we have a few regions in the Middle East as well. We haven't had any issues so far in terms of scalability because we started with APAC. Usually, we start with only London and then slowly start extending to Europe and APAC regions. So, it's scalable because we started with one region, and now, we already have four or five regions.

We have a middleware team of 45 to 50 people in APAC and EMEA who use IBM MQ, but the usage is not limited to the team. We have users across all our venous functions everywhere because this is for backend transmissions connectivity. We use Message Queue everywhere.

At the moment, there are no plans to increase usage, but I think we'll soon be looking to do so. By the first quarter of 2022, we will be moving most applications to the cloud. We know that IBM MQ is very well supported in the cloud and that it will be easier. Right now, our infrastructure is very much on-premise dependent, and we have some legacy dependencies there. So to get to the cloud for us is a big journey, and once we are at that stage, then we'll be able to look into increasing usage.

We setup IBM MQ about four or five years back. I think the setup now would be much easier than the one we did then.

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 use it for application-to-application integration.

Reliable messaging and throughput are the most valuable.

We are looking at the latest version, and we hope that resilience, high availability, and monitoring will be improved. 

It can have some more improvements in the heterogeneous messaging feature. The current solution is on-premises, so good integration with public cloud messaging solutions would be useful.

I have been using IBM MQ for 20 years.

Its stability is great.

Its scalability is okay. The inside scalability is great. We are hoping that the outside scalability is improved in the latest version.

Most of the users are just using the applications, and they are using IBM MQ without realizing it. In terms of the number of people really dealing with IBM MQ on a global scale, there are probably around 30 users. They are actually working with the product. There are thousands of developers who are using applications with IBM MQ.

I am an architect, and I talk with the architects of IBM. The engineers talk with technical support when needed.

The basic setup is simple. The deployment is fully automated.

We received the software from the vendor, but we deployed it on our own. We also do the maintenance ourselves. 

There is real money involved here. As compared to RabbitMQ, IBM MQ is on the higher side in terms of cost.

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.

There are a couple of projects where we are using MQ heavily.

It is on-premises right now. We are looking to move to the cloud in the future.

• Offers better reliability and monitoring compared to other tools.
• Integrates well with other IBM solutions. Therefore, it makes sense to use this product when a company has a large IBM solutions portfolio.

I would like IBM to improve the performance. Right now, it is lacking and can be bulky.

We have been using it for three to four years.

It is a stable product. The reliability is better than open source software solutions. MQ performs even in extreme conditions.

Scalability is lacking compared to the cloud native products coming into the market. However, IBM is working to move their products into the cloud.

The software is more suited for medium to large businesses.

The support is good. They try to resolve problems as quickly as possible.

The setup and configurations are very easy, not complex. I would give the product plus points for this. This is compared to readily available, open source products that make you scratch your head when you go to set them up because they don't have documentation.

It takes a couple days to deploy the product to production.

We are a software development firm working with medium to large businesses.

It is a very expensive product compared to the open source products in the market.

We are also using Kafka, which is an open source tool, extensively in our projects. 

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).

The pub/sub model is the one that we use heavily on IBM MQ. That's the most valuable for us. We are an enterprise team and we provide a lot of integration to the enterprise systems, so when the data changes on the enterprise systems, we publish a lot of these changes to all the subscribers, whether it's a customer change or the account changes.

It provides seamless integration with the enterprise and any enterprise data changes. Also, the reliability is important for us.

Using it as a service, as a platform on cloud, would be an improvement. I think it's always had room for improvement, so I would definitely put more on the cloud-based services than on what we currently use.

Also, ease of use isn't that great, as it's still considered enterprise class, whereas the more modern applications or platforms do offer modern interfaces and a way to integrate with those systems. Still, I feel its very legacy-natured.

I think the stability is great. That's one of the assets IBM MQ is known for.

So far, I think we haven't faced any scalability issues, but it is well architected in terms of its high availability and DR purposes.

I don't have any complaints about the technical support.

I think it was always an IBM MQ base which we used.

I was not involved in the initial setup.

I don't have information regarding which vendors were considered before we chose IBM MQ.

The features and the reliability of the product are important considerations when selecting a vendor.

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