DECnet-Plus for OpenVMS
Applications Installation and Advanced Configuration

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:
1. 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 
```
2. 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.
  1. Exit from the terminal emulator: Press and hold down the Control key while you press the \ (backslash) key on your OpenVMS system.
  2. 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.
  3. 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:

asy$dynamic_maxlines
Specifies the maximum number of dynamic asynchronous modem connect lines that can be active on a system at any one time. You can specify values in the range of 0--65534 lines. The default is 16 lines. For example:
```
$ define/system asy$dynamic_maxlines 16 
```
asy$dynamic_line_timeout
Specifies the amount of time in seconds that a dynamic asynchronous line waits before deciding that a dynamic connection has broken. When the dynamic asynchronous line decides that a link is broken, the line is automatically switched back to a terminal line. You can specify values in the range of 10--65535 seconds. The default is 300 seconds. For example:
```
$ define/system asy$dynamic_line_timeout 300 
```

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 
```
1. 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.
2. 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.
3. 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
```
1. 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.
2. Including checksums reduces data throughput. Use checksums only if you have reason to believe that data will be corrupted by the network.
3. 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.
4. 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.
5. 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.
6. The following example creates the X25 Access module, and enables it:
```
ncl> create x25 access 
ncl> enable x25 access 
```
7. 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 
```
  1. 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.
  2. 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.
8. 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
```
  1. 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.
  2. 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

DECnet-Plus for OpenVMSApplications Installation and Advanced Configuration