Permanent Dynamic Queues

Permanent dynamic queues occupy the middle ground between static DEFINE QLOCAL and throwaway temporary dynamic queues. Created at MQOPEN from a model with DEFTYPE(PERMDYN), they behave like normal local queues until someone deletes them—they survive application disconnect and queue manager restart. That persistence helps when a workflow must reopen the same dynamic name later, when multiple programs share a dynamically created queue, or when audit requires the queue to remain for inspection. The trade-off is explicit cleanup: unlike TEMPDYN, nothing automatic removes PERMDYN queues when the creator walks away. This tutorial covers model definition, MQCLOSE delete options, purge semantics, housekeeping, authority, and choosing PERMDYN versus static or temp dynamic queues.

DEFINE QMODEL with PERMDYN

DEFINE QMODEL('WORKSPACE.MODEL') DEFTYPE(PERMDYN) MAXDEPTH(10000) DEFPSIST(YES) copies those defaults to each created queue. Applications supply the dynamic name—often including user or session ID. Because queues persist, naming collisions matter: two apps opening the same dynamic name attach to the same queue, which may be collaboration or corruption.

MQCO close options on permanent dynamic queues
OptionBehavior
MQCO_NONEClose handle; queue and messages remain
MQCO_DELETEDelete queue only if empty (no messages)
MQCO_DELETE_PURGERemove committed messages, delete queue; fails if uncommitted activity

Explainer: Lifecycle Compared to Static Queue

Static ORDERS.IN exists before any application runs. Permanent dynamic APP.USER42.WORK is born when user 42 program opens the model, lives through restarts if not deleted, and blocks that name until DELETE. Static names appear in deployment manifests; permanent dynamic names appear in logs and require governance for patterns (prefix APP.*.WORK).

Surviving Queue Manager Restart

Persistent messages on a PERMDYN queue reload from logs after strmqm. Non-persistent messages may be lost on crash. The queue definition itself reloads from the repository like any QLOCAL. Operations after unclean shutdown should DISPLAY QLOCAL for unexpected AMQ or APP dynamic names and decide delete versus drain.

Application Responsibilities

  1. Create with MQOPEN on model when session starts.
  2. Use queue for work; commit or back out transactional messages.
  3. MQCLOSE with MQCO_DELETE or MQCO_DELETE_PURGE when session ends successfully.
  4. On failure paths, still close with delete or leave for housekeeping job.
  5. Log dynamic name for support correlation.

Administrative DELETE

DELETE QLOCAL('APP.USER42.WORK') works when queue is empty and not open—same as static queues. Batch jobs scan DISPLAY QLOCAL for patterns older than N days, alert owners, delete orphans. Without housekeeping, repository clutter and MAXDEPTH on thousands of queues stress administration tools.

PERMDYN vs DEFINE QLOCAL

If the queue name is known at deploy time, static DEFINE is simpler for ops. PERMDYN suits variable suffixes (tenant ID, session token) where pre-defining thousands of QLOCAL is impractical. Temp dynamic suits when no restart survival is needed. Decision matrix: lifetime, restart, shared access, cleanup automation.

Transactional Gets and PURGE

MQCO_DELETE_PURGE fails while uncommitted gets or puts hold syncpoints open. Applications using syncpoint must commit or rollback before purge close. Mixed UoW with database coordinators adds coordination—delete queue only after both sides commit.

Tutorial: Create and Delete Pattern

shell
1
2
3
4
5
6
7
8
DEFINE QMODEL('SESSION.WORK') REPLACE + DEFTYPE(PERMDYN) MAXDEPTH(5000) DEFPSIST(YES) * Application creates dynamic name SESSION.WORK.USER001 * When done (pseudocode): * MQCLOSE(Hobj, MQCO_DELETE) if CURDEPTH is 0 * or MQCLOSE(Hobj, MQCO_DELETE_PURGE) to force empty DISPLAY QLOCAL('SESSION.WORK.USER001') DELETE QLOCAL('SESSION.WORK.USER001') * if app failed to delete

Monitoring

  • Count QLOCAL matching prefix SESSION.WORK.*
  • Alert on growth week over week
  • Include in dmpmqcfg exports for DR
  • Document max concurrent dynamic queues per app tier

Explain Like I'm Five: Permanent Dynamic Queues

You rent a storage unit with your name on it (dynamic name). It stays rented after you go home until you officially end the rental (DELETE close). A temp dynamic queue is a locker that disappears when you leave the building.

Practice Exercises

Exercise 1

When MQCO_DELETE fails, what will you check before trying MQCO_DELETE_PURGE?

Exercise 2

Write a housekeeping policy for PERMDYN prefixes older than 7 days.

Exercise 3

Choose TEMPDYN, PERMDYN, or static QLOCAL for a multi-day batch job reply queue.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. DEFTYPE(PERMDYN) means dynamic queues:

  • Survive until explicitly deleted
  • Delete on first MQGET
  • Are always non-persistent
  • Cannot have MAXDEPTH

2. MQCO_DELETE on permanent dynamic queue with messages:

  • Fails until queue empty
  • Always succeeds
  • Deletes QMGR
  • Starts channel

3. MQCO_DELETE_PURGE:

  • Deletes committed messages then queue
  • Never deletes
  • Only for topics
  • Only for listeners

4. Housekeeping is needed because:

  • Orphan PERMDYN queues accumulate
  • Temp queues never delete
  • Channels auto-delete
  • Models self-delete
Published
Read time15 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation