MQDISC

MQDISC is the last line of the classic MQI lifecycle: connect, open, put or get, close, disconnect. It releases Hconn from MQCONN or MQCONNX, telling the queue manager this application instance no longer participates in messaging on that session. All object handles still open on that connection are closed implicitly—though relying on implicit close is sloppy compared to explicit MQCLOSE per queue. Disconnect drives down DISPLAY CONN counts, frees channel conversation resources on client connections, and allows endmqm quiesce to complete when no applications remain. Batch jobs that exit without MQDISC leave ghost connections until timeout; microservices under Kubernetes rolling deploy must drain in-flight gets then disconnect before SIGKILL window expires. This tutorial covers MQDISC parameters, interaction with syncpoint, pooled connections in Java, graceful shutdown under quiesce, reconnect after MQDISC, and operations monitoring of lingering connections.

Calling MQDISC

MQDISC takes Hconn and returns completion and reason codes. On success, Hconn must not appear in further MQI calls—2018 HCONN_ERROR results if code paths reuse it. Set Hconn to a sentinel in languages that allow nulling pointers after disconnect to catch bugs in finally blocks.

c
1
2
3
4
5
6
MQDISC(&Hconn, &compCode, &reason); if (compCode != MQCC_OK) { /* log reason; may already be disconnected */ } /* do not use Hconn again */
MQI lifecycle call order
StepCallHandle
1MQCONN / MQCONNXHconn created
2MQOPENHobj per object
3MQPUT / MQGETUses Hconn + Hobj
4MQCLOSEHobj released
5MQDISCHconn released

Explainer: Leaving the Building

MQDISC is checking out of the IBM MQ building and returning your lobby badge. MQCLOSE was returning keys to individual mailboxes; disconnect means you leave the building entirely.

Syncpoint Before Disconnect

Transactional applications MQCMIT successful work units before MQDISC. MQBACK rolls back poison processing attempts. Disconnect with open syncpoint typically rolls back uncommitted puts and gets—the message reappears on the queue for another consumer or the same after reconnect. XA transactions coordinate with resource managers; disconnect without XA end may leave in-doubt states—use supported transaction managers.

Connection Pools and Frameworks

Java application servers pool connections: physical MQCONNX is rare per HTTP request; sessions borrow Hconn from pool and return without MQDISC until pool destroy or redeploy. Understand your container's pool policy—leaks show as many CONN entries with same APPNAME. Node and Python long-running workers hold one Hconn for process lifetime and MQDISC on SIGTERM handler after closing consumers.

Quiesce and endmqm

Operators run endmqm -w to quiesce: new MQCONN fails; existing apps should finish and MQDISC. Applications using MQGMO_FAIL_IF_QUIESCING exit get loops and disconnect cleanly. Hung apps block shutdown—DISPLAY CONN identifies USERID and APPLTAG. Kill process only after documented timeout.

Client Channel Impact

Remote MQDISC ends or pauses the SVRCONN channel instance depending on SHARECNV and client reconnect settings. Frequent connect/disconnect per message is anti-pattern—amortize with long-lived Hconn. Server DISPLAY CHSTATUS instance count drops after disconnect storm stops.

Reconnect Pattern

After network failure, client libraries may auto-reconnect in some configurations; application still sees MQRC_CONNECTION_BROKEN on in-flight calls. Pattern: catch error, MQDISC if handle invalid, MQCONNX again, MQOPEN queues, resume get loop. Idempotent consumers tolerate duplicate messages after redelivery.

z/OS and Batch

COBOL batch programs CALL MQDISC before GOBACK. CICS transactions may hold connection across pseudo-conversation—different lifecycle than batch. Follow platform sample for your environment; wrong disconnect mid-transaction loses in-flight work.

Troubleshooting

  • High CONN count — missing MQDISC on exit; connection pool mis-sized.
  • Quiesce stuck — find CONN with longest duration; contact app owner.
  • 2018 after disconnect — code reused Hconn; fix finally order.
  • Messages rolled back unexpectedly — disconnect before MQCMIT.

Explain Like I'm Five: MQDISC

MQDISC is waving goodbye and leaving the post office building so they can lock the doors for cleaning at night.

Practice Exercises

Exercise 1

List five steps for graceful pod shutdown of an MQ consumer.

Exercise 2

Explain pooled JMS connections versus per-request MQDISC trade-offs.

Exercise 3

What DISPLAY command helps find applications that forgot to disconnect?

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. MQDISC releases:

  • Hconn connection
  • Only MQMD
  • Channel definition
  • Disk volume

2. Before MQDISC you should:

  • MQCLOSE open handles
  • DELETE QMGR
  • Format DASD
  • Skip all closes

3. Uncommitted syncpoint work on disconnect usually:

  • Rolls back
  • Always commits
  • Duplicates messages
  • Starts channel

4. After MQDISC the Hconn is:

  • Invalid
  • Reusable forever
  • Same as Hobj
  • A queue name
Published
Read time17 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation