IBM MQ Reviews

IBM MQ is used to ensure that transactions are properly handled.

The most valuable feature of IBM MQ is transaction processing.

I have been using IBM MQ for approximately 10 years.

IBM MQ is stable.

The scalability of IBM MQ is good.

We have only customer transactions using IBM MQ.

I have used the support from IBM MQ. There is some room for improvement.

I rate the support from IBM MQ a four out of five.

Positive

I have not used another solution prior to IBM MQ.

The initial setup of IBM MQ is complex.

The price of IBM MQ could improve by being less expensive.

I rate the price of IBM MQ a three out of five.

I choose IBM MQ over other solutions because of personal comfort.

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

I rate IBM MQ an eight out of ten.

IBM MQ can be used as an integrated bus system in an API for message queuing.

The solution is easy to use and has good performance.

I have been working with IBM MQ for a few months.

The solution is stable.

The scalability of the solution is good.

We have approximately 100 users using this solution in my organization.

The technical support from IBM is very good, they are responsive, and customer friendly.

The installation is not difficult for IBM MQ and takes approximately one day.

We have approximately seven engineers and administrators that do the implementation and maintance.

The price of the solution could be reduced, and we are on an annual subscription.

I would recommend this solution to others.

I rate IBM MQ a nine out of ten.

This product has helped integrate between applications, reduce rework, and costs by reusing working components of existing applications, such as mainframe applications.

At Citibank, for example, they could utilize the already working components in the legacy system and integrate them with web, mobile, and tablet-based applications, instead of developing three separate applications in each of these technologies. This tremendously reduced efforts, costs, errors, and timeline.

• Can process large amount of messages in a small amount of time.
• Integrates between distributed systems: For example, it can help integrate processing between mainframe, client-server, web-based applications by integrating the messages, supporting Service Oriented Architecture.
• It helps avoid rework by using already developed and working features of the application.

Many customers are gravitating towards open source products such as RabbitMQ, or going for a web-based package.

Also, the level of training as well as product marketing for this product are not that great. You rarely find a good training institute that provides training. Many of the architects in several organization are neither aware of the product nor interested in using it. IBM should provide good training on products like this to me and other candidates and post us to the US or UK where we can provide excellent support to the clients using the product.

Not applicable.

Not applicable.

Level of support with IBM WebSphere products, including IBM WebSphere Commerce server, IBM WebSphere Portal server, and IBM Websphere Integration server is fantastic.

For clients such as Target, IBM provided excellent support for IBM CICS Web Services, as well as IBM WebSphere Integration server, by having a dedicated IBM team in the USA that provided support.

Not applicable.

Setup has to be done by the team from IBM. Client just needs to enjoy the excellent support.

Pricing could be better, as with all IBM products. But their performance in production, along with security and scalability, will pay returns in the long run.

There are other products available, such as TIBCO ESB, and we have many
clients who are using that.

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.

The way that we use MQ is just for messaging. We have various systems in our organization and we have various applications.

We use our routing feature when the request is coming from the business application. The request goes to the distributive side and it is routed to the right claim instance.

We use MQ in between for messaging. We process the messages we receive and we send the responses back to whoever sent us the message.

That person or application basically picks up the response and distributes it to whoever requested it. The way we design the environment of that instance can leverage any of the environments.

Because we are a 24/7 company, we always want to have a robust solution where we can keep getting messages. There should be no delays, outages, or blockages. Those messages should be coming in seamlessly, transparently, and efficiently.

The way that we envision the future of our organization is that MQ works well. We have MQ local and MQ distributed and we're leveraging both.

The way that we are using the solution may not be utilizing the full version of MQ. However, what is available right now works well for us. We are not looking to expand.

It's very robust. It's stable. Whenever we have a situation where our listener is down for some reason, MQ has the capacity to put those messages into some queues where we can retrieve them later on.

It has those alerts built-in. It tells our operation that the queues are getting filled up and they need some attention. We have those kinds of features turned on.

It is very scalable.

Our team is very well versed in MQ and they're always able to solve all the problems. In fact, last year we moved to iApps, and they were able to work with IBM. They were able to solve whatever roadblocks we had.

We have our own support team. Whenever we have some situation, we go to them. If they're unable to solve it, then they reach out to IBM.

I'm not aware of the pricing. That's something others deal with, but they do tell me that it is expensive. I don't know how much it is.

We have an ELA contract with IBM and everything is included. It's not like MQ has a different price, and different products have difference prices. Everything is done as part of one big contract

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.

The most valuable feature of IBM MQ is that it is robust. Its dependability and reliability are its most valuable features.

It has allowed us to take applications that would not normally be able to communicate, to be able to talk to each other.

I would like to see more integration into the security back end.

It's very stable.

It’s very scalable.

Technical support is OK. Quicker escalation would make it better.

This was the first solution of this type and it was the one that was the best fit.

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.

There are a lot of valuable features, such as high availability, and workload balancing. Those are the main two.

It allows different applications to communicate with each other.

I'd definitely like to see a more-stable high availability feature.

There is a feature that is in beta right now which synchronously writes messages to another server. That's something that we'd like to see, just for the stability.

It's been there for a while. We've had it for over 15 years.

Lately, it hasn't been that stable. We're using multi-instance queue managers and we're having a lot of issues with storage and that affects the availability of the queue manager.

Scalability is pretty good.

Support has been good so far. We submit a lot of PMRs and we usually get pretty good response.

I didn't make the decision to invest in this product. There was someone before me that decided.

The initial setup was straightforward.

Definitely read the manual before you do anything.

The asynchronous messaging and the assured delivery are the most valuable features because your data needs to make it through from one app to the other, and you don't want to lose it.

It's multi-platform, so we can go between mainframe, Unix, Windows, different platforms, and we can have applications send data using the messaging.

I really can't think of anything that needs improvement. For our company, it does what we need it to do.

The price is always an issue. Like anything you buy, you want the best deal. We are retailers, so we are always looking at costs. I am sure every company does. It would be nice if the message security and file transfer weren’t an extra cost. But I suppose if you want a deluxe of anything, you will need to pay.

We've had it for 20 years.

It's very stable.

It's very scalable.

We don't have to use support very often, but they are responsive.

I was not involved in the initial setup.

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.

The most valuable feature is primarily seeing the messages as soon as I log in; being able to see in real time that information.

It allows us to observe the status of our applications in real time; basically, very quick.

I would say it makes the organization more efficient, more reliable; and whenever there is an error, I guess resilient is the word I'd use.

It would be nice to see it outside of the z/OS environment, I think. If there was any other type of standalone client application, that's something that I would be interested in.

It's within z/OS, so it's green screen. It's not user friendly, but I can understand that. I've had the training to be able to look at it. It definitely could be improved, but within z/OS, you know you're not going to get any type of color graphical interface. I don't know what else you could do with it.

It's pretty stable. I don't work with the support of it much, so I'm a general user.

We do have issues from time to time, but because our environment is so complex, it's hard to say whether it's MQ's fault or the messages coming in and out of MQ. I deal a lot with performance and capacity. When there are capacity concerns, when there is too much taking up the system’s CPU, it's difficult to see where the issue lies, but I would say it's been solid for what I use it for.

As far as advice, I would just say familiarize yourself with MQ as much as you can. The Redbooks are great. The implementation of that software solution is something that anyone should be knowledgeable about.

We have a list of approved vendors so I guess the most important criteria for me when selecting a vendor is just a reliable relationship. That's all approved by a different team. We have a hand in maintaining some of the relationships but not much in the creation of them.