Message persistence is the switch that determines whether IBM MQ must durably record a message before telling your application the put succeeded. Persistent messages underpin payments, claims, inventory, and regulatory audit trails—they survive queue manager restarts and power failures on properly configured systems. Non-persistent messages trade durability for speed. Beginners confuse persistence with guaranteed business processing; persistence is necessary but not sufficient—consumers still must get, process, and commit. This page explains the MQMD Persistence field, DEFPSIST queue defaults, MQPMO put options, logging on distributed and z/OS queue managers, interaction with syncpoint, performance tuning, and MQSC to establish safe defaults in a lab.
Effective persistence comes from the application message descriptor (MQMD.Persistence or JMS delivery mode), optional MQPUT options (MQPMO), and queue defaults (DEFPSIST). If the application explicitly sets persistent or not persistent, that choice usually wins. If the application leaves persistence as MQPER_AS_Q_DEF, the queue DEFPSIST attribute applies. Understanding precedence prevents surprises—an empty MD on a DEFPSIST(NO) marketing queue may lose campaigns on restart while the payments queue on DEFPSIST(YES) survives.
| Value | Meaning | Effect |
|---|---|---|
| MQPER_PERSISTENT (1) | Persistent message | Logged to durable storage before successful put completes |
| MQPER_NOT_PERSISTENT (0) | Non-persistent | May be lost on abrupt queue manager failure |
| MQPER_AS_Q_DEF (2) | Use queue default | Follows DEFPSIST on the target queue |
Operations set DEFPSIST(YES) on business queues so careless application defaults still persist. High-throughput status queues may use DEFPSIST(NO) with explicit application control. Transmission queues for cross-site forwarding almost always persist financial traffic. Pub/sub subscriber queues inherit persistence from the publication and queue attributes—fan-out multiplies persistent storage. Capacity planning includes log size, log retention, and disk for persistent depth.
Distributed IBM MQ uses log files (circular or linear per configuration) to record changes before they are visible to other consumers. Persistent puts wait for log force according to product and platform settings. Administrators monitor log usage, media failures, and secondary log copies in HA pairs. Beginners should know persistence implies log I/O—not magic disk on the queue file alone.
On z/OS, persistent messages interact with log streams and queue data in shared structures for queue sharing groups. Operations use ISPF panels, MQSC, and SMF to manage structures. The persistence concept matches distributed—messages must survive planned and unplanned outages—but the storage mechanics live in mainframe storage administration. Cross-platform teams should document which flows are persistent end-to-end, not only on the mainframe leg.
A persistent put under syncpoint is not visible to other applications until MQCMIT. Backout removes the message as if the put never happened. This pairs database updates with message publication in composite applications. A committed persistent put on a transmission queue still store-and-forwards if the channel is down—persistence and forwarding solve different problems.
Non-persistent messages reduce log pressure and latency—suitable for repeated sensor readings where the next sample replaces a lost one. Mixing persistent and non-persistent traffic on one queue manager requires monitoring log write rates. Batch puts with many small persistent messages may need tuning (grouping, larger messages, consumer scale) compared to fewer large messages. Never disable persistence on settlement queues to win benchmarks without explicit business sign-off.
12345678910DEFINE QLOCAL('PAYMENTS.WORK') REPLACE + DEFPSIST(YES) MAXDEPTH(1000000) + DESCR('Persistent by default') DEFINE QLOCAL('METRICS.IN') REPLACE + DEFPSIST(NO) MAXDEPTH(500000) + DESCR('Non-persistent by default') DISPLAY QLOCAL('PAYMENTS.WORK') DEFPSIST DISPLAY QLOCAL('METRICS.IN') DEFPSIST * Application: MD.Persistence = MQPER_AS_Q_DEF uses queue default * Application: MD.Persistence = MQPER_PERSISTENT forces persistent
After putting test messages with amqsput, stop and restart the queue manager in a controlled lab (with change approval). Persistent messages should remain; non-persistent test messages may not. Never test restart in production without procedures.
Persistent messages are written in the school safe before the teacher says "got it." If the classroom loses power, the safe keeps the letters. Non-persistent messages are like sticky notes on a desk—they might blow away if the window opens during a storm. Important homework goes in the safe; doodles might stay on the desk.
Queue DEFPSIST(NO), application sets MQPER_PERSISTENT. Is the message persistent? Why?
Choose persistent or not for: ATM withdrawal record, CPU temperature every second, legal contract PDF notification.
1. DEFPSIST(YES) on a queue means:
2. Persistent messages survive:
3. MQPER_NOT_PERSISTENT is appropriate when:
4. Before a persistent put returns success, the queue manager typically: