Recovering a queue sharing group at the alternative site

For to recover a queue sharing group, we must understand the steps needed to prepare the recovery, and the steps needed to recover the queue managers in the queue sharing group.

Before we can recover the queue sharing group, we need to prepare the environment:

1. If we have old information in your coupling faciltiy from practice startups when you installed the queue sharing group, we need to clean this out first (if we do not have old information in the coupling faciltiy, we can omit this step:
   1. Enter the following z/OS command to display the CF structures for this queue sharing group:

      D XCF,STRUCTURE,STRNAME= qsgname*
      

   2. For all structures that start with the queue sharing group name, use the z/OS command SETXCF FORCE CONNECTION to force the connection off those structures:

      SETXCF FORCE,CONNECTION,STRNAME= strname,CONNAME=ALL
      

   3. Delete all the CF structures using the following command for each structure:

      SETXCF FORCE,STRUCTURE,STRNAME= strname
      

2. Restore Db2 systems and data-sharing groups.
3. Recover the CSQ.ADMIN_B_STRBACKUP table so that it contains information about the most recent structure backups taken at the prime site. Note: It is important that the STRBACKUP table contains the most recent structure backup information. Older structure backup information might require data sets that we have discarded as a result of the information given by a recent DISPLAY USAGE TYPE(DATASET) command, which would mean that your recovered CF structure would not contain accurate information.
4. Run the ADD QMGR command of the CSQ5PQSG utility for every queue manager in the queue sharing group. This will restore the XCF group entry for each queue manager. When you run the utility in this scenario, the following messages are normal:

   CSQU566I Unable to get attributes for admin structure, CF not found
   or not allocated
   CSQU546E Unable to add QMGR queue_manager_name entry,
   already exists in DB2 table CSQ.ADMIN_B_QMGR
   CSQU148I CSQ5PQSG Utility completed, return code=4
   

To recover the queue managers in the queue sharing group:

1. Define new page set data sets and load them with the data in the copies of the page sets from the primary site.
2. Define new active log data sets.
3. Define a new BSDS data set and use Access Method Services REPRO to copy the most recent archived BSDS into it.
4. Use the print log map utility CSQJU004 to print information from this most recent BSDS. At the time this BSDS was archived, the most recent archived log you have would have just been truncated as an active log, and does not appear as an archived log. Record the STARTRBA, STARTLRSN, ENDRBA, and ENDLRSN values of this log.
5. Use the change log inventory utility, CSQJU003, to register this latest archive log data set in the BSDS that we have just restored, using the values recorded in Step 4.
6. Use the DELETE option of CSQJU003 to remove all active log information from the BSDS.
7. Use the NEWLOG option of CSQJU003 to add active logs to the BSDS, do not specify STARTRBA or ENDRBA.
8. Calculate the recoverylrsn for the queue sharing group. The recoverylrsn is the lowest of the ENDLRSNs across all queue managers in the queue sharing group (as recorded in Step 4 ), minus 1. For example, if there are two queue managers in the queue sharing group, and the ENDLRSN for one of them is B713 3C72 22C5, and for the other is B713 3D45 2123, the recoverylrsn is B713 3C72 22C4.
9. Use CSQJU003 to add a restart control record to the BSDS. Specify:

   CRESTART CREATE,ENDLRSN= recoverylrsn
   

   where recoverylrsn is the value you recorded in Step 8.

   The BSDS now describes all active logs as being empty, all the archived logs you have available, and no checkpoints beyond the end of our logs.

   We must add the CRESTART record to the BSDS for each queue manager within the queue sharing group.

10. Restart each queue manager in the queue sharing group with the usual START QMGR command. During initialization, an operator reply message such as the following is issued:

    CSQJ245D +CSQ1 RESTART CONTROL INDICATES TRUNCATION AT RBA highrba.
    REPLY Y TO CONTINUE, N TO CANCEL
    

    Reply Y to start the queue manager. The queue manager starts, and recovers data up to ENDRBA specified in the CRESTART statement.

    At IBM MQ Version 7.0.1 and later, the first queue manager started can rebuild the admin structure partitions for other members of the queue sharing group as well as its own, and it is no longer necessary to restart each queue manager in the queue sharing group at this stage.

11. When the admin structure data for all queue managers has been rebuilt, issue a RECOVER CFSTRUCT command for each CF application structure.

    If we issue the RECOVER CFSTRUCT command for all structures on a single queue manager, the log merge process is only performed once, so is quicker than issuing the command on a different queue manager for each CF structure, where each queue manager has to perform the log merge step.

When conditional restart processing is used in a queue sharing group, IBM WebSphere MQ Version 7.0.1 and later queue managers, performing peer admin rebuild, check that peers BSDS contain the same CRESTART LRSN as their own. This is to ensure the integrity of the rebuilt admin structure. It is therefore important to restart other peers in the QSG, so they can process their own CRESTART information, before the next unconditional restart of any member of the group.

Parent topic: Restarting IBM MQ