Dynamic Queues

Dynamic queues let applications create queue names at runtime without a separate DEFINE QLOCAL for every possible name. The queue manager copies attributes from a model queue (QMODEL) and instantiates a real local queue when the program MQOPENs with the right dynamic naming pattern. Request-reply is the classic pattern: each client gets a private reply queue name, puts a request with ReplyToQ set, and reads the answer only on that queue. This overview explains how dynamic creation works, how model queues fit in, naming rules, temporary versus permanent lifecycles, security, monitoring clutter, and links to deeper pages on each dynamic type.

Model Queue as Template

Administrators DEFINE QMODEL('REPLY.MODEL') with DEFTYPE(TEMPDYN) or PERMDYN plus defaults like MAXDEPTH, DEFPSIST, and SHARE. The model is not where messages land in steady state—opening it with dynamic intent creates child queues. Multiple models support different policies: short-lived reply queues versus longer-lived partner workspaces.

MQOPEN Flow

1. Application fills MQOD with object type queue and dynamic name string.
2. ObjectName or ModelName fields identify model and target per API rules.
3. MQOPEN with MQOO_DYNAMIC option (language bindings wrap this).
4. Queue manager creates QLOCAL, returns Hobj handle.
5. Application MQPUT/MQGET on the dynamic name.
6. MQCLOSE with appropriate options deletes or retains queue per type.

Explainer: Request-Reply with Dynamic Reply

Client opens model, gets dynamic name AMQ.8723.12345678.REPLY, puts request to SERVER.REQUEST with ReplyToQ set to that name, CorrelId or MsgId linking response. Server processes, puts reply to ReplyToQ. Client gets on private queue—no cross-talk between clients. When client closes with temp dynamic rules, queue vanishes—cleanup automatic.

Naming Patterns

Letting the queue manager generate names (forms using *) avoids collisions. Prefix AMQ.* is common for generated names. Applications supplying their own names must coordinate uniqueness—two programs opening the same dynamic name share one queue, which may be intended or catastrophic. JMS temporary queues use similar concepts under vendor prefixes.

Security

Restrict which IDs may open the model with create authority. Wildcard authority on dynamic names is sensitive—attackers could create many queues exhausting resources. MAXDEPTH on the model caps each dynamic instance. Monitor object counts during load tests.

Operations and DISPLAY

DISPLAY QLOCAL(*) during peak may list hundreds of AMQ.* queues—normal for request-reply. Alerts on object count or repository size help. Stale permanent dynamic queues from buggy apps that never MQCO_DELETE require housekeeping scripts.

Tutorial: Conceptual Steps

1
2
3
4
5
6
7
8
9
DEFINE QMODEL('REPLY.MODEL') REPLACE +
  DEFTYPE(TEMPDYN) MAXDEPTH(1000) DEFPSIST(NO) +
  DESCR('Template for temp reply queues')
DEFINE QLOCAL('SERVER.REQUEST') REPLACE MAXDEPTH(100000)
* Application code (pseudocode):
* open model -> dynamic reply name
* put to SERVER.REQUEST with ReplyToQ = dynamic name
* get from dynamic reply
* close dynamic with options -> queue deleted if TEMPDYN

When Not to Use Dynamic Queues

• Fixed integration points known at deploy time—use static QLOCAL.
• Audit requires permanent queue names in CMDB—dynamic names harder to track.
• Cross-queue-manager reply—need explicit remote definitions, not temp dynamic on wrong QM.

Explain Like I'm Five: Dynamic Queues

Instead of building a hundred mailboxes in advance, you ask the post office to make one disposable box with your ticket number when you arrive. When you leave, they recycle the box (temporary) or keep it until you say throw it away (permanent).

Practice Exercises

Exercise 1

Draw request-reply message flow with model queue, dynamic reply, and server queue.

Exercise 2

Why should only trusted apps open REPLY.MODEL?

Exercise 3

When would PERMDYN beat TEMPDYN?

Frequently Asked Questions

Test Your Knowledge