Queue Attributes

Every IBM MQ queue is more than a name—it is a bundle of attributes that tell the queue manager how the queue behaves. MAXDEPTH caps backlog; DEFPSIST chooses default durability; GET and PUT gate access; TRIGGER wires automatic processing. Mis-set attributes cause production mysteries: applications that worked yesterday fail with not authorized or queue full today after an ALTER. This tutorial walks through the attributes beginners touch most often, what each value does, how attributes interact, and MQSC patterns for safe change. Dedicated pages in this series go deeper on MAXDEPTH, TRIGGER, and CLUSTER; here you build the full attribute vocabulary.

Definition vs Runtime

DEFINE and ALTER QLOCAL change the repository definition. DISPLAY QLOCAL shows definition attributes; DISPLAY QSTATUS shows runtime depth and open handles. Some attributes exist only on the definition (DESCR, DEFPSIST); CURDEPTH is runtime. After ALTER, verify with DISPLAY and test MQOPEN from a representative application account—not only admin.

Essential queue attributes compared
AttributeEffect
MAXDEPTHMax message count on queue—queue full when reached
MAXMSGLMax bytes per message—reject oversize puts
DEFPSISTDefault YES/NO persistence for puts
GET / PUTAllow get, put, or both
SHAREWhether multiple apps can share queue access
DEFSOPTDefault syncpoint option for gets
TRIGGER familyTRIGGER, TRIGTYPE, TRIGDPTH, PROCESS, INITQ
USAGENormal queue vs transmission (XMITQ) usage
CLUSTERPublishes queue to named cluster

GET and PUT

GET(YES) allows MQGET; PUT(YES) allows MQPUT. Maintenance sometimes sets PUT(NO) to freeze inbound traffic while consumers drain backlog. GET(NO) creates a write-only queue—rare, used in special ingest patterns. These flags work with OAM: attribute YES plus no authority still fails. Teach developers that 2035 can be attribute or security.

DEFPSIST and DEFSOPT

DEFPSIST(YES) makes persistence the default—appropriate for financial and order data. DEFPSIST(NO) suits telemetry where loss on crash is acceptable. DEFSOPT controls default whether gets are under syncpoint (logical grouping with commit/rollback). YES encourages transactional gets coordinated with databases; NONE may improve throughput when idempotent processing allows it. Applications can override with MQGMO and MQPMO per call.

SHARE and DEFPRESP

SHARE(YES) is standard for multiple consumers competing for work. SHARE(NO) forces exclusive open—useful when only one legacy program may touch the queue. DEFPRESP relates to default persistence response on put—advanced; beginners focus on DEFPSIST first. Platform-specific attributes (z/OS STGCLASS, QSGDISP) extend the table on mainframe queues.

Trigger Attributes Together

TRIGGER(YES) enables the feature. TRIGTYPE(FIRST|EVERY|DEPTH) picks the event. TRIGDPTH applies to depth triggers. PROCESS names the process definition with APPLICID. INITQ names where trigger messages go. Missing any piece silences automation. See process definitions and trigger monitor tutorials for the full chain.

USAGE, DEFBIND, DISTL

USAGE(NORMAL) is a standard application queue. USAGE(XMITQ) marks a transmission queue feeding sender channels—do not point applications at XMITQ for business logic. DEFBIND controls how puts to QREMOTE resolve queue manager binding (OPEN, NOTFIXED, GROUP). DISTL enables distribution lists on supported platforms. Wrong USAGE on a queue used for apps breaks routing or channel startup.

Backout and Dead Letter: BOQNAME, BOTHRESH

BOQNAME names a backout queue where messages land after repeated rollback failures (backout count). BOTHRESH sets the backout threshold. Pair with poison message handling and dead-letter queues for operations runbooks. Without BOQNAME, poison messages may loop forever on the main queue, inflating CURDEPTH.

Explainer: Altering Attributes Safely

Change one attribute at a time in production when possible. Document before/after DISPLAY output. For MAXDEPTH reductions, ensure CURDEPTH is below the new cap first. For GET/PUT changes, coordinate application restarts. Cluster attributes may require REFRESH CLUSTER after ALTER on cluster queues.

Tutorial: Compare Two Queue Profiles

shell
1
2
3
4
5
6
7
8
9
10
11
12
* High-reliability work queue DEFINE QLOCAL('ORDERS.IN') REPLACE + MAXDEPTH(500000) MAXMSGL(4194304) + DEFPSIST(YES) GET(YES) PUT(YES) SHARE(YES) + DEFSOPT(YES) DESCR('Persistent orders') * Low-value telemetry DEFINE QLOCAL('METRICS.IN') REPLACE + MAXDEPTH(10000) MAXMSGL(65536) + DEFPSIST(NO) GET(YES) PUT(YES) SHARE(YES) + DESCR('Non-persistent metrics') DISPLAY QLOCAL('ORDERS.IN') MAXDEPTH DEFPSIST DEFSOPT DISPLAY QLOCAL('METRICS.IN') MAXDEPTH DEFPSIST

Attribute Interactions

  • High MAXDEPTH + DEFPSIST(YES) + large messages = plan disk and log.
  • TRIGGER(YES) + PUT(NO) — unusual; triggers rarely fire without puts.
  • CLUSTER + USAGE(XMITQ) — invalid pattern; cluster queues are normal usage.
  • MAXMSGL smaller than application message — immediate MQRC_MSG_TOO_BIG.

Explain Like I'm Five: Queue Attributes

The mailbox has rules on a sign: how many letters fit (MAXDEPTH), whether letters must be copied into a safe vault (DEFPSIST), whether you may drop letters in (PUT) or take them out (GET), and whether a robot should run when letters arrive (TRIGGER). Attributes are the sign; the queue is the box.

Practice Exercises

Exercise 1

Design attribute sets for payment queue vs metrics queue. List at least six attributes each.

Exercise 2

After ALTER QLOCAL DEFPSIST(NO), old messages still persistent. Why?

Exercise 3

PUT(NO) but depth still rises. Name two non-application causes to check.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. DEFPSIST(YES) means new messages default to:

  • Persistent unless put overrides
  • Never logged
  • Only non-persistent
  • Only on topics

2. PUT(NO) on a queue prevents:

  • New messages being added
  • All DISPLAY commands
  • Channel creation
  • TLS

3. TRIGGER(YES) with PROCESS and INITQ enables:

  • Automatic application start via trigger monitor
  • Only pub/sub
  • Only clustering
  • Only LDAP

4. MAXMSGL controls:

  • Maximum length of one message
  • Maximum message count
  • Channel heartbeat
  • Topic wildcard
Published
Read time16 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation