OSI/AS Configuration and Management Manual

OSI/AS Configuration and Management Manual—424119-001
4-1
4
Installing and Configuring the
Subsystem
This section describes how to install the software components of an OSI/AS subsystem
and how to configure attributes for the OSI protocol layers that the subsystem
implements. The section also includes information on the tools and commands to use,
the interrelationships to consider, and the general procedures you need to follow to get
all the components of your OSI/AS subsystem up and running.
This section contains the following main topics:
•
Sequence of Tasks on this page
•
Configuring and Starting Subsystem Processes on page 4-4
•
Configuring OSI Protocol Attributes on page 4-15
•
Configuring Connections on page 4-20
•
Step-by-Step Configuration Example on page 4-36
•
Configuring Large X.25 Applications on page 4-39
•
Verifying Your Configuration on page 4-43
You should also read Section 6, Performance Considerations
. That section describes the
effect of various attributes on performance and is intended to help you plan your
configuration for optimal performance.
Sequence of Tasks
When installing and configuring your OSI/AS subsystem, the only sequence
requirement is that you must install the Network Layer and start the lines before you
install and configure the upper layers. However, we recommend that you install and
configure the OSI/AS subsystem in an orderly manner, using the following sequence:
1. Configure and start OSI/AS and underlying subsystem processes:
a. Install the Network Layer.
b. Create the MIB database.
c. Install the OSI manager process.
d. Add NSP, TSP, and TAPS processes.
e. Start TSP and TAPS processes.
For these tasks, you should understand how to manage processes within a NonStop
environment. You should know how to install communications I/O processes in your
NonStop system. You also need to be familiar with SCF.
Note. Always configure and manage the OSI/TS subsystem through the OSI/AS OSI
manager process, using OSI/AS commands (not OSI/TS commands). This practice
ensures that all configuration changes are registered in the MIB and that all status
information requested reflects the actual current configuration. The very few exceptions to
this rule are noted, where appropriate, in this manual.