USAGE

The USAGE attribute classifies a local queue as either a normal application queue or a transmission queue (XMITQ). That single word changes how IBM MQ treats puts, how channels bind to the queue, and how operators interpret depth on monitoring screens. Beginners sometimes create a queue named PARTNER.XMIT but leave USAGE(NORMAL)—the channel fails or messages do not flow as expected. This page explains USAGE(NORMAL) versus USAGE(XMITQ), how remote queue definitions and sender channels reference transmission queues, why applications should not put business data directly to XMITQ, and how USAGE fits into store-and-forward across queue managers.

USAGE(NORMAL): Application Queues

USAGE(NORMAL) is the default role for queues that hold business messages: orders, payments, audit events, and replies. Producers MQPUT; consumers MQGET; triggering, backout, and MAXDEPTH apply as documented for application traffic. Most queues in your estate are NORMAL. Cluster queues publishing to a cluster are still local queues with NORMAL usage on each queue manager instance unless they are explicitly transmission queues.

USAGE(XMITQ): Transmission Queues

USAGE(XMITQ) marks the queue as part of inter-queue-manager messaging. When an application puts to a remote queue definition, the queue manager moves the message onto the transmission queue named in the remote object's XMITQ attribute (or derived from cluster routing). A sender channel with matching XMITQ drains messages and sends them to the partner. Depth on an XMITQ during a channel outage is expected store-and-forward backlog—not necessarily “no consumer on an app queue.”

NORMAL vs XMITQ at a glance
AspectUSAGE(NORMAL)USAGE(XMITQ)
PurposeApplication work and repliesHold messages for channel to remote QM
Typical putterApplication programsQueue manager (routing)
Typical getterApplication consumersSender channel
MonitoringConsumer lag, poison, backlogChannel health, WAN outage

Remote Put Resolution

Application puts to QREMOTE('ORDERS.TO.HUB'). The definition specifies RNAME, RQMNAME, and XMITQ('QM_HUB.XMIT'). The queue manager stores the message on local queue QM_HUB.XMIT which must have USAGE(XMITQ). Channel TO.HUB with CHLTYPE(SDR) and XMITQ('QM_HUB.XMIT') forwards to the hub. If QM_HUB.XMIT were USAGE(NORMAL), configuration is inconsistent—fix the definition before go-live. DISPLAY QLOCAL USAGE is a quick audit field when onboarding a new partner connection.

shell
1
2
3
4
5
6
7
DEFINE QLOCAL('QM_HUB.XMIT') REPLACE USAGE(XMITQ) + MAXDEPTH(500000) DEFPSIST(YES) DESCR('XMIT to QM_HUB') DEFINE QREMOTE('ORDERS.TO.HUB') REPLACE + RNAME('ORDERS.IN') RQMNAME('QM_HUB') XMITQ('QM_HUB.XMIT') DEFINE CHANNEL('TO.HUB') CHLTYPE(SDR) TRPTYPE(TCP) + CONNAME('hub.example.com(1414)') XMITQ('QM_HUB.XMIT') REPLACE DISPLAY QLOCAL('QM_HUB.XMIT') USAGE CURDEPTH

Why Not Put Directly to XMITQ

Direct application puts to a transmission queue bypass remote queue naming, security, and reporting conventions. Operations cannot map depth to a business flow name on dashboards keyed to QREMOTE. Cluster routing and uniform MQRFH2 headers may be wrong. Reserve XMITQ for queue-manager-directed traffic. If you need a local staging queue before forward, use USAGE(NORMAL) and bridge with an application or channel design documented in your integration architecture.

XMITQ Sizing and Attributes

Transmission queues need MAXDEPTH and disk planning for longest channel outage × put rate, as covered in store-and-forward tutorials. DEFPSIST(YES) is standard for business traffic. Triggering on XMITQ is usually inappropriate. GET and PUT attributes still matter for channel internal access but differ from application consumer patterns. Some teams use separate XMITQ per partner for isolation; others one XMITQ per remote queue manager—USAGE(XMITQ) on each.

Clusters and USAGE

In cluster configurations, cluster transmission queues may be created with USAGE(XMITQ) when queue managers join cluster routes. Cluster repository and CLUSQMGR definitions influence which XMITQ names appear. When DISPLAY CLUSQMGR or cluster-sender channels show retries, check the associated cluster XMITQ depth and USAGE. Mixing cluster and non-cluster paths to the same partner is a common source of duplicate XMITQ definitions—standardize naming conventions.

Troubleshooting USAGE Mismatches

  • Channel fails at start referencing XMITQ—verify queue exists and USAGE(XMITQ).
  • Messages on XMITQ but channel RUNNING—check partner RCVR, TLS, and message size.
  • Remote put fails 2085—remote or XMITQ name typo, or NORMAL queue used as XMITQ.
  • Depth on NORMAL queue when expecting XMITQ—routing may put to wrong queue name.

Explain Like I'm Five: USAGE

NORMAL is the mailbox at your desk where you read letters. XMITQ is the outbound mail cart waiting for the truck (channel) to take bags to another city (remote queue manager). You write letters to people's names (remote queues); the post office sorts them into the right cart—you do not throw letters directly into the truck cart unless you are the post office.

Practice Exercises

Exercise 1

Sketch QREMOTE, XMITQ with USAGE(XMITQ), and SDR channel for one remote put path.

Exercise 2

XMITQ depth grows; channel status RETRY. List four checks unrelated to application consumers.

Exercise 3

Why is USAGE(NORMAL) wrong for QM_PARTNER.XMIT?

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. USAGE(XMITQ) identifies:

  • A transmission queue
  • A topic string
  • A listener port
  • A CF structure

2. Application business messages normally use:

  • USAGE(NORMAL)
  • USAGE(XMITQ)
  • USAGE(DLQ)
  • USAGE(TOPIC)

3. Sender channel XMITQ attribute must name:

  • A queue with USAGE(XMITQ)
  • Any alias queue
  • The dead-letter queue
  • INITQ

4. Remote puts route to XMITQ via:

  • Remote queue definition XMITQ
  • TRIGDATA only
  • DISTL only
  • BOQNAME only
Published
Read time14 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation