I use MQ MFT for asynchronous communication – file and message transfers. I also frequently use IBM MQ for its queuing mechanisms and queue management.

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

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

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

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.

There were some long-running processes where it was timing out. We got the request from this source application, and we put the data into IBM MQ. Then, we read the data from IBM MQ before doing the rest of the processing. Especially for real-time processes, we have just decoupled it into two different ways to ensure there is no time-out.

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.

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

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

IBM MQ is used for message queuing. IBM MQ is used if applications exchange messages and need a queue in between to hold them.

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

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

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

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.

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

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.

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.

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. 

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.

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 have various strips statements, and we use IBM MQ to pass those strips statements to different systems within our organization.

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 just switched versions from 8.0.0.6 to 9.1.

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 are all using the file transfer or MQ FTP feature. We are also it for distributed queuing and clustering.

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 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 use MQ for guaranteed delivery and once only delivery of important business to business transactions.

We use persistence messaging to ensure messages are not lost in case machine is restarted.

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

We use it for application-to-application integration.

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

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.

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

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.

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

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

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.

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.

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

It's predominantly for message queuing, to assure delivery.

Our team manages messaging aspects with this product, among others.

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.

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. 

Our primary use case is for messaging monitoring. 

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. 

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.

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.

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

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

We use it for data integration.

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.

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 have a diverse distributed environment that includes Z/OS, Microsoft Windows, Solaris, Linux, and zLinux. We use multiple programming languages and different databases.

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.

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 use it to send a notification to our customers.

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

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.

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

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

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