Digital PDFs

AA-D601A-TC

March 1978

67 pages

Original

2.4MB

Document:	DAP
Order Number:	AA-D601A-TC
Revision:	0
Pages:	67
Original Filename:

OCR Text

Order No. AA-0601A-TC

DAP

" ....

"""

To order additional copies of this document, contact the Software Distribution
Center, Digital Equipment Corporation, Maynard, Massachusetts 01754.

mDmDomo

DEeNET
DIGITAL NETWORK ARCHITECTURE

Data Access Protocol

(DAP)

Functional Specification
Version 4.1

March 1978

digital equipment corporation · maynard. massachusetts

First Printing, March 1978

The information in this document is subject to change without notice
and should not be construed as a commitment by Digital Equipment
Corporation. Digital Equipment Corporation assumes no responsibility
for any errors that may appear in this document.
The software described in this document is furnished under a license
and may only be used or copied in accordance with the terms of such
license.
No responsibility is assumed for the use or reliability of software on
equipment that is not supplied by DIGITAL or its affiliated companies.

ABSTRACT
This document describes the features,
message formats,
and operation of the
Data
Access
Protocol
(DAP) .
DAP
provides
standardized
formats
and
procedures for accessing and passing
data between a user process and a file
system
existing
in
a
network
environment.
It assumes a controlled
conversation path
provided
by
the
network system.
In DECnet, this path is
created by the Network Services Protocol
and its associated interface.

iii

Table of Contents

Section

Title

Page

1.0

SCOPE

2.0

FUNCTIONAL DESCRIPTION
2.1 DAP Functions
2.2 Relationship to DECnet
2.3 Generic Model

2
2
2
3

3.0

MESSAGE FORMATS
3.1 Notation
3.2 General Message Format
3.3 Configuration Message
3.4 Attributes Message
3.5 Access Message
3.6 Control Message
3.7 Continue Transfer Message
3.8 Acknowledge Message
3.9 Access Complete Message
3.10 Data Message
3.11 Status Message

6
6
7
8
11
19
22
25
26
26
27
27

4.0

FILE ORGANIZATION
4.1 Types of Files
4.2 Record Formats/Attributes
4.3 Data Formats

37
37
37

OPERATION
5.1 Setting up the Link
5.2 Transferring Data over the Link
5.3 Closing a File and Terminating
Data Streams
5.4 Terminating a Logical Link
5.5 File Security and Protection

41
41

APPENDIX A

GLOSSARY

APPENDIX B

RSX/IAS/RT DECNET IMPLEMENTATIONS
Bl.0 FAL
B2.0 NFARS
B3.0 NFT

57
57
57

REVISION HISTORY

5.0

APPENDIX C

54
54
55

List of Illustrations
Figure

Title

Page

2-1

Typical OAP Message Exchange (Sequential
File Retrieval)
Setup Sequence
File Retrieval Sequence
Sequential File Storage
FAL State Diagram

44
48
49
58

5-1
5-2
5-3
B-1

List of Tables
Table

Title

Page

2-1
3-1
3-2

OAP Messages
MACCOOE Field Values
MICCOOE Field Values for Use with MACCOOE
Values of 2, 10, and 11 Octal
MICCOOE Field Values for Use with MAC CODE
Values of 0, 1, 4, 5 and 7 Octal
MICCOOE Field Values with MACCODE Value
of 12 Octal
Conversion Table
Responses to Setup Message Errors

4
28

3-3
3-4
4-1
5-1

29
32
36
38
44

1.0

SCOPE

This document describes the functions, characteristics, capabilities,
and operation of the Data Access Protocol (DAP). It is primarily
intended to assist developers and implementers in understanding how
DAP functions within a system.
The document is not intended to
address specific implementations.
The Data Access Protocol Version 4.1 is specifically designed for
remote file access via a file system such as Record Management
Services. Unit Record Devices and terminals can be accessed if
supported by a file system. When Unit Record Devices and terminals
are supported by a file system in a device-independent manner, the
device control features are not supported by DAP.

2.0

FUNCTIONAL DESCRIPTION

The Data Access Protocol is a user level protocol.
Its primary
purpose is to permit remote file access within the DECnet environment
independently of the I/O structure of the operating system being
accessed.

2.1

DAP Functions

Within DECnet, DIGITAL Operating Systems can employ DAP to provide the
following remote file access functions:

2.2

Retrieve a file from an input device (e.g., a disk file, card
reader, or terminal);

Store a file on an output device (e.g.,
printer or terminal);

Provide ASCII file transportability between nodes;

Provide Error Recovery;

Allow multiple data streams to be sent over a logical link;

Command file execution and submission;

Provide for random access of records in a file;

Provide for file deletion,

Rename files;

10.

List directories.

disk

file,

line

and

Relationship to DECnet

DECnet is a family of products that create distributed networks from
DIGITAL computers and their interconnecting data links.
DECnet
creates a general mechanism for sharing resources and providing
interprocess communications within a distributed data processing
environment.
DECnet implementations adhere to a common network
architecture
that defines the structure and protocols used to
communicate through the network.
The DIGITAL Network Architecture provides a modular design for DECnet.
Its functional components are defined within three distinct layers:
the Physical Link Control Layer, the Network Service Layer, and the
Application Layer. Each layer performs a well-defined set of network
functions (via network protocols) and presents a level of abstraction
and capability to the layer above it:

Physical Link Control Layer - The Physical Link Control Layer controls
the physical link operation to ensure
both data integrity and sequentiality.
Network Service Layer

- The Network Service Layer provides the
mechanism
that
permits node-to-node
communications and
process-to-process
communications between processes in the
same or different nodes.
It performs
the network routing, message handling
and information flow control functions.

Application Layer

- The Application Layer
supports
the"
various user services and programs that
utilize the network facilities.
These
services and programs must utilize the
network communication mechanism provided
by the Network Services Laver.
DAP
resides within the Application-Layer.

2.3

Generic Model

As an aid toward understanding the Data Access Protocol, a generic
model is presented.
This model consists of a summary of the DAP
messages and a typical DAP message exchange sequence (illustrating how
DECnet Sequential File Retrieval is accomplished between two dialogue
processes).
For a more detailed description of the DAP message formats and
protocol operation, refer to Sections 3.0 and 5.0, respectively.

the

Table 2-1.

DAP Messages

Message

Function

Configuration
Message

Used to exchange system capability and
configuration
information
between
DAP
speaking processes.
This message is sent
immediately following link establishment.
It contains information about the operating
system, the file system, protocol version,
and buffering ability.

Attributes
Message

Provides information on how data is being
structured in the file being accessed. The
message
contains
information
on file
organization, data type, format, record
attributes, record length, size, device
characteristics, and security.

Access
Message

Specifies the file name and type of
requested.

Control
Message

Used to send control information to a file
system and to establish data streams.

Continue-Transfer
Message

Allows recovery from errors.
retry, skip, and abort.

Acknowledge
Message

Used to acknowledge access commands and
control connect messages used to establish
data streams.

Access Complete
Message

Denotes Termination of Access.

Data Message

Transfers the file data over the link.

Status
Message

Used to return status
error conditions.

access

Used

for

and information on

Connect Initiate Message
Request to Communicate
Connect Confirm Message
Request Accepted
Configuration Message
Configuration Information
(e.g., as, File System
DECnet Phase No., and
DAP Version No.)
Configuration Message
4

Similar information
returned from
distant Node
Attributes Message

Data Information
(e.g., Type, Blk Size
and Record Size)

Access Message
File Information Requested

Attributes Message
Information Verified

Acknowledge Message
Control (Initiate Data Stream)

Send information

Acknowledge Message
Control Get
~

Record 1
4

Starts file transfer
Data Sent in records

••
•
Record N
Status Message

End-of-file

Access Complete Message
~

Request to terminate
Access Complete Response

Request Accepted

Figure 2-1.

Typical DAP Message Exchange (Sequential File Retrieval)

3.0

MESSAGE FORMATS

3.1

Notation

The following notation is used to describe the DAP messages:
Field (length) : coding = description of field.
where:
the name of the field being described.

Field

length = the length of the field, which can be
four ways:

indicated

one

A number meaning number of 8-bit bytes (octet).

A number followed by a "B" meaning number of bits.

The letters "EX" meaning extensible field. Extensible fields
are of variable length consisting of 8-bit bytes in which the
high-order bit of each byte denotes whether the next byte is
part of the same field. A 1 means the next byte is part of
this field and a 0 denotes the last byte. Extensible fields
are for bit maps only. Seven bits from each octet are used
as information bits. The notation EX-n means an extensible
field where the maximum length of the field is n bytes.

The letters "I-n" means this is an image field, with n being
a number that specifies the maximum length of 8-bit bytes in
the image. The image is preceded by a I-byte count of the
length of the remainder of the field.
Image fields are
variable in length and may be null (count=O). Al18-bits of
each byte are used as information bits. The meaning and
interpretation of each image field is defined with that
specific field.

coding

the representation type used.

Where:

A
7-bit ASCII
B = binary
BM
bit map (in which each bit has a specific meaning)

The following rules apply to the notation:
1.

If length and coding are omitted, Field represents
of subfields specified in description.

Any bit or field described as "reserved" shall be zero unless
otherwise specified.

All fields are presented to the Network Services Protocol
with the least-significant byte first.
In an ASCII field,
the left-most character is contained in the low-order byte.

All numbers are in decimal unless otherwise specified.

number

When default values are defined for fields in DAP messages,
the values will be used only if that field is absent from the
message. There are two ways in which fields within DAP
messages can be omitted so the default can be used:
a.

A field that appears under a MENU may
setting the corresponding MENU bit zero.

omitted

Trailing fields in DAP messages may be omitted if they
are not needed or if the default value can be used. If a
MENU field is truncated in this way, its value is zero
(which means all the fields controlled by the MENU are
absent, too).

If a field is present with a zero value, the default value is
not used.

3.2

General Message Format

All DAP messages have the following form:
OPERATOR

OPERAND

where:
OPERATOR

This field describes the characteristics and
type of message.
It is divided into four
subfields, TYPE, FLAGS, STREAMID and LENGTH.
TYPE (1) : B

FLAGS (EX-5)

The type of DAP message.
These
numbers are given
with
each
DAP
message
description. Types 196-255
are
reserved
for
user
extensions to DAP.
BM

The DAP
message
flags.
Bits
in this extensible
field are currently defined
as follows:
Bit(s)
0

1
2-6
7

Meaning (when set)
Stream
identification
field present.
Length field
present.
Reserved.
Extension (0) •

STREAMID(I)

The stream identification
field.
This
field
is
included only if bit 0 of
the FLAGS field is set.
This field is used to allow
a
single
user to have
multiple data streams in
use for a single open file.
All data streams use the
same
logical link
(they
multiplex on the STREAMID
number).
If the STREAMID number is
omitted, it is assumed to
be zero.
Not all
file
systems
are
capable of
supporting multiple
data
streams.

LENGTH (I)

OPERAND

3.3

Denotes the length of the
OPERAND field
(number of
8-bit bytes).
This field
IS
optional.
It
is
included only if bit r of
the FLAGS field is set.
Messages between I and 255
bytes long may be blocked.
Lengths greater than 255
bytes are sent unblocked or
as the last part of
a
blocked message.

The information field for DAP messages.
dependent on the TYPE field.

It is

Configuration Message

The configuration message is used to pass system configuration
information between both operating systems involved in a DAP Message
exchange.
This message
is
sent
immediately
following
link
establishment. The configuration message format is:
CONFIG

BUFSIZ

OSTYPE

FILESYS

VERSION

SYSCAP

where:
The OPERATOR field with TYPE=I.

CONFIG
BUFSIZ(2)

= The maximum buffer size (in bytes) of the
sending
system
allocated
for
message
exchange. The two cooperating OAP speaking
processes will use the lesser of the two
buffer sizes as the maximum size.
If a
system has an unlimited buffer size, it
sends a 0 and the two systems will use the
nonzero buffer size as the maximum.

OSTYPE(l)

Operating system type (the sending system).
Values in the range 1-127 are reserved for
DIGITAL use;
128-255 are reserved
for
user-specified operating systems.

Value

OS Type

0
1
2
3
4
5

Illegal
RT-ll
RSTS
RSX-llS
RSX-IIM
RSX-IID
lAS
VAX/VMS
Reserved for TOPS-20
Reserved for TOPS-IO

6
7

8
9

FILESYS(l)

= File system type

(of the file system being
used by the process sending this message).
Values in the range 1-127 are reserved for
DIGITAL
use;
128-255 are reserved for
user-specified file systems.
System

Value

Illegal
RMS-ll
RMS-20
RMS-32
FCS-ll
RT-ll
No file system supported

1
2
3
4
5
6
VERSION

A field identifying
the
software version numbers.
subdivided as follows:

protocol
and
This field is

I VERNUM I ECONUM I USRNUM I SOFTVER I USRSOFT
where:
DAP version number.
This
is the same as the first
digit
of
the
protocol
version number.

VERNUM(l)

ECONUM(l)

USRNUM(l)

: B

SOFTVER(l)

= DAP

ECO
(Modification)
number.
This is the same
as the second digit of the
protocol version number.
Customer modification level
of DAP.

B = DAP Software version number
in binary.
This is the
DIGITAL release number.
If
the software is completely
user written, this field
should be O.

USRSOFT(l)

SYSCAP(EX-12)

User
software
version
number in binary. If the
user
modifies
DIGITAL
software,
he
should
increment this
byte
to
reflect
his modification
number.
Set
to
0
by
DIGITAL.

Generic system capabilities.
defined as follows:

These

are

Bit

Meaning (When Set)

Supports file preallocation.
Supports
sequential
file
organization.
Supports relative file organization.
Reserved - intended
to
support
direct file organization.
Reserved - intended
to
support
indexed file organization.
Supports sequential file access.
Supports random access by record
number.
Extension (0 if subsequent fields
are not needed).
Supports random access by Virtual
Block Number.
Reserved - intended
to
support
random access by Key.
Reserved - intended
to
support
random access by user generated hash
code.
Reserved - intended
to
support
random
access
by
Record
File
Address.
Reserved - intended to support ISAM.
Reserved - intended
to
support
switching access mode.
Supports append to file access.
Extension (0 if subsequent fields
are not needed).
Supports command file
submission
and/or execution.
Reserved - intended to support file
compression.
Supports multiple data streams.
Supports status return (See ACCOPT
field in ACCESS message).
Supports blocking of DAP Messages.
Reserved.
Extens ion (0).

1
2
3
4

5
6
7
8
9

11
12
13
14
15
16

17
18
19
20

21-22
23

3.4

Attributes Message
message is used to describe how data is being
a file that is being transferred. The Attributes
part of the initial setup.
The Attributes

PROTGRPlpROTWLD
NOTE
Symbolic names where supplied, refer to
thp corresponding RMS names. They are
included here for ease of reference
only; they have no meaning for DAP.
where:
= The OPERATOR field with TYPE=2.

ATTRIB
ATTMENU(EX-6)

= The bit map below specifies which of the
indicated fields, groups of fields, or
messages follow. Some groups of attribute
fields
can become extremely long.
To
resolve the buffering problem (i.e., all
attributes
messages
must
fit into a
256-byte buffer), these groups are split
into separate messages and sent separately.
The following bit map specifies which of
the attributes fields will be present in
the main attributes
message
(if
the
corresponding bit is set):
Bit

Meaning (when set)

DATATYPE
ORG
RFM
RAT
BLS
MRS
ALQ
Extension (0 if subsequent fields
are not needed).

I
2
3
4

5
6

Bit

Meaning (when set)

8
9
10
11
12
13
14
15

BKS
FSZ
MRN
RUNSYS
DEQ
FOP
Reserved;
intended for BSZ.
Extension (0 if subsequent fields
are not needed).
16
Reserved;
intended for DEV.
17
Reserved;
intended for SDC.
18
Reserved;
intended for summary
attributes fields: NOK, NOA and
NOR.
19
Reserved;
intended for Date and
Time attributes fields CDT, RDT
and EDT.
20
Reserved;
intended for use with
the Protection attributes fields
OWNER, PROTSYS, PROTOWN, PROTGRP
and PROTWLD.
21
Reserved;
intended for use with
the Access Control List Message.
22
Reserved;
intended for use with
the Key Definition Message.
23
Extension
(0 if the following
field is not needed).
24
Reserved;
intended for use with
the Allocation Message.
25
Reserved;
intended for use with
the File Header Characteristics
Message.
26-30 Reserved (0).
31
Extension (0).

DATATYPE(EX-2)

BM = The type of data being transferred.
The
default is IMAGE.
This field is very
important for file/record retrieval.
Many
file systems do not explicitly store with
the file attributes, information as to
whether the file contains ASCII, EBCDIC or
Image data. Therefore, the contents of a
file are interpreted according to the data
type supplied by the user. In many cases,
for
DAP
remote
file
access,
where
conversions may be necessary on
ASCII
files, this field (supplied by the user) is
the only indication of data type.
Bit

Meaning (When Set)

ASCII (see Note 1).
IMAGE (see Note 2)~
EBCDIC (Reserved).
Compressed Format (Reserved
for
future use).
Executable Code.
Privileged Code.
This bit is set if the attributes
of the file
(as stored with the
file), match those specified in the
accessing ATTRIBUTES message. This
bit is used only in the ATTRIBUTES
message being returned (i.e., by
the accessed DAP process).
Extension (0).

1
2
3

4
S
6

Notes:
1. This is the 7-bit ASCII code set as
defined in the 1968 ANSI Standard. To
transmit this within 8-bit frames, the
high-order bit is set to zero.
2. Image is the mode where no code set is
specified.
It is a format for sending
8-bit quantities in DAP without specifying
any code representation. The actual data
may be ASCII, or binary. It is up to the
user process to determine how to use the
data.
ORG{l)

Attributes of the file being
These attributes are as follows:
Value
(octal)

accessed.

Meaning

FB$SEQ;
FB$RELi
FB$IDXi
FB$DIRi

20
40
60

Sequential (default).
Relative.
Indexed (Reserved).
Direct (Reserved).

RFM (1)

Format of the records being
These formats are as follows:

Value

Meaning

Undefined record format.
FB$UDF;
FB$FIX;
Fixed-length
records
(default) •
FB$VAR; Variable-length records.
FB$VFC;
Variable
with
fixed
control format (disk only).
FB$STM;
ASCII
Stream
Format
(sequential files only).
FB$LSA;
Line-sequenced
ASCII
format (sequential files only).

1
2
3
4

RAT (EX-3)

Information
about
individual records;
Bit

o
1
2
3

4
5-6
7

transferred.

Meaning

the

attributes

(When Set)

FB$FTN;
Records contain FORTRAN
carriage control (see Note 1).
FB$CR;
Records have an implied
LF/CR envelope.
Reserved
(O}-Intended for
COBOL
carriage control.
FB$BLK;
Records that do not span
blocks (see Note 2).
Records
have
embedded
format
control.
Reserved (0).
Extension (0).

Notes:

1. FORTRAN Carriage Control.
For line
printers and some terminals,
the first
character of each record is to be treated
as a carriage control character according
to the ANSI definition.
2. This bit when set informs the
that the record length should not
the physical device blocking size.
some systems and on some I/O devices
disk and magnetic tape)
this may
factor
in determining the actual
used on the device.

system
exceed
With
(e.g. ,
be a
format

BLS (2)

Physical block size in bytes. The Default
value is 512. The actual byte size is as
specified by field BSZ.

MRS(2)

The length of each file record in number of
bytes.
For variable-length records, this
field specifies the maximum record size.
When the accessed process receives the MRS
(maximum record size),
it must check it
against the length of its buffer.
If the
buffer will not accommodate this
size
record,
the accessed process should return
its buffer size.

If the accessed process receives a zero
value, it should do one of the following:

ALQ(I-S)

If the accessed process has a limited
buffer
size, it should return its
maximum buffer size to the accessing
process.

If the accessed process has unlimited
buffer space (i.e., dynamic buffering),
it should return a zero value.

= This

field
specifies
the
allocation
quantity.
For file creation, it specifies
the initial size of the new file.
The
actual size of the new file is returned in
this field.

NOTE
On opening existing files, this
value is ignored.
This field is
used only to return the file size.
BKS(I)

FSZ(I)

MRN (I-5)

= Bucket

size.
Used only for access to
relative (not RMS-20), direct and indexed
files with RMS.

Size in bytes of fixed part of variable
length record with fixed control format.

RUNSYS(I-40)

DEQ (2)

Maximum record number
for
relative
files
only).
If
checking is suppressed.

file
(for
set to 0,

Name of the Run-Time System environment
required to execute the code contained in
the file.
This field
is
useful
to
operating systems that can emulate other
operating system environments. The default
value
is
accessed
operating
system
dependent.
File extension quantum size in virtual
blocks, which is the amount of space, in
blocks, added to the file each time the
file is implicitly extended. Default will
be the normal default for individual file
systems.

FOP (EX-6)

The File Access Options a user requires:
Bit

Meaning

FB$RWOi
FB$RWCi

rewind on open.
rewind on close.
reserved (0).
FB$POS;
position magnetic tape
just
past
the
most recently
created file.
FB$DLKi do not lock file if not
properly closed.
Reserved (0).
FB$ACKi
check
attributes
specified for open against those
in file and return error
if they
don't match.
Extension (0 if subsequent options
are not needed).
FB$CTGi
a
contiguous
file
extension required.
FB$SUPi supersede existing file
on create.
FB$NEFi do not position to EOF on
opening magnetic tape file
for
PUT.
FB$TMP;
create temporary file.
FB$MKDi create temporary file and
mark for delete on close.
FB$FIDi open by file ID.
FB$DMOi
rewind
and
dismount
magnetic tape on close.
extension (0 if the following bits
are not used).
FB$WCKi Enable write checking.
FB$RCKi Enable Read checking.
FB$CIFi create new file if one by
the same name does not exist.
If
one does exist, open the file.
Ignore version number.
FB$LKOi
Override file lock on
open (reserved).
FB$SQOj
Sequential access only
(reserved) •
Reserved
for
maximum
version
number.
Reserved for spool file on close.
Extension (0 if subsequent fields
not needed).
Reserved for submit command file.
Reserved for delete sub-option on
submit command file.
Reserved for contiguous best try.
Reserved (0).
Extension (0).

1
2
3

5
6

7
8
9

11
12
13
14
15
16
17
18

20
21
22
23
24

26
27-30
31
BSZ (1) : B
(Reserved for
future use)

(when set)

Number of bits per byte in the file data.
The default value is 8.
Zero is invalid
value.

DEV(EX-6) : BM
(Reserved for
future use)

= For attributes sent to the

This
field
characteristics
file resides.

accessing node.
contains
the
generic
of the device on which a

Bit

Meaning (When Set)

FB$REC
FB$CCL
FB$TRM
FB$MDI
FB$SDI
FB$SQD

record oriented.
carriage control device.
2
terminal.
3
directory structured.
4
single directory only.
5
sequential - block
oriented (e.g., magnetic
tape) •
6
Reserved:
7
- extension
(0
if
subsequent bits are not
set).
FB$FOD
8
a file-oriented
device
(e.g. a disk or magnetic
tape) •
FB$SHR
9
device can be shared.
FB$SPL
10
device is being spooled.
11
FB$MNT
device
is
currently
mounted.
FB$DMT
12
device is
marked
for
dismount.
device is allocated.
13
FB$ALL
14
FB$IDV
device is
capable
of
providing input.
extens ion
(0
if
15
subsequent bits are not
set).
16
FB$ODV
device is
capable
of
providing output.
device
is
software
17
FB$SWL
write-locked.
device is available for
18
FB$AVL
use.
device has error logging
19
FB$ELG
enabled.
device is a mailbox.
20
FB$MBX
device is realtime
in
21
FB$RTM
nature, not suitable for
RMS use.
a random access device.
22
FB$RAD
extension
(0
if
23
subsequent bits are not
set).
- device has read checking
24
enabled.
- device has write checking
25
enabled.
- device is foreign, (i.e.,
26
not Files-II).
- network device.
27
- generic device.
28
- Reserved (0).
29-30
- Extension (0).
31
1

SDC(EX-6) : BM
(Reserved for
future use)

Spooling device characteristics.
SDC uses
the same bit definitions as in the DEV
field.

NOK (1) : B
(Reserved for
future use)

Number of keys defined in file.

NOA (1) : B
(Reserved for
future use)

Number of areas defined in file.

NOR (1) : B
(Reserved for
future use)

= Number of record descriptors in file.

CDT (18) : A
(Reserved for
future use)

Date and time file created in GMT.

RDT (18) : A
(Reserved for
future use)

Date and time file last updated in GMT.

EDT (18) : A
(Reserved for
future use)

= Date and time file may be deleted in GMT.

The preceding three fields should be in the
following format:
dd-mon-yybhh:mm:ss
where:
dd is the day
mon is a 3-letter abbreviation for the
month
yy is the year
b is blank (space)
hh is the hour
mm is the minutes
ss is the seconds

OWNER(I-40) : A
(Reserved for
future use)

= The name or user

code (e.g., a DIC such as
240,220) of the file owner. This field is
used only when
returning
the
file's
attributes. When creating a file, the file
owner information is taken from the user
identification information which comes with
the connect.

PROTSYS(EX-3)
(Reserved for
future use)

= File protection for system access rights.

Bit

Meaning (When Set)

XB$RDV ; deny read access.
XB$WRV : deny write access.
XB$EXE , deny execute access.
XB$OLE : deny delete access.
deny append access.
deny list access.
deny update access.
extension (0 if bits 8 and 9 are
not used).
deny
change
access
protection
attribute.
deny extend access.

1
2
3
4
5
6

7
8
9

3.5

PROTOWN(EX-3)
(Reserved for
future use)

= File
protection for file
rights. Refer to the bit
PROTSYS above.

owner access
map used for

PROTGRP (EX-3)
(Reserved for
future use)

= File protection for group access rights.
Refer to the bit map used for PROTSYS
above.

PROTWLO (EX-3)
(Reserved for
future use)

File protection for general (world) access.
Refer to the bit map used for PROTSYS
above.

Access Message

The access message specifies the file name and type of access
requested.
This message is followed by a Control Message if data
transfer over the link is requested. The optional FILESPEC in the
message definition below is used only with file rename. The format
for the access message is:

I ACCESS IACCFUNCIACCOPTI FILESPEC I (FILESPEC) I FAC ISHR I
NOTE
Symbolic names where supplied, refer to
the corresponding RMS names. They are
included here for ease of reference
only - they have no meaning for OAP.
where:
ACCESS

The OPERATOR field with TYPE=3.

ACCFUNC(l)

B = The request code specifying the operation to
performed is as follows:
I 2 3 4 S 6 7 8 -

$OPEN;
Open existing file.
$CREATE; Open new file.
Rename a file (Reserved).
$ERASE; Delete a file.
Reserved.
Directory List (Reserved).
Submit as a command (batch) file.
Execute command (batch) file.

In the case of ACCESS code 3 above, two file
specifications are present.
The first is the
old file specification and the second is the new
file specification.
If $CREATE is specified, but a file of that name
already exists, the rules of the remote node for
file creation will be followed.
For example,
the file system may create a new file whose
version number is one greater than the current
highest version number.
NOTE
The Data Access Protocol (DAP) is not concerned
with functions beyond remote data access. DAP
should not be extended to attempt to cover RJE,
Spooling, etc., which, while they involve file
transfer, are also concerned
with
command
processing, parameter passing, job queueing,
etc. The two command file submission commands
are here for historical reasons.
They have
already been implemented in the first release of
DAP-based
software.
However,
their
functionality will not be extended.

ACCOPT (EX-S)

BM = The access options are as follows:
Bit

FILESPEC
(VAR-128 )

FAC(EX-3}

Meaning (When Set)

- I/O errors.

- If set (1), a status message will be
returned following each record sent
to the accessed process in the record
access mode.

- If set (1), return a

3-6

- Reserved.

- Extension

A record may be skipped
or
repeated as specified by the
Continue Message. I/O errors are not
fatal.

status message
with each record retrieved from an
accessed system. The status message
should precede the data message so
that it is always possible to block
the two into one NSP message. When a
user requires a record file address
to be returned, this option is used.

(0).

= The file specification in the format required

by the remote node.
This ASCII field is
treated as a quoted string by DAP software.
It is delivered, as is, to the file system at
the remote node.
= The file access operations a user requires:

Bit

Meaning (When Set)

FB$PUTj Put access.
FB$GETj Get access (default).
FB$DELj Delete access.
FB$UPDj Update access.
FB$TRNj Truncate access.
FB$BIOj Block I/O access (see Note).
Reserved.
Extension (0).

I
2
3
4
5
6
7

NOTE
FB$REA
FB$BIO!FB$GET; Block I/O Read access.
FB$WRT = FB$BIO!FB$PUTj Block I/O
Write
access.

SHR(EX-3)

= Operations shared with other users:
Bit

Meaning (When Set)

FB$PUT; Put access.
FB$GET; Get access (default).
FB$DELi Delete access.
FB$UPDi Update access.
FB$TRNi Truncate access.
FB$BIOi Block I/O access.
FB$NILi No access by other users.
Extension (0).

I
2
3
4
5
6
7

3.6

Control Message

The control message is used to send control type information to a file
system. The control message format is as follows:

where:
CONTROL
CTLFUNC(I)

The OPERATOR field with TYPE=4.
B

Specific control information:
Value

Meaning

I - $GET or $READi get record.
If random
access to a relative file is made, the
key field contains the record number.
If a random access to an indexed file is
made, KEY
contains
the
key.
If
sequential access is employed, get the
next record.
2 - $CONNECTi
initiate data stream.
If
multiple data streams are used, they are
multiplexed on the STREAMID number. The
STREAMID number in the CONTROL message
is used to initiate a data stream.
If
the
STREAMID
number is omitted, a
default of zero is assumed.
3 - $UPDATEi
update
current
record.
Indicates to the accessed system the
intent of the accessing system to update
the currently positioned record with the
next data transmission.
4 - $PUT or $WRITEi
indicates
to
the
accessed system, that the information to
follow should be written into the file.

Value

Meaning

5 - $DELETEi

delete current record.

6 - $REWINDi
rewind
future use.

file.

Reserved

for

7 - $TRUNCATEi
truncate
file.
Writes
End-of-file at current position. Used
with sequential files only.
Reserved
for future use.
8 - Reserved for future use.
9 - $RELEASEi unlock record specified by
Record
File
Address in KEY field.
Reserved for future use.
10 - $FREEi unlock all locked records for
this data stream. Reserved for future
use.
11 - $SPACEi forward or backward space the
file by the number of blocks specified
in KEY below. Reserved for future use.
NOTE
KEY contains a two's complement number
which is positive for forward spacing
and negative for backward.
12 - $FLUSHi
buffers
stream.

write out all modified I/O
and attributes for this data
Reserved for future use.

13 - $NXTVOLi
perform
end-of-volume
and
start-of-next-volume
processing.
Reserved for future use.
14 - $FIND; find record. Same as 1, but the
data is not transferred. Reserved for
future use.
15 - $EXTENDi extend this file by the amount
specified in the following allocation
attributes extension message.
Reserved
for future use.
file's
16 - $DISPLAYi
retrieve
this
attributes
as defined by the field
DISPLAY. Reserved for future use.

CTLMENU(EX-4) :BM

= The

following bits
when
optional fields are present:
Bit

Field

RAC
KEY
KRF (Reserved)
ROP
HSH (Reserved)
DISPLAY (Reserved)
Reserved (0)
Extension (0)

1
2
3
4
5
6
7
RAC (1)

set,

indicate

= Sets the access mode:

Value

Meaning

o - RB$SEQ; sequential record access.
1 - RB$KEY;
keyed access.
2 - RB$RFA; access by Record File Address
(an RMS specific access mode).
3 - sequential file access (the remainder of
the file is transferred sequentially
from the current file position).
4 - block mode;
access by Virtual Block
Number.
For retrieval, each block must
be requested by a Control message as in
the record access mode.
5 - block mode file transfer.
Blocks are
transferred sequentially to end-of-file
without need for a Control
message
preceding each block transferred. An
explicit Control GET or PUT is required
to start data moving.
KEY(I-255)

File or Mode
Relative Files
Indexed Files
Direct Files
Record File Address
Access Mode
Block Mode Access

KRF (1) : B
(Reserved for
future use)

Record Number
Record Key
Record Key
Record File Address
Virtual Block Number
(binary, range 1 to n)

= Key

of reference.
If this field is not
present, the key of reference is not changed.
Default is primary if never set.

o - primary key
1 - 255-secondary key indicator

ROP (EX-6)

= Optional record processing features. If this
field is not present, the options in force
for the last access are retained.
Bit

Meaning (When Set)

RB$EOF; position to EOF.
Reserved (0).
RB$HSH;
use hash code
in
HSH
(Reserved) •
RB$LOAi
follow
fill
quantities
(Reserved) •
RB$ULKi
manual
locking/unlocking
(Reserved) •
Reserved (0).
extension (0
if
following
not
needed).
RB$RAH: read ahead (Reserved).
RB$WBHi write behind (Reserved).
RB$KGEi key is >=(Reserved).
RB$KGTi key is > (Reserved).

1-2
3
4
5
6
7
8
9
10
11
HSH (1-5) : B
(Reserved for
future use)

= Hash code if keyed access on direct file
employed and the user is doing hashing.

OISPLAY(EX-4)
(Reserved for
future use)

BM= Attributes messages which are to be returned
in response to a request to retrieve the
file's attributes are:
Bit

Meaning (When Set)

main attributes message.
key definition attributes.
area definition attributes.
access control list.
file header characteristics message.

1
2
3
4

3.7

Continue Transfer Message

The continue transfer message is used when an error is detected in the
I/O transfer and the user process wishes to continue OAP transfer.
The normal use of this message would be to receive an error message,
take appropriate- action, and then send a continue transfer to allow
the OAP link to resume operation. The format of the continue transfer
message is:
CONTRAN

CONFUNC

where:
CONTRAN
CONFUNC(l)

= The OPERATOR field with TYPE=5.
B = This field is used
action to be taken:

specify

the

recovery

Value

Meaning

I - Try again.
2 - Skip this record and continue.
3 - Abort transfer (i.e., discard all records
in the pipeline until an access complete
message is found indicating the pipeline is
clear).

3.8

Acknowledge Message

The acknowledge message is used to acknowledge
control connects.
Its format is as follows:

access

commands

and

I ACKNOWLEDGE I
where ACKNOWLEDGE:

3.9

The OPERATOR field with TYPE=6.

Access Complete Message

The Access Complete Message is used either to terminate access or to
acknowledge a request to terminate access.
The Access Complete
Message format is as follows:

I ACCOMP I CMPFUNC

FOP

where:
ACCOMP
CMPFUNC(I)

The OPERATOR field with TYPE=7.
B

The access completion functions are:
Meaning

Value

I - command. Terminate access.
Close a file
that is currently open. When multiple data
streams are in use, they are all closed-out
($CLOSE) .
2 - response. Sent by the accessed process in
response to an Access Complete Command or a
purge from the accessing process.
3 - purge. A file is to be purged.
That
closed and deleted ($CLOSE + $ERASE).

is,

4 - end-of-stream. Terminate the data stream
associated with this STREAMID number but do
not close the file ($DISCONNECT).
NOTE
The Access Complete (EOS) does not
require a response nor is the file
closed.
However, the
accessed
process
should be in a state
wherein it can accept
another
Control
(Connect) to open another
stream.

FOP (EX-6)

3.10

BM = The file access options a user requires.
to Section 3.4 for option values.

Refer

Data Message

The Data message is used to transfer the file data over a DAP link.
When data messages are longer than the maximum NSP message size, the
message should be sent using NSP segmentation.
The Data message
format is as follows:

I DATA I RECNUM I FILEDATA
where:
The OPERATOR field with TYPE=8

DATA :
RECNUM (I -8)

FILEDATA

3.11

= This field is used to send the record number
when accessing relative files (or in some
cases sequential files in a relative manner).
For random store, this field will contain the
record number (for relative files) or hash
code (if the user is generating his own hash
codes with direct files). When RECNUM is not
used, the byte count is zero. When in the
block mode, this field will contain the VBN
instead of the record number.
The file data being transferred. This field
is totally transparent and uses all 8-bits of
each byte.

Status Message

The status message is used to return information on the status of DAP
messages or data transfers. It is sent synchronously in response to
another message or an error during data transfer. The format is:
STATUS i STSCODE I RFA I RECNUM I STY I
where:
STATUS

The OPERATOR field with TYPE=9

STSCODE

A 2-byte status field
as:

(16

15
12 11
IMACCODE

0
MICCODE

bits)

subdivided

where:
MACCODE(4B):B = The macro or functional group
reason for the error. Values
for this field are specified
in Table 3-1.
MICCODE(12B):B= The specific reason for the
error
(by
MACCODE type).
Values for this field are
specified in Tables 3-2, 3-3
and 3-4.
27

RFA(I-8)

RECNUM(I-8)

STV (1-8)

Used to return the record file address of the
record to which this status message applies.
If the ACCESS message field ACCOPT indicates
a return of status after each record is
stored, then this field contains the record
file address of the record in the destination
file.

Used to return the record number for relative
files when a status message is returned after
each record is transferred (as specified in
the ACCOPT field of the ACCESS message).
Null for non-relative files.

= Secondary status.

Used to return secondary
status information where required (e.g., RMS
uses it for device error codes).

Table 3-1.
Value
(Octal)

MACCOOE Field Values
Meaning

Name

Pending

Operation in progress.

Successful

Returns
success.

Unsupported

This implementation of OAP does not
support specified request. For example,
this is used
when
an
unsupported
bit/field
or
a
field/value
is
encountered
which
a
particular
implementation does not support.

information

indicates

that

Reserved.

File Open

Errors that occur before
successfully opened.

Transfer

Errors that occur after opening
and before closing that file.

file

Reserved.

6
7

Access
Termination

Errors
associated
access to a file.

with

terminating
Format

Format

Error in parsing a message.
not correct.

Invalid

Field of message is invalid (e.g., bits
that are meant to be mutually exclusive
are set, an undefined bit is set, a
field value is out of range or an
illegal string is in a field).

Sync

OAP
message
synchronization.

13-17

Reserved.

received

out

Table 3-2. MICCODE Field Values for Use
with MACCODE Values of 2, 10, and 11 Octal
Type of Error

I
I Code

Reason

I(Octal)

I MICCODE Format:

Miscellaneous
Configuration
Message
errors by field

NOTE

I
I

Bits 0-5 spec i fy the DAP
message field number. Bi ts 6-11 specify
I the DAP message type number.

, 00 00
I 00 10

I DAP

(11

I :: 10
I 01 11
I 01 12
I

I 01 20

I Unspecified DAP message error.

message type field (TYPE) error.

I Unknown field.
I DAP message flags field (FLAGS).
I Data
stream
identification
field
I (STREAMID).
I Length field (LENGTH).
I
, Buffer size field (BUFSIZ).
I Operating system type field (OSTYPE).
I File system type field (FILESYS).
I DAP vers~on number f~eld (VERNUM).
I ECO verSlon number fleld (ECONUM).
I USER protocol version number field
! (USRNUM).
I DEC software release number
field
I (SOFTVER).
i User software release number field
I

IH H
I 01 24
' 01 25

I 01 26
I

i
Attributes
Message
errors by field

01 27

I (USRSOFT).

01 30

System capabilities field (SYSCAP).

02 00

Unknown field.

02 10
02 11

DAP message flags field (FLAGS).
Data
stream
identification
(STREAMID).
Length field (LENGTH).

02 12
02 20
02 21
02 22
02 23
02 24
02 25
02 26

02 27
02 30
02 31
02 32
02 33
02 34
02 35

02 36
02 37

field

I
I Attr ibutes menu field (ATTMENU).
I Data type field (DATATYPE).

File organization field (ORG).
Record format field (RFM).
Record attr ibutes field (RAT).
Block size field (BLS).
Maximum record size field (MRS).
" Allocation quantity field (ALQ).
Bucket size field (BKS).
Fixed control area size field (FSZ).
Maximum record number field (MRN).
Run-time system field (RUNSYS).
Default extension quantity field (DEQ).
File options field (FOP).
Byte size field (BSZ)i Reserved.
Device
characteristics
field
(DEV); Reserved.
II

Table 3-2. MICCODE Field Values for Use
with MACCODE Values of 2, 10, and 11 Octal (Cont.)
Type of Error

Reason

Code
(Octal)

I
I

02 40
02 41
02 42
02 43
02 44
02 45
02 46
02 47
02 50
02 51
02 52
02 53
03 00
Access
Message
I
errors by field I 03 10

Spooling device
characteristics
(SDC) ; Reserved.
Number
of
keys
in
file
(NOK) ; Reserved.
Number
areas
of
file
in
(NOA) i Reserved.
Number of record descriptors in file
(NOR) i Reserved.
time
File creation
date
and
(CDT) ; Reserved.
date
time
File reV1Slon
and
(RDT) ; Reserved.
File expiration date and
time
(EDT) ; Reserved.
File
identification
owner
(OWNER) i Reserved.
System access
file
protection
(PROTSYS) ; Reserved.
Owner
access
file
protection
(PROTOWN) ; Reserved.
Group
access
file
protection
(PROTGRP) ; Reserved.
World
protection
access
file
(PROTWLD) ; Reserved.

03
03
03
03
03

Control
Message
errors by field

20
21
22
23
24

DAP message flags field (FLAGS) •
identification

04 10
04 11

DAP message flags field (FLAGS) •
Data
stream
identification
(STREAMID) •
Length field (LENGTH) •

20
21
22
23
24
25

field
field
field
field
field
field
field
field
field

field

Access function field (ACCFUNC) •
Access options field (ACCOPT) •
File specification field (FILESPEC) •
File access field (FAC) •
File sharing field (SHR) •
Unknown field.

04
04
04
04
04
04

field

Length field (LENGTH) •

04 00

04 12

field

Unknown field.

stream
I 03 11 I Data
(STREAMID) •
I
I
03 12

field

Control function field (CTLFUNC) .
Control menu field (CTLMENU) •
Record access field (RAC) •
Key field (KEY) •
Key of reference field (KRF) ; Reserved.
Record options field (ROP) •

Table 3-2. MICCODE Field Values for Use
with MACCODE Values of 2, 10, and 11 Octal (Cont.)
Type of Error

I coae
~

Reason

I (Octal) I

I 04 26 I Hash code field (HSH)1 Reserved for future
I
I use.
II 04 27 I Display
attributes
request
field
(DISPLAY) 1 Reserved.

Continue
Message
errors by field

I 05 00
II

05 10

DAP message flags field (FLAGS).
Data
stream
identification
(STREAMID) "
Length field (LENGTH).

field

05 20

Continue
(CONFUNC) •

function

field

06 00

Unknown field.

06 10
06 11

DAP message flags field (FLAGS).
Data
stream
identification
(STREAMID) •
Length field (LENGTH).

field

I 05 11
I 05 12

Acknowledge
Message
errors by field

I
Access Complete
Message
errors by field

Data Message
errors by field

Status Message
errors by field

Unknown field.

06 12

transfer

I 07 00

Unknown field.

I 07
07 10
' 11
07 12

DAP message flags field (FLAGS).
Data
stream
identification
(STREAMID) •
Length field (LENGTH).

07 20
07 21

Access complete function field (CMPFUNC).
File options field (FOP).

10 00

Unknown field.

10 10
10 11
10 12

DAP message flags field (FLAGS).
Data
stream
identification
(STREAMID) .
Length field (LENGTH).

10 20
10 21

Record number field (RECNUM).
File data field (FILEDATA).

11 00

Unknown field.

11 10
11 11

DAP message flags field (FLAGS).
Data
stream
identification
(STREAMID) .
Length field (LENGTH).

11 12
11
11
11
11
11

20
21
22
23
24

Macro status code field (MACCODE).
Micro status code field (MICCODE).
Record file address field (RFA).
Record number field (RECNUM).
Secondary status field (STV).

field

Table 3-3. MICCODE Field Values for Use
with MACCODE Values of 0, 1, 4, 5, and 7 Octal
Value
(Octal)

Error/Reason
NOTE
MICCODE Format: Bits 0-11 contain the error code
number.
Symbolic status codes, where supplied,
refer to the corresponding RMS status codes.
They
are
included
here
for
ease
of
reference
only -- they have no meaning for DAP.

o
1
2

3
4

5
6
7

10
11
12
13
14
15
16
17
20

21
22

23
24
25

26
27

ER$ABO:
ER$ACC:
ER$ACT:
ER$AID;
ER$ALN:
ER$ALQ:
ER$ANI:
ER$AOP:
ER$AST:
ER$ATRi
ER$ATW:
ER$BKS;
ER$BKZ;
ER$BLN:
ER$BOF;
ER$BPA;
ER$BPSi
ER$BUG;
ER$CCRi
ER$CHGi
ER$CHKi
ER$CLS:
ER$COD;
ER$CRE:
ER$CURi

Unspecified error.
operation aborted.
FIl-ACP could not access file.
"FILE" activity precludes operation.
bad area 10.
alignment options error.
allocation quantity too large.
not ANSI "0" format.
allocation options error.
invalid (i.e., synch) operation at AST level.
attribute read error.
attribute write error.
bucket size too large.
bucket size too large.
"BLN" length error.
beginning of file detected.
private pool address not multiple of "4".
private pool size not multiple of "4".
internal RMS error condition detected.
cannot connect RAB.
$UPDATE changed a key without having attribute of
XB$CHG set.
bucket format check-byte failure.
RSTS/E close function failed.
invalid or unsupported "COD" field.
FIl-ACP could not create file (STV=sys err code).
no current record
(operation not preceded
by
GET/FIND).
Fll-ACP deaccess error during "CLOSE".
data "AREA" number invalid.
RFA-Accessed record was deleted.
bad device, or inappropriate device type.
error in directory name.
dynamic memory exhausted.
directory not found.
device not ready.
device has positioning error.
"DTP" field invalid.
duplicate key detected, XB$DUP not set.
RSX-FllACP enter function failed.
operation not selected in "ORG$" macro.
end-of-file.
expanded string area too short.
file expiration date not yet reached.
file extend failure.
not a valid FAB ("BID" NOT = FB$BID).
4

32
33
34
35
36
37
40

41
42

43
44
45
46

47
50

51
52

ER$DACi
ER$DAN:
ER$DEL;
ER$DEV;
ER$DIR;
ER$DMEi
ER$DNF:
ER$DNR:
ER$DPE;
ER$DTPi
ER$DUP;
ER$ENTi
ER$ENV;
ER$EOF:
ER$ESSi
ER$EXP;
ER$EXTi
ER$FAB;

Table 3-3. -MICCODE Field Values for Use with MACCODE
Values of 0, 1, 4, 5, and 7 Octal (Cont.)
Value
(Octal)

Error/Reason

ER$FACi illegal FAC for REC-OP,O, or FB$PUT not set for
"CREATE" •
ER$FEX: file already exists.
ER$FID: invalid file I.D.
ER$FLG: invalid flag-bits combination.
ER$FLK: file is locked by other user.
ER$FND: RSX-FIIACP "FIND" function failed.
ER$FNF: file not found.
ER$FNM: error in file name.
ER$FOP: invalid file options.
ER$FUL: DEVICE/FILE full.
ER$IAN: index "AREA" number invalid.
ER$IFli invalid IFI value or unopened file.
ER$IMXi maximum NUM(254) areas/key XABS exceeded.
ER$INli $INIT macro never issued.
ER$IOP: operation illegal or invalid for file organization.
ER$IRC: illegal record encountered (with sequential files
only) .
ER$ISI: invalid lSI value, on unconnected RAB.
ER$KBF: bad KEY buffer address (KBF=O).
ER$KEY: invalid KEY field (KEY=O/neg).
ER$KRF; invalid key-of-reference ($GET/$FIND).
ER$KSZ: KEY size too large.
ER$LAN: lowest-level-index "AREA" number invalid.
ER$LBL: not ANSI labeled tape.
ER$LBY; logical channel busy.
ER$LCH: logical channel number too large.
ER$LEX: logical extend error, prior extend still valid.
ER$LOC: "LOC" field invalid.
ER$MAP: buffer mapping error.
ER$MKD; FII-ACP CQuld not mark file for deletion.
ER$MRN: MRN value=neg or relative key>MRN.
ER$MRS; MRS value=O for fixed length records. Also 0 for
relative files.
ER$NAM: "NAM" block address invalid
(NAM=O,
or
not
accessible) •
ER$NEF: not positioned to EOF (sequential files only).
ER$NID; cannot allocate internal index descriptor.
ER$NPK: indexed file: no primary key defined.
ER$OPN: RSTS/E open function failed.
ER$ORD: XAB'S not in correct order.
ER$ORG: invalid file organization value.
ER$PLG: error in file's prologue (reconstruct file).
ER$POS: "POS" field invalid (POS>MRS,STV=XAB indicator).
ER$PRM: bad file date field retrieved.
ER$PRV: privilege violation (OS denies access).
ER$RAB: not a valid RAB ("BID" NOT=RB$BID).
ER$RAC: illegal RAC value.
ER$RAT: illegal record attributes.
not
ER$RBF: invalid record buffer address ("ODD", or
word-aligned if BLK-IO).
ER$RER: file read error.
ER$REX: record already exists.
ER$RFA: bad RFA value (RFA=O).
ER$RFlv1: invalid record format.

55
56
57
60
61
62
63
64

65
66
67
70
71
72
73
74
75
76
77
100
101
102
103
104
105
106
107
110
III
112
113
114
115
116
117
120
121

122
123
124
125
126
127
130
131
132
133
134
135

Table 3-3.

Error/Reason

Value
(Octal)
136
137
140
141
142
143
144
145
146
147
150
151
152
153
154
155
156
157
160
161
162
163
164
165
166
167
170
171
172
173
174
175
176
177
200
201
202
203
204
205
206
207
210
211
212
213

I
I

214
215
216
217
220

MICCODE Field Values for Use with MACCODE
Values of 0, 1, 4, 5, and 7 Octal

target bucket locked by another stream.
RSX-Fll ACP remove function failed.
record not found.
record not locked.
invalid record options.
error while reading prologue.
invalid RRV record encountered.
RAB stream currently active.
bad record size (RSZ)MRS, or NOT=MRS if fixed
length records).
ER$RTBi record too big for user's buffer.
ER$SEQi primary key out of sequence (RAC=RB$SEQ for $put).
ER$SHRi "SHR" field invalid for
file
(cannot
share
sequential files).
ER$SIZi "SIZ field invalid.
ER$STKj stack too big for save area.
ER$SYSi system directive error.
ER$TREi index tree error.
ER$TYPi error in file type extension on FNS too big.
ER$UBFi invalid user buffer addr (0, odd, or if BLK-IO not
word aligned).
ER$USZ; invalid user buffer size (USZ=O).
ER$VERi error in version number.
ER$VOL; invalid volume number.
ER$WERi file write error (STV=sys err code).
ER$WLKi device is write locked.
ER$WPL; error while writing prologue.
ER$XABi not a valid XAB (@XAB=ODD,STV=XAB indicator).
BUGDDI; default directory invalid.
CAA
i cannot access argument list.
CCF
i cannot close file.
CDA
; cannot deliver AST.
CHN
; channel assignment failure (STV=sys err code).
CNTRLOi terminal output ignored due to (CNTRL) o.
CNTRLY; terminal input aborted due to (CNTRL) Y.
DNA
; default filename string address error.
DVI
; invalid device 1.0. field.
ESA
; expanded string address error.
FNA
; filename string address error.
FSZ
i FSZ field invalid.
IAL
i invalid argument list.
KFF
; known file found.
LNE
; logical name error.
NOD
; node name error.
NORMAL: operation successful.
OK DUP; record inserted had duplicate key.
OK-lOX; index update error occurred-record inserted.
OK-RLK: record locked but read anyway.
not
be
OK=::RRV: record inserted in primary o.k.: may
accessible by secondary keys or RFA.
CREATE; file was created, but not opened.
PBF
; bad prompt buffer address.
PNDING; async. operation pending completion.
QUO
: quoted string error.
RHB
; record header buffer invalid.

ER$RLKi
ER$RMVi
ER$RNFi
ER$RNL;
ER$ROP;
ER$RPL;
ER$RRV;
ER$RSA;
ER$RSZ;

Table 3-3. MICCODE Field Values for Use with MACCODE
Values of 0, 1, 4, 5, and 7 Octal (Cont.)
Value
(Octal)

Error/Reason

221
222
223
224
225
226

RLF
RSS
RST
SQO
SUC

227
230

SYN
TMO
;
ER$BLK;
ER$BSZi
ER$CDR;
ER$CGJ;
ER$COF;
ER$JFN;
ER$PEF;

231
232
233
234
235
236
237
240
241
242
243
244
245
246
247
250

SPRSED~

ER$TRU~
ER$UDF~

ER$XCLi

251
252
253
254
255
256
257
260
261
262
263
264
265
266
267
270
271
272
273
274
275
276

277
300
301
302
303
304
305
306
307

NMF

invalid related file.
invalid resultant string size.
invalid resultant string address.
operation not sequential.
operation successful.
created file superseded existing version.
filename syntax error.
time-out period expired.
FB$BLK record attribute not supported.
bad byte size.
cannot disconnect RAB.
cannot get JFN for file.
cannot open file.
bad JFN value.
cannot position to end-of-file.
cannot truncate file.
file is currently in an undefined state; access
denied.
file must be opened for exclusive access.
directory full.
handler not in system.
fatal hardware error.
attempt to write beyond EOF.
hardware option not present.
device not attached.
device already attached.
device not attachable.
sharable resource in use.
illegal overlay request.
block check or CRC error.
caller's nodes exhausted.
index file full.
file header full.
accessed for write.
file header checksum failure.
attribute control list error.
file already accessed on LUN.
bad tape format.
illegal operation on file descriptor block.
rename; 2 different devices.
renamei new filename already in use.
cannot rename old file system.
file already open.
parity error on device.
end of volume detected.
data over-run.
bad block on device.
end of tape detected.
no buffer space for file.
no blks.
file exceeds allocated space
specified task not installed.
unlock error.
no file accessed on LUN.
send/receive failure.
cannot submit command file.
no more files.

Table 3-4. MICCODE Field Values
(with MACCODE Value of 12 Octal)
Error/Reason

Value
(Octal)

NOTE
MICCODE Format:
type number.

o
1
2
3
4
5
6
7
10
11

Bits 0-11 contain the message

Unknown Message Type
Configuration Message
Attributes Message
Access Message
Control Message
Continue Transfer Message
Acknowledge Message
Access Complete Message
Data Message
Status Message

4.0

FILE ORGANIZATION

4.1

Types of Files

The following types of files are addressed by this

4.2

~pecification:

Sequential - Each record's position depends on the position
of the previous record. Records may not be processed in any
other order.

Relative - Each record in the file has a unique identifying
number, its record number. Records may be accessed randomly
by specifying their record number in a Control message.

Direct/Indexed - These files have records organized according
to some classification method i usually an access key. Within
a particular key, the records are assumed to be sequential.

Record Formats and Attributes

There are two ways in which ASCII records are stored in
systems:

DIGITAL

file

Byte Count. A byte count associated with the record
file indicates how long the record is and is
determine record boundaries.

Stream. The ASCII record is stored exactly as is.
The
record is assumed to be terminated with a vertical form
effector (VFE), which is one of line feed (LF), vertical tab
(VT), or form feed (FF).

Files using ASCII stream usually do not have record attributes
with the file.
DAP supports five ASCII record formats:
1.

Fixed length records,

Variable length records,

Variable with fixed control,

Line sequential ASCII records, and

ASCII stream

In addition, DAP supports the following attributes:
1.

FORTRAN carriage control,

COBOL carriage control,

Implied LF/CR envelope for printing,

Embedded carriage control, or

None of the above.

in the
used to

stored

4.2.1 Conversions - Not all systems support all the above record
formats and attributes. Transferring ASCII data between systems with
different record formats and attributes sometimes require conversions.
If a conversion is n~cessary in transferring ASCII data between
systems, the converSlon must always be done by the accessing (user)
process, not by the accessed (essentially passive server) process. In
other words, all intelligence resides with the user. The remote
server process does only as it is told and exhibits no intelligence.
Thus the accessed process will return an error when creating a file
whose type, as specified in the ATTRIBUTES and ACCESS messages, is not
supported by the remote system.
Also, when accessing an existing
file, data is transferred according to the attributes of the existing
file at the remote node.
That is, when retrieving data from an
existing file, the data is sent with the attributes of the remote
file. When updating or appending data to an existing file, the data
sent by the user process must have the attributes of the existing
file. No conversions will be performed by the accessed process.
Where conversions are necessary, they can be reduced to those shown in
Table 4-1.
For purposes of this table, variable length records,
variable length records with fixed control, and line sequential ASCII
records can all be considered as variable length records.
Table 4-1.

~
From

Conversion Table

Implied
LF/CR

No Attributes
(Attr ibutes) Stream

Implied LF/CR

No Attributes

Stream

FORTRAN/COBOL
Carriage Control
where:
N ::

no conversion necessary.

C :: conversion.
X ::

no conversion allowed (error) •

Table 4-1 lists six situations in which conversions are allowed.
are:
is

placed

around

each

record

They

A LF/CR envelope
accessing process.

A CR/LF is appended to each record by the accessing process
if the final character of the record is not already a VFE.

Same as 3.

The receiving node collects and concatenates successive
records until a VFE is encountered.
If the VFE is a LF
preceded by a CR, the CR/LF is stripped and the record
stored. Otherwise the record is stored as is.

11.

FORTRAN or COBOL carriage control characters cause an FF or a
CR followed by the appropriate numbers of LFs to be placed
before or after the record depending on the rules for
interpreting the control character. The control character is
discarded.

12.

Same as 11.

4.2.2 Conversion Rules and Restrictions - The following
should be observed when conversions are performed:
1.

Any conversion of variable to fixed-length
should be done by the accessing process.

No attempt should be made to convert any
FORTRAN or COBOL carriage control form.

No attempt should be made to convert image
between fixed and variable length records.

file

three
ASCII

rules
records

format
files

the

into
except

These techniques have the following effects and restrictions:
1.

A file transferred from a system having the implied LF/CR
envelope for records when transferred to a stream-system will
list without the initial LF.

Records transferred from a byte count system to a stream
system containing embedded vertical form effectors (VFE's)
will be subdivided on retrieval from the stream system by the
VFE's. However, such files will list properly, regardless of
the system listing them.

Any attributes other than ASCII or image data types or fixed/variable
length records are useful only for local file system attribute
storage. No translation or processing is mandatory. Thus, if a file
is stored as EBCDIC, but an ASCII retrieval is done, it is not
required, or even desirable, to translate the data. Some systems may
choose to do so, but it is currently outside the scope of this
document to detail that type of operation.

4.3

Data Formats

4.3.1 Fixed-Length Records - All records are of the fixed length
specified in the MRS field. They are delimited by physical message
blocks (that is, the last byte in a data message is the end of the
record).

4.3.2 Variable-Length
Records - These
records
are
like
the
fixed-length ones except the maximum length is that specified in the
MRS field.

4.3.3 Variable with Fixed-Control Format Records - These records are
normal variable-length ones with an associated fixed-length field used
for control purposes.
In DAP data messages, this fixed-length control
field immediately precedes and is contiguous with the variable part of
the record. The length of the fixed field is found in the FSZ field
in the attributes message.
MRS contains the maximum length of the
variable portion only. FSZ + MRS = total maximum record length.
Regardless of the type of the data in the variable portion of the
record, the data in the fixed portion is always sent as a binary field
contained in an integral number of 8-bit bytes.

4.3.4 LSA Records (Line Sequential ASCII Records) - These records are
variable-length ones that have as their first five characters a
5-digit ASCII line number. This line number is in binary at the ·RMS
interface.
It is sent across the network as three bytes of binary
data preceding the ASCII data.

4.3.5 ASCII Stream - Here a file contains just a stream of ASCII
characters with no real concept of records.
However, Vertical Field
Effectors are used to delimit "records" for purposes of reading and
writing the file.

5.0

OPERATION

The Data Access Protocol (DAP) is a user level protocol that resides
within the Application Layer of the DIGITAL Network Architecture
(DNA). Its purpose is to transfer data to and from I/O devices and
mass storage files independent of the I/O structure of the system
being accessed. This transfer is accomplished by communication with a
DAP process that accepts DAP requests on the network side and
translates them into equivalent requests to the local I/O system.
From the network it appears as if DECnet systems support DAP messages
directly within their file systems.
DAP provides the mechanism for setting up the conversation path for
remote file access, transferring data over the link, and terminating
the logical link.

5.1

Setting up the Link

Processes that implement the DAP protocol operate at the user level
within a OECnet system. They use the Network Service Protocol and the
network facilities for the creation and flow control of the data path
(logical link) between the processes exchanging messages within the
OAP environment. The originating process issues a Connect Initiate
command requesting the creation of a logical link to the OAP process
at the destination node. This request may specify an actual process
name or the generic OAP object type.
All systems must support
connection to the generic OAP object type as a
minimum,
if
device-independent file access is to be performed. The destination
OAP process completes the connection by returning a Connect Confirm
command. Once the link is established, the processes may now exchange
OAP messages over the link.
A separate logical link is used for each remote file access.
This
means a single user can not access more than one file at a time over a
single logical link. It also means several users cannot access the
same file over a single logical link.
During link establishment, the identity of the user is
the Connect Initiate Message.
Following link establishment, the OAP-speaking
configuration messages for four purposes:
1.

To establish the
messages.

maximum

buffer

processes
for

from

exchange

exchanging

NSP

To identify system type to each other;

To enable the other DAP process to know which version of
protocol this process speaks; and

the

To inform the opposite process of the generic capabilities of
the system sending the message.

size

obtained

The system type is used when it is necessary to know the type of both
the operating system and the file system on the other end of the link.
This is helpful in deciding if block mode file transfer can be used
when transferring files between like systems or multiple data streams
can be initiated as is possible between RMS-based systems.
The capabilities field of the configuration message indicates to each
of the DAP processes the generic capabilities of the other DAP process
with which it is communicating. It is used to determine the type of
file support offered by a remote system without resorting to trial and
error techniques. It can be used to help produce more positive,
useful error messages.
The node where the file or device resides is the accessed node while
the node where the user process is located is the accessing node. The
accessing process is the one that initiates the connection. For each
DAP message sent over the link, a transmit request and corresponding
receive request must be issued to NSP. This discussion is concerned
with the DAP messages only and assumes that the necessary receives and
transmits are issued by the processes involved.
After link creation and the exchange of Configuration Messages, the
accessing process sends an attributes message specifying the desired
mode and f0rmat of the data~ This is then followed by an access
message specifying the desired operation. The Attributes and Access
messages may be blocked and sent together in o~e transmission if
buffer space is available (the LENGTH field must be used) and blocking
is supported as indicated by the Configuration message. Data messages
are the only messages whose length can exceed 256 bytes.
Systems not retaining the file attributes use the Attributes Message
to set the attributes for the transfer. When creating a new file, the
Attributes Message sent by the accessing process specifies the
attributes the new file should have.
When storing records with
systems retaining attributes, the accessed system uses the attributes
message sent by the accessing process to indicate the attributes of
the records being sent by the accessing process. For record retrieval
with systems retaining attributes, records are transferred with the
attributes of the attributes message returned by the accessed process.
File systems that store attributes often have no information as to the
type of data stored in the file.
When this is the case, the
user-supplied data type in the attributes message is used to determine
whether any conversion is necessary when transferring records from one
type of system to another.
After the initial set-up messages are sent, the accessing system will
receive a response from the accessed processs.
If the access
specified opens a file, an Attributes Message followed by
an
Acknowledge Message will be sent from the accessed system containing
the actual attributes of the accessed file.
If the operation
specified in the Access Message deletes or renames a file, no
Attributes Message or Acknowledge Message is returned.
The response
is an Access Complete Message.
To minimize the tying up of network resources (e.g., logical links and
buffers), the Configuration, Attributes, and Access messages should be
sent in a "timely" manner. A timer may be set for each message and if
it does not arrive in a reasonable time the link may be disconnected.
After the Acknowledge Message has been received, the file is open and
the accessing process sets the pace for access of the file.
If there are errors in the setup procedure, a status message
returned.

will

NOTE
A receive must always be outstanding in
order
to
accept both expected and
unexpected Status
Messages.
Status
Messages are always sent as ordinary
(not interrupt) DAP messages.
Errors in exchanging configuration messages should be very rare since
the information in configuration messages will generally be "canned"
and of an informative nature. If the accessed system detects an error
in the configuration message it returns a status message and the
accessing system can either retry or disconnect.
If the accessing
system detects an error, it just disconnects.
If, however, a
configuration message appears to be in error because the SYSCAP field
is too long and the DAP version number is greater than that to which
the current software is written, it should be assumed that the SYSCAP
field has been extended in the future version of DAP. This error
should be ignored. This is the only time when an error is ignored.
The assumption is that the more sophisticated DAP process will use
only a subset of the protocol and thus both sets of software will be
able to work together. This standard specifies the DAP for version
4.1.

5.1.1 Errors in the Setup Sequence - Errors in the Configuration
Message, Attributes Message, and Access Message, all return a Status
Message. On receiving an error in response to one of these messages,
there are three possibilities open to the accessing DAP process:
1.

Disconnect the link.

Send the corrected message responsible for the error.
There
is no point in sending the original message unless there is
sufficient doubt that the message was delivered properly or
that the error indicated was of a temporary nature (e.g., an
attempt to open a file already open by another process).

Start a different access. A new access will usually start
with an Attributes Message, but it could start with an Access
Message (where the type of access does not require attributes
such as ERASE) or even a Configuration Message.

If the user process tries to recover by sending a corrected message or
starting a new access, the accessed DAP process should be capable of
accepting any of the three setup messages in response to a Status
Message.
Table 5-1 provides a list of responses to setup message
errors.

Table 5-1.

Responses to Setup Message Errors
Responses
Configuration Attributes Access
Message
Message Message

Error
Configuration Message

Attributes Message

Access Message

where:
0 = invalid response.
1 = valid response.
2 = valid response only for accesses requiring no
attributes message.

5.1.2 Setup Sequence - If a timer is being used between setup
messages, this same timer should be set by the accessed process after
an error during setup.
If the timer expires, a disconnect should be
initiated.
Accessed Process

Accessing Process
1.

Establish link:
issue connect------)
<------complete connect

Configuration information exchange:
CONFIGURATION------)
Message
<------CONFIGURATION
Message

Setup for access:
ATTRIBUTES------)
Message
ACCESS
Message

------)
<------ATTRIBUTES
Message
<------ACKNOWLEDGE
Message
NOTE

An Attributes Message is not required when the Access
Message specifies the ERASE, RENAME, or EXECUTE
command file.
For these types of access, neither the
Attributes Message nor the Acknowledge Message is
returned by the accessed process.

Figure 5.1.

Set-up Sequence
44

Error in configuration messages:
(a)

CONFIGURATION------>(received in error)
Message
<------STATUS Message
disconnect

------>
or

(b)

CONFIGURATION------>(received in error)
Message
<------STATUS Message
CONFIGURATION------>
Message
or

(c)

if the error is in the returned message
CONFIGURATION------>
Message

(in error)

<------CONFIGURATION
Message

disconnect

------>

Error in Attributes Message:
(a)

ATTRIBUTES------>(received in error)
Message
<------STATUS Message
disconnect------>
or

(b)

ATTRIBUTES------>(received in error)
Message
<------STATUS Message
ATTRIBUTES------>
Message
or

(c)

ATTRIBUTES------>(received in error)
Message
<------STATUS Message
ACCESS
Message

------>

Figure 5-1 (Cont.).

Set-up Sequence

Error in access message:

(a)

ATTRIBUTES------>
Message
ACCESS
Message

------>(received in error)
<------STATUS Message

disconnect------>
or
(b)

ATTRIBUTES------>
Message
ACCESS
Message

------>(received in error)
<------STATUS Message

ATTRIBUTES------>
Message
or

(c)

ATTRIBUTES------>
Message
ACCESS
Message

------>(received in error)
<------STATUS Message

ACCESS
Message

------>

Figure 5-1 (Cont.).

5.2

Set-up Sequence

Transferring Data over the Link

The message exchange sequence for transferring data over the link
depends on the direction of data flow with respect to the accessing
and accessed systems. Data may be sent to the accessing node as in a
retrieve operation or from it as in a store operation.
Before data transfer can start, however, a data stream must be
initiated by sending a control message after the file is open. With
file systems that support multiple data streams, additional data
streams can be initiated with more control messages. Multiple data
streams are differentiated by using the STREAMID number.
Data
messages for a particular data stream must have the same STREAMID
number as the control message that initiated the data stream.
If the
STREAMID number is omitted, a default of 0 is used.
The sequence for initiating a data stream is as follows:

Accessing Process

Accessed Process

CONTROL (connect)---->
<----ACKNOWLEDGE

If an error occurs, a Status Message will be returned instead of an
ACK.
A new data stream can be initiated any time the file is open by
using the above message sequence.
NOTE
Multiple data streams cannot be used if
file transfer mode is specified in the
RAC field of the control message.
The
file transfer mode implies a single data
stream with only data
(no
control
messages) flowing over the link. By
eliminating control messages, efficiency
is gained.

5.2.1 Sequential File Retrieval - For sequential file retrieval, data
records are sent from the accessed system. Once the initial startup
sequence is completed and the data stream initiated, a single Control
(GET) Message is sent to start data records flowing. Thereafter, the
file records are transmitted without waiting for any further DAP
messages to control sending messagesv All flow control is performed
implicitly by the Network Service Protocol.
To specify sequential file retrieval the accessing process specifies
sequential file access or virtual block number file transfer in the
Control (GET) Message. The accessed process will then send file
records without waiting for any further DAP control messages. In
contrast to sequential file retrieval, if sequential record access is
specified, the accessing process must send a control message for each
record retrieved.
Data messages will continue to arrive until: a) the end-of-file is
reached on the accessed system; b) an error occurs in accessing the
file; or c) the accessing system decides it has completed its access.
In the first case, the last record sent in a data message is followed
by a Status Message with end-of-file detected set. In the second
case, a status message will be sent when an error occurs in accessing
the original file. If the accessing system receives a Status Message
with end-of-file, it sends an Access Complete Command and waits for an
Access Complete Response.
It then either disconnects or initiates
another access by sending a setup sequence. If the accessing system
receives an error, it may either send an Access Complete Command and
wait for an Access Complete Response or try to recover with a continue
transfer.
If the accessing system decides to terminate access prior
to
end-of-file, it sends an access complete command and waits for an
access complete response in return.
In such cases, an accessing
system issuing an access complete command may still receive one or
more records of the file or even an end-of-file indication or an error
indication due to the pipelining delay in the system. It should pass
over these records until an access complete response is received.
It
may then disconnect or access another file.

Accessing Process
1.

Accessed Process

Retrieval until End-of-File

(EOF):

CONTROL (GET)------>
<------[STATUS,] RECORD 1
NOTE
Transfer continues until •
End-of-File or error
[STATUS,] RECORD n
<------STATUS

(End-of-File)

ACCOMP (COMMAND)------>
<------ACCOMP (RESPONSE)
The accessing process
disconnect the link.

may

now

issue

another

access

NOTE
The Status Messages in square brackets
are optional depending on whether they
are asked for in the ACCOPT field of the
Access Message.
If they are required,
they should immediately precede the data
message in a single NSP message. The
optional status message precedes the
data message
(record)
so that it is
always possible to block the two DAP
messages for
transmission as a single
unit even if the data message is longer
than 255 bytes.
2.

Retrieval until error:
(a)

Accessed Process

Accessing Process

<------RECORD n
<------STATUS
When an error is received, the Accessing Process can
link termination.
ACCOMP (COMMAND}------>
<------ACCOMP (RESPONSE)
or
(b)

request the information be sent again
CONTINUE (Try again}------>
<------RECORD n
or

(c)

skip that record and continue
CONTINUE (SKIP)------>
<------RECORD n+l
Figure 5-2.

File Retrieval Sequence
48

request

Retrieval with access termination:
<----RECORD m
ACCOMP (COMMAND)----)
<----ACCOMP (RESPONSE)
The accessed process may set a timer following sending ACCOMP
and if neither a disconnect or another message is received
within the time interval it may disconnect the link.
Figure 5-2 (Cont.).

File Retrieval Sequence

5.2.2 Sequential File Storage/Append - In the store case, data is
sent to the accessed system. Following the initialization of the data
stream the accessing system sends a Control (PUT) Message to tell the
accessed process what to do. The control message is followed by file
records using the data message. These messages will be accepted by
the accessed system and will continue until the accessing system sends
an Access Complete Command. This procedure will cause a corresponding
Access Complete Response to be returned following successful file
closure, or a Status Message to occur if an error is incurred in
closing the file. In either case, the access is concluded and another
access may start or the link may be disconnected.
To specify sequential file storage, the accessing process specifies
sequential file access in the Control Message together with PUT. To
specify sequential file append, the operations are the same except in
the Control Message where "position to EOF" is also specified. As
with sequential file retrieval, sequential file storage implies the
use of only one data stream. If optional status messages are desired,
the ACCOPT field of the access message must be used to request them.
If an error occurs during record transfer, the accessed system will
return a Status Message.
This must always be replied to with a
Continue Message sent as an interrupt message (because of possible
pipelining).
In addition, if it is desired to terminate the access,
an Access Complete Message should be sent.
Accessing Process
1.

Accessed Process

Store with no errors:
CONTROL (PUT)------)
RECORD 1
------)
[<------STATUS]
NOTE
Transfer continues .
until access
complete or error
RECORD n

------)
[<------STATUS]
ACCOMP (COMMAND) ------)
<------ACCOMP (RESPONSE)
Figure 5-3.

Sequential File Storage

NOTE
The Status Messages (in square brackets)
are optional depending on whether they
are asked for in the ACCEPT field of the
Access Message.
They are not used to
indicate an error condition.
An error
will be contained in a Status Message
without brackets (see Step 2).

Error during transfer:
(a)

Purge the new file and terminate
RECORD n

------)
(------STATUS
ACCOMP (PURGE)
------)
CONTINUE (ABORT) ------) (INTERRUPT)
NOTE
The accessed system will discard
until ACCOMP (PURGE) is received.

records

Purge incomplete file (------ACCOMP (RESPONSE)
or
(b)

close the new file and terminate
ACCOMP (COMMAND) ------)
CONTINUE (ABORT) ------) (INTERRUPT)
NOTE
The accessed system discards records until
ACCOMP (COMMAND) is received.
close incomplete file (------ACCOMP (RESPONSE)
or

(c)

retry - the accessed system still has the record which
caused the error in its buffer.
CONTINUE (Try again)------)INTERRUPT
RECORD n+l
------)
or

(d)

skip the record and continue
CONTINUE (SKIP)------)INTERRUPT
RECORD n+l
------)
Figure 5-3 (Cant.).

Sequential File Storage

NOTE
On an error, the accessed process does
not
issue
any more receives after
sending the Status Message and before
receiving the Continue Message, which
tells it what to do. If the accesslng
process responds to the error by sending
an interrupt continue message and the
retry
is
successful,
the accessed
process will post a receive and carryon
with the data transfer.
If the retry fails, another
status
message is sent.
A Continue Message
with skip always posts a receive and
tries to carryon having skipped the

record which caused the original
Continue
messages
must be
interrupt mode as there may be
the pipeline.
3.

error~

sent
data

in
in

If the accessing system wants to stop a sequential file
storage operation before it is complete and purge the
incomplete file on the accessed system, the sequence is as
follows:
Accessing Process
RECORD

Accessed Process

n---------------)

ACCOMP (PURGE)

-------)

purge incomplete file<----ACCOMP (RESPONSE)
on accessed system
To save an incomplete file
operations are as in Step 1.
Figure 5-3 (Cont.).

the

accessed

system,

the

Sequential File Storage

5.2.3 Record Retrieval - Record retrieval is similar to sequential
file retrieval except that a control message (with a record key for
random retrieval) must be sent by the accessing process for each
record accessed.
Record retrieval is specified by the accessing
process setting sequential record access, Keyed access or Record File
Address access in the Control Message. Block mode transfer is similar
to record retrieval and is specified by setting Virtual Block Number
access.
For keyed or Record File Address access, the sequence is as follows:
CONTROL (get record with Key n)----)
<----[STATUS,] RECORD n
CONTROL (get record with Key m)----)
<----[STATUS,] RECORD m

For sequential record access, the state operation is as follows:
CONTROL (get sequential)--------->
<----[STATUS,] RECORD k
CONTROL (get sequential)-------->
<----[STATUS,] RECORD k+l
Once the location of a particular record in a file is found using
random access, the user frequently wants to get subsequent records
sequentially. This can be done by switching the access mode from
keyed or Record File Address to sequential in the Control Message and
issuing a GET.
(With RMS systems, the user is free to switch access
modes according to the RMS rules.)
CONTROL (get record with Key r)---->
<----[STATUS,]RECORD r
CONTROL (get sequential)

-------->
<----[STATUS,]RECORD r+l

Once a particular record in a file is found,
it is possible
transfer the remainder of the file in sequential file access mode.

CONTROL (get record with key t)---->
<----[STATUS,]RECORD t
CONTROL (sequential file access, get)----->
<----[STATUS,]RECORD t+l
<----[STATUS,]RECORD t+2, t+3,
... to end-of-file
Error handling for sequential record retrieval is similar to error
handling for sequential file retrieval. When an EOF is reached while
accessing a file sequentially, the accessed process sends the Status
Message "end-of-file-detected." This prevents automatic file closure
and control is retained by the accessing process.
Error handling for random record retrieval is similar to that for
sequential file retrieval.
However, the continue (skip) recovery
option which is valid for sequential retrieval is not valid for random
retrieval.
When a control request specifies a nonexistent record
while doing random record retrieval, the accessed process will return
an appropriate error message
(e.g., record number out of range or
record not found).

5.2.4 Record Store - This is similar to sequential file store in
messages exchanged.
For relative files,
the data messages must
include the relative record number field specifying the number of the
record (RECNUM). For direct files where the user is supplying his own
hash code (RB$HSH set in the ROP field of a Control Message), RECNUM
contains the hash code.
For indexed files, RECNUM is null. For
sequential files, records are written starting at the current position
within the file.

The access message specifies whether to open an existing file or
create and open a new file. PUT access must have been specified in
the Control Message. For record storage, the accessing process may
specify sequential record access, or keyed access. Optionally, VBN
access may also be used.
The sequence of records to be stored may be preceded by a Control
(PUT) Message if it is necessary to change record options or access
mode from the current value. Optionally, each record to be stored may
be preceded by a Control (PUT) Message. This procedure is inefficient
since it doubles the number of DAP messages transmitted. When storing
a record, if the Data Message is preceded by a Control Message that
contains a record number in the key field and the Data Message also
contains a record number in the RECNUM Field, then the record number
in the RECNUM Field will be used.
When an accessed RMS system must return Record File Addresses to the
accessing RMS system (bit 1 of ACCOPT in the Access Message set), the
sequence for record storage with return of status is as follows:
RECORD n -------->
(-------- STATUS
RECORD n+l ------>
(-------- STATUS
Errors are handled as indicated in Section 5.2.2 except for the use of
continue skip.

5.2.5 Append to Existing File - The append operation is identical to
sequential store and applies only to sequential files. The records
are placed at the logical end of the file by the accessed system:
RECORD 1-------->
RECORD 2-------->
If it is necessary to return Record File Addresses, the sequence
the same as that described for Record Store (see Section 5.2.4).

5.2.6 Deleting a File - The delete operation does not cause any file
data to be transferred, but does manipulate file structures. Deleting
a file does not require an Attributes Message in the setup sequence.
The message sequence for the delete operation is as follows:
[ATTRIBUTES---------->]
ACCESS (ERASE)----->
(-----ACCOMP (RESPONSE)
or
(-----STATUS

5.2.7 Command/Batch Execution Files - The Data
Access
Protocol
includes commands for the transfer and submission of files to a batch
processing
facility
or
command
interpreter.
The
"submit-as-command-file" request in the Access Message requests that a
store operation be done on the data that follows in a temporary file
and that this file be submitted to a batch-type facility upon access
completion (closing of the file). The file will be deleted following
execution by the batch facility.
DAP does nothing with regard to any
feedback from the batch facility and does not guarantee that the file
actually executes in the batch monitor. The file is transferred using
sequential file storage.
The "execute-as-command-file" requests that the specified file be only
submitted to the batch facility. No data follows this command (the
specified file having been previously established on the accessed
system).
The file is not deleted following execution by the batch
facility, so that the sequence "store, and execute command file" will
transfer a file,
submit it and retain the file for later use. The
sequence for "submit-as-command-file" is identical to "store", while
the "execute command file" is identical to ERASE.
NOTE
Since errors are not returned to the
originating node automatically, a test
for errors might be included in indirect
command
files.
Upon
error
or
completion, a suitable message can be
returned to the originating node.

5.3

Closing a File and Terminating Data Streams

The ACCOMP End of Stream (EOS) command is used to terminate a data
stream. When the accessing process wishes to terminate a data stream,
it may do so by sending it the appropriate STREAMID number to
terminate.
This is particulary useful when multiple data streams are
employed. This will not close the file even if it terminates the last
active data stream.
An ACCOMP (COMMAND) is used to close the file and terminate the
access, which includes closing out all remaining active data streams.

5.4

Terminating a Logical Link

The logical link is terminated by issuing a disconnect request.
During the setup of the link, this may be done by the accessed process
if optional timers indicate delay by the accessing process in
supplying the required information.
Once setup is complete, the
accessing process controls the rate of access
of
the
file.
Disconnection at this point will usually follow access completion.
The accessing process may disconnect at any time; however, different
systems may handle file closing and disposition differently if
disconnection occurs during transfers.

The accessing process is not required to disconnect and reconnect
following each access. However, if a new access is to be started, it
must be initiated in a timely manner.
If a timer is being used
between setup messages, it should also be set by the accessed process
following an Access Complete Message.
Disconnection will normally
occur only at the end of a group of transfers.

5.5

File Security and Protection

DAP attempts to provide approximately the same degree of file security
and protection over the network as is available locally. To do this,
a DAP user must be a registered user of each system holding files he
wishes to access.
Embedded in the connect message sent by the
accessing process is sufficient information for the user to be logged
onto the system whose files he wishes to access. User access is first
verified (not necessarily actually logged-on) and then file access is
allowed to proceed under the normal rules for file access applicable
to a local user.
If the user wants to change the account under which he is running at
the remote node, he must disconnect the logical link and reconnect
specifying the new account in the connect.

APPENDIX A
GLOSSARY

ISAM

Indexed Sequential Access Method. This access method
is a combination of random and sequential access.
Random access is used to locate a sequence of records
and then access is switched to sequential to read the
remaining records in the series.

JFN

Job File Number.
a file.

Key

A data item used to locate a record in a random
file system.

Key field

For direct and indexed files, the position of
within the record.

Key of
reference

The particular key field
key applies.

Octets

Octets in this document are bytes of 8 bits, with bit 0
the rightmost
(low-order, least-significant) bit and
bit 7 the leftmost (high-order, most-significant)
bit.
Fields
and
bytes of other lengths are numbered
similarly.

Object Type

Numeric value that may be used for process addressing
by DECnet processes instead of a process name. See the
NSP specification for further details.
DAP server
processes are object type number 21 (octal).

RFA

Record File Address. The unique address of a record
within a file. This method of addressing can be used
explicitly with RMS.

RMS

Record Management Services. This file system will be
used on all major DIGITAL systems except where space is
limited (e.g., RT-ll).
In addition to access modes
provided by previous file systems, RMS provides random
access for direct and indexed files and ISAM.

URD

Unit Record Device.

VBN

Virtual Block Number. This number is in the range 1 to
n where n is the highest numbered block allocated to
the file.

The JFN is the job's global handle on

the

access
the

key

record for which the

APPENDIX B
RSX/IAS/RT DECNET IMPLEMENTATIONS

DECnet remote file access (and transfer) is implemented via three
distinct pieces of software: a File Access Listener (FAL) , a set of
user callable subroutines (Network File Access Routines) called NFARS
and a Network File Transfer utility (NFT). A brief description of
each is provided below.

Bl.O

FAL

FAL is the mechanism which maps DAP protocol messages to the local
file system.
FAL accomplishes this by accepting DAP file access
requests from the user on the network side and mapping them into
equivalent requests to the local file and/or operating system. Figure
B-1 is the FAL State Diagram.
FAL is a user level process, resident on every node whose file system
is to be accessed via the network. It is a passive element in that it
services requests for remote access to the local file systems, it does
not generate activity by itself, and is idle (suspended) when no such
requests are in progress. Requesting processes are connected to FAL
through the network provided communication mechanism. The Data Access
Protocol (DAP) is used for exchanging commands and data between FAL
and the accessing process. A single FAL process can handle multiple
accesses and logical links simultaneously.

B2.0

NFARS

To simplify remote file access a set of FORTRAN callable subroutines,
NFAR's are provided.
The routines build, send, and interpret DAP
messages for the user. The basic functions provided by the user
interface are reflected in the NFAR's to effect remote file access.
The NFAR's accomplish this functionality by communicating with the
cooperating remote task FAL over the network using DAP messages.

WRITE
DATA
TO FILE
REPEAT
OR ABORT
TRANSFER

FOR CONTROL
GET,START
SENDING DATA
MESSAGES TO
USER PROCESS
DELETE FILE
OR EXECUTE
COMMAND FILE
& RETURN
ACCOMP (RESPONSE)

OPEN FILE
& RETURN
ATTRIBUTES

Figure B-1.

FAL State Diagram

B3.0

NFT

NFT is an internode file manipulation utility which allows a user to:
a)
b)
c)
d)
e)

transfer files to a remote node;
retrieve files from a remote node;
delete a file at a remote node;
execute command files at a remote node; and
submit command files to a remote node for execution there.

NFT calls the NFAR's directly, as user programs do, to perform the
requested operations. It maps commands entered by the user, into NFAR
calls which are interpreted by the FAL ·process on the remote node.
For example in a network with nodes A, B, and C, a user on node A
could transfer files between: A and B, A and C, or Band C using NFT.

APPENDIX C
REVISION HISTORY

A number of significant changes have been made to the Data Access
Protocol since its first release. The major differences between DAP
Version 4.1 are:
a.

DAP Version 1.U could not adequately support indexed and ISAM
file access;

The format of the operator field has been expanded;

The USERID message has been eliminated;

The status and error message have been combined;

The ACCESS COMPLETE Message has been added;

The CONFIGURATION Message has been added;

The two types of DATA Messages employed in Version
been merged into one DATA Message in Version 4.1.

and
1.0

have

While a definite incompatlbility exists between Versions 1.0 and 4.1,
numerous steps have been taken to build a more flexible architecture.
DAP Version 4.1 is flexible enough to allow new file access functions
to be added to the protocol framework.

digital equipment corporation

Printed in U.S.A.