after losing logs, restart" /> Restarting if you have lost your log data sets

 

Restarting if you have lost your log data sets

If, after stopping a queue manager (using the STOP QMGR command), both copies of the log are lost or damaged, we can restart the queue manager providing you have a consistent set of page sets (produced using Method 1: Full backup).

Follow this procedure:

  1. Define new page sets to correspond to each existing page set in your queue manager. See the WebSphere MQ for z/OS System Setup Guide for information about page set definition.

    Ensure that each new page set is larger than the corresponding source page set.

  2. Use the FORMAT function of CSQUTIL to format the destination page set. See Formatting page sets (FORMAT) for more details.

  3. Use the RESETPAGE function of CSQUTIL to copy the existing page sets or reset them in place, and reset the log RBA in each page. See Copying a page set and resetting the log (RESETPAGE) for more information about this function.

  4. Redefine your queue manager log data sets and BSDS using CSQJU003 (see The change log inventory utility (CSQJU003)).

  5. Restart the queue manager using the new page sets. To do this, you do one of the following:

    • Change the queue manager started task procedure to reference the new page sets. See the WebSphere MQ for z/OS System Setup Guide for more information.

    • Use Access Method Services to delete the old page sets and then rename the new page sets, giving them the same names as the old page sets.

Attention:
Before you delete any WebSphere MQ page set, ensure that you have made the required backup copies.

If the queue manager is a member of a queue-sharing group, GROUP and SHARED object definitions are not normally affected by lost or damaged logs. However, if any shared-queue messages are involved in a unit of work that was covered by the lost or damaged logs, the effect on such uncommitted messages is unpredictable.

Note:
If logs are damaged and the queue manager is a member of a queue-sharing group, the ability to recover shared persistent messages might be lost. Issue a BACKUP CFSTRUCT command immediately on another active queue manager in the queue-sharing group for all CF structures with the RECOVER(YES) attribute.