DECnet-Plus for OpenVMS
Introduction and User's Guide

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" 

Note

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:

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 

Information of interest to a number of users on the DECnet-Plus for OpenVMS network may be stored in central directories or databases accessible to everyone on the network. To make access to a public directory easier, define a logical name for the public directory. For example, you can use the logical name public to define the public directory [comments.public] at remote node concord:

$ define public concord::disk1:[comments.public]  

Users logged in to any node on the network can then access the file freedom.txt located in the directory [comments.public], for example:

$ directory public 
$ type public::freedom.txt)  

They can also copy the file to the local node and then print it, as described in the next section.

5.4.3 Copying and Printing Remote Files

Use the COPY command to copy a file from one node to another. As part of the copy operation, you can create a new file from existing files.

5.4.3.1 The COPY Command

The following command copies the file liberty.dat on node boston to a new file of the same name on remote node britain:

$ copy boston::disk:liberty.dat;2 
_To: britain::dba0:[product]liberty.dat 

The following command copies the remote file liberty from Digital UNIX node boston to a new file on local node britain:

$ copy boston::"/usr/users/user/test" liberty.dat 

Both of the following commands copy the file traitors.lis from the local node to a file with the same name at remote node concord:

$ copy traitors.lis concord::disk1:[patriots]traitors.lis 
$ copy traitors.lis concord::disk1:[patriots]  

The following command is the wildcard form of the COPY command. The latest versions of all files in the user's default directory at the local node are copied to the remote node lexington.

$ copy *.* lexington::[british]*.* 

The next command copies two local files, user1.dat and user2.dat, to a single new file, users.dat, at remote node lexington:

$ copy user1.dat,user2.dat lexington::[british]users.dat  

To specify explicitly the access privileges of a particular account on a remote node when copying a file from that node, include the user name and password for that account in the file specification, as in the following example:

$ copy lexington"revere silver"::[statistics]summary.lis * 

Use the APPEND command to add the contents of one or more input files to the end of an output file located at a different node. For example, to add the contents of the files data1.lis and data2.lis at remote node lexington to the end of the file results.lis at node britain, use the following command:

$ append lexington"revere silver"::[liberty]data1.lis,data2.lis 
_To: britain::dba0:[product]results.lis 

To queue a file for printing at the remote node on which it exists, specify the remote file specification in the PRINT/REMOTE command. The PRINT/REMOTE command does not copy the file to the remote node; you must enter a separate COPY command if the file does not reside at the remote node on which it is to be printed. For example, the following commands cause the local file witches.lis to be copied to the default DECnet directory at remote node salem and queued for printing at node salem:

$ copy witches.lis salem::work:[project] 
$ print/remote salem::work:[project]report 

Alternatively, you can copy a file to a printing device on the remote system. If the device is spooled (for example, a line printer), the file will be stored temporarily on disk and entered in the print queue for the device. For example, the following command performs the same operation as the two previous commands, causing the local file to be printed at the line printer at node salem under the default nonprivileged DECnet account:

$ copy report.lis salem::lpa0: 

Note that the /REMOTE qualifier is required in the PRINT command whenever a remote file is specified, and that you cannot include any other qualifiers with this command. The PRINT/REMOTE command supplies a default file type of LIS.

5.4.4 Other Remote File Operations

In addition to displaying, copying, and printing remote files, you can also:

• Edit
• Delete
• Purge
• Search
• Compare
• Sort
• Merge
• Examine
• Back up

To invoke the EDT editor to edit the file story.txt in the directory [manuscript] on remote node london, enter:

$ edit/edt london::[manuscript]story.txt 

To delete the file details.lis;2 in the directory information at remote node boston, use this command:

$ delete boston"walker projmgr"::dba1:[information]details.lis;2 

If you have a proxy account that allows you full access to the directory suggestions on remote node austin, you can delete all files in that directory, as follows:

$ delete austin::work:[suggestions]*.*;* 

To purge all but the two highest-numbered versions of each file of the type LIS in the directory proposals at remote node austin, use this command:

$ purge austin::work:[proposals]*.lis/keep=2 

The following SEARCH command causes the files members.lis and data.lis at remote node concord to be searched for all occurrences of the character string name:

$ search concord::disk1:[club]members.lis,data.lis 
_String(s):      name   

This command compares the two highest-numbered versions of the file test.dat in the nonprivileged default DECnet account on remote node boston:

$ differences boston::test.dat 

The following command compares two remote files and displays any differences found. The first file is test.dat at remote node boston and the second file is test.dat at remote node london.

$ differences boston::test.dat london::dba0:[product]test.dat 

The following command requests a default alphanumeric sort of the records in the file random.fil at remote node boston. The SORT program sorts the records on the basis of the contents of the first seven characters in each record and writes the sorted list into the output file alphanm.srt created in the default directory at the local node.

$ sort/key=(position:1,size:7) - 
_$ boston::dba1:[records]random.fil alphanm.srt 

The example of a merge command shown below causes two identically sorted files, file1.srt and file2.srt, on the directory project at remote node austin to be merged into an output file. This output file, mergefile.dat, is created at the current default directory at the local node.

The input file qualifier /CHECK_SEQUENCE is specified to ensure that the input files are sorted in the correct order.

$ merge/key=(position:1,size:30) - 
_$ austin::work:[project]file1.srt,file2.srt/check_sequence - 
_$ mergefile.dat) 

The following command analyzes the structure of the file run.dat at remote node austin:

$ analyze/rms_file austin::work:[production]run.dat 

The following command causes records from the file sales.tmp at the local node to be added sequentially to the end of the output file sales.cmd at remote node boston. The file sales.tmp is sequential with variable-length record format, and the file sales.cmd is sequential with stream record format. When the Convert utility loads records from the input file to the output file, it changes the record format.

$ convert/append sales.tmp boston::dba1:[records]sales.cmd 

Use the DUMP/RECORDS command to display the contents of remote files in ASCII, hexadecimal, decimal, or octal representation. The DUMP command qualifiers /ALLOCATED and /BLOCKS are not supported in the network context. The following command dumps the contents of the file calc.dat, which resides at remote node boston. The command formats the output both in octal words and in character strings, and queues the output to the system printer at the local node.

$ dump/records/octal/word 
_File(s):  boston::dba1:[records]calc.dat/printer 

The following command saves the files in the directory sched on disk DB1 at the local node in the BACKUP save set sch.bck at remote node miami. The /SAVE_SET qualifier is required to identify the output specifier as a save set on a Files-11 medium.

$ backup 
_From:  db1:[sched]*.* 
_To:    miami::dba2:[save]sch.bck/save_set 

Any user can send electronic mail to, and receive mail from, any other user on the network. Mail can be exchanged between all DECnet and DECnet-Plus nodes.

5.5.1 The MAIL Command

To address the mail message to the intended recipient on the remote node, you normally use the format nodename::username. For example, to send mail to user longfellow on remote node salem, invoke mail and enter the following:

$ mail 
MAIL> send 
To:   salem::longfellow 

If the network connection to the remote node is not available, you receive the following message:

_SYSTEM-F-UNREACHABLE, remote node is not currently reachable 

When someone on a remote node sends you mail, the sender is identified by node name as well as user name. For example, if user alcott at node concord sends you a mail message over the network, the sender is identified in the following way:

From:  CONCORD::ALCOTT 

You can receive notification of mail arriving from a remote node. The notice displayed on your screen is in the following form:

New mail on node 'local-nodename' from 'remote-nodename::username' 

For example, if user alcott on node concord sends you mail on node literature, this notice is displayed:

New mail on node LITERATURE from CONCORD::ALCOTT 

For example, user bronte is logged in to node literature in a cluster that uses the alias CLUST1. When she receives a reply to a message she sent user alcott at remote node concord, the message will indicate the cluster node name CLUST1 (rather than the node name literature), as in the following:

From:  CONCORD::ALCOTT 
To:    CLUST1::BRONTE    

Additionally, the mail notification that user BRONTE receives may indicate that the mail was received at a different node (for example, BOOKS) in the same cluster, as in the following:

New mail on node BOOKS from CONCORD::ALCOTT 

You can send either messages or files over the network. If you are composing a long message for transmission to a remote node, you may prefer to use an editor to create the message file and then invoke MAIL to transmit the file. This method permits you to avoid the possibility of losing the network connection before you complete your message.

5.5.2 The Phone Utility

To contact OpenVMS users over the network, you can also use the Phone utility, which allows you to have an "online" conversation with a user on another OpenVMS node that supports Phone.

To receive messages from the Phone utility, one of the following conditions must be met.

• Default access must be provided by a default access account for the Phone utility or by the default DECnet account.
• The sender must have a proxy account on your system or include, in the command, the name and password for an account on your system.

To address a user on a remote node, use the format nodename::username. Your outgoing connection identifies your local node. During your conversation, Phone creates a number of incoming links addressed to your node. You should not use a cluster alias node name with the Phone utility because links addressed to a cluster alias node name can be assigned to any node in the cluster.

This chapter contains material to help you use DECnet-Plus for OpenVMS to initiate remote file operations in a heterogeneous network environment. This chapter discusses restrictions on using DCL commands and RMS service calls to access files on the following types of remote systems:

• OpenVMS to Digital UNIX or ULTRIX
• OpenVMS to MS-DOS
• OpenVMS to RSX using RMS-based FAL
• OpenVMS to OpenVMS

The chapter is organized by operating-system type: one section for each system with which your OpenVMS operating system running DECnet-Plus for OpenVMS can communicate. Each section describes differences in file system operation between the two systems and constraints on the use of OpenVMS file processing commands. The restrictions on the remote file operations you can perform from a DECnet-Plus for OpenVMS node to a particular node result from file system design differences and DECnet implementation restrictions between the systems.

The appropriate section for each remote system itemizes the OpenVMS Record Management Services (RMS) features that are supported between DECnet-Plus for OpenVMS systems, but are not supported when accessing files on a different system. The chapter also discusses limitations on the Digital Command Language (DCL) commands that you can use when communicating with the remote node. Throughout this chapter, comments are provided to help you handle the differences in file system design.

6.1 General DECnet Restrictions

This section is a brief summary of OpenVMS RMS features that are not supported by DECnet-Plus for OpenVMS for remote file access. The list is not complete; it is meant only to highlight the more important differences between local and remote file access capabilities.

• The following OpenVMS RMS service calls are not supported for network use:
  • $ENTER
  • $NXTVOL
  • $REMOVE
• The Terminal XAB is not supported for network operations; it is ignored.
• Protection XAB fields that support access control lists are ignored for network operations.
• Only one data stream per open file is allowed. That is, the multistream (MSE) bit option of the file sharing (SHR) field of the FAB is not supported for network use.
• Access to files on magnetic tapes mounted on a remote OpenVMS operating system is not supported. You can, however, copy files from a local magnetic tape to disk on a remote node.
• When multiple Allocation XABs are linked to the FAB, they must be in ascending order by area number (AID field). Similarly, when multiple Key Definition XABs are used, they must be in ascending order by key of reference (REF field).
• File protection information may not be completely preserved if the two nodes do not fully support each other's protection attributes. An example of this incompatibility occurs between RSX--11M--PLUS and OpenVMS operating systems. Although both systems represent their protection masks as RWED, RSX--11M--PLUS interprets that as Read, Write, Extend, and Delete, while the OpenVMS operating system interprets RWED as Read, Write, Execute, and Delete. This results in the "E" protection field being unmappable between these two systems.
• The Journaling XABs are not supported.
• File monitoring is not supported.
• The user file open (FAB$V_UFO) file processing option is not supported.

This section pertains to an OpenVMS node communicating with a Digital UNIX or ULTRIX node running DECnet-Plus for Digital UNIX or ULTRIX. The discussion focuses on file operations initiated from the OpenVMS node, to access remote files by means of the FAL at the Digital UNIX or ULTRIX node.

6.2.1 File System Constraints

The file systems used by Digital UNIX or ULTRIX and OpenVMS are dissimilar in many respects. A fundamental difference between them involves the handling of file attribute information. When you create a file on an OpenVMS operating system, attribute information about the file is stored in a header block on disk for use when the file is subsequently opened.

The implication is that the structure of an established file cannot change. In contrast, Digital UNIX or ULTRIX does not save attribute information such as file format with a file; it expects you to provide this information when you open the file. File attribute information, however, is not an input to OpenVMS RMS when a file is opened.

To provide transparent access to files on a remote Digital UNIX or ULTRIX operating system, OpenVMS RMS restricts the types of files you can create and open on the remote node. When you access a Digital UNIX or ULTRIX file in record mode, OpenVMS RMS treats the file as having STREAM_LF (STMLF) format.

6.2.1.1 File Formats and Access Modes

Because of differences in file system design, the following types of file and access method are not supported by OpenVMS when communicating with a Digital UNIX or ULTRIX node:

• File organizations and record formats

  Sequential	Fixed length (FIX) without implied carriage control
  	STREAM_CR (STMCR)
  	Stream (STM)
  	Variable length (VAR) without implied carriage control
  	Variable with fixed control (VFC)
  Relative	All formats
  Indexed	All formats

• Record attributes
  • FORTRAN carriage control (FTN)
  • Print file carriage control (PRN)
  • None specified (embedded carriage control)
• Record access modes
  • Random access by relative record number
  • Random access by key value
  • Random access by record file address
  • Block I/O

For record mode access, the only file type in common between the two systems is a sequential file in STMLF (STREAM_LF) format. For convenience, however, when you are transferring a file to a Digital UNIX or ULTRIX node, OpenVMS RMS automatically converts an OpenVMS sequential file with fixed or variable format and implied carriage control to a sequential file with stream format and embedded carriage control. This automatic conversion is performed during a file create operation, and OpenVMS RMS returns an alternate success code (RMS$_CVT_STM) to indicate that the file format has been modified.

Note also that when a STREAM-LF format file is retrieved from a Digital UNIX or ULTRIX node, OpenVMS RMS automatically changes the record attribute from embedded carriage control to implied carriage control.

To transfer files that cannot be copied directly, enter the following DCL command:

$ CONVERT/FDL=STMLF.FDL input-file output-file 

  INTRO_PROFILE_007.HTML
  OSSG Documentation
   2-DEC-1996 12:54:28.45

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal