![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
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.
The following OpenVMS RMS features, supported between two OpenVMS nodes, are not supported between an OpenVMS node and a Digital UNIX or ULTRIX node:
| $DELETE | $DISPLAY | $EXTEND | $FIND |
| $FREE | $RELEASE | $RENAME | $REWIND |
| $TRUNCATE | $UPDATE |
The general format of a file specification for naming a file on a remote Digital UNIX or ULTRIX operating system is as follows:
node::name
The following are the major differences in syntax between file specifications on Digital UNIX or ULTRIX and on OpenVMS:
Because of these differences, most accesses to a Digital UNIX or ULTRIX operating system require a foreign file specification. Without the foreign file specification syntax, the name is converted to uppercase by OpenVMS, and is then unlikely to match files on the Digital UNIX or ULTRIX operating system. The OpenVMS concepts of device and directory do not match the Digital UNIX or ULTRIX concept of path, nor does Digital UNIX or ULTRIX support separate file type or version fields. Therefore, OpenVMS-related name processing does not work with Digital UNIX or ULTRIX file names.
Of the OpenVMS DCL commands that you can use over the network, the following are not supported between OpenVMS and a Digital UNIX or ULTRIX node:
The /ALLOCATION and /EXTENSION qualifiers to the COPY command are not supported and are ignored if specified.
When you enter a DIRECTORY/FULL command to examine a Digital UNIX or ULTRIX file, the information displayed differs in the following respects from that displayed for an OpenVMS file:
This section pertains to an OpenVMS node communicating with a PC running the DECnet feature of PATHWORKS for DOS. The discussion focuses on file operations initiated from the OpenVMS node, to access remote files by means of the FAL at the MS-DOS node.
The file systems used by MS-DOS 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, MS-DOS 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 MS-DOS system, OpenVMS RMS restricts the types of file that you can create and open on the remote node. When you access an MS-DOS file in record mode, OpenVMS RMS treats the file as having stream format.
Because of differences in file system design, the following types of file and access method are not supported by OpenVMS when communicating with an MS-DOS node:
| Sequential | Fixed length (FIX) without implied carriage control |
| Stream_CR (STMCR) | |
| Stream_LF (STMLF) | |
| Variable length (VAR) without implied carriage control | |
| Variable with fixed control (VFC) | |
| Relative | All formats |
| Indexed | All formats |
For record mode access, the only file type in common between the two systems is a sequential file in STM (stream) format. For convenience, however, when you are transferring a file to an MS-DOS 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 format file is retrieved from an MS-DOS node, OpenVMS RMS automatically changes the record attribute from embedded carriage control to implied carriage control.
In general, you can copy text files created by the TPU or EDT editor to an MS-DOS operating system. OpenVMS batch log files, however, are stored in VFC format, and cannot be copied in that form to an MS-DOS operating system. To transfer this type of file, enter the following DCL command:
$ CONVERT/FDL=STM.FDL input-file output-file
The FDL control file STM.FDL contains the following information:
FILE
ORGANIZATION sequential
RECORD
FORMAT stream
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.
The following OpenVMS RMS features, supported between two OpenVMS nodes, are not supported between an OpenVMS node and an MS-DOS node:
| $DELETE | $DISPLAY | $EXTEND | $FIND |
| $FREE | $RELEASE | $RENAME | $REWIND |
| $TRUNCATE | $UPDATE | $WRITE |
The general format of a file specification for naming a file on a remote MS-DOS operating system is as follows: node::"device:\directory\name"
The major difference in syntax between file specifications on MS-DOS and on OpenVMS is that the directory components of an MS-DOS file specification are in an incompatible format. For example: \directory\
As a result, you must use quoted strings when you access these MS-DOS files from an OpenVMS operating system.
On DOS-based systems, the FAL object accepts incoming requests using file specifications in OpenVMS syntax and maps those requests to file specifications for DOS. For example:
$ DIRECTORY PC::[REPORT]
This directory specification is mapped to the following directory specification:
$ DIRECTORY PC::\report\*.*
DOS file specifications are restricted to file names of eight characters, file extensions of three characters, and do not support version numbers.
Of the OpenVMS DCL commands that you can use over the network, the following are not supported between OpenVMS and an MS-DOS node:
The /ALLOCATION and /EXTENSION qualifiers to the COPY command are not supported and are ignored if specified.
When you enter a DIRECTORY/FULL command to examine an MS-DOS file, the information displayed differs in the following respects from that displayed for an OpenVMS file:
This section pertains to an OpenVMS node communicating with an RSX node running either DECnet-11M or DECnet-11M-PLUS where the RSX file access listener (FAL) calls RMS-11 to perform local file operations. The discussion focuses on file operations initiated from the OpenVMS node, to access remote files by means of the FAL at the RSX node.
The following restrictions are related to incompatible features in file system design between the two systems.
The following types of file and record attributes are not supported by OpenVMS when communicating with an RSX node running the RMS-based FAL:
| Sequential | Stream_CR (STMCR) |
| Stream_LF (STMLF) | |
| Indexed | All prologue three formats |
| With 64-bit binary (BN8) key types | |
| With 64-bit integer (IN8) key types | |
| With collating (COL) key types | |
| With descending key types (DSTG, DIN2, DBN2, DIN4, DBN4, DIN8, DBN8, DPAC, DCOL) |
The following OpenVMS RMS features, supported between two OpenVMS nodes, are not supported between an OpenVMS node and an RMS-based RSX node:
| $RELEASE |
The general format of a file specification for naming a file on a remote RSX-11M or RSX-11M-PLUS system is as follows:
node::device:[directory]name.type;version
The following are major differences in syntax between file specifications used on RSX and OpenVMS:
Of the OpenVMS DCL commands that you can use over the network, the OPEN/WRITE command is not supported between OpenVMS and an RMS-based RSX node.
Because RSX-11M and RSX-11M-PLUS operating systems use octal version numbers in file specifications, any attempt to copy a file with a version number containing an 8 or 9 is rejected by the remote system. For example:
$ copy a.dat;9 rsx::*.* %COPY-E-OPENOUT, error opening rsx::a.dat;9 as output -RMS-F-FNM, error in file name
There are two ways to circumvent this problem. You can specify an appropriate octal version number in the output file specification, or you can specify a null or zero version number in the output file specification to force highest version number processing on the remote node. This latter technique is particularly useful when several files are copied with one DCL command. For example:
$ copy a.dat;9 rsx::a.dat;11 $ copy b.dat;28 rsx::*.*; $ copy b.dat;28 rsx::*.*;0 $ copy *.dat rsx::*.*;0
This DECnet-Plus Glossary covers terms that explain the features and operation of DECnet-Plus for OpenVMS covering these areas:
Table 1 at the end of the glossary lists open-networking-related acronyms and their meanings. Table 2 lists the ISO and IEC acronyms in transition.
A-ASSOCIATE request: Association Control Service
Element (ACSE) service that initiates a communications channel for data
transfer at the Application layer between two peer service users; used
by applications such as FTAM and OSAK.
absolute time: Point on a time scale. For DECdts,
absolute time references the Coordinated Universal Time (UTC) standard.
abstract syntax: Implementation-independent way of
representing Application layer data or application or presentation
protocol control information (PCI). Consists of a group of data types
that describe a set of data structures that several applications can
share.
abstract syntax notation: Notation in which an
abstract syntax is described. The rules of abstract syntax notation are
independent of the encoding techniques used to represent them.
Abstract Syntax Notation One: See
ASN.1.
acceptor: Peer entity that responds to a service
request.
access context: FTAM method of specifying the type of
information for a file-access data unit (FADU) that can be accessed.
access control entry (ACE): Defined as:
access control information: Character string with
login information that validates connect or login at a remote host. On
an OpenVMS system, for example, user name and password are access
control information.
access control list (ACL): List of access control
entries (ACEs) that grant or deny access to a particular system object.
access control set (ACS): Attribute associated with
DECdns clearinghouses, directories, object entries, and soft links that
determines who has access to them, and what the access rights are;
consists of one or more ACEs.
access plug-in: Plug-in responsible for the director's
end of the Management Access Protocol.
access rights: Set of DECdns assignable rights that
determines what users can do with clearinghouses, directories, and the
names they contain. The access rights are read, write, delete, test,
and control.
ACE: See access control
entry.
acknowledgment: Message sent from a PSDN indicating
that a packet has been received.
ACL: See access control list.
ACS: See access control set.
ACSE: See Association Control Service
Element.
actively associated task: Task that asks OSI transport
to associate it with a particular transport service access point
(TSAP). When a connection request for that TSAP arrives, OSI transport
directs the request to the task associated with that TSAP.
activity: Logical piece of work.
activity attribute: Any of a set of attributes that
describe the current use of the FTAM file service; descriptive tool for
describing specific actions that are local to a given FTAM regime and
any nested regime.
adaptive routing: Feature of DECnet-Plus routing in
which the intermediate system dynamically determines the most
cost-effective path currently available, forwards messages through the
network along this path, and automatically reroutes messages if a
circuit becomes disabled. The path, or choice, depends on the current
information stored in the routing database, which is updated regularly.
address prefix: Some leading portion of a network
service access point (NSAP); can be of any length, from zero digits up
to the full length of the NSAP; can be used in a reachable-address
table to indicate that any packets with a destination NSAP beginning
with a specified address prefix are to be routed through a specified
circuit.
address resolution: Session Control function that maps
from a DECnet-Plus full name to the identifiers of protocols and
corresponding addresses that are mutually supported by the local system
and the remote system on which the named object resides.
address selection: DNA Session Control function that
provides transparent selection of protocols and addresses for transport
connection establishment based upon the destination object name.
address tower: See tower.
addressing: Function that ensures that different
communicating systems are identified correctly at all times. For
example, in the Transport layer, provides a unique address to every
transport service access point (TSAP). See also
DECnet-Plus addressing.
addressing authority: Authority responsible for the
unique assignment of Network layer addresses within an addressing
domain. Example: the American National Standards Institute (ANSI).
addressing domain: Level in the hierarchy of Network
layer addresses. Every NSAP address is part of an addressing domain
administered directly by one addressing authority.
adjacency: Single connection to an adjacent node.
Collection of state information representing a node in the local node's
routing databases.
adjacency address: Address that identifies a local
subnetwork access point and a subnetwork address of an adjacent system.
adjacent nodes: Nodes with direct lines between them;
can communicate without an intermediate system. For example, all nodes
on an Ethernet LAN are adjacent to each other.
adjustment: DECdts process of changing the system
clock time by modifying the incremental value that is added to the
clock's software register for a specified duration.
ADMD: See Administration Management
Domain.
Administration Management Domain (ADMD): X.400 Message
Handling System public service carrier, for example, MCImail and
ATTmail in the U.S. and British Telecom Gold400mail in the U.K. The
ADMDs in all countries worldwide together provide the X.400 backbone.
See also Private Management Domain.
administrative domain: Collection of end systems,
intermediate systems, and subnetworks operated by a single organization
or administrative authority; can be subdivided into a number of routing
domains.
advertisement: Information sent in the multicasts of
DECdns servers to make their existence known; includes the server's
address and attributes. This information is used by other servers and
DECdns clerks in a local area network. The clerks cache the addresses.
AE qualifier (application-entity qualifier):
Identifier of a specific application entity within an application
process.
AE title (application-entity title): Unique name of an
application entity. Consists of an application-process title and an
application entity qualifier.
AFI: See authority and format
identifier.
aged packet: Data packet that is discarded because it
exceeded the maximum number of visits while being forwarded through the
network.
agent: Defined as:
agent access point: Instance of a connection between a
director or a parent entity and an agent.
aggregate throughput: See
throughput.
algorithm: See link state
algorithm and routing vector algorithm.
alias: FTAM and Virtual Terminal: Application name
that corresponds to an address and, optionally, other information
required to locate a remote system and its FTAM implementation.
alias node identifier: See cluster
alias.
American National Standards Institute (ANSI): U.S.
standardization body that defines U.S. standards for the information
processing industry; ANSI participates in defining network protocol
standards.
AOW: See Asia and Oceania
Workshop.
AP-title (application-process title): Component of an
application-entity title. Identifier of an application process.
API: See application programming
interface.
application: Process that performs a specific network
function, such as remote file operations and mail.
application context: Explicitly identified set of one
or more application service elements (ASEs), for example, FTAM, related
options, and any other necessary information or rules for an
association.
application entity: Set of resources, for example,
programs and process slots, that perform a communication function.
Entity that invokes one or more protocol machines of the Application
layer within an application process.
application-entity qualifier: See
AE-qualifier.
application-entity title: See
AE-title.
Application layer: Top layer (Layer 7) in the OSI
Reference Model; provides for distributed processing and access;
contains the applications and supporting protocols that use the lower
layers. Has no formal upper boundary because it includes application
programs, for example, electronic mail and file transfer, and their
individual user interfaces. All OSI application programs are part of
this layer.
application process: Defined as:
application-process title: See
AP-title.
application programming interface (API): Set of
calling conventions defining how an application invokes a service
through a software package.
application service element (ASE): Application layer
element that supplies a specific service to an application process.
architecture: Model that defines the relative
positions of specific functions and the types of relationships that
these functions can make. A layered architecture defines the grouping
of functions within a layer and provides the basis for defining formal
protocols. For example, the OSI Reference Model is a layered model,
based on the concept of functional layers. See also
Digital Network Architecture and ISO Reference
Model for Open Systems Interconnection.
area: Group of systems, within a routing domain, that
make up a single level 1 routing subdomain. These systems can run
independently as a subnetwork.
area address: Address prefix, which consists of the
inital domain part (IDP) through to and including the LOC-AREA field of
an NSAP. A DECnet-Plus system can have more than one area address, but
the systems making up an area must have at least one area address in
common with each of their neighbors.
area router: See level 2
router, DECnet-Plus level 2 router, and
DECnet Phase IV level 2 router.
area routing: Forwarding of data packets from one
network area to another by the intermediate systems in the level 2
network.
INTRO_PROFILE_008.HTML OSSG Documentation 2-DEC-1996 12:54:30.14
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.