MQ Logs

IBM MQ logs on z/OS are the flight recorder for everything the queue manager must remember across a failure. When an application puts a persistent payment message, MQ does not only write bytes to a page set—it first records the intention in the active log. That write-ahead discipline means a sudden LPAR crash or subsystem restart can replay log records and restore queues to a consistent point. Beginners see “log full” messages in the operations log and learn that messaging throughput and recovery are linked. Active logs are circular in purpose but linear data sets in implementation: they fill, archive, and reuse under administrator control. This tutorial explains what log records contain at a conceptual level, Log 1 and Log 2 rotation, relationship to page sets and BSDS, sizing and monitoring, archive handoff, and how logs differ from distributed linear logs on Linux—so you can read CSQ messages and capacity reports without fear.

Why MQ Needs Logs

Page sets hold message data on disk. Logs hold the ordered history of changes required to make page set updates crash-safe. Without logging, a power loss during a put could leave a message half-written or a queue depth wrong. With logging, restart recovery reapplies or undoes work consistently. Logs also support media recovery when page sets are restored from backup—you replay archive logs forward to the desired point in time.

Active Log Data Sets

Write-Ahead Logging Flow

1. Application MQPUT persistent message with syncpoint or equivalent commit path.
2. Queue manager formats log record describing the change.
3. Log record written to current active log and forced to DASD.
4. Page set updated with message data and metadata.
5. Commit visible to other applications after log and page set rules satisfied.

Non-persistent traffic skips much of this path for performance, which is why fire-and-forget telemetry tolerates loss but payment queues use DEFPSIST(YES) and syncpoint discipline.

Log 1 and Log 2 Rotation

Two active logs let the queue manager archive one while the other accepts new records. When Log 1 reaches capacity, the archiving process copies records to archive log data sets and updates BSDS with range information. Log 2 becomes the primary write target during portions of this cycle depending on release and configuration. Operators schedule archiving so active logs never simultaneously unavailable and full—a recipe for CSQ messages and application backpressure.

What Drives Log Volume

• Persistent message puts and gets under syncpoint.
• High-rate durable publish/subscribe with persistence.
• Object definition changes ALTER and DEFINE during migrations.
• Long-running transactions holding log space until commit.
• Indoubt units of work blocking log reuse in edge cases.

Capacity planning estimates megabytes per second from peak persistent throughput, message size, and syncpoint frequency. Undersized logs cause frequent archive cycles and operational noise; oversized logs waste DASD but buy time during archive delays.

Monitoring Active Logs

1
2
3
4
/* Operator-oriented — exact commands vary by release
   DISPLAY LOG DETAILS
   DISPLAY QMSTATUS
   Review CSQOUT for CSQJ* log-related messages */

Watch percent full, archive in progress flags, and whether puts are delayed for log. Automate alerts before ninety percent full. Correlate spikes with batch windows or new persistent interfaces.

Logs, BSDS, Page Sets, Archives

BSDS is the index of log and recovery metadata—see the BSDS tutorial. Page sets store messages. Active logs store change records. Archive logs store historical log ranges for recovery. Checkpoints mark points where recovery can start efficiently on page sets. The five topics form one recovery story; learn them in order when studying z/OS MQ operations.

Recovery Scenarios

Explainer: Receipt Before Goods on the Shelf

The log is the cashier writing a receipt before stock is placed on the shelf. If the store loses power, receipts tell you what should be on the shelf when lights return.

Explain Like I'm Five

MQ writes in a diary every important change before it finishes. If the computer trips, it reads the diary to remember what it was doing.

Practice Exercises

Exercise 1

Explain why persistent puts increase log I/O compared to non-persistent.

Exercise 2

Sketch Log 1 archive while Log 2 receives writes during a peak batch hour.

Exercise 3

List five monitoring signals for impending log full conditions.

Frequently Asked Questions

Test Your Knowledge