A remote queue definition lets applications send messages to another queue manager using a single MQPUT on a name defined locally. IBM MQ looks up the QREMOTE object, reads RNAME (where the message should ultimately arrive), RQMNAME (which queue manager owns that queue), and XMITQ (which local transmission queue stages the message for the channel). The application does not open TCP sockets to the remote host—the queue manager and channels handle forwarding. Hub-and-spoke integration, mainframe-to-cloud bridges, and partner B2B layouts depend on remote queues. This page teaches DEFINE QREMOTE, each attribute in depth, how remote puts interact with sender and receiver channels, multi-hop cautions, and troubleshooting when puts succeed locally but never arrive remotely.
| Attribute | Meaning | Example |
|---|---|---|
| RNAME | Target queue name on remote QM | ORDERS.IN |
| RQMNAME | Remote queue manager name | QM_HUB |
| XMITQ | Local transmission queue for first hop | QM_HUB.XMIT |
The QREMOTE object name (for example ORDERS.TO.HUB) is arbitrary but should follow your naming standard. RNAME must match a QLOCAL (or resolved name) on QM_HUB. RQMNAME must match the partner queue manager name exactly as defined on the remote system—typos cause messages to sit on XMITQ or dead-letter. XMITQ must be a QLOCAL with USAGE(XMITQ) and must match the sender channel XMITQ attribute.
123456789101112DEFINE QREMOTE('ORDERS.TO.HUB') REPLACE + RNAME('ORDERS.IN') + RQMNAME('QM_HUB') + XMITQ('QM_HUB.XMIT') + DESCR('Spoke to hub orders') DEFINE QLOCAL('QM_HUB.XMIT') REPLACE USAGE(XMITQ) DEFPSIST(YES) DEFINE CHANNEL('TO.HUB') CHLTYPE(SDR) TRPTYPE(TCP) REPLACE + CONNAME('hub.example.com(1414)') XMITQ('QM_HUB.XMIT') * On QM_HUB partner side: * DEFINE QLOCAL('ORDERS.IN') ... * DEFINE CHANNEL('FROM.SPOKE') CHLTYPE(RCVR) ... DISPLAY QREMOTE('ORDERS.TO.HUB') RNAME RQMNAME XMITQ
Syncpoint behavior: commit on spoke before message is transmissible; channel protocol acknowledges delivery to partner per persistent rules. Fire-and-forget non-persistent puts may be lost on crash—architects choose persistence per message and queue defaults.
QREMOTE is explicit routing to a known RQMNAME—best for point-to-point spokes. QALIAS indirection can point at a QREMOTE for naming flexibility. Cluster queues publish a queue to a cluster name; the queue manager picks a destination using repository data—different object model, similar business goal of “put here, deliver there.” Beginners master QREMOTE first; clusters layer on top.
Standard QREMOTE design is one hop: spoke to hub. Multi-hop (spoke to relay to final) requires each queue manager in the path to have correct QREMOTE, XMITQ, and channel definitions—or use queue manager aliases and advanced routing. Misconfigured multi-hop shows messages stuck on intermediate XMITQs. Document every hop in integration diagrams; ALTER QREMOTE on one hop without updating partners breaks the chain.
Request/reply across queue managers requires reply paths in the opposite direction: ReplyToQ and ReplyToQMgr in the message descriptor, plus QREMOTE or channels from hub back to spoke. Asymmetric firewalls often allow outbound requests but block replies—test both directions in lower environments. Remote queue tutorials pair with reply-to queues and correlation ID pages for full patterns.
ALTER QREMOTE RNAME, RQMNAME, or XMITQ changes routing for new puts immediately in most cases. In-flight messages on old XMITQ paths may still follow previous channel bindings until drained. Coordinate changes with channel restarts and depth monitoring. Use QALIAS in front of QREMOTE if applications cannot change names but operations need flexible TARGET-style cutovers at the remote definition layer.
You write a letter and drop it in a box labeled “send to Grandma’s house in Boston” (remote queue). Your local post office (queue manager) does not keep it in that labeled box—it moves it to the truck room (transmission queue) and drives it to Boston’s post office (remote queue manager), where it goes to Grandma’s mailbox (RNAME).
Write DEFINE QREMOTE for PAY.TO.CENTRAL targeting PAY.IN on QM_CENTRAL via XMITQ QM_CENTRAL.XMIT.
Put succeeds; XMITQ depth zero; remote queue empty. List four places to investigate.
Why might RNAME differ from the QREMOTE object name? Give a business reason.
1. QREMOTE attribute for remote queue name is:
2. RQMNAME is:
3. Messages wait on local QM at:
4. Applications typically put to: