Point-to-Point Messaging

Point-to-point messaging is the foundational IBM MQ pattern: applications exchange work by putting messages on a queue and another application getting them when ready. Each message is intended for one consumer process among those listening on the queue—unlike publish/subscribe, where many subscribers each receive a copy. Beginners encounter point-to-point in payment files, order fulfillment, job dispatch, and request workloads routed to a named service queue. This page covers queue semantics, put and get lifecycle, competing consumers, workload balancing, relationship to JMS Queue destinations, comparison with topics, and hands-on MQSC plus sample utility flow.

Queues as Point-to-Point Destinations

A local queue (QLocal) belongs to one queue manager and holds messages until consumers get them. The producer does not address a specific consumer by name; it addresses the queue. Any authorized application with get authority can compete for messages. This indirection is what decouples sender and receiver in time and technology—COBOL batch can put, Java microservice can get, without direct network calls between programs.

Alias queues (QAlias) let applications use a stable name while administrators retarget the underlying base queue. Remote queues (QRemote) forward puts to another queue manager, still appearing as point-to-point from the application's perspective. Model queues support dynamic queue creation for temporary reply queues in request/reply patterns covered in later tutorials.

Put and Get Lifecycle

MQPUT (or JMS send) adds a message at the tail of the queue (ordering is FIFO for a single open consumer sequence). The message descriptor (MD) carries format, persistence, priority, expiry, message ID, and correlation ID. MQGET (or JMS receive) removes the message when using default destructive get and successful commit. Syncpoint wraps put/get in transactions: backout returns the message to the queue or removes an uncommitted put depending on phase.

A successful put does not mean the consumer processed it—only that the queue manager accepted storage. End-to-end completion requires the consumer to get, process, and commit. Monitoring queue depth shows backlog; rising depth signals slow consumers or downstream outage.

Competing Consumers and Scale-Out

When order processing cannot keep up, teams run multiple instances of the consumer program, each issuing MQGET on the same queue. The queue manager assigns each message to one instance. Throughput scales roughly with instance count until CPU, disk I/O, or lock contention limits gains. Messages for the same customer may process out of order across instances unless you use message grouping, separate queues per partition key, or single-threaded consumers for that key.

On z/OS, multiple CICS regions or batch tasks can compete on a shared queue in a queue sharing group. Distributed Kubernetes pods do the same with the MQ client. Design idempotent handlers: redelivery after failure can cause duplicate processing unless business keys detect duplicates.

Point-to-Point vs Publish/Subscribe

Use a queue when exactly one application should handle each unit of work—pay this invoice, transform this file, update this account. Use a topic when many subscribers should react to the same event—order placed notifications to warehouse, email, and analytics. Mixing patterns on the same business object without clear rules causes duplicate processing or missed handlers. The event-driven systems tutorial expands pub/sub; this page anchors the queue side.

JMS Queue Destination

In JMS, javax.jakarta.jms.Queue maps to an IBM MQ queue. Spring JmsTemplate convertAndSend targets a queue name. Session.createConsumer(queue) competes with other consumers in the same JVM or cluster. Durable subscription concepts apply to topics, not classic point-to-point queues. Beginners learning JMS should still understand MQI get options because operations tooling and mainframe peers speak in queue manager terms.

Reliability in Point-to-Point

Persistent messages survive restarts. Non-persistent messages are faster but may be lost on failure. Consumers should use syncpoint or CLIENT_ACKNOWLEDGE when processing must not lose messages after partial side effects. Dead-letter queues capture messages that cannot be delivered or exceed backout thresholds. Point-to-point does not automatically imply persistence—application and queue defaults decide.

Tutorial: Create a Queue and Test Put/Get

Run the following on a lab queue manager, then use sample programs amqsput and amqsget (or your installation path) to verify flow.

1
2
3
4
5
6
7
8
DEFINE QLOCAL('WORK.REQUESTS') REPLACE +
  DESCR('Point-to-point work queue') +
  MAXDEPTH(100000) MAXMSGL(4194304) +
  DEFPSIST(YES)
ALTER QLOCAL('WORK.REQUESTS') GET(ENABLED) PUT(ENABLED)
* Put:  amqsput WORK.REQUESTS 
* Get:  amqsget WORK.REQUESTS 
DISPLAY QLOCAL('WORK.REQUESTS') CURDEPTH

CURDEPTH shows how many messages wait. After get, depth should decrease. Run two get processes simultaneously with multiple messages to observe competing consumers splitting work.

Explain Like I'm Five: Point-to-Point

There is one lunch line tray (the queue). Each sandwich (message) is for one kid to take. When you put your sandwich on the tray, the next hungry kid at the line takes exactly one sandwich—not every kid gets the same sandwich. If three kids help at the line, they share the work: each sandwich still goes to only one kid. That is point-to-point. A loudspeaker announcement (topic) is different—everyone hears the same announcement.

Practice Exercises

Exercise 1: Queue vs Topic

Classify: send one fraud check job, notify five systems of login failure, process payroll row once. Choose queue or topic for each.

Exercise 2: Competing Consumers

Ten messages arrive; three consumer instances run. Describe possible distribution. Why might message 7 be processed before message 5?

Exercise 3: Depth Alert

WORK.REQUESTS depth grows for two hours. List four possible causes and one monitoring action per cause.

Frequently Asked Questions

Test Your Knowledge