MQCLOSE

MQCLOSE ends your application's session with a specific queue or topic object. MQOPEN gave you Hobj; MQPUT and MQGET used it; MQCLOSE tells the queue manager you are done with that mailbox slot. Until close completes, the queue manager tracks your open intent (put, get, browse) and may hold locks or reservation state associated with the handle. Production services that open dozens of queues per request must close each handle in finally blocks or use language patterns that auto-close—leaks accumulate across traffic and show up as DISPLAY QSTATUS IPPROCS counts that never drop. Close options go beyond simple release: MQCO_DELETE and MQCO_DELETE_PURGE govern permanent dynamic queue cleanup. This tutorial explains standard close, delete options, temporary versus permanent dynamic behavior, close order relative to MQCMIT, multi-handle programs, reason codes, and operational symptoms of applications that never close.

Basic MQCLOSE

After processing, call MQCLOSE with Hconn, address of Hobj, and CloseOptions MQCO_NONE for a normal queue that remains defined for other applications. Hobj is undefined for further use—do not MQPUT after close without a new MQOPEN. The queue object itself persists on the queue manager unless you used delete options on a dynamic queue type that allows removal.

c
1
2
3
4
5
6
7
8
9
10
11
12
MQLONG closeOptions = MQCO_NONE; MQCLOSE(Hconn, &Hobj, closeOptions, &compCode, &reason); if (compCode != MQCC_OK) { /* 2019 handle error if already closed */ } /* Hobj must not be reused without MQOPEN */
MQCLOSE options compared
OptionEffectTypical use
MQCO_NONERelease handle; queue remainsNormal QLOCAL consumers and producers
MQCO_DELETEDelete empty permanent dynamic queuePERMDYN cleanup when CURDEPTH 0
MQCO_DELETE_PURGEDelete queue and discard messagesForced teardown of dynamic queue
MQCO_KEEP_SUBTopic publish: keep subscriptionAdvanced pub/sub scenarios per IBM docs

Temporary Dynamic Queues

Queues created from a model with DEFTYPE(TEMPDYN) exist for the creating application's conversation. IBM MQ treats MQCLOSE on temporary dynamics such that the queue is removed when the last handle closes—MQCO_DELETE and MQCO_DELETE_PURGE are equivalent to MQCO_NONE for temps. Beginners sometimes try explicit DELETE QLOCAL in runmqsc on a temp name that already vanished. Reply queues in request/reply must stay open on the client until the reply is MQGET, then MQCLOSE removes the temp name automatically.

Permanent Dynamic Queues

PERMDYN queues survive MQCLOSE with MQCO_NONE—they behave like ordinary queues until MQCO_DELETE succeeds (usually empty queue) or an operator DELETE QLOCAL. Forgotten PERMDYN queues clutter repositories and backups. Application design should document who calls MQCO_DELETE_PURGE on error paths versus leaving messages for support to inspect.

Explainer: Returning the Mailbox Key

MQCLOSE is handing the mailbox key back to the post office clerk. You cannot put more letters in that slot until you check out a new key (MQOPEN again). For temporary mailboxes, the clerk removes the whole box when you return the key.

Order of Operations at Shutdown

  1. Stop accepting new work (flag or quiesce response).
  2. Finish MQGET/MQPUT loops; MQCMIT or MQBACK open transactions.
  3. MQCLOSE each Hobj (reply queue, then request queue, etc.).
  4. MQDISC Hconn when all objects closed.

Closing the connection before objects may force implicit close but logs warnings and risks rollback surprises. Frameworks like JMS session.close() should run before connection.close().

Syncpoint and Close

If MQPUT under MQPMO_SYNCPOINT was not committed, MQCLOSE behavior interacts with the unit of work—consult IBM documentation for your language binding. Best practice: explicit MQCMIT or MQBACK before MQCLOSE on transactional queues. Poison message handlers that MQBACK in a loop should still close browse handles opened for inspection.

Multiple Handles

Programs with HobjIn and HobjOut for request/reply close each independently. Close order rarely matters for independent queues unless sharing a single UOW across both. Re-opening the same queue name gets a new Hobj value—do not assume numeric handle equality across open cycles.

Operations: Stuck IPPROCS

DISPLAY QSTATUS shows open input and output process counts. Stale IPPROCS after application crash usually clear when the queue manager detects disconnect. Persistent high IPPROCS with idle apps indicates handle leak—find the APPNAME in DISPLAY CONN and restart or fix code. ALTER QLOCAL INHIBIT may be needed during incident to stop new opens while draining.

Troubleshooting

  • 2019 — double close or use after MQDISC.
  • 2018 — Hconn no longer valid.
  • Delete fails — queue not empty; use PURGE option or drain first.
  • Cannot DELETE QLOCAL in MQSC — open handles remain elsewhere.

Explain Like I'm Five: MQCLOSE

MQCLOSE is giving back the key to your classroom mailbox so someone else can use it, and for temporary boxes the teacher throws the whole box away.

Practice Exercises

Exercise 1

Write shutdown pseudocode closing two handles then disconnecting.

Exercise 2

When would you choose MQCO_DELETE_PURGE over MQCO_DELETE?

Exercise 3

Explain why temp dynamic reply queues must not be closed before MQGET of the reply.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. MQCLOSE requires:

  • Valid Hconn and Hobj
  • Only MQDISC
  • START CHANNEL
  • DISPLAY QMGR

2. MQCO_NONE means:

  • Close handle only
  • Delete QMGR
  • Start listener
  • Format disk

3. Temp dynamic queues delete on close:

  • Automatically
  • Never
  • Only with MQDISC
  • Only on z/OS

4. 2019 means:

  • Invalid object handle
  • Queue full
  • SSL failure
  • Unknown QM
Published
Read time18 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation