HP OpenVMS Systems Documentation
DECnet-Plus for OpenVMS
There are two types of virtual circuits:
A DTE may have many virtual circuits active at the same time over a
single DTE-DCE interface. These circuits can be any combination of PVCs
18.104.22.168 Logical Channel Numbers
When you subscribe to a PSDN, you are allocated a range of LCNs for the different types of virtual circuits:
An LCN is a 12-bit number. Some PSDNs use the first 4 bits as a
logical channel group number (LCGN) to represent the
use of the channel, and the remaining 8 bits to represent the LCN. Some
PSDNs use the full 12 bits to represent the LCN.
4.4.3 DTE Addresses
Each DTE has an address that the PSDN uses to route calls. DTE addresses are contained in the call request packets and are used for setting up SVCs. The address may be up to 15 digits long and consists of:
DTE addresses may consist of up to 15 digits. However, for internetworking X.121 restricts international data numbers (that is, DTE addresses) to 14 digits.
An example of an X.121 format DTE address is shown in Figure 4-9.
Figure 4-9 DTE Address Example
Some networks use an abbreviated form of addressing to refer to DTEs on
the same network. In such networks, an extra digit is often prefixed to
the DTE address to indicate that the address of the called DTE is on a
different network to the calling DTE.
4.4.4 Controlling the Flow of Packets
When a packet has been received by a called (remote) DTE, the PSDN sends a message to the calling (sending) DTE. This message is known as an acknowledgment. Because of the time it takes a packet to travel across a network, it is inefficient to wait for the acknowledgment of the packet before sending more. For this reason, PSDNs let you send a number of packets before you receive acknowledgment for the first one.
The maximum number of unacknowledged packets you are allowed to have on a virtual circuit is called the window size. Once the window size is reached, and acknowledgments for previously sent packets are received, more packets can be sent. Acknowledgments are often carried by incoming packets of data.
You can specify the window size you want to use, up to the maximum set
by the PSDN. You may want to subscribe to larger window sizes if you
have large amounts of data, or if there is a long delay between sending
a packet and receiving the acknowledgment of that packet.
4.5 Optional Facilities of Public and Private PSDNs
As well as switching packets, each PSDN offers optional facilities to its users. Some must be subscribed to, and others must be requested at the time the call is set up. A specific PSDN may support additional facilities that are not defined by the CCITT. A full list of such facilities can be obtained from the PSDN supplier.
According to CCITT X.25 (1984), these facilities fall into three categories:
DTE parameters govern the frame- and packet-level operation of DTEs.
They specify properties such as window size and packet size. Various
PSDNs support different parameters. For more information on the
parameters supported, contact your PSDN supplier.
4.5.2 PAD Parameters
PSDNs offer optional PAD facilities that are represented by variables known as PAD parameters. You can set PAD parameters to indicate that you want to use a PAD facility and how you want to use it.
A set of PAD parameters is a profile; most networks define several profiles to suit different types of character-mode DTEs (X.29 terminals). When you connect to a PAD, you can select a profile to control the actions of the PAD. During a call, you can read and reset most of the PAD parameters.
Refer to the X.25 for OpenVMS Management Guide which describes
the CCITT-defined PAD parameters, all supported by DECnet-Plus for
4.6 Network Profiles
DIGITAL supports the use of its X.25 products with a number of public and private PSDNs. A network profile contains the information necessary to support a particular PSDN including network parameters pertinent to a specific network. For example, it contains the default value and permissible range of values for the X.25 window size.
Details of the PSDNs supported by DIGITAL's X.25 products can be
obtained from your DIGITAL representative. For details of the
permissible network parameters for a specific network, refer to the
documentation provided by your PSDN supplier.
4.7 PSDNs Supported by DIGITAL's X.25 Products
Before a PSDN is supported by DIGITAL, it has to go through DIGITAL's own testing procedure. This is necessary to determine the network parameters to store in the associated network profile. The testing procedure produces a network profile for each PSDN. If you use the correct profile for the PSDN you are connecting to then your communications will be successful, and DIGITAL will provide you with support in the event of any problems.
If you want to use a PSDN that is not currently supported by DIGITAL, you can ask DIGITAL to provide support for the network. DIGITAL will then test the PSDN and produce a network profile for use with the PSDN. Your local DIGITAL office can provide details on how this support service is provided.
Part III provides information on using remote files with DECnet-Plus, using the DECnet-Plus login utility, and sending mail to DECnet-Plus nodes. This section includes the following chapters:
This chapter explains the functions you can perform in a DECnet network
environment including remote login, file, and mail operations. It also
explains how to develop command procedures and application programs
that run over the network.
5.1 How You Can Use DECnet
You perform network operations as a natural extension of the input/output operations you perform on your own local system, because DECnet-Plus for OpenVMS networking capabilities are completely integrated into the operating system.
With appropriate access on a remote node, you can carry out general
user operations over the network as easily as at the local node. Most
DECnet-Plus for OpenVMS file-handling commands permit you to access
files on remote systems in the same way as files on your own system as
long as you have appropriate access.
5.1.1 Performing Operations using DCL Commands
You can use DCL commands to perform the following DECnet-Plus for OpenVMS operations over the network:
$ help decnet_osi
Node synonyms are required for layered products and utilities that do
not yet support DECnet-Plus full names. Full name support is available
for the SET HOST and Mail utilities, and for most DCL commands that use
file specifications (such as COPY, DIRECTORY, etc.) and some utilities
that use RMS.
5.2.1 Phase IV-Style Node Synonyms
Because a full name consists of the complete directory path from the root directory to the target object entry, directory, or soft link, full names can be long if a namespace has several levels of directories.
DECnet-Plus supports a 6-character Phase IV-style node name called the node synonym. A node synonym is a soft link that points to the full name of a node object entry. Node synonym soft links enable applications that do not support the length of full names to continue to use 6-character node names.
Node synonyms should not be viewed as a way for users to avoid typing
the full name of a node. Logical names, and a feature called the local
root, are faster and more convenient methods of shortening names. Both
logical names and local roots are for use only on the system where they
are defined; unlike node synonyms, they do not have global meaning
throughout the namespace. Also, logical names and local roots can be
used to name any resource (such as a disk or an application), not just
5.2.2 Name Abbreviation Using Local Roots
The local root is a prefix that DECnet-Plus obtains automatically by stripping off the rightmost simple name of the local node's DECnet-Plus full name. For example, a node named IAF:.DIST.QA01 would have IAF:.DIST as its local root. Users will likely want to refer frequently to other names in the hierarchy in which their local node is named. The local root capability makes such name references more convenient by allowing users to omit the part of the full name that is also part of their node's full name.
DECnet-Plus Session Control creates the local root under the fixed name
dnsroot in the dns$system logical name table.
5.2.3 Logging In to Other DECnet Nodes
To gain access to the network, log in to your account on the OpenVMS system. Before you perform an operation over the network, you can check the availability of the network by entering the following command:
$ show logical net$startup_status "net$startup_status" = "running-all" (lnm$system_table)
This command returns with a display indicating that all network software is loaded and running.
After you log in to a network node, you may be able to log in to other nodes on the same network. If you are authorized to access an account on another OpenVMS node or on a non-OpenVMS node that supports DECnet, you can log in to that node over the network. To log in to the other node, enter the DCL command SET HOST, specifying the remote node name, and follow the login procedure the remote node uses. Once you are logged in to the remote node, you can perform all general user operations on that system as though it were the local node:
To set host to another OpenVMS system, enter:
$ set host node-name
To set host to an DIGITAL UNIX system with its synonym registered in DNS, enter:
$ set host node-name
To set host to another system using full name support, enter:
$ set host namespace:.abc.xyz
This section describes the format of the remote file specification and
the access controls that affect access to remote files. This section
also explains how to use logical names in specifying remote directories
and files, and how to specify remote files located on OpenVMS clusters.
5.3.1 Specifying Files
You can access remote files by simply including in the file specification the name of the remote node on which the file is located. You can access files that are protected if the owner has granted you access, either by a proxy account or by providing you with the name and password of the account.
The full format for a remote file specification for DECnet-Plus for OpenVMS nodes is as follows:
For example, to identify the file example.lis residing in the directory information on device dba1, which belongs to user cmiller whose password is techwriter, at node boston, you would use the following file specification:
If a file resides on a non-OpenVMS system, enclose the name of the file in quotation marks. For example, to access a file named /usr/users/user/test on an DIGITAL UNIX node named U32, you would use the following format for the file specification:
DECnet-Plus for DIGITAL UNIX file specification is case sensitive.
You can use the SET PROTECTION command to protect a file or directory against unauthorized access. One way to access a protected remote file is to supply the user name and password of a user on the remote system who does have access to the file. If the user walker, who has the password projmgr, has access to the file, you could use the following file specification:
To avoid using a password in a file specification to be transmitted over the network, you may want to have a proxy account at the remote node that permits you to access specific directories and files as though you were a local user. If you have proxy access to a remote file, you can omit the access control information when specifying that file name, even if the file is protected against outside access. For example, use this file specification to access the file tasks.lis in the directory project on device work at remote node austin, at which you have a proxy account:
If the remote node system manager has established a default DECnet-Plus for OpenVMS account for the remote node, you can specify a null access control string in the remote file specification to invoke the default DECnet-Plus for OpenVMS account. For example, the following file specification causes the file trends.dat at remote node london to be accessed using the default DECnet-Plus for OpenVMS account:
When you access a remote file, a process at the remote system actually performs the file access on your behalf. The remote process follows the rules normally used to access files on that system. The rights and privileges the remote process uses to access the file depend on the user name supplied. The user name can be one of the following (in order of precedence):
The following sections illustrate ways you can use DECnet-Plus for
5.4.1 Displaying Remote Directories and Files
To list the files in a remote directory, use the DIRECTORY command. For example, the following command lists all files in the directory [comments.public] at remote node concord:
$ directory concord::disk1:[comments.public]
The TYPE command lets you display the contents of one or more remote files to which you have access. For example, to display the contents of the unprotected file members.lis in directory [patriots] at remote node concord, use the following command:
$ type concord::disk1:[patriots]members
For example, the following command displays the file redcoats.lis in directory [british] on the default device at node lexington:
$ type lexington::[british]redcoats