Cluster I/O Protocols (CIP) Configuration and Management Manual (H06.16+, J06.05+)

Configuring CIP Processes for Persistence
Three types of CIP processes run on the NonStop host system:
• CIPMAN. The CIPMAN process is the main management component on the NonStop host
system side of the CIP subsystem. The CIPMAN object is the root of all other CIP configuration
objects on the NonStop host system side and is used to configure, control, and query the
components of CIP on its local system. One CIPMAN process pair runs on each NonStop host
system. You can run the CIPMAN process pair only in processors 0 and 1 (the location of
$System.)
• CIPMON. The CIPMON process is a monitor process (MON object). It is responsible for CLIM
connection management and for stack operations other than data transfer, for example socket
migration and OSS shared sockets. You configure one CIPMON process per processor, for
a maximum of 16 CIPMON processes per NonStop host system.
• CIPSAM (for IP CIP only). The CIPSAM process pair is a transport provider: it provides the
Socket Interface TCP^PROCESS^NAME. You configure as many CIPSAM process pairs as
you need to serve applications on the local system.
To ensure the availability of your CIP subsystem, CIPMAN, CIPSAM (IP CIP only), and CIPMON
are configured as in the Kernel subsystem. These processes are pre-configured in manufacturing.
See Chapter 2 (page 62) for a list of pre-configured processes.
The SCF commands directed to the Kernel subsystem add the CIPMAN, CIPSAM and CIPMON
processes to the NonStop system configuration database. For information about the attributes
shown in these configuration examples, see the SCF Reference Manual for the Kernel Subsystem.
The CIPMAN, CIPSAM, and CIPMON processes are system-managed processes (managed by the
$ZPM persistence manager). By adding CIPMAN (#ZZCIP) with a nonzero AUTORESTART attribute
and a STARTMODE attribute set to SYSTEM, makes these processes persistent, so whenever the
processes stop, $ZPM restarts them. See “Starting CIP on the NonStop Host System” (page 100)
for examples of the SCF commands for adding these processes to the Kernel subsystem.
Other CIP Management Objects
In addition to the CIPMAN, CIPSAM and CIPMON processes, these CIP management objects are
also required.
• CLIM. The CLIM object on the NonStop host system represents the NonStop host system
interface to a CLIM; it does not really represent the CLIM device itself. The CLIM itself starts
operating as soon as it boots the CLIM software, but the NonStop host system gains access
to the CLIM by starting the CLIM object.
• PROVIDER (for IP CIP only). The PROVIDER object represents a transport service provider and
directs socket requests to a specific CLIM. Each provider must have a corresponding CIPSAM
process whose name is used by applications to select the transport service provider. It is best
to make the provider name the same as the CIPSAM name. If you do not, then you must specify
a TPNAME attribute in the ADD PROVIDER command and that attribute must match the CIPSAM
name.
To define these objects:
1. For IP CIP only, add a PROVIDER object by using the SCF ADD PROVIDER command:
> ADD PROVIDER $ZZCIP.ZTC02
The Provider name must match the CIPSAM process. You can either name the Provider to
match the CIPSAM process (for example, $ZZCIP.ZTC02, where $ZTC02 is a CIPSAM process
name) or use the TPNAME attribute (for example, $ZZCIP.SAM1 , TPNAME ZTC02, where
$ZTC02 is CIPSAM process name).
NOTE: If you want more than one provider for this CLIM, see “Setting Up Multiple Providers
per CLIM” (page 129) and “Changing Providers, Adding and Starting a CLIM (IP and Telco
Only)” (page 130).
Configuring CIP 73