OSI/TS Configuration and Management Manual

Configuring the OSI/TS Subsystem
OSI/TS Configuration and Management Manual424831-001
3-8
Using PAM with OSI/TS
Using PAM with OSI/TS
PAM is a system process that provides local-area, connectionless-mode subnetwork
service over standard 802.3 and 802.4 networks. It has an application interface and an
interface to SLSA that runs the data-link protocols (logical link control and CSMA/CD).
Note that when you configure Layer 4 attributes to operate with PAM processes, you
must specify the transport class 4 protocol.
PAM Port Management
The following information describes how the OSI/TS subsystem names, creates, and
deletes PAM ports.
Naming PAM Ports
When interfacing with PAM, the TSP process builds a PAM port name by using the first
five characters after the $ sign of its own TSP process name as the prefix, followed by a
two-character alphanumeric string that is associated with the LSAP-selector it uses
(normally FE). This method allows for easy identification and prevents possible
duplicate names created by other TSP processes.
Creating PAM Ports
The first time a connect request or an attach request is received requiring the PAM
device specified in the NSPDEVICE attribute, the TSP process adds the following:
A normal port to the PAM subdevice
A port to receive broadcast messages, if the ESISENABLE attribute is set to ON
While the naming scheme for PAM ports guarantees that no two TSP processes can
create ports with identical names, the PAM subsystem can still potentially reject a port at
this stage. This can happen when the port is being used by other TSP processes that are
stopped. In such cases, an event message is generated to point to the source of the
problem.
To avoid this problem, always do the following:
Abort all transport subdevices before stopping TSP processes. This should be part of
your normal shutdown procedure.
Assign the same PAM to the same TSP process.
Deleting PAM Ports
PAM ports can only be deleted by aborting all the TSP subdevices; otherwise, PAM
ports are retained for the lifetime of the TSP process.
To change the value of the ESISENABLE attribute, you must first abort all the TSP
subdevices. If the TSP subdevices are not first aborted, unpredictable behavior can
result.