DEFPSIST (default persistence) tells IBM MQ what durability to apply when an application puts a message without saying otherwise. Persistent messages are written to logs and queue files so they can survive queue manager restart; non-persistent messages live primarily in memory and may disappear after a crash. The attribute is a safety net: even if a developer forgets persistence flags, DEFPSIST(YES) on a payment queue still logs business data. Conversely, DEFPSIST(NO) on a high-frequency metrics queue avoids log churn when architects accept loss. This page explains YES versus NO, application overrides, interaction with syncpoint and channels, DEFPSIST on model and transmission queues, and governance patterns for mixed estates.
| DEFPSIST | Default message type | After QM restart | Typical cost |
|---|---|---|---|
| YES | Persistent | Messages remain if committed | Higher log/disk I/O |
| NO | Non-persistent | May be lost | Lower I/O, faster |
1234DEFINE QLOCAL('PAYMENTS.IN') REPLACE DEFPSIST(YES) MAXDEPTH(500000) DEFINE QLOCAL('METRICS.IN') REPLACE DEFPSIST(NO) MAXDEPTH(2000000) ALTER QLOCAL('PAYMENTS.IN') DEFPSIST(YES) DISPLAY QLOCAL('PAYMENTS.IN') DEFPSIST
Infrastructure pipelines should codify DEFPSIST per queue class. Drift between test (NO for speed) and prod (YES for payments) causes “works in test, loses data in prod” incidents when promotions miss the attribute.
MQI put options include persistence flags. A careless client can put non-persistent to DEFPSIST(YES) queue by explicit option—MQ honors the application. Code review and client configuration templates should default to queue default unless override is intentional. JMS delivery mode persistent maps to this concept. COBOL and Java samples in your organization should document the standard pattern for financial versus telemetry traffic.
Persistent put under MQPUT with syncpoint and MQCMIT makes the message visible to other applications after commit and recoverable after restart. Backout before commit removes the message as if never put. DEFPSIST(YES) without syncpoint still persists on commit of the put itself per normal logging rules—understand your application transaction boundaries. Composite applications coordinating database and MQ should use one unit of work where supported.
Persistent messages on an XMITQ remain through channel retry and queue manager restart. Non-persistent messages on XMITQ may be lost if failure happens before delivery completes. Cross-site forwarding for business data almost always pairs DEFPSIST(YES) on XMITQ with persistent messages. Fire-and-forget telemetry across sites might use NO only with explicit architectural sign-off.
Reply queues from QMODEL often use DEFPSIST(NO) when replies are ephemeral RPC responses. Request queues use YES when requests must not vanish during restart. Mismatch—persistent request with non-persistent reply—is valid when business rules differ for each direction.
Publications inherit persistence from publish options and subscriber queue DEFPSIST. Fan-out multiplies persistent storage when many subscribers have DEFPSIST(YES). Topic administrators coordinate with queue owners when changing defaults.
DEFPSIST is the default “write in pen” (YES) or “write in pencil” (NO) rule for new letters in the mailbox. Pen letters survive if the building loses power; pencil letters might smudge away. You can still choose pen or pencil for one letter when you mail it (application override).
Queue DEFPSIST(YES) but app puts non-persistent. What happens on restart if message was on queue?
Design DEFPSIST for ORDERS.IN (payments) and HEARTBEAT.IN (probe every 5 sec).
Why pair DEFPSIST(YES) on XMITQ with persistent puts for hub integration?
1. DEFPSIST(YES) means default puts are:
2. After QM restart, non-persistent messages:
3. ALTER DEFPSIST affects:
4. XMITQ for finance traffic often has: