Issuing The Takeover Command In An Obey File; Monitoring Takeover Outcome - HP NonStop RDF J-series RVUs Management Manual

For j-series and h-series rvus
Table of Contents

Advertisement

By using the TAKEOVER ! version of the TAKEOVER command you eliminate the Expand
level-four timer and the prompt.
For super fast takeover, see
Your Backup System After Takeover" (page

Issuing the TAKEOVER Command in an Obey File

You have the following three options to issue the TAKEOVER command through an OBEY file.
1.
As stated in the section entitled
(page
102), you can issue RDFCOM commands in a TACL obey file or a script file. You issue
the command as follows:
RDFCOM <control-subvol-name>; Takeover !
Please note that you run this command on the backup system and that the
<control-subvol-name> is the name that identifies the specific RDF subsystem for which
you want to execute the Takeover command. It is suggested that you use the ! option for
simplicity. Otherwise you must configure your script file to handle the prompts that RDFCOM
asks when executing the Takeover command.
2.
The second option is to write the TAKEOVER command appended with the bang (!) character
in an EDIT file and OBEY the file from the RDFCOM prompt.
For example, consider an EDIT file RDFTKOV that has the following content:
TAKEOVER!
Now, you can obey the file RDFTKOV from the RDFCOM prompt, as shown below:
RDFCOM] obey RDFTKOV
3.
The third option is to write the TAKEOVER command appended with the bang (!) character
in an EDIT file and pass it as an IN file to RDFCOM.
For example, consider an EDIT file RDFTKOV has the following content:
TAKEOVER!
Now, you can use the EDIT file RDFTKOV as an INFILE to RDFCOM, using the following
command:
RDFCOM /IN RDFTKOV/
NOTE:
when issued in an IN file / OBEY file.

Monitoring Takeover Outcome

You can monitor the status of RDF takeovers by issuing a STATUS RDF command on the backup
system or by examining the events in the EMS log.
When all of the updater processes have stopped, the purger logs either the RDF event number
724 or 725 before stopping. Event 724 indicates that the takeover completed successfully. Event
725 indicates that it did not, and you should reissue the TAKEOVER command. Event 724 is
always followed by event 735, which indicates the last MAT position seen by the receiver process.
The 735 event is used primarily for triple contingency. These events will be followed by either
RDF event 888 or 858. See
For RDF network takeover considerations, see
For super fast takeover, see
Your Backup System After Takeover" (page
142
Critical Operations, Special Situations, and Error Conditions
"How to Plan for the Fastest Movement of Business Operations to
RDFCOM does not allow the TAKEOVER command without the bang (!) character
"Restoring the Primary System"
"How to Plan for the Fastest Movement of Business Operations to
144).
"Using RDFCOM Noninteractively (without an IN File)"
Chapter 14 (page
144).
for more information.
295).

Hide quick links:

Advertisement

Table of Contents
loading

This manual is also suitable for:

Nonstop rdf h-series rvusNonstop rdf

Table of Contents