Model Queues

Model queues are templates for creating queues on demand. When a client needs a private reply address for one request, defining thousands of permanent QLOCAL objects is wasteful. Instead, administrators define one QMODEL with the right defaults; applications open a dynamic queue name and the queue manager materializes a temporary queue that inherits those defaults. When the application finishes and closes handles, the temporary queue disappears. Request/reply over IBM MQ, JMS temporary destinations, and many integration patterns built on correlation IDs rely on this mechanism. This tutorial covers DEFINE QMODEL, which attributes matter, how MQOPEN creates dynamic names, temporary versus permanent dynamic queues, security, and operations monitoring when dynamic queue creation fails.

DEFINE QMODEL

DEFINE QMODEL('REPLY.MODEL') REPLACE sets defaults for dynamically created queues. Typical production models set MAXDEPTH modestly (reply queues should be shallow), MAXMSGL to match request queue, DEFPSIST(NO) for ephemeral replies or YES when replies must survive brief outages, GET and PUT enabled, SHARE if multiple threads get replies, and DESCR documenting the pattern. DISPLAY QMODEL shows the template; after an app creates a dynamic queue, DISPLAY QLOCAL(dynamicName) shows the live object.

1
2
3
4
5
6
7
8
DEFINE QMODEL('REPLY.MODEL') REPLACE +
  MAXDEPTH(5000) +
  MAXMSGL(1048576) +
  DEFPSIST(NO) +
  GET(ENABLED) PUT(ENABLED) +
  SHARE(ENABLED) +
  DESCR('Template for temp reply queues - Request/Reply')
DISPLAY QMODEL('REPLY.MODEL') ALL

How Applications Use the Model

In the MQI, the application sets ObjName to a dynamic queue name pattern (implementation-specific; many use a prefix the queue manager expands) and specifies the model queue in the MQOD or equivalent. MQOPEN returns the resolved dynamic queue name in the descriptor. The client puts the request including ReplyToQ and ReplyToQMgr pointing at that dynamic name. The server processes and puts the reply to the dynamic queue. The client MQGETs the reply and MQCLOSE deletes the temporary queue when configured. JMS hides much of this behind TemporaryQueue APIs but the queue manager behavior remains model-driven on classic MQ bindings.

Temporary vs Permanent Dynamic Queues

Temporary dynamic queues (the common case) delete when the creating application closes the last handle. Permanent dynamic queues survive until explicitly deleted—used less often but valuable when a long-lived process needs a private queue name without pre-defining QLOCAL. Creation options on MQOPEN distinguish behavior; consult IBM MQ application programming guide for MQOO_DYNAMIC and related options on your platform. Misunderstanding lifetime causes “reply never arrived” when the client closed too early or “orphan queues” when permanent dynamic was chosen accidentally.

Request/Reply Pattern with Model Queue

1. Client opens dynamic queue from REPLY.MODEL.
2. Client MQPUT request to SERVER.REQ with ReplyToQ set to dynamic name.
3. Server MQGET request, processes, MQPUT reply to ReplyToQ.
4. Client MQGET reply from dynamic queue.
5. Client MQCLOSE; dynamic queue deleted.

CorrelationId or MsgId/ReplyTo correlation fields tie reply to request. Model queue does not replace correlation discipline—applications must still match messages correctly under load.

Security and Authority

Applications need authority to open the model queue and to create dynamic queues—often granted via special profiles or +crt on model name patterns. Restrict model names so developers cannot create unlimited dynamic queues with huge MAXDEPTH. Monitor object counts on queue managers where buggy clients leak permanent dynamic queues. Channel puts to dynamic reply queues on remote queue managers require reply path definitions and firewall rules as covered in remote queue tutorials.

Model Queue vs Defining Thousands of QLOCAL

Static QLOCAL per session does not scale for millions of short clients. Model queues centralize policy: change DEFPSIST on the model once, all new dynamic queues inherit. Trade-off: dynamic names are harder to monitor in dashboards unless tools group by prefix. Operations sometimes set naming prefixes AMQ.12345... for automatic queues—learn your queue manager's name generation rules.

Troubleshooting

• MQOPEN fails 2035 — authority on model or dynamic create profile.
• 2082 object exists — rare dynamic name collision; retry open.
• Reply lost — client closed dynamic queue before get; server put too late.
• Disk growth — permanent dynamic queues not deleted; audit DISPLAY QUEUE(*) where QTYPE is LOCAL and dynamic.

Relation to JMS and Modern Clients

JMS TemporaryQueue on IBM MQ uses model queue machinery underneath. Spring JMS, Quarkus, and .NET clients abstract MQOPEN details but administrators still define REPLY.MODEL or accept default model names created at install. Cloud-native services should tune MAXDEPTH on models to prevent slow consumers from filling reply queues during storms.

Explain Like I'm Five: Model Queue

The teacher has a stamp that says “make a small empty tray for each student” (model queue). When you raise your hand (MQOPEN), the helper makes a tray just for you (dynamic queue). You get answers on your tray. When you leave and put the tray away (close), the tray is recycled (deleted). The stamp is not a tray itself—you cannot put cookies on the stamp.

Practice Exercises

Exercise 1

Define REPLY.MODEL with MAXDEPTH 100 and DEFPSIST(NO). Explain why for a synchronous RPC-style client.

Exercise 2

Server puts reply after client disconnected. Where does the message go? How prevent?

Exercise 3

Compare model queue approach to a fixed shared reply queue AMQ.REPLY.SHARED—pros and cons.

Frequently Asked Questions

Test Your Knowledge