Recovering a queue-sharing group at the alternative site
Before you can recover the queue-sharing group, you need to prepare the
environment:
- If you have old information in your Coupling Facility from practice startups
when you installed the queue-sharing group, you need to clean this out first
(if you do not have old information in the Coupling Facility, you can omit
this step:
- Enter the following z/OS command to display the CF structures for this
queue-sharing group:
D XCF,STRUCTURE,STRNAME=qsgname
- 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
- Delete all the CF structures using the following command for each structure:
SETXCF FORCE,STRUCTURE,STRNAME=strname
- Restore DB2(R) systems and data-sharing groups
- 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 you 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.
To recover the queue managers in the queue-sharing group:
- Define new page set data sets and load them with the data in the copies
of the page sets from the primary site.
- Define new active log data sets.
- Define a new BSDS data set and use Access Method Services REPRO to copy
the most recent archived BSDS into it.
-
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.
- Use the change log inventory utility, CSQJU003, to register this latest
archive log data set in the BSDS that you have just restored, using the values
recorded in Step 4.
- Use the DELETE option of CSQJU003 to remove all active log information
from the BSDS.
- Use the NEWLOG option of CSQJU003 to add active logs to the BSDS, do not
specify STARTRBA or ENDRBA.
-
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.
- 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 your logs.
You must add the CRESTART record to the
BSDS for each queue manager within the queue-sharing group.
- 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.
- Once all the queue managers are active, issue a RECOVER CFSTRUCT command
for each CF application structure.
If you 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.