HP StorageWorks XP Remote Web Console Software - Manual (Page 169)

1. Temporarily suspend all application I/O operations to the M-VOL.
2. Enter an IEA491E message in the system log (SYSLOG) which indicates the time that the
M-VOL was suspended. Make sure that the system log is common to both the main and remote
OSs.
3. Place specific information about the failure (SIM) in the SYS1.LOGREC dataset for use by
service personnel.
4. Wait for the IEA491E message to reach the remote system.
5. Resume all host application I/O operations to the M-VOL. If the M-VOL fence level setting
does not allow subsequent updates, the MCU will return a unit check for all subsequent write
I/O operations, and the application will terminate.
Make sure that the MCUs and RCUs are configured to report the service-level SIMs to the host.
Select the Service SIM of Remote Copy = Report setting on the RCU Option dialog box.
File and Database Recovery Procedures
When a TrueCopy for Mainframe Sync pair is suspended, or when the MCU fails due to a disaster,
the R-VOL may contain in-process data. A data set could be open, or transactions may not have
completed. Even if you use the Data fence level for all TrueCopy for Mainframe Synchronous pairs,
you need to establish file recovery procedures. These procedures should be the same as those used
for recovering any volume which becomes inaccessible due to control unit failure. These procedures
are more important if the Status or Never fence level settings are used.
TrueCopy for Mainframe Asynchronous does not provide any procedure for detecting and retrieving
lost updates. To detect and recreate lost updates, you must check other current information (for
example, database journal log file that was active at the primary system when the disaster occurred).
Note that the journal log file entries of most DBMS have the same system TOD clock information
that is used for the I/O time-stamps (when timer type = system). The TrueCopy for Mainframe
Asynchronous group consistency time can be extremely useful when performing this detection and
retrieval. Since this detection/retrieval process can take a while, your disaster recovery scenario
should be designed so that detection and retrieval of lost updates is performed after the application
has been started at the secondary system.
You should prepare for file and database recovery by using:
•
Files for file recovery (for example, DB2 log files which have been verified as current). To
ensure the currency of these files, use the Data fence level setting for the TrueCopy for
Mainframe pairs which contain these important files.
•
The sense information with system time stamp which will be transferred via ERC.
IMPORTANT: Remote copy and disaster recovery procedures are inherently complex. Consult
your HP account team on sense-level settings and recovery procedures.
CSUSPEND/QUIESCE TSO Command
See IBM documents SG24-2595, SC35-0355, and SC35-0169 for important information on the
optional QUIESCE parameter for the CSUSPEND TSO command.
CAUTION: The QUIESCE option of the CSUSPEND command has been disabled by APAR
OW15247 or APAR OW15248. See either of these APARs and the latest IBM PPRC documentation
for detailed information on the QUIESCE option of the CSUSPEND command. Check with your HP
account team before using the CSUSPEND command with the QUIESCE option to suspend TrueCopy
for Mainframe pairs on XP storage systems. If the CSUSPEND command with the QUIESCE option
is issued to certain volumes (for example, active SPOOL, PAGE, or CATALOG datasets, active
SYSRES volume), the attached host(s) may enter a deadlock condition and may require a storage
control IML to correct the condition. TrueCopy for Mainframe Asynchronous does not support the
CSUSPEND/QUIESCE option.
Using TrueCopy for Mainframe for Disaster Recovery 169