What is your primary use case for IBM MQ?

Our primary use case for IBM MQ is as an enterprise messaging between applications. So when applications need to transmit data from one to another, they use a messaging broker, the IBM MQ, RabbitMQ and ActiveMQ.

I usually recommend IBM MQ for financial, government, and large enterprise companies. It is beneficial for handling high volumes of messages.

I worked as an employee for a bank where we recommended IBM MQ, and we used it. It's for real-time messaging, an exchange between applications. On the IBM side, we use Message Queue, all the Message Queue products from IBM. For six years, we used it for a bank, an international bank, and we integrated all the applications synchronously using Message Queue.

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

MQ is the middleware, which takees the files from an upstream system to a downstream system or the downstream system to an upstream system.

I was part of a small team that tested and used the IBM infrastructure in a QA environment. My activities included configuring and creating test environments and finding solutions to monitor the infrastructure.

During my tenure, there was a transition to using IBM MQ due to its compatibility with IBM mainframe systems, which was beneficial for projects involving message queuing systems, particularly for clients like Volkswagen. I've handled various tasks related to IBM MQ, including testing connections, configuring and installing the system, setting up high availability and disaster recovery solutions, and providing administration support. Additionally, I've conducted training courses on IBM MQ.

We mainly use IBM MQ when creating the integration buses for different customers. For example, for creating external API for the internal systems, we use IBM MQ quite extensively.

I work for a company that has an ESB backbone built on the MQ. It's the enterprise bus for the whole company. I was a trainer for IBM products long ago, but I moved to different companies and now I'm a senior developer supporting MQ and IBM.

I've mainly seen IBM MQ used where that technology is specified as the interface for some B2B information sharing system, that only IBM MQ can be used to connect to that information system. IBM MQ is an example of the general class of enterprise integration technologies providing capabilities that go by names like message-oriented-middle-ware (MoM), Message Queue, and Enterprise Service Bus (ESB). IBM MQ is a proprietary product implementing a proprietary message protocol. It does offer limited support for MQ-related standards in the form of JMS. Interoperability with other technologies is primarily implemented through other products implementing an adapter or bridge to IBM MQ. 

Our use case for MQ is for unlimited processing. I'm a solutions architect.

We use to connect the core banking system to several other systems in our environment. We are working on an IBM server with multiple clients sending XML messages through the IBM environment using MQ. The end users are working on front-end services that are communicating with the servers. We are installing MQ on the backend system to act as middleware. Mainly the users are coming from somewhere else.

We use it as our enterprise messaging bus, not from the transformation use cases. It's mainly from the messaging use cases only. We use it for connecting to mainframes predominantly.

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

IBM MQ is the standard for financial industry messaging. As far as I know, it is the best in class.

The solution has many use cases from the middleware like IBM WebSphere, Message Broker, and payments.

I use IBM HQ to communicate with subsystems within our plants e.g. the supply chain.

We use this solution locally and work in port authority where we deal with multiple parties like warehousing, containers, customs and Egyptian customs. Therefore we can communicate with each other and achieve middleware goals. We use the MQ Server and MQ client in each party and control it with the MQ server in port authority.

We use the solution when connecting with the external system to process messages in a queue-based flow. When the solution receives a message, the flow is triggered to cycle through routing, mapping, and logic to create a pipe delimited, XML, or other formats that send to the end system. We created the queue-based flow to receive messages and connect them to end systems using a pop-up concept to classify messages by subscription topics.

Primarily, I use IBM MQ for microservices, modeling, and communications.

We are using version 9.2. The solution is deployed on the cloud and Azure is the provider. There are four people in my company who are working with IBM MQ.

I am an integration developer at a bank, and we use IBM tools to develop our solutions. We use IIB (version 10), IBM App Connect (version 11), IBM MQ (version 9.1), IBM web servers, and IBM ODM. We use IBM MQ for exchanging messages between applications.

We are a solution provider and this is one of the products that we implement for our clients. The primary use case for IBM MQ is handling the transportation of messages between applications. This is being used in a mainframe environment.

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.

Our use cases for IBM MQ involve share markets. In this organization, we are not using many of the features because we have a very small infrastructure. In my previous organizations, I used many of the components including AMS. However, here, we are just using it as a messaging solution and not any of the other components.

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

Mainly we are using MQ to pass the orders in the format of messages. We use MQ mainly for all the asynchronous messages that we pass.

We're a service provider. My company provides services to different clients that include financial institutions in the banking sector. IBM MQ is used for queue messaging. I have to install and configure, the MQ features of listener channels, remote queues, and some transmit queues. We enable these as per customer requirements.

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.

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

I'm a technical specialist and we are customers of IBM.

IBM MQ is one of the biggest message exchanges in our company. We are in the process of migration to a cloud base environment because in some projects we are using RabbitMQ and Amazon SQS. However, IBM MQ is a big part of our technology ecosystem.

We have two different use cases for this solution. We use it for the interactive interconnectivity between clients into the cloud and applications communicating within our enterprise software.

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

The solution is primarily used for business transactions. It's used for financial transactions as well. Those are the two main use cases. We exchange information with our in-house applications before we supply information to our customers and so on.

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

We are using the solution for taking messages off the mainframe and distributing them down to a large, high-performance computing environment supporting over 4,000 servers.

The primary use case of this solution is for the general merchandising and retail market.

We are all using the file transfer or MQ FTP feature. We are also it for distributed queuing and clustering.

