Instruction manual

CHAPTER 8. SYSTEM BACKUP FOR DEFINITY G3r
If the user requests that announcements be saved to a tape, the tape must be in service (E14).
If the user requests that announcements be saved to the standby processor, the standby proces-
sor must be in service and shadowing must be enabled (E16).
If an error is encountered in the above steps, the save operation is not attempted.
When MSS devices on both processors in a duplicated system are specified, the save announce-
ments operation will save announcement data from the announcement board to the active and
standby MSS devices in parallel. The status of each save operation is reported to the user
separately. If one of the save operations fail, the save operation to the other device continues.
The goal is to save the new announcement data on some MSS device so that it is not totally lost;
this will cause the announcement data to be inconsistent between these MSS devices.
The command completion status is displayed on the system administration terminal. The screen
will be identical to that shown in Figure 5-1, except it will be entitled “Save Announcement.” The
displayed information includes a success or error message for each processor.
In case of a failure, it is the user's responsibility to make the announcement
files on the two MSS
devices consistent. The files may become inconsistent due to hardware
failures or if “save” to
one device fails while the other continues; for example, while using the
either
option.
If announcement files are inconsistent due to failure on the hardware used during the
save
announcements
command, the user should take appropriate action based on the error message
returned. Maintenance software monitoring this hardware
will log a hardware error with mainte-
nance. Maintenance software will invoke tests to diagnose and attempt to correct the problem. If
maintenance software fails to correct the problem, an alarm would be raised and the system
technician should take appropriate action.
The
save announcements
command writes two time
-stamped identical copies of announcement
data to the selected device(s). The time stamp for both copies will be the same (it will be the
time of writing to the first copy). Each copy is written as consecutive 2K Blocks. Each block con-
tains a checksum for error detection purpose. Each copy contains the following status informa-
tion: time stamp, and the state of the copy (i.e., “good” or “bad”).
The save operation writes one complete copy first, then writes the second copy in a different area
of the device. The save operation only updates one of the copies at a time. The save operation
will always choose to overwrite the “least good” copy first. The following selection criteria is
applied separately on the active and standby devices:
If a copy has a bad status, then always overwrite that copy first.
If both copies have good status, then overwrite the one with the older time stamp. If both
time stamps are the same, then it doesn’t matter which copy is overwritten first since
both copies are identical.
Each copy of the announcement data is marked “bad” prior to an announcement save operation,
and it will only be marked “good” after the save operation to that file completes successfully. Any
failure during the save operation, including a system crash, should only affect one copy of
announcement data. In that case, the affected copy will be marked with a “bad” status indicator
and will not be used to restore announcements into the system. Thus, an intact copy of
announcement data can be used as a backup. Normally at least one of the two copies should be
in a good state.
8-4