SCF Reference Manual for the Kernel Subsystem

• The STARTMODE value takes effect at the next system load or processor reload. For example,
if you configure a process with a STARTMODE value of SYSTEM, it is started during the
SYSTEM phase when the system is next loaded or when the processor in which the process
is configured is next reloaded.
When the system is loaded, a generic process is automatically started at the first reload of its
processor or processors unless its start mode is MANUAL or DISABLED. Or you can use the
START command on a process with any start mode except DISABLED.
• When configuring the STARTMODE attribute of a generic process, it is important to understand
that a generic process started in a specific phase must be able to resolve dependencies on
resources not yet available. This understanding is especially important with regard to generic
processes configured to start in the KERNEL or SYSTEM phase of the system load or processor
reload.
For example, the storage subsystem is initialized during the KERNEL phase. Disks supported
by a process in the loading processor might not be available until the storage subsystem has
completed its initialization in that processor. If you configure a generic process to start during
the KERNEL phase, that process must be able to handle the situation where a device is not
available until after that generic process is started; that is, it must continue running without the
necessary resources being available. That process must also be capable of recognizing when
those resources have become available and take necessary steps to use them.
For this reason, HP suggests that you configure a generic process using the APPLICATION or
MANUAL start mode.
• When the system is loaded (and the processor in which a generic process is configured is
reloaded), the configured value for the STARTMODE attribute takes effect, regardless of the
current state of the process. For example, if you configure a process with a STARTMODE value
of APPLICATION, it will be started in the APPLICATION phase when the system is next loaded,
even if the process was in the STOPPED object state when the system was loaded.
When the processor in which a generic process is configured is later reloaded, the persistence
of the process depends on its last object state (unless the STARTMODE is DISABLED). For
example, if you abort a generic process, a processor reload does not restart the process. You
must restart it manually.
Persistence Considerations
When specifying an AUTORESTART value for a generic process, consider that:
• The persistence of a generic process governs the restart of a generic process on a running
system; that is, after the system is up (and the processor in which the generic process is
configured and loaded). This is in contrast to the start mode of a generic process, which
governs its startup during system load (and initial processor reload).
• A generic process is configured to be persistent if it is configured with a nonzero AUTORESTART
value (described on page 6-6). This AUTORESTART value is known as the persistence count.
A generic process with an AUTORESTART value of 10 (the maximum) is said to have a
persistence count of 10. That is, the process can be restarted up to 10 times in a 10-minute
interval. After 10 minutes of uninterrupted operation, the persistence count is restored to its
original value.
• A generic process that is configured with a nonzero AUTORESTART value is known as a
persistent generic process. If a persistent generic process abends due to a processor failure,
the $ZPM persistence manager restarts it but does not decrement the persistence count.
If a persistent generic process abends or is stopped outside of SCF (but not by a processor
failure), the $ZPM persistence manager restarts it and decrements the persistence count by 1.
$ZPM responds this way until the persistence count is reduced to zero (or until the user stops
the generic process with an SCF ABORT command).
Controlling When a Generic Process Starts 45