DECnet-Plus for OpenVMS
Applications Installation and Advanced Configuration
Previous
| Contents
Figure A-1 shows a typical configuration in which dynamic
asynchronous switching occurs over a dialup line. The local node in
Figure A-1 is a standalone VAXstation 3100 system; the remote node
is a VAX 8800. After the user at the local node dials in to the remote
node, he or she can switch the lines connected to terminal ports
tta2 and txb1 to dynamic asynchronous DDCMP.
Figure A-1 Dynamic Switching of Asynchronous DDCMP
Lines
- The following steps can be performed by any OpenVMS user.
- Log in to your local OpenVMS system. This login creates a process
(identified by Process_L in Figure A-1).
- Enter the following DCL command:
$ set host/dte terminal-port-name:
terminal-port-name is the name of your local
terminal port that is connected to the modem. If both systems use modems
with autodial capabilities (for example, DF03, DF112, or DF224 modems),
you can optionally include the /dial qualifier on the set
host/dte command
to cause automatic dialing of the modem on the remote node, as follows:
$ set host/dte/dial=number:number terminal-port-name:
- If you do not specify the /dial qualifier in the previous
step, dial the remote system manually. After the dialup connection is
made and you receive the remote system welcome message, log in to your
account on the remote node. In this case, you supply your user name and
password to the remote OpenVMS operating system.
- If you are not using automatic dialing, dial in to the remote node
manually.
- Once the dialup connection is made and you receive the remote
OpenVMS system welcome message, log in to your account on the remote
node. This process is identified by Process_R in Figure A-1.
- You can initiate the dynamic switch by specifying the following
DCL command on the remote node:
$ set terminal/network/switch=decnet
The set terminal command is an OpenVMS DCL command. If you
are on a node other than an OpenVMS node, specify the equivalent
function for your system.
- When the SET image on the remote system recognizes the
/NETWORK and /switch=decnet qualifiers, it calls the
shareable image asydynswitch (see
Figure A-1). The asydynswitch image verifies the link and
sends an escape sequence to the terminal emulator on the local system.
The escape sequence notifies the local terminal emulator that the line
connected to the remote system is becoming a dynamic asynchronous line.
- When the terminal emulator at the local system receives the escape
sequence, it calls the asydynswitch image (see Figure A-1)
on the local system. The asydynswitch image verifies the line
on the local system and switches it to an asynchronous DECnet line.
- When the switch occurs on the local system, asydriver
first searches for an explicitly named dynamic asynchronous line. For
example, if the switch is on device tta1:, it searches for a
line with a communications port attribute of
async-tt-0-1. If asydriver cannot find that line, it
searches for a "floating" line (created with a communications
port attribute of async). Because a protocol stack
previously had been preconfigured over this line, the data link
protocol now attempts to start the link.
- The local system then sends a ddcmp start message (see
Figure A-1) to the remote system that initiated the dynamic switch.
When asydynswitch on the remote system detects the
start message, it activates the preconfigured local protocol
stack. (For information about the protocol stack, see Section A.1.2.1,
steps 5--7.)
The remote system first searches for an explicitly
named dynamic asynchronous line. When it searches for an explicitly
named dynamic line, it searches for one that refers to the physical
terminal over which the original switch was made. In Figure A-1, the
remote system searches for a line associated with port txb1.
Therefore, it looks for a line with a communications port
attribute of async-tx-1-1. If it does not find one, it uses a
"floating" async-n line. If this fails, the dynamic
switch fails.
- Since both ends of the link have a preconfigured protocol stack,
the DECnet link comes up over both circuits. Any preconfigured security
checks also occur at this time.
The following message indicates
that the terminal emulator on the local system has exited and that the
DECnet link is being established:
%REM-S-END - control returned to local-nodename::
$
To check whether the communications link has come up, specify the
following command on the local system:
$ run sys$system:ncl
ncl> show routing circuit dynamic_asynch adjacency adjacent-node all
ncl> exit
If there is an adjacency, you can start to communicate with the
remote system over the asynchronous DECnet connection.
- As an alternative to switching the terminal line to a DECnet line
automatically, you can switch the line manually. If you originate a
dynamic connection to an OpenVMS node from a system other than OpenVMS,
manual switching is required; from an OpenVMS system, it is optional.
If you are originating the connection from a node other than OpenVMS,
follow system-specific procedures to log in to the remote OpenVMS node
by means of terminal emulation.
Once you are logged in to the
remote node, two steps are required for manual switching:
- Using your account on the remote OpenVMS node, specify the set
terminal command described in Step 7, but add the /manual
qualifier. For more information see Section A.1.2.1, Step 5.
$ set terminal/network/switch=decnet/manual
You will receive the following message from the remote node
indicating the remote system is switching its line to DECnet use:
%SET-I-SWINPRG The line you are currently logged over is becoming
a DECnet line
- You should exit from the terminal emulator and switch your line
manually to a DECnet line. The procedure depends on the specific
operating system on which you are logged in.
The following example
shows how an OpenVMS user originating a dynamic connection exits from
the terminal emulator and turns on the DECnet line.
- Exit from the terminal emulator: Press and hold down the Control
key while you press the \ (backslash) key on your OpenVMS
system.
- Enter the following command to switch your terminal line to a
DECnet line manually:
$ set terminal/network tta0:
tta0 is the name of the terminal port on the local node.
- Next, you must manually turn on the lines, data links, and routing
circuits connected to your terminal port. See Steps 5 through 7 in
Section A.1.1 for information about setting up your static asynchronous
link.
Asynchronous DECnet is then started on the local OpenVMS node.
A.1.2.3 Managing Dynamic Asynchronous Resources
You can define the following system logical names in
sys$manager:net$logicals.com to manage the resources used by a
dynamic asynchronous connection:
A.1.2.4 Terminating a Dynamic Asynchronous Connection
Take the following steps to terminate a dynamic asynchronous connection:
- Disable the modem connect line and then re-enable it. For
example:
$ run sys$system:ncl
ncl> disable modem connect line dynamic_asynch
ncl> enable modem connect line terminal_line
ncl> exit
- Switch your asynchronous line back to a terminal line.
$ set terminal/permanent/nonetwork/typeahead terminal_port_name
The dynamic asynchronous connection can also terminate, if the time
specified by the logical name asy$dynamic_line_timeout
expires. The link is considered idle if it has no input or output for
the timeout interval. When this occurs, the link is broken and the line
automatically switches from a DECnet line back to a terminal line. For
more information about asy$dynamic_line_timeout, see
Section A.1.2.3.
A.1.2.5 Reasons for Failure of Dynamic Asynchronous Connections
If you are using dynamic switching and the asynchronous DECnet
connection is not made, check that:
- DECnet-Plus has been started.
- WANDD has been started.
- The asydriver has been loaded (the asy0 device is
present).
- The asyswitch has been installed.
- The asydynswitch has been installed.
- The modem connect lines have been configured correctly.
- Virtual terminals must be enabled both on the remote node and, in
particular, for the terminal at which you are logged in. The terminal
line at the remote node must have the attribute disconnect set.
- After you enter a set terminal command with the
/manual qualifier, you must specify NCL commands to turn on
the DECnet line within approximately 2 minutes or the line returns to
terminal mode.
If the logical station is in the on-starting state,
check that:
- The routing circuits have been configured correctly.
- The routing initialization passwords on each node must be set
correctly. (Refer to the DECnet-Plus for OpenVMS Network Management guide.)
- The parity is correct. Asynchronous DECnet requires the parity on
the asynchronous line to be set to none and the terminal line
to be set up to use 8-bit characters. If you are using a non OpenVMS
system, you must check that the terminal line is set to the correct
parity.
For more information about solving problems in your DECnet-Plus
network, refer to the DECnet-Plus Problem Solving guide.
Appendix B
Configuring Transports
B.1 Overview
To configure NSP Transport, OSI Transport, DECnet over TCP/IP, or OSI
over TCP/IP on your system, invoke the
sys$manager:net$configure using the ADVANCED option, and
select Option 4 ("Configure Transports"). Section 1.4 and
Section 1.5 in this manual describe in detail the questions
net$configure asks in order to configure the transports.
Digital recommends that you do not modify the NSP and OSI startup
scripts that net$configure creates. (These scripts in
SYS$MANAGER are named NET$NSP_TRANSPORT_STARTUP.NCL and
NET$OSI_TRANSPORT_STARTUP.NCL.) Digital also recommends that you accept
the default settings for the various attributes.
This appendix describes the NCL commands that you can use to manually
create and modify these transports if necessary. Refer to
DECnet-Plus Network Control Language Reference for more
information about transport attributes.
B.2 Manually Configuring NSP
This section describes how to configure the Network Services Protocol
(NSP). The following example shows the commands to create the
nsp entity on your system. Digital recommends that you accept
the default settings (used in the example) for the various attributes
and change these only if you need to. Refer to the DECnet-Plus Network Control Language Reference for
more information about these attributes.
ncl> create nsp
ncl> set nsp delay factor 2, delay weight 3, - (1)
_ncl> maximum remote nsaps 200, maximum transport connections 200, - (2)
_ncl> maximum window 20, nsap selector 32, -
_ncl> retransmit threshold 5
ncl> enable nsp
-
The effect of delay factor is to increase the retransmission
time by increasing the average round-trip delay time, thus allowing for
additional network delay.
The value of the weighting factor is given by the delay weight
characteristic. Basically, delay weight determines how quickly
the retransmission timer responds to variations in actual round-trip
delay times. A low value of delay weight means that the
retransmission timer responds quickly to each sample of round-trip
delay time; a delay weight of 0 means that an
estimate is nearly the same as the last actual sample of round-trip
delay. A high value for delay weight reduces the impact of
recent variations in network delay; the higher the value, the closer
each estimate of round-trip delay is to the average of all estimates.
The default values of delay factor and delay
weight should be suitable for most networks. However, consider
increasing these values if there are wide variations in round-trip
delay times on your network.
-
You can save memory resources by reducing the value of maximum
remote nsaps. However, you do not have access to the information
provided by this entity's counters and status attributes (except
through information in event logs). The maximum NSAPs must be greater
than the maximum transport connection.
For some NSP characteristics, such as maximum remote nsaps, or
maximum transport connections, you can raise values at any
time, but you cannot lower the value without first disabling NSP.
The following is an example of how to set up NSP:
ncl> create nsp
ncl> set nsp maximum window 8
ncl> set nsp maximum transport connections 200
ncl> set nsp maximum receive buffers 2000
ncl> enable nsp
ncl> create session control transport service nsp protocol %x04
B.2.1 Transmit and Receive Window
NSP receiver's window is controlled by a combination of Maximum
Transport Connections, Maximum Receive Buffers, and Maximum Window.
The receiver initial quota is determined by dividing Maximum Receive
Buffers by Maximum Transport Connections. During the life of the
connection, the receiver quota fluctuates, using the value of Maximum
Receive Buffers divided by Currently Active Connections. The credit
window sent to the remote transmitter may or may not be this quota
value, depending on the value of Maximum Window. If Maximum Window is
set to less than the determined receiver quota, this value is used
instead for the credit granted to the remote transmitter.
The transmitter on an NSP connection uses the credit sent by the remote
receiver as its transmit window, unless Maximum Window is a lower
value. In that case, Maximum Window is used for the transmitter window.
By controlling the transmitter's and receiver's window as above a
dynamic balance of system resource consumption and network performance
may be achieved and maintained.
B.3 Manually Configuring the OSI Transport Service
This section describes how to configure the OSI transport service. The
following example shows the commands to create the osi
transport entity on your system. Digital recommends that you
accept the default settings (used in the example) for the various
attributes and change these only if you need to. Refer to the
DECnet-Plus Network Control Language Reference for more information about these attributes.
The characteristics specified in the following command example are
those that apply to all types of network service. For details of
osi transport entity characteristics that are specific to
Connection-Oriented Network Service (CONS) or Connectionless-Mode
Network Service (CLNS), see Section B.3.2 or Section B.3.3.
ncl> create osi transport
ncl> set osi transport delay factor 4, delay weight 5,- (1)
_ncl> maximum receive buffers 96, maximum remote nsaps 64, - (2)
_ncl> maximum transport connections 33, maximum window 20
ncl> enable osi transport
-
The effect of delay factor is to increase the retransmission
time by increasing the average round-trip delay time, thus allowing for
additional network delay.
The value of the weighting factor is given by the delay weight
characteristic. Basically, delay weight determines how quickly
the retransmission timer responds to variations in actual round-trip
delay times. A low value of delay weight means that the
retransmission timer responds very quickly to each sample of round-trip
delay time; a delay weight of 0 means that an
estimate is nearly the same as the last actual sample of round-trip
delay. A high value for delay weight reduces the impact of
recent variations in network delay; the higher the value, the closer
each estimate of round-trip delay is to the average of all estimates.
The default values of delay factor and delay
weight should be suitable for most networks. However, consider
increasing its value if there are wide variations in round-trip delay
times on your network.
For a complete discussion of delay
factor and delay weight and how to calculate round-trip
delay, refer to DECnet-Plus for OpenVMS Network Management.
-
You can save memory resources by reducing the value of maximum
remote nsaps. However, you will not have access to the information
provided by this entity's counters and status attributes (except
through information in event logs). The maximum remote NSAPs cannot be
lower than the maximum transport connections.
You must disable the osi transport entity before you can
modify any of its characteristics.
B.3.1 Transmit and Receive Window
OSI transport receiver's window is controlled by a combination of
Maximum Transport Connections, Maximum Receive Buffers, and Maximum
Window. The receiver initial quota is determined by dividing Maximum
Receive Buffers by Maximum Transport Connections. During the life of
the connection, the receiver quota fluctuates, using the value of
Maximum Receive Buffers divided by Currently Active Connections. The
credit window sent to the remote transmitter may or may not be this
quota value, depending on the value of Maximum Window. If Maximum
Window is set to less than the determined receiver quota, this value is
used instead for the credit granted to the remote transmitter.
The transmitter on an OSI transport connection uses the credit sent by
the remote receiver as its transmit window, unless Maximum Window is a
lower value. In that case, Maximum Window is used for the transmitter
window.
By controlling the transmitter's and receiver's window as above a
dynamic balance of system resource consumption and network performance
may be achieved and maintained.
The following NCL script creates and sets up OSI transport, including
the Connection-Oriented Network Service (CONS), and the
Connectionless-mode Network Service (CLNS) services.
ncl> create node 0 osi transport
ncl> create node 0 osi transport application osit$ivp
ncl> set node 0 osi transport application osit$ivp file name sys$test:osit$ivpresp.com
ncl> set node 0 osi transport application osit$ivp user name "systest"
ncl> set node 0 osi transport application osit$ivp called tsels {%X564f5453495650}
ncl> create node 0 osi transport template osit$loop_clns
ncl> set node 0 osi transport template osit$loop_clns network service clns, -
_ncl> classes {4}, -
_ncl> expedited data true, -
_ncl> checksums false, -
_ncl> inbound false, -
_ncl> loopback true
ncl> create node 0 osi transport template osit$loop_cons
ncl> set node 0 osi transport template osit$loop_cons network service cons, -
_ncl> classes {4,2,0}, -
_ncl> expedited data true, -
_ncl> checksums false, -
_ncl> inbound false, -
_ncl> loopback true
ncl> create node 0 osi transport template osit$rfc1006
ncl> set node 0 osi transport template osit$rfc1006 network service RFC1006, -
_ncl> classes {0}, -
_ncl> inbound true
ncl> create node 0 osi transport template osit$rfc1006plus
ncl> set node 0 osi transport template osit$rfc1006plus network service RFC1006, -
_ncl> classes {2}, -
_ncl> RFC1006 port number 399, -
_ncl> inbound true
ncl> set osi transport RFC1006 listener ports = { 102, 399 }
ncl> enable node 0 osi transport
B.3.2 Configuring the Connection-Oriented Network Service
The following sections describe how to configure the
Connection-Oriented Network Service (CONS). CONS is a network service
that operates according to a connection-oriented model. Before data can
be exchanged, a connection must first be established. X.25 provides
this type of service.
B.3.2.1 Establishing Outbound Connections Using CONS
To establish an outbound transport connection that uses CONS as its
network
service, an application makes a connection request in which it
specifies:
- The OSI transport address of the destination host.
- The OSI transport service access point identifier (TSAP-ID) of the
remote application. A TSAP-ID identifies a TSAP. A TSAP is a unique
identifier for a single transport user.
- Optionally, other transport connection parameters.
The OSI transport address consists of:
- The name of the OSI transport template to be used in setting up the
transport connection. The specified OSI transport template must have
its network service characteristic set to cons.
- A network address that uniquely identifies the destination host.
The network address for a CONS connection is a DTE address.
OSI transport either creates a new network connection (using either
X.25 or X25 Access), or uses an existing outbound network connection
(provided the transport connection is class 2 or class 4). If a new
connection is to be created, X.25 uses the DTE address from the OSI
transport address and the X25 Access template specified in the OSI
transport template to set up a network connection.
B.3.2.2 Establishing Inbound Connections Using CONS
To establish an inbound transport connection:
- OSI transport must be listening to one or more X25 Access filters.
X.25 or X25 Access passes calls from these filters up to OSI
transport.
- OSI transport must have an OSI transport template for CONS
connections with its inbound characteristic set to TRUE. This
OSI transport template must also specify an X25 Access template with
the same name (including matching case) as the X25 Access filter on
which a call arrives.
- If a suitable OSI transport template for CONS connections is found,
it is used to accept the call, using the X25 Access template specified
in the OSI transport template.
- The incoming transport connection can then be received. If an
application is found to receive the inbound request, the application
can accept or reject the request.
- If the application accepts the inbound request, the OSI transport
template for CONS connections is used for the accept.
For incoming connections to applications that are invoked by passive
TSAP association, you must also configure one or more OSI transport
application entities to represent the passive association between a
TSAP-ID and an application. Refer to the DECnet-Plus for OpenVMS Network Management guide for
information about managing application entities.
B.3.2.3 Manually Configuring Support for CONS
To configure CONS support, each element in the set of the CONS
filters attribute of the OSI transport entity must have a
corresponding X25 Access filter of the same name. By default, the
CONS filters attribute of the OSI transport entity is set to
OSI transport.
Similarly, the CONS template attribute of the OSI transport
template subentity must contain a name that is a PSI filter and is
contained in the set of CONS filters of the OSI transport
entity. The default value of the CONS template attribute of an
OSI transport template subentity is OSI transport.
The following steps list the commands required to configure CONS. The
characteristics added or set up for OSI transport in this
example are relevant to CONS. In addition, consider setting some of the
more general characteristics shown in Section B.3.
For the variables, substitute values appropriate to your
configuration. Digital recommends that you accept the default settings
(used in the example) for the various attributes. Change them only if
you need to. Refer to the DECnet-Plus Network Control Language Reference guide for more information
about these attributes.
- The following example shows how to create the OSI transport module,
set its characteristics, and enable it.
ncl> create osi transport
ncl> add osi transport cons filters {filter-name}
ncl> set osi transport disconnect holdback 0, -
_ncl> maximum multiplexing 65535, maximum network connections 65535
ncl> enable osi transport
-
Specifies the names of one or more X.25 filters used to listen for
incoming transport connection requests.
If you do not specify any X.25 filters, a default filter called OSI
transport is used.
-
Set a high value for disconnect holdback if you want to keep
idle network connections. This saves the cost of re-establishing
network connections. You should be aware, however, that this is
unnecessarily costly if the network connection remains idle.
Set
disconnect holdback to 0 if you want to lose idle
network connections as soon as possible.
disconnect
holdback is supported only for transport protocol classes 2 and 4.
-
Sets the value of maximum multiplexing. Increasing the value
saves on the cost of network connections but reduces the throughput for
each transport connection that uses a multiplexed network connection.
maximum multiplexing is supported only for transport
protocol classes 2 and 4.
If you set maximum network
connections too low, local transport users might be unable to make
transport connection requests, particularly if all the active network
connections are inbound. For example, if the limit is 7 and there are 7
active network connections, all inbound, then local transport users
will be unable to make transport connections unless you either increase
the value of maximum network connections or one of the network
connections is released by a remote host.
- The following example shows how to create the OSI transport
templates:
ncl> create osi transport template template-name
ncl> set osi transport template template-name -
_ncl> acknowledgment delay time 1, -
_ncl> checksums false, classes {4}, -
_ncl> cons template osi transport, cr timeout 30, er timeout 30, -
_ncl> inbound true, initial retransmit time 15, loopback false, -
_ncl> keepalive time 60, maximum nsdu size 2048, -
_ncl> network service cons, retransmit threshold 8 (5)
ncl> enable osi transport template template-name
-
OSI transport templates are used by OSI transport to supply connection
parameters not provided by the requesting OSI transport application.
An OSI transport template name must contain only alphanumeric
characters, underscores (_), hyphens (-), or dollar
($) signs. OSI transport template names should not be more
than 16 characters long.
You can configure two types of OSI
transport templates for CONS connections:
- For outbound connections only
You can configure as many
outbound OSI transport templates as you want.
- For both outbound and inbound connections
You should configure
a single outbound--inbound OSI transport template for each X25 Access
filter used by inbound transport connections.
-
Including checksums reduces data throughput. Use checksums only if you
have reason to believe that data will be corrupted by the network.
-
The default value for cr timeout is adequate for most
networks. However, consider increasing the value if you find that a
high proportion of transport connection requests are being timed out.
-
When true, inbound specifies that this OSI transport
template for CONS connections can be used for inbound as well as
outbound connections.
The default initial retransmit time value should be suitable
for most networks. It is set to a relatively high value to reflect the
fact that a transport connection request Transport layer protocol data
unit (TPDU) usually has a longer round-trip delay than a data TPDU.
Consider increasing the value if transport connection requests
frequently time out.
You can set up different OSI transport
templates to provide different values of this characteristic for
networks with significantly different round-trip delay. For example,
round-trip delay on an X.25 PSDN is usually much greater than on an
802.3 LAN.
-
network service cons indicates that transport connections set
up using a specified template will use CONS. An OSI transport template
for CONS connections configured with the net$configure
procedure have this characteristic set correctly. However, if you
create a CONS OSI transport template directly, you must set this
characteristic, because the default is CLNS.
The default value for retransmit threshold should be suitable
for most networks. However, consider increasing the value for networks
with a high probability of losing data.
- The following example creates the X25 Access module, and enables it:
ncl> create x25 access
ncl> enable x25 access
- The following example shows how to create the x25 access
template and set its characteristics:
ncl> create x25 access template template-name
ncl> set x25 access template template-name -
_ncl> call data hex-string, dte class dte-class-name
-
Outbound transport connections that use X.25 network connections use
X25 Access templates to supply most of the parameters for setting up
the network connection. Inbound transport connections that use X.25
connections use X25 Access templates to negotiate network connection
parameters.
Each OSI transport template for CONS connections that
you configure names an X25 Access template in its cons
template characteristic. You must, therefore, configure each of
the X25 Access templates named in your OSI transport templates for CONS
connections.
-
When you create an X25 Access template for use with CONS, set the value
of the call data characteristic to %X03010100. The
destination host will recognize this value as indicating that the call
should be passed to CONS.
- The following example shows how to create the x25 access
filter:
ncl> create x25 access filter filter-name
ncl> set x25 access filter filter-name -
_ncl> call data mask mask, call data value value, -
_ncl> inbound dte class dte-class-name
-
If your system is to accept inbound transport connections over X.25
network connections, you need to configure one or more X25 Access
filters. An X25 Access filter listens for incoming network connection
requests and passes these requests to the appropriate destination. One
or more X25 Access filters are required for each X25 Access DTE class
that CONS wants to use.
Each outbound-inbound OSI transport
template for CONS connections that you configure specifies the name of
an X25 Access template in its cons template characteristic.
This X25 Access template will be used to accept an inbound network
connection. The name of this X25 Access template must be the same as
the name of an X25 Access filter that is used to receive inbound
network connections.
-
When you create an X25 Access filter for use by CONS, set call data
mask to %Xffffffff.
When you create an X25 Access
filter for use by CONS, set call data value to
%X03010100.
B.3.3 Manually Configuring the Connectionless-Mode Network Service
The following sections describe how to configure the
Connectionless-Mode Network Service (CLNS). CLNS is a network service
that operates according to a datagram model. Each message is routed and
delivered to its destination independently of any other. When using
CLNS, only TP4 is available in the default configuration.
B.3.3.1 Establishing Outbound Connections Using CLNS
To establish an outbound transport connection that uses CLNS as its
network service, an application makes a connection request in which it
specifies:
- The OSI transport address of the destination host.
- The TSAP-ID of the responding application. A TSAP-ID identifies a
TSAP. A TSAP is a unique identifier for a single transport user.
- Optionally, other transport connection parameters.
Previous
| Next
| Contents
| [Home]
| [Comments]
| [Ordering info]
| [Help]
PROFILE_014.HTML
OSSG Documentation
2-DEC-1996 12:33:45.36
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.
Legal