IBM MQ Reviews

For me, the most important features are its interfaces with RACF and how we can set up the security to allow and disallow who can get to it, who can use it; and then what MQ gets to do on the mainframe and what it does not get to do, basically.

Our organization uses it a lot to interface applications that are outside the mainframe with applications on the mainframe, or to CICS, items like that.

It helps meet that threshold between what do the application people want to do – because they want to do everything now on GUIs and outside applications – and be able to have the security of the data living on the mainframe and how they get to it. It's the go-between between those two worlds.

There are probably dozens of ways we are using MQ to better connect across cloud, mobile, and devices, but it's mostly the fact that they are setting up stuff and then they use the MQ as the go-between between the distributed world and the mainframe. That's mostly what it's being used for.

Sometimes the applications people don't really understand MQ. For example, we had somebody set up a call through MQ and they ended up making dozens and dozens of calls when they only really only needed to do one. They don't understand how MQ really works, and how it pulls the data and then distributes it back to them, etc.

I think the application people understand that MQ can do it, but they don't really understand the mechanics behind it. They need to be better educated; how to use MQ, get the data that they need, and not cause conflicts.

At the level of the application development people, there needs to be more communication, more information that they have so they understand, because, in essence, what you're using MQ to do is to go to the mainframe and get things. They're so used to their Windows environment, and they don't really understand how MQ grabs that data, and what the mechanics are behind the scenes. And I think that the applications people need to better understand it. Or else something put into MQ so that it is more obvious to them. They don't know what to ask for. They just know, "We're going to go against this data" and they don't know the difference between the different types of security they can set up. The different access and the different classes. We use different classes in RACF; they have no clue what a class is.

There either needs to be better education on there, and or some tools built into MQ that helps them know what to ask for.

I have a very high impression of the stability of MQ; we haven't had any problems with it. MQ has been very stable. I think we've had it go down once since I've been here, but it was due to something somebody screwed up somewhere else, not MQ's fault.

So far, we haven't had any scalability problems either, but we're only about a year and a half into this.

I have not had to use technical support. I've had to use IBM technical support because of some issues, but I never had to talk to the MQ people. We have an MQ rep on site and he handles that stuff.

I was involved in the decision process of how we were going to use RACF, and what they were going to set up to do their calls, but they decided they were going to use MQ. I was actually called in as a RACF specialist to help get that interface going.

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.

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.

We use MQ for our transactional layer in conjunction with IBM Bus. We use MQ for our web application servers and many of our processes.

We like IBM MQ for our synchronous communications and transactional applications that require a lot of CPS.

We've been using IBM MQ for about 10 years, but we are currently in the process of migrating our IBM workload to the integration layer in AWS.

IBM MQ is highly stable.

The portion of IBM MQ that we have in the cloud is scalable, but the on-premise part isn't so much. However, we are working on sending our loads to cloud.

IBM support is good. I would rate it nine out of 10.

Positive

It's straightforward to set up IBM MQ because we can use it in lightweight modules, like containers, for example. It's not always easy for applications to connect to IBM MQ, but I think it's fine in general.

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