NonStop NS-Series Operations Guide (H06.12+)

a. Load the system as described in “Starting a System” (page 158). In the Configuration
File box, select Base (CONBASE) as the configuration file.
b. Reload the remaining processors. See “Reloading Processors” (page 163).
c. From the Startup TACL window, configure a tape drive.
d. Restore a previously backed-up configuration file.
e. Load the system as described in “Starting a System” (page 158) from the current
configuration file (CONFIG). Check that the CIIN file is enabled.
11. After you load a system from a saved version (CONFxxyy) of the system configuration
database file or the CONFBASE, verify that no pending changes to system attributes appear.
From a TACL prompt:
INFO SUBSYS $ZZKRN
Pending changes can appear (but are misleading) if the earlier configuration has different
system name, number, or time attributes than the configuration you replaced. For example,
if you load the \EAST system from the CONFBASE file (which specifies \NONAME as the
system name), an INFO SUBSYS $ZZKRN command displays \EAST as the current system
and \NONAME as a pending change. Enter an ALTER SUBSYS command to change the
system name to \EAST and cause the pending change to disappear. It is not displayed when
you enter INFO.
Getting a Corrupt System Configuration File Analyzed
If the current system configuration file is corrupt, send it to your service provider for an analysis:
1. Return to a saved, stable configuration file. See “Configuration File” (page 160).
2. After the system is up and stable, copy to a backup tape the corrupt CONFSAVE file. For
example:
> BACKUP $TAPE, $SYSTEM.ZSYSCONF.CONFSAVE, LISTALL
You must backup the CONFSAVE file before you perform the next system load. Another
system load operation overwrites the CONFSAVE file you want analyzed.
3. Submit the tape to your service provider for analysis, along with a copy of any SCF command
file or SCF log file of the commands that were part of the process that created the corrupt
configuration.
Recovering From a Reload Failure
If a reload is not successful:
1. Check the Processor Status dialog box of the OSM Low-Level Link for halt codes. Look up
the halt codes in the Processor Halt Codes Manual for further information about the cause of
failure and the appropriate recovery procedure.
2. Check the System Load dialog box of the OSM Service Connection for messages.
3. Check for any event messages. Look up event messages in the EMS logs ($0 and $ZLOG)
and refer to the OSM Event Viewer or the Operator Messages Manual for further information
about the cause, effect, and recovery for any event message.
4. Perform a processor dump, if needed, as described in Dumping a Processor to Disk on
page 9-16.
5. Try a soft reset of the processor.
6. Reload the processor or processors as described in Section 9, Processors and Components:
Monitoring and Recovery. If you cannot to correct the problem, contact your service provider.
7. If you still cannot reload the processor or processors, try a hard reset of the processor.
Troubleshooting and Recovery Operations 169