Transmission Queues

A transmission queue is where IBM MQ holds messages that are leaving this queue manager for another. Your application puts to a friendly remote queue name; the queue manager resolves routing and stores the message on a transmission queue (XMITQ) until a sender channel can move it across the network. That staging step is the heart of store-and-forward between sites: the link can fail, maintenance can run, and messages still wait safely on disk (when persistent) instead of being dropped. Beginners who understand transmission queues can read channel backlog at a glance, size disk correctly, and fix incidents where remote partners are fine but local XMITQ depth climbs without explanation.

Transmission Queue as QLOCAL with USAGE(XMITQ)

Technically, a transmission queue is a local queue. You create it with DEFINE QLOCAL like any other queue, but you set USAGE(XMITQ). That single attribute changes how the queue manager treats the queue: it is intended for inter-queue-manager traffic via channels, not for application MQGET workloads. Most shops name XMITQs after the partner queue manager, for example QM_LON.XMIT or SYSTEM.TRANSMIT.LON.TO.NYC, so operators know which channel and remote system each queue serves. DISPLAY QLOCAL shows USAGE(XMITQ); DISPLAY QSTATUS shows CURDEPTH and whether a sender channel is actively draining the queue.

How Messages Reach the XMITQ

1. Application (or bridge) issues MQPUT to a queue name—often a QREMOTE definition.
2. Queue manager resolves QREMOTE: RNAME (remote queue), RQMNAME (remote queue manager), XMITQ (local transmission queue).
3. Message is stored on the named XMITQ with appropriate persistence.
4. Channel initiator starts or runs the sender channel whose XMITQ attribute matches.
5. Channel sends messages to partner receiver; partner puts to target QLOCAL on remote QM.

Applications rarely put directly to the transmission queue name. Doing so bypasses QREMOTE indirection and can confuse routing if multiple remote targets shared one XMITQ incorrectly. Standard designs use one XMITQ per outbound channel path to a given partner queue manager (or per cluster path), keeping backlog attributable to one link.

Binding Sender Channels to XMITQ

DEFINE CHANNEL(...) CHLTYPE(SDR) includes XMITQ('QM_PARTNER.XMIT'). The sender channel and transmission queue form a pair: the channel reads only from its XMITQ. If you define two SDR channels to the same XMITQ without understanding advanced sharing, you can create unpredictable delivery order or contention—beginners should use one SDR per XMITQ per direction. CONNAME on the channel points to the partner listener; TRPTYPE(TCP) is typical. When you START CHANNEL, the channel moves to RUNNING and depth on the XMITQ should decrease if the partner accepts traffic.

Explainer: XMITQ vs QREMOTE vs Target QLOCAL

Think of three mailboxes in a journey. QREMOTE is the label on the envelope your app writes—it does not hold letters. XMITQ is the sorting bin at your local post office waiting for the truck. Target QLOCAL on the remote queue manager is the inbox at the destination city. The truck is the sender channel. If the truck never leaves, the sorting bin (XMITQ) fills up; your app may still succeed on put until MAXDEPTH blocks further puts.

Defining a Transmission Queue (MQSC)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
DEFINE QLOCAL('QM_HUB.XMIT') REPLACE +
  USAGE(XMITQ) +
  MAXDEPTH(500000) +
  MAXMSGL(4194304) +
  DEFPSIST(YES) +
  GET(ENABLED) PUT(ENABLED) +
  DESCR('Transmission to QM_HUB - Finance link')
DEFINE CHANNEL('TO.HUB') CHLTYPE(SDR) TRPTYPE(TCP) REPLACE +
  CONNAME('hub.example.com(1414)') +
  XMITQ('QM_HUB.XMIT')
DEFINE QREMOTE('ORDERS.TO.HUB') REPLACE +
  RNAME('ORDERS.IN') RQMNAME('QM_HUB') +
  XMITQ('QM_HUB.XMIT')
DISPLAY QLOCAL('QM_HUB.XMIT') USAGE CURDEPTH MAXDEPTH DEFPSIST
DISPLAY CHSTATUS('TO.HUB')

