Asynchronous Messaging

Asynchronous messaging is one of the defining behaviors of IBM MQ. When an application puts a message, it does not wait for another program to read and process that message before continuing. The queue manager accepts the message, stores it on a queue if configured to do so, and returns control to the caller. A consumer—perhaps on z/OS batch overnight, perhaps a Linux microservice milliseconds later—gets the message when it is ready. This page explains synchronous versus asynchronous communication, fire-and-forget versus request/reply patterns, why asynchronous queues help during traffic peaks, how the Message Queue Interface (MQI) put works without waiting for consumers, and the classic MQ Series message types: request, reply, one-way (datagram), and report.

Synchronous vs Asynchronous Communication

In synchronous communication, the caller waits for the callee to finish before moving on. A browser waiting for an HTTP response, a COBOL program calling another module and blocking until return, or a database client holding a cursor open until a row is fetched—all are synchronous from the caller's point of view. If the downstream system is slow or down, the caller stalls. Timeouts and thread pools help, but the fundamental coupling remains: progress on one side depends on immediate cooperation from the other.

Asynchronous communication breaks that coupling in time. The sender hands work to middleware and proceeds. IBM MQ implements asynchrony through queues: the put operation completes when MQ has the message, not when processing finishes. The receiver may be idle, overloaded, or on another continent in another time zone. Beginners sometimes confuse "async" with "unreliable." MQ can be both asynchronous and reliable when messages are persistent and transactions are used correctly. Asynchrony describes timing; persistence and syncpoints describe durability.

Many enterprise flows mix both styles. A web API might respond synchronously to the user ("order accepted") while putting the real fulfillment work on MQ asynchronously. A CICS transaction might put a request message and syncpoint commit before replying to a terminal, knowing batch will process the queue later. Understanding where the synchronous boundary ends and the asynchronous pipeline begins is essential architecture work.

Fire-and-Forget vs Request/Reply

Fire-and-forget—also called one-way messaging—means the sender has no expectation of a reply message from MQ. Examples include audit events, telemetry, "order placed" notifications, and log shipping. The producer sets the message type to datagram (one-way), puts to a queue, and continues. If nobody ever consumes the queue, that is an operational problem, not a protocol error; the sender already succeeded when the put committed.

Request/reply is asynchronous too, even though the business conversation has two legs. The requester puts a request message with MsgType request, sets ReplyToQ (and often ReplyToQMgr), and assigns MessageId or CorrelId. The requester may then get from a reply queue, browse, or use a callback pattern. The responder gets the request, processes it, and puts a reply message with MsgType reply, copying correlation data so the requester can pair them. Neither put waits for the other program's internal logic—only the get on the reply queue blocks the requester if it chooses to wait there.

Request/reply over MQ differs from RPC. RPC usually implies a single blocking call stack. MQ request/reply implies two independent programs, two queues (or a dynamic reply queue), and explicit header discipline. Teams that skip correlation IDs or reuse reply queues without design often see crossed replies under load. Model queues and temporary dynamic queues are common for reply destinations in client applications.

Why Asynchronous Messaging Helps During Peaks

Retail flash sales, month-end interest calculation, and market-open trading bursts can produce far more events per second than downstream systems can process if every event must be handled inline. Synchronous chains amplify failure: one slow fraud engine slows every checkout. Asynchronous queues act as shock absorbers. Producers issue puts at peak rate; the queue depth rises; consumers drain at sustainable rate. Operations watch CURDEPTH and oldest-message age to add capacity or throttle upstream before disks or MAXDEPTH limits bite.

On the mainframe, online CICS might accept customer traffic continuously while batch settlement runs in a controlled window. Without MQ, you might reject transactions when batch is busy. With MQ, messages wait safely (persistent, transactional) until batch is ready. The peak is flattened over time—classic load leveling, covered in more detail on the decoupled systems page. Asynchronous messaging does not create infinite capacity: queues need depth limits, consumer scaling plans, and poison-message handling. It trades immediate back pressure for buffered work with visible metrics.

MQI Put Without Waiting for the Consumer

The Message Queue Interface put call—whether invoked from C, Java JMS, .NET, or COBOL on z/OS—returns when the queue manager completes the put according to your options. For a non-transactional persistent put, that means the message is on durable storage. For a syncpoint put, the message is visible to other units of work after commit, not before. In no case does the put wait for a get on the other side.

Put options (MQPMO) control behavior: syncpoint participation, new message ID, fail-if-quiescing, and more. The message descriptor (MQMD) carries format, persistence, priority, message type, reply-to fields, and correlation ID. Beginners should trace one put in a trace or log: note the reason code on return, then display the queue depth—depth increases even if no consumer is running. That experiment proves asynchrony at the API level.

Gets can be synchronous from the consumer's perspective: MQGET with wait blocks until a message arrives or timeout. That is the consumer choosing to wait, not the producer being blocked by consumer speed during put. Multiple consumers on one queue compete for messages; each message is typically consumed once in point-to-point queueing.

MQ Series Message Types

IBM MQ (from MQ Series onward) classifies messages using the MsgType field in the MQMD. The four primary types beginners encounter are datagram, request, reply, and report. Tools and sample programs display these names; constants in headers are MQMT_DATAGRAM, MQMT_REQUEST, MQMT_REPLY, and MQMT_REPORT.

