Open System Services Management and Operations Guide (G06.25+, H06.03+)

Open System Services Monitor
Open System Services Management and Operations Guide—527191-002
12-5
OSS Monitor Features
Fault Tolerance and Continuous Availability
All servers controlled through the OSS Monitor (except for the $ZTAnn transport agent
server) can be run as fault-tolerant process pairs. The OSS Monitor itself can be run as
a persistent process, as described in Starting the OSS Monitor as a Persistent Process
on page 2-9.
In the unlikely event that both the primary and backup OSS name server processes
fail, the OSS Monitor restarts an OSS name server and restarts any filesets that that
OSS name server was managing. If the OSS name server is not running with a backup
process and fails because of a processor halt, the OSS Monitor restarts the OSS name
server when the processor becomes available again.
The OSS Monitor remembers the state of all filesets (DIAGNOSING, STARTED,
STOPPED, or UNKNOWN) if it stops and is restarted, even after a system load.
Software Requirements
SCF is required for the OSS environment, and the version of SCF must be compatible
with that of the OSS PM. You can determine the versions of SCF and the OSS PM on
your system by using the SCF VERSION command described in VERSION SUBSYS,
VERSION MON, and VERSION PROCESS Commands on page 12-86.
Localization
The OSS PM does not use the National Language Support (NLS) product. All error
messages and help text are displayed in English.
Networking and Distributed Processing
The OSS Monitor controls one local NonStop S-series or NonStop NS-series node.
Error Handling
The OSS PM defines a set of SPI error messages specific to the OSS environment
that are returned from the OSS Monitor. For normal successful completion of all
commands, the standard SPI status value of ZSPI^ERR^OK is returned.
Some OSS Monitor commands require that the OSS Monitor access its configuration
files. If the OSS Monitor cannot access these files or if they contain invalid data, an
error is returned.
For each command involving a fileset, the OSS Monitor first checks whether the fileset
exists by searching the ZOSSFSET file for an entry whose fileset name matches the
desired name. If the fileset name is successfully located in the ZOSSFSET file, the
OSS Monitor then verifies that the current object state of the fileset is compatible with
the initial state required by the command being executed. If the fileset is not
successfully located, the appropriate SPI error is returned.