Recovery manager messages (CSQR...)

This message delimits the beginning of the restart process within startup. The phases of restart are about to begin. These phases are necessary to restore the operational environment to that which existed at the time of the previous termination and to perform any recovery actions that might be necessary to return IBM® MQ-managed resources to a consistent state.

This message delimits the completion of the restart process within startup.

Startup continues.

The message indicates the first phase of the restart process is in progress and identifies the log positioning RBA of the checkpoint from which the restart process will obtain its initial recovery information.

Restart processing continues.

This message indicates the completion of the first phase of the restart process. The counts indicate the number of units of recovery with an execution state during a previous queue manager termination that indicates (to ensure MQ resource consistency) some recovery action must be performed during this restart process. The counts might provide an indication of the time required to perform the remaining two phases of restart (forward and backward recovery).

The IN COMMIT count specifies the number that had started, but not completed, phase-2 of the commit process. These must undergo forward recovery to complete the commit process.

The INDOUBT count specifies the number that were interrupted between phase-1 and phase-2 of the commit process. These must undergo forward recovery to ensure that resources modified by them are unavailable until their INDOUBT status is resolved.

The INFLIGHT count specifies the number that neither completed phase-1 of the commit process nor began the process of backing out. These must undergo backward recovery to restore resources modified by them to their previous consistent state.

The IN BACKOUT count specifies the number that were in the process of backing out. These must undergo backward recovery to restore resources modified by them to their previous consistent state.

Restart processing continues.

The message indicates the completion of the forward recovery restart phase. The counts indicate the number of units of recovery with recovery actions that could not be completed during the phase. Typically, those in an IN COMMIT state remain because the recovery actions of some subcomponents have not been completed. Those units of recovery in an INDOUBT state will remain until connection is made with the subsystem that acts as their commit coordinator.

Restart processing continues.

The message indicates the completion of the backward recovery restart phase. The counts indicate the number of units of recovery with recovery actions that could not be completed during the phase. Typically, those in either state remain because the recovery actions of some subcomponents have not been completed.

Restart processing continues.

This message precedes a table showing the status of units of recovery (URs) after each restart phase. The message and the table will accompany the CSQR004I, CSQR005I, or CSQR006I message after each nested phase. At the end of the first phase, it shows the status of any URs that require processing. At the end of the second (forward recovery) and third (backout) phases, it shows the status of only those URs which needed processing but were not processed. The table helps to identify the URs that were active when the queue manager stopped, and to determine the log scope required to restart.

  T  CON-ID     THREAD-XREF     S   URID     TIME 

There was not enough storage available during the creation of the recoverable UR (unit of recovery) display table.

Restart continues but the status table is not displayed.

Increase the region size of the xxxxMSTR region before restarting the queue manager.

An internal error has occurred.

Restart continues but the status table is not displayed.

Note the error code in the message and contact your IBM support center.

An internal error has occurred.

Restart continues but the status table is not displayed.

Note the error code in the message and contact your IBM support center.

The checkpoint RBA in the conditional restart control record, which is deduced from the end RBA or LRSN value that was specified, is not available. This is probably because the log data sets available for use at restart do not include that end RBA or LRSN.

Restart ends abnormally with reason code X'00D99001' and the queue manager terminates.

Run the change log inventory utility (CSQJU003) specifying an ENDRBA or ENDLRSN value on the CRESTART control statement that is in the log data sets that are to be used for restarting the queue manager.

During restart, a unit of work was found that predates the oldest active log. Information about the unit of work is displayed in a table in the same format as in message CSQR007I.

Message CSQR021D is issued and the operator's reply is awaited.

An old unit of work was found, as indicated in the preceding CSQR020I message.

The queue manager waits for the operator's reply.

This message is sent if the operator answers 'Y' to message CSQR021D.

The indicated unit of work is committed.

This message is sent if the operator answers 'N' to message CSQR021D.

CSQR023I is also sent when an old unit of work which is already in the 'in-backout' state is identified. Units of work in the 'in-backout' state are ineligible for force commit processing as it can lead to a queue becoming unusable. For such units of work, the message CSQR021D is not issued, and no choice is possible.

The indicated unit of work is left for handling by the normal restart recovery process.

During checkpoint processing, an uncommitted unit of recovery was encountered that has been active for at least 3 checkpoints. The associated log records have been rewritten ('shunted') to a later point in the log, at RBA rba. The unit of recovery identifier urid together with the connection name name identify the associated thread.

Processing continues.

Uncommitted units of recovery can lead to difficulties later, so consult with the application programmer to determine if there is a problem that is preventing the unit of recovery from being committed, and to ensure that the application commits work frequently enough.

During checkpoint processing, an uncommitted unit of recovery was encountered that has been active for at least 3 checkpoints. However, the associated log records could not be rewritten ('shunted') to a later point in the log. The unit of recovery identifier urid together with the connection name name identify the associated thread.

The unit of recovery is not shunted, and will not participate in any future log shunting.

The most likely cause is insufficient active log data sets being available, in which case you should add more log data sets for the queue manager to use. Use the DISPLAY LOG command or the print log map utility (CSQJU004) to determine how many log data sets there are and what their status is.

Uncommitted units of recovery can lead to difficulties later, so consult with the application programmer to determine if there is a problem that is preventing the unit of recovery from being committed, and to ensure that the application commits work frequently enough.

The operator did not respond correctly to the reply message CSQR021D. Either 'Y' or 'N' must be entered.

The original message is repeated.

This indicates the log range that must be read to perform forward recovery during restart.

Restart processing continues.

This is issued periodically during restart recovery processing to show the progress of the forward recovery phase and the current status rebuild phase. For the forward recovery phase the log range that needs to be read is shown in the preceding CSQR030I message.

For the current status rebuild phase, the starting log RBA is shown in the preceding CSQR003I message and the end log RBA is shown in the preceding CSQJ099I message. The RBA represents the position in the recovery log during the forward recovery phase of current status rebuild.

Restart processing continues.

This indicates the log range that must be read to perform backward recovery during restart.

Restart processing continues.

This is issued periodically during restart recovery processing to show the progress of the backward recovery phase. The log range that needs to be read is shown in the preceding CSQR032I message.

Restart processing continues.

During queue manager restart it has been detected that one or more of the page sets that have been connected has been used at a higher version of queue manager code.

The queue manager will automatically perform special processing during restart to alter any messages stored on those page sets so they can be read by the current version of the queue manager. This special processing is dependent on there being no unresolved units of work found at the end of restart, so you might be prompted by way of further messages during restart to force commit these.

Restart processing continues.