Report messages are easy to overlook but important in operations. When applications or queue manager settings request confirmation on delivery (COD) or arrival (COA), MQ generates report messages that land on a reply or report queue. Expiration and dead-letter handling also surface as reports or redirected messages. Monitoring report queues catches stuck traffic without parsing every business queue.

Combining Async Patterns with Guaranteed Delivery

Asynchronous does not mean "fire and forget to disk." Critical flows combine async timing with persistent messages and transactional puts so work survives outages. A payment request might be MQMT_REQUEST, persistent, under syncpoint with a Db2 update in the same unit of work. The put still returns without waiting for the ledger consumer, but once commit succeeds, the message must survive a restart. Link to guaranteed delivery concepts: persistence, syncpoint, and dead-letter queues protect async pipelines when consumers fail or mis-parse messages.

Key Terms

• Asynchronous — Sender does not wait for receiver processing to complete.
• Fire-and-forget — One-way message; no reply expected.
• Request/reply — Two message types and correlation across queues.
• MQMD — Message Descriptor controlling headers on each message.
• MQPMO — Put Message Options controlling put behavior.
• CorrelId — Field linking replies (or reports) to original messages.
• ReplyToQ — Queue name where replies should be sent.

Tutorial: Put a Datagram and a Request with Java

The following simplified Java fragment shows two puts on the same queue manager: a one-way datagram and a request with reply-to fields. This is illustrative—adjust queue names and connection for your lab. Notice both calls return after producer.send (JMS) or equivalent MQI put, not after any consumer runs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
import jakarta.jms.*;
import com.ibm.msg.client.jms.JmsConnectionFactory;
import com.ibm.msg.client.jms.JmsFactoryFactory;
import com.ibm.msg.client.wmq.common.CommonConstants;
 
// Connection factory configured for queue manager QM1 (lab settings)
JmsFactoryFactory ff = JmsFactoryFactory.getInstance(JmsConstants.WMQ_PROVIDER);
JmsConnectionFactory cf = ff.createConnectionFactory();
cf.setStringProperty(CommonConstants.WMQ_HOST_NAME, "localhost");
cf.setIntProperty(CommonConstants.WMQ_PORT, 1414);
cf.setStringProperty(CommonConstants.WMQ_QUEUE_MANAGER, "QM1");
cf.setStringProperty(CommonConstants.WMQ_CHANNEL, "DEV.APP.SVRCONN");
 
try (JMSContext context = cf.createContext()) {
  Destination ordersQ = context.createQueue("queue:///ORDERS.IN");
  Destination replyQ = context.createQueue("queue:///APP.REPLY");
 
  // Fire-and-forget (one-way) — no reply expected
  JMSProducer producer = context.createProducer();
  TextMessage event = context.createTextMessage("ORDER-PLACED-88421");
  event.setJMSDeliveryMode(DeliveryMode.PERSISTENT);
  producer.send(ordersQ, event);
 
  // Request — business partner should reply to APP.REPLY
  TextMessage request = context.createTextMessage("BALANCE-INQUIRY-ACC123");
  request.setJMSReplyTo(replyQ);
  request.setJMSCorrelationIDAsBytes(new byte[] { 1, 2, 3, 4 });
  request.setJMSDeliveryMode(DeliveryMode.PERSISTENT);
  producer.send(ordersQ, request);
  // Returns here — consumer may not have run yet
}

In native MQI C, you would set md.MsgType = MQMT_DATAGRAM for one-way and MQMT_REQUEST for request, copying ReplyToQ and ReplyToQMgr in the MQMD before MQPUT. JMS maps many of these fields to standard properties. Use DISPLAY QSTATUS or MQ Explorer to see depth increase after running the producer while the consumer is stopped.

Explain Like I'm Five: Asynchronous Messaging

When you drop a letter in the mailbox, you do not stand at the mailbox until the mail carrier delivers it and your friend reads it. You drop it and go play. Your friend reads it later. That is asynchronous. Fire-and-forget is a letter with no "please write back" inside. Request/reply is a letter that says "please answer on this postcard"—you still do not wait at the mailbox; you check your own mailbox later for the answer. IBM MQ is the mailbox system for programs.

Practice Exercises

These exercises reinforce sync vs async and message types. Use a lab queue manager where possible.

Exercise 1: Blocked Caller Diagram

Draw a synchronous chain: Web → API → Mainframe program. Mark where the user waits. Redraw with Web → API → MQ put → immediate HTTP 202 response, and Mainframe getting from a queue later. List three failure modes that hurt only the synchronous drawing.

Exercise 2: Classify Message Types

For each scenario, choose datagram, request, reply, or report: (a) nightly sales total to data warehouse, (b) balance inquiry with answer to caller, (c) COA notification to monitoring queue, (d) fraud service response to checkout. Which fields must (b) set on the request?

Exercise 3: Peak Absorption Math

Producers put 5,000 messages per minute; consumers process 3,000 per minute. Starting from empty, how many messages are on the queue after 10 minutes? What happens at MAXDEPTH if this continues? Name two operational responses.

Exercise 4: Stop the Consumer Test

Run a producer put while no consumer is active. Record put return code and queue CURDEPTH. Start the consumer and record how depth changes. Write two sentences explaining why the put did not block on consumer processing.

Test Your Knowledge