We use it for application-to-application integration.

IBM WebSphere MQ is deployed on a Windows machine, as well as almost all of our infrastructure. Windows services read and write to the MQ server - this is the way that we interact with it. All the messages that we put on the queue are also stored in an SQL Databases. A Windows service reads that message from the SQL Database storage and puts it on a queue on a certain channel; these Windows services are running indefinitely, on a loop so any message is read instantly.

It's the EAI for connecting all our services like transport systems, replenishment systems, and order entry systems to our supply chain warehouse systems.

We are currently working on the use case. I work as an IBM system admin and part of MQ is hosted on the IBM server. We have a lot of other servers and appliances for IBM MQ that costs us a lot of money so we are currently looking for less expensive alternatives. Kafka is one of the choices on the table. We are looking to migrate to services on Google which is why Kafka was proposed for us to implement. We use it to integrate the backend and front end solutions and applications.

Our use cases include ATM transactions where a customer, for example, inquires about balances. Transactions go from an ATM at a branch, using a Java application to take the information, and it connects into our mainframe, gets the balances, and goes back. We also use it for when customers go online using the internet itself for things like pre-approved home loans. We take the customers' information from the front-end and pop it into MQ to look up the customer's data in the bank itself — all of the databases — and then come back to the customer. It is also used in our mobile banking. MQ is connected to SAP in the background. MQ is in between, passing information to SAP and SAP will give the reply back on the mobile banking app, like when a customer asks for a one-time password.

We use it for data integration.

Our primary use case for pushing data as a queuing mechanism for all the applications to send out messages. We use it as a pipeline. We also use it to publish data and for the application to extract it all.

It's predominantly for message queuing, to assure delivery. Our team manages messaging aspects with this product, among others.

We develop applications for 20 companies in the insurance industry. We have about 20 different product systems that use the same MQ layout. We are also using it for testing and educational purposes. Our customer base is in the closed market of Switzerland and Liechtenstein. We are currently switching versions from 8.0.0.6 to 9.1.

In our company, it's the main hub for our whole CRM solution. MQ manages things through the Broker.

We use it to send a notification to our customers.

We use it for all our integration cases, including the integration of core applications within our company and external solutions from our partners. We use IBM MQ and IBM Integration Bus, App Connect.

Our primary use case is for messaging monitoring.

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.

For 90 percent of our applications, we are using IBM MQ for a point-to-point setup, from one application to another application. It is like a passage between them. For the other 10 percent of our applications, we are using topic subscriptions. It's deployed on-premises. We have tried it on Docker Containers as well, where we have an instance. We haven't done a cluster setup using Docker and Kubernetes.

We use it for file transfer and batch processing. We upload electronic documents to the Chilean government. We use version M2002 Model B and our clients use version 7.5.

All our applications run around MQ. We run a backend system working with a mainframe and we distribute records via MQ. We are using it daily.

We are mainly using it for communication, for connecting to multiple systems. Applications are putting their messages on MQ and, from MQ, we are reading them using IBM Integration Bus. We then process them and send back the response.

We use it for message transfer, mostly for a queue of the messages. Sometimes, we also consider using the topic space solution. But it is mostly for transferring messages between two applications. The applications are located in a different country, so it is also used for communication of MQ to MQ.

We mainly use it for exchanging messages between application servers, back applications (e.g., databases), etc.

We are a bank whose core banking system is not so advanced. It is still running on an AS/400 system. Credit Card system is are deployed on IBM mainframes. About 70 to 80 percent of the bank's core systems rely on IBM AS/400 and mainframes. The enterprise service bus is used in conjunction with MQ to break synchronous web service /TCP calls into asynchronous MQ calls and expose them a web services-based or API-based service for both internal and external customers. As part of enterprise architecture principles, we have enforced all connectivity to be service/ interface based by using ESB, MFT or API. Minimize the point to point connectivity. We are using dedicated IBM power/pure-app servers to run IBM Integration Bus, IBM MQ, and WebSphere Application Server. These are the three components being used for the bank's enterprise service bus.

We have a core banking application. If any system or application wants to talk to the core banking application, the request and the response will go through the MQ servers. The requests and responses are in the form of XML. We have a VMware environment with Windows and Linux.

We have a diverse distributed environment that includes Z/OS, Microsoft Windows, Solaris, Linux, and zLinux. We use multiple programming languages and different databases.

IBM MQ is used heavily in all of the companies I have worked for, mostly in the financial industry. It is easy to set up and has good instrumentation.

Originally, we were doing this in-house, and it was a huge effort. Now, with IBM MQ, we have increased our performance, and it performs really well. The queuing system, given the size of information, is helpful.

I have installed a cluster MQ in a bank using HACMP for the failover solution on AIX. I have also configured the product accordingly.

We use IBM MQ as a reliable way of integrating different applications. Our transaction service operates using IBM MQ for organizing the asynchronous interaction between different applications and the core banking system. It is easy to organize parallel reading and writing, and you can easily link two IBM MQ servers using the remote queue feature. We also use IBM MQ in web services which are developed using IBM Integration Bus. MQ helps us scale web services and organize parallel execution.

We use IBM MQ for message transmission between our customers, and their agents or global message service providers, such as SITA or ARINC, for tier one critical applications.

Enterprise messaging with international clustering in 120 data centers in 82 countries around the world.

We use queue managers/concentrators for message flow going upstream and downstream on applications with enterprise licenses.