What happens during restart and recovery

WebSphere MQ uses its recovery log and the bootstrap data set (BSDS) to determine what to recover when it restarts. The BSDS identifies the active and archive log data sets, and the location of the most recent WebSphere MQ checkpoint in the log.

After WebSphere MQ has been initialized, the queue manager restart process takes place as follows:

• Log initialization

• Current status rebuild

• Forward log recovery

• Backward log recovery

• Queue index rebuilding

When recovery has been completed:

• Committed changes are reflected in the data.

• In-doubt activity is reflected in the data. However, the data is locked and cannot be used until WebSphere MQ recognizes and acts on the in-doubt decision.

• Interrupted in-flight and in-abort changes have been removed from the queues. The messages are consistent and can be used.

• A new checkpoint has been taken.

• New indexes have been built for indexed queues containing persistent messages (described in Rebuilding queue indexes).

Batch applications are not notified when restart occurs after the application has requested a connection.

If dual BSDSs are in use, WebSphere MQ checks the consistency of the time stamps in the BSDS:

• If both copies of the BSDS are current, WebSphere MQ tests whether the two time stamps are equal. If they are not, WebSphere MQ issues message CSQJ120E and terminates. This can happen when the two copies of the BSDS are maintained on separate DASD volumes and one of the volumes was restored while the queue manager was stopped. WebSphere MQ detects the situation at restart.

• If one copy of the BSDS was de-allocated, and logging continued with a single BSDS, a problem could arise. If both copies of the BSDS are maintained on a single volume, and the volume was restored, or if both BSDS copies were restored separately, WebSphere MQ might not detect the restoration. In that case, log records not noted in the BSDS would be unknown to the system.