IBM MQ logging internals explain why a queue manager can promise that persistent messages survive a power cut—and why that same queue manager sometimes sits at ninety-nine percent CPU for an hour on Monday morning replaying logs after an unclean shutdown. The log is a write-ahead journal: before a persistent message or definition change is considered committed, MQ records the operation in log files on disk. Only after the log is safe can the queue data files reflect the change. Beginners see Log and Q directories under the queue manager path without knowing that restart merges them. Administrators who set LogPrimaryFiles too small see AMQ errors about log full; those who set gigantic logs without monitoring disk wonder why backup windows balloon. This tutorial explains linear versus circular logging concepts, primary and secondary log file roles, checkpointing intuition, interaction with syncpoint commit, log full and media recovery symptoms, tuning trade-offs, z/OS differences at overview level, and what to capture for IBM support when log-related failures occur.
Application issues MQPUT persistent under syncpoint. Queue manager appends log records describing the put and index updates. On MQCMIT, log records are forced to disk according to durability settings. Queue file pages may be updated immediately or lazily depending on internal buffering, but recovery can always redo or undo using the log if crash happens mid-flight. Non-persistent messages may skip much log work—faster but not restart-safe on the queue.
| Model | Behavior | Typical platform |
|---|---|---|
| Linear | Log extents grow or archive | Distributed Linux/Windows |
| Circular | Reuse log range in ring | z/OS traditions |
| Media recovery | Archive log to tape/cloud | Enterprise backup policy |
LogPrimaryFiles sets how many primary log files exist at creation; each file size also configured in mq.ini. Secondary files extend the pool when primaries fill during a spike. Too small: frequent extension operations and risk of log full if disk quota hit. Too large: wasted disk and longer replay. Change requires planning—some changes need queue manager recreate on older releases; verify IBM doc for your version. DISPLAY QMSTATUS shows log utilization metrics on supported releases.
123456# Illustrative mq.ini fragment — verify attribute names for your version LogType: LINEAR LogPrimaryFiles: 3 LogSecondaryFiles: 2 LogFilePages: 4096 # LogFilePages * page size ≈ per-file capacity
The log is a notebook where every change is written before papers go into the filing cabinet (queue files). If the office floods mid-afternoon, you replay the notebook to know which papers were officially filed.
Periodically MQ checkpoints: flush updated queue file pages and mark log position so replay skips already-settled work on restart. Frequent checkpoints shorten restart but add I/O during run. Rare checkpoints lengthen restart. Tuning is workload dependent—batch overnight may tolerate long restart; 24x7 retail may pay checkpoint I/O for faster failover.
When log cannot extend—disk full or max files—persistent puts fail with MQRC LOGGING_NOT_AVAILABLE or queue manager may stop depending on severity. Operations: add disk, extend log, archive inactive logs per procedure, investigate runaway uncommitted transactions holding log space.
AMQ61xx and AMQ70xx families often relate to log problems—read full FCID in FDC. strmqtrc with log components for short reproduction. Compare dspmqlog or platform log print commands. Never delete active log files manually.
Logging is writing down every move in a game before you change the board, so if the table flips you can put the pieces back where they were supposed to be.
DISPLAY QMSTATUS and note log-related fields on lab QM.
Calculate disk for LogPrimaryFiles given LogFilePages.
Describe what happens on restart after kill -9 on queue manager process.
1. MQ log purpose:
2. Linear log grows:
3. Log full causes:
4. Replay happens at: