Temporary dynamic queues are IBM MQ way of handing each conversation a disposable mailbox. Created from a model queue with DEFTYPE(TEMPDYN), they inherit attributes such as MAXDEPTH and DEFPSIST, exist only while the creating application needs them, and disappear when the application closes the handle or disconnects—carrying away any leftover messages. That automatic cleanup is why request-reply clients use them for reply destinations without flooding the repository with static queue names. This tutorial explains TEMPDYN models, MQOPEN and MQCLOSE behavior, close options that do not change temp deletion semantics, differences from permanent dynamic queues, JMS temporary queues, security limits, and troubleshooting missing replies.
DEFINE QMODEL('REPLY.TEMP.MODEL') DEFTYPE(TEMPDYN) sets the lifecycle policy for every dynamic queue created from that model. Other attributes copy forward: a model with DEFPSIST(NO) yields non-persistent dynamic replies unless the put overrides. MAXDEPTH caps one client backlog. SHARE(YES) still allows only that application pattern you design—temp queues are not for multi-team shared workloads.
| Aspect | TEMPDYN | PERMDYN |
|---|---|---|
| Deleted when | App close or disconnect | MQCO_DELETE or admin DELETE |
| Survives QM restart | No | Yes if not deleted |
| Messages at close | Removed with queue | DELETE fails if messages remain |
| z/OS shared queue | Not allowed | Possible per config |
T0: Client MQOPEN model, receives dynamic name DQ.REPLY.123. T1: Client MQPUT to SERVICE.REQUEST with ReplyToQ=DQ.REPLY.123. T2: Server gets request, processes, MQPUT reply to DQ.REPLY.123. T3: Client MQGET on DQ.REPLY.123. T4: Client MQCLOSE—queue manager deletes DQ.REPLY.123 and any straggler messages. No operator cleanup shift required.
Supply ObjectName as the model name and dynamic string per API—exact field layout varies between C MQI, Java, and JMS. Generated names often look like AMQ.8721.5A1B2C3D4. Using queue-manager-generated names reduces collision risk versus hard-coded dynamic strings shared by mistake between two programs.
IBM MQ documentation states that for temporary dynamic queues, MQCLOSE options MQCO_NONE, MQCO_DELETE, and MQCO_DELETE_PURGE are all treated as MQCO_NONE—the temp lifecycle already removes the object. Beginners trying MQCO_DELETE on temp queues expecting different behavior should read permanent dynamic queue rules instead.
Abrupt application kill may leave temp queues until queue manager detects disconnect and cleans up—usually quickly. Long-lived orphaned temp queues after crashes warrant investigation (hang, shared handle). Design finally blocks to MQCLOSE handles.
JMS Session.createTemporaryQueue() creates IBM MQ temporary dynamic queues when connected to IBM MQ. Same lifecycle: close session or connection removes them. .NET and other clients expose similar helpers. Logging should not assume static reply queue names in support tools.
An authorized program could open the model in a loop creating thousands of temp queues—denial of service. Limit create authority on models, cap MAXDEPTH, monitor object counts, use rate limits in application design. Temp queues cannot be QSG shared queues—cross-LPAR reply still needs channels or static queues.
1234567DEFINE QMODEL('REPLY.TEMP') REPLACE + DEFTYPE(TEMPDYN) MAXDEPTH(500) DEFPSIST(NO) + SHARE(YES) DESCR('Temp reply template') * After app creates dynamic queue: DISPLAY QLOCAL(*) WHERE(DESCR EQ 'Temp reply template') * Or display specific generated name from app log * After app disconnect: name should disappear from DISPLAY
You get a disposable paper cup with your order number for the answer. When you leave the counter, staff throws the cup away—even if you did not read the note inside. Next customer gets a new cup.
Why is DEFPSIST(NO) common on temp reply models?
Client swears server replied but client got nothing—list five checks including temp queue lifetime.
Compare temp dynamic reply to static QLOCAL REPLY.CLIENT123 for operations monitoring.
1. DEFTYPE(TEMPDYN) on a model creates:
2. Temp dynamic queues on z/OS QSG:
3. Messages on temp queue at close:
4. Typical use case: