Requester Channels

The requester channel (CHLTYPE RQSTR) is the outbound half of the requester/server message-channel pair in IBM MQ. While sender channels dial receiver channels in the classic store-and-forward model, requester channels dial server channels when your network design forbids the opposite direction. Branch offices behind strict firewalls often cannot open listener ports for a central data-center queue manager to call in, but they can initiate TCP sessions to a well-known hub address. RQSTR carries that initiation: it reads messages from a transmission queue, connects to CONNAME on the partner, and hands them to the SVR instance on the hub. Beginners confuse RQSTR with request/reply messaging patterns or with SVRCONN client channels—this tutorial keeps the distinction clear, walks through DEFINE and START, explains XMITQ placement, and covers monitoring and failure modes you will see in production.

Why Requester Channels Exist

Distributed MQ assumes queue managers cooperate across TCP. The simplest cooperation is SDR on the source and RCVR on the target. Security teams sometimes reject that layout because RCVR implies inbound connections to the queue manager that owns business-critical queues. Requester/server flips who dials: the branch with the transmission queue runs RQSTR and connects out; the hub runs SVR and listens. Messages still move according to routing and XMITQ design—the change is who opens the socket, not whether MQ is asynchronous. Document your integration with arrows showing permitted firewall flows; auditors care about direction as much as port numbers.

RQSTR vs SDR (outbound initiator comparison)
AspectRQSTRSDR
Partner CHLTYPESVRRCVR
Typical siteBranch / DMZ client QMSource with XMITQ
CONNAMERequired (hub address)Required (target address)
XMITQOn QM that forwards messagesOn QM that forwards messages
Main driverFirewall policyStandard point-to-point

Defining a Requester Channel

A requester definition mirrors a sender in several attributes: TRPTYPE(TCP), CONNAME, XMITQ, MCAUSER, heartbeat, batching, and retry timers. The critical difference is CHLTYPE(RQSTR) and the partner type SVR with the same channel name string on both queue managers.

shell
1
2
3
4
5
6
7
8
9
* Branch queue manager — initiates to hub DEFINE QLOCAL('XMIT.TO.HUB') USAGE(XMITQ) DEFINE CHANNEL('BRANCH.TO.HUB') CHLTYPE(RQSTR) TRPTYPE(TCP) + CONNAME('hub.mq.corp(1414)') XMITQ('XMIT.TO.HUB') + MCAUSER('mqbranch') HBINT(300) SHORTRTY(10) SHORTTMR(60) * Hub queue manager — partner (see server channels tutorial) DEFINE CHANNEL('BRANCH.TO.HUB') CHLTYPE(SVR) TRPTYPE(TCP) + MCAUSER('mqhub') HBINT(300) START CHANNEL('BRANCH.TO.HUB')

CONNAME('hub.mq.corp(1414)') tells the branch queue manager to resolve host hub.mq.corp and TCP port 1414. That port must match a LISTENER on the hub. If DNS fails or the port is closed, DISPLAY CHSTATUS shows RETRY and the XMITQ depth climbs. MCAUSER on RQSTR affects the identity used during protocol phases on the branch side; the hub SVR MCAUSER affects how inbound messages are authorized when they become local puts—coordinate both with queue authority tables.

XMITQ and Message Direction

The transmission queue named in XMITQ holds messages the queue manager will forward to the partner. For branch-to-hub traffic, branch routing (remote queue definitions or alias queues) targets that XMITQ. When depth becomes non-zero, the queue manager may auto-start RQSTR or wait for an operator START CHANNEL depending on DISCINT and trigger-related settings. Misconfigured routing that puts messages on the wrong XMITQ looks like “MQ is broken” when only the channel name in the route is wrong. Trace one test message with DISPLAY QLOCAL CURDEPTH before and after a successful run.

Explainer: You Call the Store, Not the Other Way Around

Imagine you need to deliver packages to a central warehouse, but the warehouse cannot send trucks to your street. A requester channel is your truck leaving your building and driving to their loading dock (SVR). You still load the truck from your local staging area (XMITQ). The warehouse does not drive to you—that is the sender/receiver pattern when RCVR listens at your site.

Starting, States, and Retries

After START CHANNEL, RQSTR moves through BINDING to RUNNING when the hub accepts the session. If the hub listener is down, certificate validation fails, or CHLAUTH blocks the branch IP, status becomes RETRY. SHORTRTY counts quick attempts; LONGRTY and LONGTMR govern extended backoff—same family of attributes as SDR. Sequence numbers on the channel instance protect against duplicate delivery after failures; never RESET CHANNEL casually without partner coordination. See the channel states and sequence number tutorials for shared behavior across message channel types.

Security on the Outbound Edge

  • CHLAUTH on the hub must allow the branch queue manager or certificate identity to connect to SVR.
  • TLS cipher suites must match on RQSTR and SVR; SSLCIPH and certificate labels must be paired in change records.
  • Restrict hub listener exposure to known branch IP ranges even when outbound initiation is allowed from branch.
  • MCAUSER on both sides should follow least privilege for target queues on the hub.

RQSTR vs SVRCONN vs SDR

SVRCONN is for IBM MQ client applications using MQI over the network—not for queue-manager forwarding. SDR is for standard point-to-point when the source can connect to RCVR. RQSTR is only for message-channel forwarding with SVR when initiation direction must be branch-outbound. Mixing types in a pair name (same string, wrong CHLTYPE) produces BINDING failures or immediate channel errors in the error log.

Operations Checklist

  1. Confirm hub LISTENER is STARTED and listening on the port in branch CONNAME.
  2. DISPLAY CHSTATUS on branch RQSTR and hub SVR during a test.
  3. Watch XMITQ CURDEPTH and correlate with MSGS on CHSTATUS.
  4. Verify channel names match exactly on both queue managers.
  5. After DR, compare sequence numbers and follow IBM recovery guidance before RESET.

Common Mistakes

  • Defining RCVR on the hub when the design requires SVR—partner SDR will not bind to RCVR in this pattern.
  • CONNAME pointing at a load balancer port with no sticky listener affinity for MQ protocol.
  • Forgetting XMITQ USAGE(XMITQ) so the queue cannot hold forwarded messages.
  • Assuming RQSTR implies request/reply application pattern—it is only a channel type name.

Explain Like I'm Five: Requester Channels

A requester channel is when your toy store calls the big warehouse phone because the warehouse is not allowed to call you—but once you call, you can send them the box of toys you packed in your back room.

Practice Exercises

Exercise 1

Draw a firewall diagram: branch RQSTR to hub SVR on port 1414. Label XMITQ on the branch.

Exercise 2

List five DISPLAY commands you would run when RQSTR is in RETRY for more than an hour.

Exercise 3

Explain to a colleague why RQSTR is not the same as the request/reply messaging pattern.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. Requester channel CHLTYPE is:

  • RQSTR
  • RCVR
  • SVRCONN
  • CLUSRCVR

2. RQSTR must specify:

  • CONNAME to partner listener
  • Only DLQ name
  • Topic string
  • JCL class

3. RQSTR pairs with:

  • SVR
  • SDR
  • CLNTCONN alone
  • INITQ

4. Branch cannot receive inbound TCP—typical branch channel is:

  • RQSTR
  • RCVR
  • CLUSRCVR only
  • No channel
Published
Read time18 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation