HP OpenVMS Systems Documentation

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

The FDL control file STMLF.FDL contains the following information:

FILE
        ORGANIZATION          sequential
RECORD
        FORMAT                STREAM_LF
        CARRIAGE_CONTROL      none

The CONVERT command and associated FDL control file transform the input file to stream format with embedded carriage control and then copy it to the remote node according to the output file specification.