MAXDEPTH on an XMITQ is a capacity guard for worst-case outages. If the WAN is down for a weekend and producers keep putting, depth rises until MAXDEPTH; then MQPUT fails with queue full (reason 2053). Capacity planning multiplies expected message rate by outage duration by average message size, and adds headroom. DEFPSIST(YES) ensures persistent messages survive queue manager restart while waiting for the channel. GET(ENABLED) is required for the channel to read messages; some sites restrict application authority so only the channel initiator effectively gets from the XMITQ.

Persistence and Syncpoint on XMITQ

A persistent message put under syncpoint is logged before the put call completes successfully. On the XMITQ, that means a committed payment message remains even if the queue manager crashes before the channel sends it. After restart, the sender channel resumes from where the protocol allows—messages still on the XMITQ are forwarded when connectivity returns. Non-persistent messages on an XMITQ may be lost on abrupt failure; use them only when the business accepts loss for that traffic class. Mixing persistent and non-persistent on the same XMITQ is allowed but complicates operations monitoring because restart behavior differs by message.

Monitoring Transmission Queue Health

• DISPLAY QLOCAL(xmitq) CURDEPTH — sustained growth signals channel or network problems.
• DISPLAY CHSTATUS(channel) — states include RUNNING, STOPPING, RETRY, INACTIVE.
• Compare depth before and after START CHANNEL — successful recovery shows depth falling.
• Alert when CURDEPTH exceeds baseline for your time-of-day (batch windows may spike legitimately).
• Check disk space on the queue manager host—XMITQ backlog uses log and queue files.

Common Problems and Fixes

Channel in RETRY: verify partner listener, firewall, CONNAME host/port, TLS cipher match, and CHLAUTH rules. XMITQ depth grows while RETRY continues. Wrong XMITQ on QREMOTE: messages may sit on an unexpected queue or fail routing—DISPLAY QREMOTE ALL and compare XMITQ to channel definition. Channel STOPPED by operations: backlog is intentional during maintenance; communicate with producers if MAXDEPTH risk exists. Remote queue full: sender may succeed leaving local XMITQ but partner rejects; investigate remote MAXDEPTH and DLQ on partner. Sequence or protocol errors: may require RESET CHANNEL after fixing root cause—follow IBM guidance for your release.

Cluster Transmission Queues

In clusters, SYSTEM.CLUSTER.TRANSMIT.QUEUE and related cluster XMITQs carry metadata and application messages between cluster members. Cluster sender channels use cluster transmission paths similar to point-to-point XMITQs. Beginners learning point-to-point XMITQ first should recognize cluster traffic as the same staging idea at cluster scope—depth on cluster XMITQs during repository or workload issues is a common advanced operations topic covered further in cluster tutorials.

Transmission Queue vs Application Queue

Tutorial: Observe Store-and-Forward

In a lab with two queue managers, stop the sender channel, put ten persistent messages via QREMOTE, and DISPLAY QLOCAL(xmitq) CURDEPTH—it should show 10. Start the channel; depth should return to 0 when the partner receives all messages. Repeat with channel running to see depth stay near zero under healthy conditions.

Explain Like I'm Five: Transmission Queue

You mailed a package to a friend in another town. Your town's post office puts it in a room labeled “waiting for the highway truck” (transmission queue). If the highway is closed, packages pile up in that room. When the road opens, the truck takes everything to the other town's post office. You already dropped off your package—you do not wait at the highway.

Practice Exercises

Exercise 1

Draw QREMOTE, XMITQ, SDR channel, RCVR, and remote QLOCAL. Label RNAME, RQMNAME, and XMITQ on each object.

Exercise 2

XMITQ MAXDEPTH is 100000 and CURDEPTH is 99900. Channel RETRY for 6 hours. What should operations do before depth hits 100000?

Exercise 3

Why should two different remote queue managers not share one XMITQ in a beginner design?

Frequently Asked Questions

Test Your Knowledge