Remote Queues

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.

DEFINE QREMOTE: The Three Core Attributes

QREMOTE routing attributes
AttributeMeaningExample
RNAMETarget queue name on remote QMORDERS.IN
RQMNAMERemote queue manager nameQM_HUB
XMITQLocal transmission queue for first hopQM_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.

shell
1
2
3
4
5
6
7
8
9
10
11
12
DEFINE 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

End-to-End Remote Put Flow

  1. Application MQPUT to QREMOTE ORDERS.TO.HUB on QM_SPOKE.
  2. QM_SPOKE resolves QREMOTE; message stored on QM_HUB.XMIT (XMITQ).
  3. Channel initiator runs SDR TO.HUB; reads messages from XMITQ.
  4. Partner QM_HUB RCVR channel receives; puts to RNAME ORDERS.IN on QM_HUB.
  5. Remote application MQGET from ORDERS.IN on QM_HUB.

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.

Remote Queue vs Alias vs Cluster Queue

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.

Single-Hop and Multi-Hop Routing

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.

Common Reason Codes on Remote Puts

  • 2053 queue full — XMITQ or target MAXDEPTH reached.
  • 2085 unknown object — QREMOTE name typo or not defined.
  • 2035 not authorized — put authority on QREMOTE or target resolution path.
  • Messages on DLQ — RNAME does not exist on partner, expiry, or size limits.

Reply Paths and QREMOTE

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.

Altering Remote Queues in Production

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.

Explain Like I'm Five: Remote Queue

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

Practice Exercises

Exercise 1

Write DEFINE QREMOTE for PAY.TO.CENTRAL targeting PAY.IN on QM_CENTRAL via XMITQ QM_CENTRAL.XMIT.

Exercise 2

Put succeeds; XMITQ depth zero; remote queue empty. List four places to investigate.

Exercise 3

Why might RNAME differ from the QREMOTE object name? Give a business reason.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. QREMOTE attribute for remote queue name is:

  • RNAME
  • CONNAME
  • HOST
  • PORT

2. RQMNAME is:

  • Remote queue manager name
  • Reply queue
  • Reason code
  • Router IP

3. Messages wait on local QM at:

  • XMITQ
  • QREMOTE object
  • Topic
  • Listener

4. Applications typically put to:

  • QREMOTE name
  • RCVR channel
  • Initiation queue
  • Process object
Published
Read time16 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation