![HP Integrity NonStop NS-series Operation Manual Download Page 197](http://html.mh-extra.com/html/hp/integrity-nonstop-ns-series/integrity-nonstop-ns-series_operation-manual_164441197.webp)
Starting and Stopping the System
HP Integrity NonStop NS-Series Operations Guide — 529869-005
15 -21
Getting a Corrupt System Configuration File
Analyzed
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
on page 15-8.
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-15.
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.