IPX/SPX Configuration and Management Manual

Managing NonStop™ IPX/SPX With the Subsystem
Control Facility (SCF)
IPX/SPX Configuration and Management Manual—425731-001
3-4
Object Attributes
There can be multiple IPXPROTO processes on a NonStop™ Himalaya S-series server.
You create each IPXPROTO process with either an SCF ADD PROCESS or a TACL
RUN command. (See ADD PROCESS on page 3-13 or Starting an IPXPROTO process
with a TACL RUN command: on page 1-6.)
SERVER Object
The SERVER object controls the Service Advertising Protocol (SAP) table, which
contains information about servers that are available on the LAN. The SAP table name
is always #SAP and is preceded by the IPXPROTO process name.
The SERVER object is subordinate to the PROCESS object. There is one SERVER
object for each PROCESS object. The PROCESS object must be in a STARTED state
when commands are issued against the SERVER object.
Object Attributes
Depending on the action of the command, you also may need to provide one or more
attribute specifiers (each consisting of an attribute name and value) to indicate which of
the object’s attributes are to be changed and what the new value is to be. Some
NonStop™ IPX/SPX objects have an associated set of attributes that you can define and
alter through the SCF ADD and ALTER commands. (See ADD Command on page 3-13
or ALTER Command on page 3-16.) Each of these object attributes identifies some
characteristic of that object and has an associated set of values. Default values exist for
many attributes. You can use the SCF INFO command to display the current attribute
values for an object. (See INFO Command
on page 3-20.)
The details of the required syntax for each attribute specifier you can use with the
NonStop™ IPX/SPX subsystem are described under the individual commands (see SCF
Command Overview on page 3-6).
Summary States
In Distributed Systems Management (DSM) interfaces to NonStop™ Himalaya S-series
data communications subsystems, one of the generally defined possible conditions of an
object is known as a summary state. A summary state differs from a state in two ways.
First, a summary state pertains to the management of an object, whereas a state can
convey other kinds of information about the object. Second, summary states are defined
the same way for all NonStop™ Himalaya S-series data communications subsystems,
whereas the set of possible states differs from subsystem to subsystem. The management
programming interfaces to NonStop™ Himalaya S-series data communications
subsystems refer to summary states rather than to states. The summary states supported
by the NonStop™ IPX/SPX subsystem are STARTING, STARTED, STOPPING,
STOPPED, ABORTING, and ABORTED.
Some commands can affect certain objects only when the objects are in particular
summary states. When a NonStop™ IPX/SPX object is in the STARTED summary state,
for example, the object is available for data transfer. When a NonStop™ IPX/SPX object
is in the STOPPED summary state, the object is defined but is not available for data
transfer.