HP OpenVMS Systems Documentation

There are two types of virtual circuits:

• Switched virtual circuits (SVCs)
  SVCs are temporary circuits that require call setup and call clearing procedures. SVCs are established using call request packets that contain the DTE address of the remote DTE. Once established, the two DTEs can carry out two-way communications until the SVC is cleared. SVCs are cleared with clear request packets. Establishing an SVC is similar to making a telephone call.
• Permanent virtual circuits (PVCs)
  PVCs are permanent circuits between two DTEs that need no call setup or call clearing procedures. Allocation of PVCs must be arranged with the supplier of the PSDN to be used. Once allocated, the use of a PVC can be requested using a management command. An allocated PVC is available for use until it is de-allocated.

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 and SVCs.

4.4.2.2 Logical Channel Numbers

When you subscribe to a PSDN, you are allocated a range of LCNs for the different types of virtual circuits:

• Permanent virtual circuits (PVCs)
• Incoming (to the DTE) switched virtual circuits (ISVCs)
• Outgoing (from the DTE) switched virtual circuits (OSVCs)
• Incoming and outgoing (both ways) switched virtual circuits (SVCs)

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:

• A Data Network Identification Code (DNIC), which identifies the country and distinguishes the PSDN from other PSDNs within the same country. This is usually the first four digits of the number.
• A national number, which identifies the DTE within the PSDN.
• An optional subaddress, which gives extra identification between the calling DTE and the called DTE. If included, this is usually the last two digits of the address.

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:

• General Optional User Facilities
  The optional user facilities that fall into this category allow tasks such as call redirection, barring of incoming calls, packet retransmission, and reverse charging to be performed. Refer to the X.25 for OpenVMS Management Guide for descriptions of the general optional user facilities supported.
• Closed User Groups (CUGs)
  A CUG is a group of DTEs that are restricted to communicating with each other. The members of the CUG can prevent unwanted calls from non-CUG members (who are on the open network). Members of a CUG receive calls only from other members of that CUG.
  Several optional facilities are available to CUGs. For example, within a CUG, one DTE can subscribe to facilities that allow it to make outgoing calls and receive incoming calls from the open network. This provides access to the open network for the specified DTE, but still prevents calls from the open network to other CUG members. Refer to the X.25 for OpenVMS Management Guide for descriptions of the optional facilities available to CUG members.
• Bilateral Closed User Groups (BCUGs)
  A BCUG is a CUG consisting of only two DTEs. Access to BCUGs from the open network is more restricted than with normal CUGs because there is no optional facility allowing incoming access. Members of BCUGs can subscribe to a facility allowing outgoing access. Refer to the X.25 for OpenVMS Management Guide for descriptions of the optional facilities available to BCUG members.

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 OpenVMS.

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:

• Chapter 5 --- DECnet Network Operations
• Chapter 6 --- File Operations to and from Other DECnet and DECnet-Plus nodes

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:

• Log in to another node on which you have an account.
• Access public directories or databases located on remote nodes.
• Display locally the contents of remote directories and files to which you have access.
• Copy files from node to node or append files on one node to a file on another node.
• Print files at the remote node where they reside, copy them to a remote printing device, or copy them to the local node for printing.
• Access and edit a file on a remote node using an OpenVMS editor.
• Create a new file in a remote directory.
• Delete or purge files from directories, search files, and compare the contents of files on different nodes.
• Perform sort and merge operations on remote files.
• Analyze the structure of files, convert their organization and format, and dump their contents in a specific format.
• Back up local files by using a remote save set on disk.
• Create, display, and delete logical names for nodes and devices that are to be included in remote file specifications.
• Send electronic mail to, and receive mail from, a user on any other node in the DECnet network, by means of the Mail utility.
• Communicate interactively over the network by means of the Phone utility.
• Invoke help for DECnet-Plus by entering the following command:

  $ 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 node names.

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:

node"username password"::device:[directory]filename.type;version

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:

boston"cmiller techwriter"::dba1:[information]example.lis

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:

U32"user password"::"/usr/users/user/test"

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:

boston"walker projmgr"::DBA1:[INFORMATION]EXAMPLE.LIS

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:

austin::work:[project]tasks.lis

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:

london""::dba0:[market]trends.dat

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):

• A user name that you supply explicitly in an access control string included in the remote file specification. (If you specify a null access control string, the user name in the default DECnet-Plus for OpenVMS account, if one exists, is used.)
• The user name in your proxy account at the remote node, if one exists.
• The user name in the default access account, if one exists, for the file access listener (FAL) object at the remote node.
• The user name in the default DECnet-Plus for OpenVMS account, if one exists, at the remote node (by default, that user name is decnet).

The following sections illustrate ways you can use DECnet-Plus for OpenVMS commands.

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