IBM MQ for z/OS writes persistent data to a set of active log data sets to ensure that it can recover messages in the event of a queue manager or system failure. Over time the active logs are copied to archive log data sets which can be used for media recovery or audit purposes. Information about the state of the active and archive logs are stored in a boot strap data set (BSDS).
The active log, archive log and BSDS are critical to the functioning of an MQ for z/OS queue manager. If the BSDS is corrupted the queue manager won’t be able to start up. If the active or archive logs are corrupted, then the queue manager might not be able to recover any inflight transactions or message state. If backup data sets aren’t available, it might be necessary to recreate the queue manager from scratch.
In order to minimize the risk of corruption or lose of these data sets, MQ for z/OS can be configured to create duplicates of them which are kept in a consistent state by the queue manager. The TWOACTV system parameter means that the queue manager will write a copy of all data being logged to a pair of active log data sets (often referred to as dual logging). The TWOARCH system parameter means that the queue manager will write two copies of each archive log (dual archiving). And the TWOBSDS system parameter means that the queue manager will keep two copies of the BSDS (dual BSDS).
These three system parameters can be enabled independently, but its most common to either have them all enabled, or all disabled.
If a queue manager attempts to use one of these data sets and finds that it is unable to, for example because the contents are corrupted, then it will fallback to the alternate copy of the data, if enabled using the above parameters, and carry on processing.
Use of dual logging comes with a performance cost of between 5-50% when doing persistent messaging, which should be traded off against the resiliency benefits. There are additional CPU overheads with dual archiving, but performance costs aren’t significant. Of course, by keeping two copies of the data, disk usage is doubled.
Customers using MQ for z/OS typically use synchronous and / or asynchronous disk mirroring with active logs, archive logs and BSDS. We regularly get asked whether disk mirroring technology means that dual archiving, etc is needed. In fact I got asked this yesterday, which is why I am writing this blog post.
Disk mirroring is great technology, it transparently (in the case of synchronous mirroring with hyper-swap) protects against loss of data caused by a disk failure. However, if you accidentally delete a data set that is being mirrored then that delete will also occur (synchronously, or asynchronously) on the mirrored device. Similarly, if another program accidentally overwrites the data in a mirrored data set, then that overwrite will be replicated to the mirrored copy.
Use of dual logging, dual archiving or dual BSDS reduces the risk of MQ’s data being lost in these “user error” scenarios. In my experience, once customers appreciate that these sorts of failures can happen even with disk mirroring, they tend to keep dual logging, archiving and BSDS turned on. But it is up to you!
If you have any questions on this topic, or anything else related to MQ, please reach out to me at lemingma@uk.ibm.com.
#IBMMQ