Digital PDFs

AA-J679A-TM

May 1982

124 pages

Original

4.2MB

Document:	DECnet-20 Users Guide Dec82
Order Number:	AA-J679A-TM
Revision:	0
Pages:	124
Original Filename:	AA-J679A-TM_DECnet-20_Users_Guide_Dec82.pdf

OCR Text

DECnet-20 User's Guide
AA-J679A-TM

December 1982

This manual contains user information for DECnet-20, version
3, a product that together with the TOPS-20 operating system,
provides the DECSYSTEM-20 family of computers with a
communications interface to DIGITAL's corporate network,
DECnet. This is a new manual.
TOPS-20 DECnet-20 Programmer's Guide and Operations
Manual, Order Number AA-5091 A-TM, is to be used for

DECnet-20, version 2 users.
OPERATING SYSTEM:

TOPS-20 V5.1
GALAXY V4.2

SOFTWARE:

DECnet-20 V3

Software and manuals should be ordered by title and order number. In the United States, send orders
to the nearest distribution center. Outside the United States, orders should be directed to the nearest
DIGITAL Field Sales Office or representative.

Western Region

Northeast/Mid-Atlantic Region

Central Region

Digital Equipment Corporation
PO Box CS2008
Nashua, New Hampshire 03061
Telephone:(603)884-6660

Digital Equipment Corporation
Digital Equipment Corporation
Accessories and Supplies Center Accessories and Supplies Center
1050 East Remington Road
632 Caribbean Drive
Schaumburg, Illinois 60195
Sunnyvale, California 94086
Telephone:(312)64G-5612
Telephone:(408)734-4915

First printing, December 1982
© Digital Equipment Corporation 1982. All Rights Reserved.

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.
The following are trademarks of Digital Equipment Corporation:

~D~DD~DTM
DEC
DECmate
DECsystem-10
DECSYSTEM-20
DECUS
DECwriter
DIBOL

MASSBUS
PDP

P/OS
Professional
Rainbow
RSTS
RSX

UNIBUS
VAX
VMS

VT
Work Processor

The postage-prepaid READER'S COMMENTS form on the last page of this
document requests the user's critical evaluation to assist us in preparing future
documentation.

CONTENTS

PREFACE
PART I INTRODUCTION
CHAPTER 1
1.1
1.2
1.3
1.4
1.5
1.6
CHAPTER 2
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.2

SYSTEM OVERVIEW
DECNET . • . . .
. .
DECNET-20 OPTIONS
. . . .
DECNET-20 STRUCTURE . . . . •
DECNET-20 CAPABILITIES .
DECNET-20 PROGRAMMER INTERFACE •
DECNET-20 TERMINAL USER'S INTERFACE

.
.

• .
. .

• .
·
·
· . .
• • • • . . •
· .

1-1
1-1
1-2
1-2
1- 3
1-3

·
·
· .
• • • • . • •
·
• • • •

2-1
2-2
2-3
2- 3
2-4
2- 4

CONCEPTS AND FACILITIES
SYSTEM CONCEPTS . . . •
Physical and Logical Links •
Network Job File Number
Network Task Identification
Network Node Identification
NETWORK FACILITIES • . . . . .

PART II PROGRAMMER'S GUIDE
CHAPTER 3
3.1
3.1.1
3.1.2
3.1.3
3.2
3.2.1
3.2.2
3.2.3
3.3
3.3.1
3.4
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
3.4.6
3.4.7
3.4.8
3.4.9
3.4.10
3.5
3.5.1
3.5.2
3.5.3

ESTABLISHING A NETWORK CONNECTION

· ·· · ·
· · · ·

OBTAINING A NETWORK JFN
Specifying a Target Task
Specifying a Network Connection
Examples of Network File Specifications
OPENING A NETWORK JFN
Opening a Target Task JFN
Opening a Source Task JFN
Limit on Open Links
USING NETWORK INTERRUPTS
Example
RETRIEVING INFORMATION FROM THE LINK DATA BASE
Reading the Link Status
Reading the Host Name
Reading the Task Name
Reading the User Name
Reading the Password
Reading the Account String
Reading the Optional Data
Reading the Object Type
Reading the Object-Descriptor
Reading the Segment Size
ACCEPTING OR REJECTING A CONNECTION
Accepting the Connection
Rejecting the Connection
Examples

· · · · ·
· · ·
· · ·
· ·· · · · · ·
· · ·
· · ·
····
· · · · ·
·
·
·
......···
· · · · ·
·
· · · · ·
· · · ·
···
· · · · ·
· · · · · ·
·
·
· · · ·
· · · ·
· ·· · · · · ·
· · · ·
· ·· ·
. . . . . . · · ·· · · · ·

iii

3-3
3-3
3-5
3-7
3-9
3-9
3-10
3-10
3-10
3-12
3-12
3-13
3-14
3-15
3-16
3-17
3-18
3-19
3-20
3-21
3-22
3-23
3-23
3-23
3-24

CONTENTS (Cont.)
CHAPTER 4

TRANSFERRING INFORMATION OVER THE NETWORK

4.1
TRANSFERRING DATA . . . . .
· . . . . .
4.1.1
Sending Data . . .
. ...
· . . . . .
4.1.2
Receiving Data .
·
4.1.3
Summary of Procedures - Source and Target Tasks
4.1.3.1
Special SINR/SOUTR Considerations
• • • •
4.2
TRANSFERRING INTERRUPT MESSAGES
·
4.2.1
Sending Interrupt Messages .
·
4.2.2
Receiving Interrupt Messages .
· . . .
CHAPTER 5
5.1
5.2

5.3

4-1
4-2
4-2
4-4
4- 5

4-6
4-6
4-7

CLOSING A
CLOSING A CONNECTION NORMALLY . • . .
· . . . 5-1
ABORTING A CONNECTION . . . . . . . . · • • • . . 5-2
SOURCE AND TARGET TASK CODING EXAMPLES
· 5-4

PART III TERMINAL USER'S GUIDE
CHAPTER 6
6.1
6.1.1
6.1.2
6.2
6.3
6.4

CHAPTER 7

TOPS-20 DECnet-20 EXEC COMMANDS
INFORMATION COMMAND . . . . . . . . .
....
Information DECnet .
. . . . . . . . .
Information Job-Status .
. ...
SET LOCATION COMMAND . .
. . . .
/DESTINATION-NODE SWITCH . . . . . . . . . . . . .
ADDITIONAL FEATURES AVAILABLE TO NONPRIVILEGED
USERS . . . . . . . . . . . . . . . . . . . . . .

6-2
6-2
6-2
6-2
6-4
6-4

NETWORK FILE TRANSFER

OVERVI EW . . . . . . . . . . . . . . . · . . . .
7.1
Specifying File Access Information .
7.1.1
NFT COMMANDS . . . . . .
. . . . .
7.2
7.2.1
SET DEFAULTS Command .
. . . . . . .
INFORMATION Command
. . . .
7.2.2
COpy Command . • . . . . . .
. . . . . .
7.2.3
7.2.4
DELETE Command . . . . . . .
....
DIRECTORY Command
. . . . . . . .
7.2.5
........... .
EXIT Command .
7.2.6
7.2.7
HELP Command .
7.2.8
PRINT Command . . . .
7.2.9
SUBMIT command .
• • • • • • •
7.2.10
TAKE Command .
· . . . .
7.2.11
TYPE Command .
• • • • • • • • • • • • ••
NFT ERROR MESSAGES .
7.3
· . . . .
NFT Warning Messages . . . . . . . . . . . . .
7.3.1
7.3.2
NFT Fatal Error Messages .
........
Internal NFT Program Errors
. . . . ..
7.3.2.1

. 7-1
7-1
7-2
· 7-3
· 7-5
. 7-6
7-14
7-14
7-17
7-17
7-18
7 -18
7-19
7 -19
7-19
7-20
7-20
7-23

CONTENTS (Con t. )
CHAPTER 8

8.1
8.2
8.3
8.4
8.5

SETHOST (REMOTE LOGIN CAPABILITY)
SETHOST PROGRAM
. . . . . . . . . . . . .
LOGGING IN TO A REMOTE HOST USING SETHOST
EXITING FROM A REMOTE HOST USING SETHOST
CONTROLLING SCROLLING ON A REMOTE NODE .
SAMPLE TERMINAL SESSIONS USING SETHOST .

· 8-1
· 8-1
8-2
· 8-3
8-4

APPENDIXES
APPENDIX A

DISCONNECT OR REJECT CODES

APPENDIX B

DECnet OBJECT TYPES

APPENDIX C

GLOSSARY

INDEX
FIGURES
FIGURE

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

DECnet-20 on a DECSYSTEM-2040s/2060 .
The Network as an I/O Device
Logical and Physical Links
Establishing a Network Connection .
Example of Source Task Coding .
Example of Target Task Coding . .

1-2
2-1
2-3
3-2
5-5
5-6

TABLES
TABLE

2-1
2-2
2-3
2-4
7-1

A-I
B-1

Monitor Calls Used in DECnet-20 . . . . . . . . .
BOOT Monitor Call Functions Used in DECnet-20 . .
MTOPR Monitor Call Functions Used in DECnet-20
NODE Monitor Call Functions Used in DECnet-20
COpy Command Switches . • . . . • . .
Disconnect or Reject Codes
DECnet Object Types . . . . .

2-5
2-5
2-6
2-6
7-7

A-I
B-1

PREFACE

This manual, DECnet-20 User's Guide, includes information about
and programming DECnet-20. This manual should be used by:

using

•

The application programmer responsible for
writing
the
programs that will be exchanging data with programs on other
systems in the network. This person should be an experienced
MACRO programmer with some knowledge of network applications,.

•

The terminal user, using the network utilities that do not
require privileges. Such a user, like all timesharing users,
should be familiar with the TOPS-20 Command Language.

This manual is organized into three parts as follows:
Part I, the Introduction, consists of an overview
network options and network facilities.

DECnet-20,

the

Part II, the Programmer's Guide, describes the programming facilities
that the MACRO programmer must use to perform the following network
functions:
network-related

Establishing a network
monitor functions.

•

Transmitting and receiving both data and interrupt messages
over a network link using standard TOPS-20 I/O monitor calls.

•

Controlling
functions.

•

Terminating a network connection
standard monitor calls.

the

connection

using

•

network

using

network-related
using

monitor

network-related

and

Part III, Terminal User's Guide, describes the TOPS-20 commands
available
to
nonprivileged users.
All network-related TOPS-20
commands, including user interaction with the file transfer utility
(NFT) , are explained.
This part also contains information relating to network remote
terminal capability (SETHOST) and provides examples of the use of this
facility.

vii

The following are suggested guidelines for using this manual:
•

Application programmers should read the entire manual.

•

Terminal users should read Part III.

•

System managers and system programmers should read the
manual.

entire

DECnet-20 version 3 runs under the
TOPS-20
monitor
on
the
DECSYSTEM-2040S/2060 models.
DECnet-20 for
the DECSYSTEM 2020 is
DECnet-20 version 2 which is described in the TOPS-20 DECnet-20
Programmer's Guide and Operations Manual, order numbe~ AA-509lB-TM.
The following documents are either referenced in this
prove useful in implementing DECnet-20 facilities.

manual

TOPS-20 Monitor Calls User's Guide

AA-D859B-TM

TOPS-20 Monitor Calls Reference Manual
and its update

AA-4166E-TM

TOPS-20 Commands Reference Manual
and ltS update

AA-5ll5B-TM

TOPS-20 User's Guide
and its update

AA-4l79C-TM

TOPS-IO/TOPS-20 Batch Reference
Manual

AA-H374A-TK

DECnet-20 System Manager's and
Operator's Guide

AA-J678A-TM

DECnet DIGITAL Network Architecture (Phase
III) General Description

AA-K179A-TK

TOPS-20 DN200 Remote Station Guide

AA-H786B-TM

viii

may

PART I
INTRODUCTION

CHAPTER 1
SYSTEM OVERVIEW

1.1

DECNET

DECnet is the name given to the set of software products that extend
the capabilities of various DIGITAL operating systems so that these
systems can be interconnect€d to form computer networks.
DECnet is based on sets of rules
(protocols)
known collectively as
DIGITAL Network. Architecture, or DNA.
These protocols govern the
transmission of data over physical lines, using error detection and
retransmission to guarantee the integrity of the data, multiplexing of
multiple logical messages over a single physical connection, and
controlling which nodes are allowed to communicate and when they can
do so.
Each operating system that supports DECnet implements some subset of
the complete DNA. The subset of DNA that runs under TOPS-20 is called
DECnet-20.

1.2

DECNET-20 OPTIONS

The capabilities of DECnet-20 include multiline support,
the Network
File Transfer
(NFT) utility, and the ability to log into a DECSYSTEM
2040S/2060 other than the one the terminal is connected to.
One DECnet option is available:
RJE-20. This option includes software for the DN200 remote batch
entry station and provides the facility for the DN200 software to
be down-line loaded, diagnosed, and operated remotely by the host
system.
A DECnet site may choose to divide the use of its
stations and other DECnet hosts.

1-1

lines

between

RJE

SYSTEM OVERVIEW
1.3

DECNET-20 STRUCTURE

When DECnet-20 is running on a DECSYSTEM-2040S/2060, the network
software resides in the KLIO processor with the TOPS-20 monitor and in
a separate processor (the DN20)
designed
to
handle
network
communications functions
(the KLIO processor and DN20 are, in fact,
separate nodes).
This latter processor is referred to as the
communications front end to distinguish it from the console front end
that controls the local command terminals and unit record peripherals.
The KLIO processor communicates with eithpr front end through a DTE
h a r d war e in t e r fa c e .
( See Fig u r e 1-1.)
remote node

DECSYSTEM-2040S or 2060

DN20

Line
Driver

Monitor Call
Interface

DDCMP

Transport
NSP

TOPS-20

DTE Driver

DTE

DTE Driver

Network
Utilities
MR·S·2238·82

Figure 1-1

1.4

DECnet-20 on a DECSYSTEM-2040S/2060

DECNET-20 CAPABILITIES

DECnet-20 provides the TOPS-20 user with basic network task-to-task
capabilities. That is, local system or user tasks written in MACRO-20
can exchange information with system or user tasks running in one or
more nodes in a network.
The local task uses the TOPS-20 file system monitor calls to open,
read and write information, and close files using a pseudo-device
representing the network. These functions create a logical link,
transmit data, and close the logical link.
Below this user level, and transparent to the user, the network
protocols take over. Network software running in the KLIO processor
and in the communications front end manages the actual transfer of
data over a logical link.
User data is first reformatted into
network-compatible segments and then transferred.
The
network
software also generates the appropriate control messages to open and
close network connections.

1-2

SYSTEM OVERVIEW
1.5

DECNET-20 PROGRAMMER INTERFACE

A MACRO-20 program can transfer data between user storage and the
network in much the same way that data is transferred between user
storage and files on a peripheral device. The peripheral device,
in
this case,
is the network;
the file is a logical link.
File system
monitor calls, such as GTJFN, OPENF, and CLOSF, control the making and
breaking of network connections.
Input/output monitor calls, such as
SIN, SINR, BIN, SIBE, SOUT, SOUTR, and BOUT, handle the movement of
messages and data across the network.
Several network-specific
functions have been added to the MTOPR monitor call to provide for
logical link management. These functions are described in subsequent
chapters.

1.6

DECNET-20 TERMINAL USER'S INTERFACE

As a terminal user (without OPERATOR or WHEEL privileges), you use the
TOPS-20 Command Language (EXEC) to communicate with the system. The
TOPS-20 User's Guide and the TOPS-20 Commands Reference Manual
descrlbe the TOPS-20 Command Language In detall.
Part III of this manual describes the network file transfer utility
(NFT)
and EXEC commands that are specific to DECnet-20. NFT allows
you to gain access to the files on other nodes through the Data Access
Protocol (DAP) of the DNA.

1-3

CHAPTER 2
CONCEPTS AND FACILITIES

2.1

SYSTEM CONCEPTS

The user interface to DECnet-20 is based on the concept that the
network is to be treated as a TOPS-20 input/output device. TOPS-20
programs written to communicate with other tasks in the network use
TOPS-20 file system monitor calls to perform network functions.
This
concept is represented graphically in Figure 2-1.
The local network
software provides the user with access to the network using many of
the same monitor calls that are used to access local peripherals.
Figure 2-1 shows this code residing in the TOPS-20 monitor of a
DECSYSTEM-2040S/2060. The communications front end is transparent to
both local and remote user tasks.
DECSYSTEM-2040S or 2060
TTY:driver
DSK:driver
TOPS-20
MONITOR
CALLS

MTA:driver

NSP Code

r--T.:---'

...."..-_ _ _ Tothe

I SRV: (line I

Network

~~:-1.D~ve~

MR-S-2239-82

Figure 2-1

The Network as an I/O Device

In order to establish a network connection, you need one task that is
willing to accept a connection (a target task) and another task that
ini tia'tes the request for a connection
(a source task).
In the
following discussion,
it is easier to imagine these two tasks as
existing on different nodes; however, there is no restriction that
prohibits tasks on the same node from engaging in a network dialogue
with one another.
To declare itself as being available for a connection by a source
task, a target task identifies itself using a file specification with
device type SRV:. When the SRV: device is opened,
the target task
has declared itself;
it then waits until a connect request occurs.
Any incoming connect request addressed to this target task is
forwarded to it by DECnet-20.
The request may be accepted or
rejected.
If the request is accepted, the connection is made and data
can be exchanged between the two tasks via reads and writes to the
file (JFN).

2-1

CONCEPTS AND FACILITIES
To initiate a dialogue with a target task, a source task identifies
the target task as a file specification with device DCN:.
The sourCe
task then opens the network file (note that both the source and target
tasks must agree to the connection).
The source and target tasks then
exchange data and either the source or target task can close the link.
Other network concepts that will be used in subsequent chapters are
physical and logical links, network job file numbers, network task
identification, and network node identification.
These concepts are
introduced in the following subsections.

2.1.1

Physical and Logical Links

Physical and logical links are the basic elements of communication on
a network.
Physical links connect network nodes and logical links
connect network tasks.
A physical link connects two adjacent network nodes and can take one
of several forms.
In Figure 2-2, the physical link between nodes ABLE
and ABLER or BAKERY and BAKER is the DTE interface, a hardware device
between a DECSYSTEM-2040S/2060 and its communications front end.
The
physical link between nodes ABLER and BAKERY or between nodes BAKER
and CHARLY can be a relatively permanent connection such as a leased
or private telephone line or cable.
It can also be a temporary
connection such as a satellite link or radio circuit.

PDP-11

Figure 2-2

Logical Link

MR-S-2240-S2

Logical and Physical Links

A physical link can support one or more logical links.
A logical link connects two network tasks that have both agreed to
communicate. A logical link usually shares a physical link with other
logical links.
A logical link can span more than one physical link as
shown from node ABLE to node BAKER in Figure 2-2.

2-2

CONCEPTS AND FACILITIES
The simultaneous sharing of a physical link by multiple logical links
is referred to as mUltiplexing. Among the functions of the network
software in DECnet-20 are the mixing of outgoing logical link data
from several users
(multiplexing)
for transmission over a physical
link and the separating of incoming logical link data (demultiplexing)
for distribution to individual users.
These functions are transparent
to the user.
In Figure 2-2, the logical links between users A and D, Band E, and C
and F, are multiplexed and span three physical links: ABLE to ABLER,
ABLER to BAKERY, and BAKERY to BAKER.
The logical link between users
G and H is the only data path on the physical link from BAKER to
CHARLY and therefore no mUltiplexing is necessary.

2.1.2

Network Job File Number

The network job file number in DECnet-20 is the same as the job file
number
(JFN)
assigned to any other TOPS-20 file specification being
processed by TOPS-20 processes.
In the TOPS~20 file system, a JFN is
associated with a file specification and constitutes a handle on the
file.
In DECnet-20, where the network is treated as an input/output
device, a network JFN is associated with a specification for a logical
link, the network equivalent for a file.
.
The same monitor call (GTJFN) is used to obtain either a network or a
file JFN.
The information passed to the GTJFN monitor call for a
network JFN is similar in format to that supplied for a file JFN.
The
format and usage of logical link specifications are explained in
Chapter 3, Establishing a Network Connection.

2.1.3

Network Task Identification

A network task is any program that is engaged in, or intends to engage
in, a network dialogue.
Network tasks in DECnet-20 can have two
distinct identities:
a generic task identification and a unique task
name.
The generic task identification is used to address a network task that
provides a class of service to other network tasks (for example, a
network utility program).
Multiple copies of such a network program
can be loaded,
started, and identified by class of service.
Other
network tasks can then request this service by specifying a connection
by generic identification. This guarantees a connection to one of the
available copies all of which are assumed to provide the same service.
The generic task identification consists of two parts:
a one-byte
object
type
(numeric)
and
an
optional
object
descriptor
(alphanumeric) .
Object types 1 through 127 are reserved for DECnet utilities and
control programs.
Object types 128 through 255 are available for
customer use.
Object type 0 is reserved for addressing tasks by their
unique task name.
See Appendix B for a list of the current DECnet
object types.

2-3

CONCEPTS AND FACILITIES
The use of object descriptors is dependent upon the implementation of
the network software on the remote node.
If the remote node is
running a system other than TOPS-20, read the DECnet manuals for the
system being used. In DECnet-20, you can use object descriptors with
object types 128 through 255.
A unique task name is used to address a specific network task.
Only
one copy of such a task can be running at anyone time on anyone
node. If a network task is identified by task name alone, it must be
addressed by the special object type 0 and a descriptor that
corresponds to the unique task name.

2.1.4

Network Node Identification

A node name must be one to six alphanumeric characters in length and
one of these must be alphabetic. At each node, the system manager
assigns names by which the users reference the nodes in the network.
When
DECnet-20 is installed, the KLIO processor and the DN20
communications front end are each considered separate network nodes.
Each, therefore, must have a unique node number.
Whenever a source task requests a connection to an existing target
task, the source task must give the name of the target node. The
network software generates a message to the target node requesting a
connection to the target task. Sending this request is the first step
in establishing a logical link.
For more information on network node names and
DECnet-20 System Manager's and Operator's Guide.

2.2

numbers,

see

the

NETWORK FACILITIES

You, as a TOPS-20 user, can write MACRO programs to communicate with
tasks in another node. When doing so, you use a subset of the TOPS-20
file system monitor calls to interface
to
DECnet-20.
These
network-related monitor calls allow you to:
•

Declare a network task as willing to accept connections.

•

Initiate a request for a connection to another network task.

•

Accept or reject a
network task.

•

Transmit data to and/or
task.

•

Interrogate the status of a logical link.

•

Retrieve the connect attributes of a network task.

•

Exchange high priority interrupt messages (up to 16
length) with other network tasks.

•

Disconnect a network connection.

request

for

receive

2-4

connection

data

from

another

network

bytes

CONCEPTS AND FACILITIES
The network-related monitor calls and their functions are listed in
Tables 2-1, 2=2, 2=3, and 2~4. Many of these calls are also used in
TOPS-20 file processing and their calling sequences are described in
the TOPS-20 Monitor Calls Reference Manual.
Information for all the
network-related calls and the calling sequences for
the network
functions of MTOPR appear in the next three chapters.
Table 2-1
Monitor Calls Used in DECnet-20
Network Function

Monitor
Call

Get a network JFN
Open a network connection
Receive a data byte
Provide maintenance and utility functions for
communicat~ons software (see Table 2-2)
Receive a data string
Receive a data record (message)
Transmit a data byte
Transmit a data string
Transmit a data record (message)
Test for input buffer empty
Close a network connection
Perform device-dependent control functions
(see Table 2-3)
Set node and line characteristics
(see Table 2-4)
Network Management interface to lower DNA
levels

GTJFN
OPENF
BIN
*BOOT
SIN
SINR
BOUT
SOUT
SOUTR
SIBE
CLOSF
MTOPR
*NODE
*NTMAN%

* BOOT, NTMAN%, and some functions of NODE are privileged monitor
calls used in DECnet-20 system programs.
Detailed descriptions of
these monitor calls can be found
in the TOPS-20 Monitor Calls
Reference Manual.
Table 2-2
BOOT Monitor Call Functions Used in DECnet-20
Function

Symbol
.BTROM
.BTLDS
.BTLOD
.BTDMP
.BTIPR
.BTTPR
.BTSTS
.BTBEL
.BTRMP
.BTCLI
.BTCPN

Puts line or DTE in MOP mode and activates
the front-end ROM
Load secondary bootstrap
Loads the DN20 or console front end
Dump the front end
Initiate line protocol
Terminate line protocol
Determine line protocol
Wait for front-end doorbell
Read MOP message
Convert line-id to port number
Convert port number to line-id

2-5

CONCEPTS AND FACILITIES
Table 2-3
MTOPR Monitor Call Functions Used in DECnet-20
Symbol
. MOACN
. MORLS
. MORHN
. MORTN
. MORUS
. MORPW
. MORAC
. MOHDA
. MORCN
.MORIM
.MOSIM
. MOROD
. MOCLZ
. MOCC
.MORSS
. MOANT
. MOSNH

Function
Set interrupt assignments
Read link status
Read host name
Read task name
Read user identification
Read password
Read account string
Head optional data
Read object type
Read interrupt message
Send interrupt message
Read object-descriptor
Reject/Close a network connection
Accept a network connection
Read segment size
Attach network terminal
Set network host
Table 2-4
NODE Monitor Call Functions Used in DECnet-20

Symbol
.NDSLN
.NDGLN
.NDSNM
.NDGNM
.NDSLP
.NDCLP
.NDFLP
.NDSNT
.NDGNT
.NDSIC
.NDCIC
.NDGVR
.NDGLI
.NDVFY

Function
Set local node name
Get local node name
Set local node number
Get local node number
Set loopback port
Clear loopback port
Find loopback port
Set network topology information
Get network topology information
Set topology change interrupt channel
Clear topology change interrupt channel
Get NSP version information
Get line information
verify node name

2-6

PART II
PROGRAMMER'S GUIDE

CHAPTER 3
ESTABLISHING A NETWORK CONNECTION

To establish a network connection, you need one task that is willing
to accept a connection (a target task) and another task to initiate
the request for a connection
(a source task).
In the following
discussion,
it is easier to imagine these two tasks as existing on
different nodes; however, there is no restriction that prohibits
tasks on the same node from engaging in a network dialogue with one
another.
A TOPS-20 task that wants to declare itself as a target task,
available for network dialogue with other network tasks, must first
obtain a Job File Number (JFN) identifying itself on device SRV:. The
target task must then open the SRV: in order to have a logical link
the
assigned to it. Whenever a connect initiate message arrives,
target task can interrogate the connect attributes of the source task
and decide whether to accept or reject the connection.
A TOPS-20 task that wants to initiate a network dialogue with a
declared target task must first obtain a JFN for a network connection
identifying the target task on device DCN:.
It must then open the
DCN: to have a logical link assigned and to have a connect initiate
message sent to the target task.
SRV: and DCN: are special network devices that provide logical link
service to another task.
The JFN constitutes a handle on the task.
A TOPS-20 task can declare itself as a target task and also act as a
source task by initiating a dialogue with some other task;
the two
actions are not mutually exclusive.
Figure 3-1 is a general overview of the dialogue that takes place when
a network connection is established.
A task at node DALLAS issues a GTJFN monitor call identifying itself
as a target task named TEX. A subsequent OPENF monitor call informs
the network software at node DALLAS that TEX is ready to receive
connection requests from the network.
A task at node BOSTON issues a GTJFN monitor call identifying itself
as a task named TONY and specifying a network connection to task TEX
at node DALLAS. A subsequent OPENF monitor call causes the network
software at node BOSTON to send a connect initiate message to node
DALLAS.

3-1

ESTABLISHING A NETWORK CONNECTION
The network software at node DALLAS knows that task TEX is accepting
calls and forwards the connect initiate message. Task TEX decides
whether to accept or reject the connection and returns a connect
confirm or connect reject message to the source task TONY.
The tOllowing sections of this chapter describe the individual
that are required to establish a network connection.

steps

DALLAS

BOSTON

TARGET NODE

SOURCE NODE
Source
Task
(TONY)

GTJFN
DCN:DALLASO-TEX.TONY
OPENF

Get me TEX
in DALLAS.

Hello DALLAS, I have
a call for TEX.

No connection

fv\ TEX, you

to DALLAS

call.

~havea

No connection toTEX.

TEX does not accept

Ithe call.

This is TEX, what can

II do for you?
MR-S-602-60

Figure 3-1

Establishing a Network Connection

3-2

ESTABLISHING A NETWORK CONNECTION
3.1

OBTAINING A NETWORK JFN

The first step in establishing a network logical link is to obtain a
Job Pile Number (JPN) for either the SRV: or DeN: device. Use the
GTJFN monitor call in either its short or long form as described in
detail in the Monitor Calls Reference Manual.
The network file
specification can be submitted interactively from your terminal,
accessed from memory, or (in the long form) developed by a combination
of both methods. Note that the connection must be opened with the
OPENF call.
The general format of a GTJFN file specification in
TOPS-20 is:
dev:<directory>filename.filetype.generationifile attributes
When you use the GTJFN call to obtain a network JFN, the network
specification takes the following form:

file

dev:

is replaced by one of the network
SRV: or DCN:.

pseudo-devices,

is unused.

filename

is replaced by objectid-descriptor for an SRV:
file and by hostname-objectid-descriptor for a
DCN: file.

file type

is replaced by a task name
the task issuing the GTJFN.

generation

is unused.

file attributes

are replaced by network attributes.

uniquely

identifying

The individual fields in the network file specification are
in detail in the following subsections.

3.1.1

described

Specifying a Target Task

Use the following format of the network file specification to obtain a
JFN identifying yourself as a target task:
SRV:objectid-descriptor.taskname
where:
SRV:

is the logical device name for a target task.

objectid

is part of an optional generic identification for a
target task.
If included, it must be a nonzero object
type expressed asa decimal number or an object name
(see Appendix B).
The numbers 1 thro~gh 127 are
reserved for DECnet system tasks and requIre enabled
WHEEL or OPERATOR privileges. Numbers 1 through 127
should not be assigned to user tasks unless the task
provides the service and uses the protocol implied by
the object type (see Appendix B). Numbers 128 through
255 are available to all tasks.
If objectid is not
specified, the target task must be addressed by its
unique task name.

3-3

ESTABLISHING A NETWORK CONNECTION

- (hyphen)

is a subfield separator that is required
descriptor is specified.

descriptor

is an optional modifier to be associated with the
objectid.
If specified, it must be 1 to 16 characters
in length and contain only alphanumerics, hyphens,
dollar signs, or underscores.
If objectid is not
specified, the descriptor must also be omitted.
If
descriptor is specified, it must also appear in the
specification used by the source task to address this
task (see Section 3.1.2).

only

the

NOTE
Some DECnet implementations do not allow a
descriptor to be associated with a nonzero
object type.
When communicating with
a
non-DECnet-20
node,
read the applicable
documentation to determine any restrictions
on the generic task identification.
. (per iod)

is a separator character and is required only
name is specified.

taskname

is the unique task name by which a task is to be
addressed independent of its generic identification.
If taskname is specified, it must be 1 to 16 characters
in length and contain only alphanumerics, hyphens,
dollar signs, or underscores.
If taskname is not
specified,
the
monitor
will
assign
one.
(To
subsequently determine the monitor-assigned task name,
use the read task name function described in Section
3.4.3. )

The maximum lengths of the variable
specification as imposed by TOPS-20 are:

fields

the

SRV:

objectid

see object type and name in Appendix B

descriptor

16 characters

taskname

16 characters

task

file

The above maximums may be reduced by any size limitations imposed by a
DECnet product running under a different operating system on a remote
node.

3-4

ESTABLISHING A NETWORK CONNECTION
3.1.2

Specifying a Network Connection

Use the following format of the network file specification to obtain a
JFN identifying a target task that you wish to connect to:
DCN:hostname-objectid-descriptor.taskname;Al;A2 ...
where:
DCN:

is the logical device name for a network connection.

hostname

is the node name of the node on which the target task
is running.
If this field is omitted, the target task
is assumed to be running on the local node.

is a subfield separator and is required.

(hyphen)

objectid

is the identification of the target task.
It is an
object name or a numeric object type when addressing a
target task by its generic identification (see Appendix
B).
The special object type 0 (or corresponding object
name TASK) is used to address a
target task by its
unique task name.
The objectid, when specified as a
numeric object type, must be entered in decimal.
This
subfield is required.

is a subfield separator that is required
descriptor is specified.

(hyphen)

descriptor

only

the

is an optional modifier
to be associated with the
objectid.
If objectid is TASK or 0, this field must be
the unique task name of the target task.
If objectid
identifies some other object type, this field must be
the descriptor specified by the target task.
NOTE
Some DECnet implementations do not allow a
descriptor
to be associated with a nonzero
object type.
When you wish to communicate
with
a
non-DECnet-20
node,
read
the
applicable documentation to determine any
restrictions
on
the
generic
task
identification .

(period)

taskname

is a separator character
taskname is specified.

and

required

only

is the unique taskname of the source task initiating
the network connection.
If taskname is specified, it
must be 1 to 16 characters in length and contain only
alphanumerics, hyphens, dollar signs, or underscores.
If taskname is not specified, the monitor will assign
one.
(To subsequently determine the monitor-assigned
task name, use the read task name function described in
Section 3.4.3.)

3-5

ESTABLISHING A NETWORK CONNECTION
~AI;A2 ...

are a collection of attributes of the source task that
are included in the connect initiate message sent to
the target task. These attributes can be used by the
target task to validate a network connection or to
perform any other handshaking functions agreed to by
both tasks. The allowable attributes are:
~USERID:userid

where userid consists of I to 39
contiguous
alphanumeric
ASCII
characters (including the hyphen,
dollar
sign,
and
underscore)
identifying the source task.
Example:
~USERID:ALIBABA

NOTE
Special characters in a
file specification must be
Av'ed.
This allows the
acceptance of PPNs for the
USERID.
;PASSWORD:password

where password consists of I to 39
contiguous
alphanumeric
ASCII
characters (including the hyphen,
dollar
sign,
and
underscore)
required by the target task to
validate the connection.
Example:
; PASSWORD: SESAME
The password can also be specified
in
binary
to allow non-ASCII
characters. The keyword for this
type of entry is BPASSWORD.

;BPASSWORD:password

where password, in this context,
consists of I to 8 octal triplets
representing
the
required
password. Each triplet represents
an 8-bit byte.
Example:
BPASSWORD:123056002

;CHARGE:acctno

where acctno consists of I to 39
contiguoHs
alphanumeric
ASCII
characters (including the hyphen,
dollar
sign,
and
underscore)
representing the source
task's
account identification.
Example:
iCHARGE:ACCT-13C

3-6

ESTABLISHING A NETWORK CONNECTION
;DATA:userdata

where userdata consists of 1 to 16
contiquous
alphanumeric
ASCII
characters (including the hyphen,
dollar
sign,
and
underscore)
representing user data.
Example:
;DATA:THIS-IS-A-TEST
The user
data
can
also
be
specified
in
binary to allow
non-ASCII characters.
The keyword
for this type of entry is BDATA.

;BDATA:userdata

where userdata, in this context,
consists of 1 to 13 octal triplets
representing user
data.
Each
triplet represents an 8-bit byte.
Example:
;BDATA:231337001

The attributes of a source task can be retrieved by a
target task via functions of the MTOPR monitor call
(see Section 3.4).
The maximum lengths of the variable
specification as imposed by TOPS-20 are:

fields

the

DCN:

file

hostname

6 characters

objectid

see object type and name in Appendix B

descriptor

16 characters

hostname-objectid-descriptor

39 characters including the hyphens

taskname

16 characters

;Al ;A2 ...

see the description of the
attribute

The above maximums may be reduced by any size limitations
the DECnet product running on the remote host system.

3.1.3

individual
imposed

Examples of Network File Specifications

The following examples show various ways that a target task can
declare itself and the corresponding ways that a source task must use
to address the target task.
These examples assume two DECnet-20 nodes
with host node names of BOSTON and DALLAS.

3-7

ESTABLISHING A NETWORK CONNECTION
Example 1
A task at node BOSTON wants to declare itself
task SAM.
It does so with the specification:

the

unique

target

SRV:.SAM
In order to request a connection to SAM at node BOSTON, a task TEX
node DALLAS would specify:

DCN:BOSTON-TASK-SAM.TEX
A task COD at node BOSTON requesting a connection to SAM at node
BOSTON can omit the node name in the specification because the target
node is the local node.
It need only specify:
DCN:-TASK-SAM.COD
Example 2
A task at node BOSTON wants to declare itself as a generic
task, object type 128.
It does so with the specification:

service

SRV:128
Task TEX at node DALLAS
specification:

can

connect

the

above

task

with

the

its

DCN:BOSTON-128.TEX
Assume that the BOSTON
specification such as:

task

had

included

descriptor

SRV:128-PARTl
The DALLAS task would then have to modify its specification to:
DCN:BOSTON-128-PARTl.TEX
Example 3
Several tasks at node BOSTON, running the same utility program, want
to declare themselves both generically as object type 129 and uniquely
by task name.
The respective specifications used to declare three
such tasks are:
SRV:129.TOM
SRV:129.DON
SRV:129.TONY
A task TEX at node DALLAS, wanting to use the utility but not caring
which copy of the program completes the connection, can specify:
DCN:BOSTON-129.TEX
If, for some reason, TEX had to connect to the particular
the specification must be submitted as:
DCN:BOSTON-TASK-TONY.TEX

3-8

task

TONY,

ESTABLISHING A NETWORK CONNECTION
Example 4
A task at node BOSTON declares itself as the target
the specification:

task

XDATA

with

SRV: .XDATA
Assume that the task XDATA restricts connections to those remote tasks
that
have
a
valid userid, password, and charge account.
A
specification from task TEX at node DALLAS to connect to XDATA would
then have to include the above attributes, for example:
DCN:BOSTON-TASK-XDATA.TEX;USERID: RITTER; PASSWORD: SESAM E
;CHARGE:ACCT-XYZ
The target task can then confirm the connect requirements
by
retrieving the network attributes using the read logical link data
functions of the MTOPR monitor call.
These functions are described in
Section 3.4.

3.2

OPENING A NETWORK JFN

Having obtained a JFN for a network file specification,
the network
task must then open the file with the OPENF monitor call.
The events
that occur when a network file is opened depend on whether the file
represents a target task or a source task.

3.2.1

Opening a Target Task JFN

An OPENF monitor call for a JFN that represents a target task implies
that the task is ready to accept connect initiate messages from other
tasks in the network.
The network software performs the following
functions:
•

Constructs a link data base for this connection.

•

Places the target task on a list of available connections.

Subsequently, when a connect initiate
source task, the network software:

message

received

from

for

matching

•

Searches the list of available connections
generic or unique task identification.

•

Notifies the appropriate target task via a connect interrupt
that it has a connect request pending and modifies the link
status appropriately.

The target task can then access the logical link data
(see
3.4) to determine whether to accept or reject the connection.

3-9

Section

ESTABLISHING A NETWORK CONNECTION
3.2.2

Opening a Source Task JFN

An OPENF monitor call for a JFN that represents a source task implies
a request for a connection to a target task. The network software:
•

Constructs a link data base for this connection.

a connect initiate message and forwards it to the
• Generates
host node specified by the host name in the DCN: file
specification.
•

Processes the resulting connect confirm or connect reject
message, and notifies the source task of the acceptance or
rejection by a connect interrupt.
NOTE
The successful completion of the OPENF monitor call
for a network connection does not ensure that a
network connection has been completed. To ensure that
the remote node has accepted the connect request, read
the link status with the .MORLS function of the MTOPR
JSYS before transferring data over the link.

3.2.3

Limit on Open Links

DECnet-20 software sets a user quota of four open links per job.
These can be any combination of SRV: and DCN: types. However, a
task running with enabled WHEEL or OPERATOR privileges is not bound by
this quota and may open as many links as the system will allow.
The system quota of open links varies according to the amount of
monitor free space available at the time. Free space, in turn, is
dependent upon the current demands of other processes.
Whenever a
request to open a link cannot be completed because of insufficient
free space, an appropriate error code is returned.

3.3

USING NETWORK INTERRUPTS

Whenever a MACRO task uses a SIN or SINR monitor call to input a data
string from the network, the task will stop running (block) if no data
is available. In situations where a network task is supporting
multiple links, blocking for each SIN or SINR call severely impacts
the speed of data transmission. Asynchronously notifying the task of
the arrival of network data reduces idle time and increases the
overall throughput.

3-10

ESTABLISHING A NETWORK CONNECTION

DECnet-20 has an interface to the MTOPR monitor call to allow a
network task to enable software interrupt channels for any combination
of the following types of network events:
•

Connect event pending (connect initiate, connect confirm)

•

Interrupt message available

•

Data message or disconnect received

The MTOPR calling sequence to enable for network interrupts places the
following arguments in the specified accumulators:
ACl:

The JFN of the logical link

AC2:

.MOACN (function code)

AC3:

Control information specifying _the
changes
in
the
interrupt
assignments
for this link.
This control
information is placed in three 9-bit fields that are
defined as follows:
Field

Symbol

Used to signal

BO-B8
B9-B17
B18-B26

MO%CDN
MO%INA
MO%DAV

Connect event pending
Interrupt message available
Data available

The content of each of these fields must be one of the
following:
Value

Meaning

nnn
.MOCIA
.MONCI

Enable the channel specified by nnn
Clear the interrupt
Do not change the previous setting

Valid user-assignable channels are defined in the Monitor
Calls Manual.

3-11

ESTABLISHING A NETWORK CONNECTION
3.3.1

Example

The following program segment illustrates one method of
interrupt channels for the three types of network events:

enabling

SET UP THE INTERRUPT CHANNELS AND GO INTO WAIT STATE
ENACHN: MOVEI
MOVE
SIR
MOVX
AIC
EIR
MOVE
MOVE!
MOVX
MTOPR
PAUSE: WAIT

Tl,.FHSLF
T2,[LEVTAB"CHNTAB]

Tl,NETJFN

iIDENTIFY CURRENT PROCESS
iSPECIFY TABLE ADDRESSES
iDEFINE PSI SYSTEM TABLES
iSET BITS FOR CHAN 0,1,2
iACTIVATE CHANNELS 0,1,2
iENABLE THE SYSTEM
iGET NETWORK JFN

'l'?
........ , • M():n.rl\l

•, c::. F'l'
flO
.....
.....,.1.

T2,7B2

'&'''_'''~_.L.

_&.11_ ........ _&. •

Pfll\lr'l'T()l\l
....

T3,(FLD(O,MO%CDN)+FLD(1,MO%DAV)+FLD(2,MO%INA)>
iISSUE THE CALL
iWAIT FOR INTERRUPT

LEVTAB: PC

iLEVEL 1 PC ADDRESS

CHNTAB: 1"HELLO
1, ,HAVDAT
1, , INTRPT
REPEAT
D33 ,(EXP 0>
PC:
BLOCK 1

iCONNECT INTERRUPT
iDATA AVAILABLE INTERRUPT
iINTERRUPT MESSAGE INTERRUPT
iUNUSED INTERRUPT CHANNELS
iLEVEL 1 PC

o
o

NOTE
MOVX and
MACSYM.

3.4

FLD

are

macros

defined

RETRIEVING INFORMATION FROM THE LINK DATA BASE

Associated with each open logical link is a link data base. This data
base contains information such as link status, link control data,
allowable segment sizes, and data governing the transmission and
receipt of data and interrupt messages.
Whenever a target task is notified of a pending connect request from a
source task, the target task's data base will contain the connect
attributes submitted by the source task. These attributes, as well as
other link data, can be retrieved by a target task using the MTOPR
monitor call. These functions retrieve the source's host name, task
name, user identification, password, user account number, and optional
user data. using this data, the target task can decide whether to
accept or reject the connection.

3-12

ESTABLISHING A NETWORK CONNECTION
3.4.1

Reading the Link Status

The read link status function of MTOPR returns a 36-bit
information regarding the status of the logical link.

word

the

Arguments must be placed in the specified accumulators:
ACl:

The JFN of the logical link

AC2:

.MORLS (function code)

The following information is returned in AC3:
Flag bits in the left half and a disconnect code
right half

AC3:

The flag bits are:
Symbol

Bit

Meaning

MO%CON
MO%SRV
MO%WFC
MO%WCC
MO%EOM
MO%ABT
MO%SYN
MO%INT
MO%LWC

BO
Bl
B2
B3
B4
B5
B6
B7
B8

Link
Link
Link
Link
Link
Link
Link
Link
Link

is connected
is a server
is waiting for an incoming connect
is waiting for a connect to complete
has the end of, or entire, message to be read
has been aborted
has been disconnected normally
has an interrupt message available
has been previously connected

The various disconnect codes are listed in Appendix A.
If a
disconnect code does not apply to the current status of the link, the
value of the right half of AC3 will be zero.
Example
Assume that a source task obtains a JFN for a connection to a target
task and opens the JFN.
A successful return from the OPENF call does
not necessarily mean that a connect confirm message from the target
node or task has been received.
To ensure that a connection really
exists, you can use a coding sequence such as the following,
which
checks the link status every five seconds for one minute to determine
whether the link was established:
MOVE I
SETZ
CHKl: MOVE
MTOPR
ERJMP
TXNE
JRST
TXNE
JRST

TXNN
JRST
JRST

T2, . MORLS
T4,
Tl,NETJFN

iSET UP FUNCTION
iINITIALIZE COUNTER
iGET NETWORK JFN
iISSUE THE CALL
iJSYS ERROR
iNOW CONNECTED?

JSYSXX
T3,MO%CON
CNCTED
T3,MO%WCC
[CAlL T4,MXTRY
JRST ABORT
MOVEI Tl, *D5000
DISMS
AOJA T4, CHKl]
T3,MO%LWC
REJECT
ABORT

i YES
iNO, WAITING FOR CC?
i MXTRY=12
iGO RELEASE THE NETWORK JFN
iYES WAIT 5
iSECONDS
iCHECK LINK STATUS AGAIN
iNO, EVER CONNECTED
iNO, CI REJECTED
iGO RELEASE THE NETWORK JFN
iOK, CONTINUE

CNCTED:

3-13

ESTABLISHING A NETWORK CONNECTION
3.4.2

Reading the Host Name

The read host name function of MTOPR returns the
node at the other end of the logical link.

ASCII

name

the

The following arguments must be placed in the specified accumulators:
ACl:

The JFN of the logical link

AC2:

.MORHN (function code)

AC3:

A byte pointer to the location where the node name is
be stored

The monitor call returns an updated pointer in AC3 and the
stored as specified.

node

to
name

Example
A target task may wish to give special connection privileges to tasks
runnlng on a particular remote node. The following program segment
will retrieve the name of the node submitting the current connect
request and store it at location NODNAM:
GTHNAM: MOVE
MOVEI
HRROI
MTOPR
ERJMP

Tl,NETJFN
T2, . MORHN
T3,NODNAM
JSYSXX

iGET NETWORK JFN
iSET UP FUNCTION
iPOINTER TO NODE NAME
iISSUE THE CALL
iJSYS ERROR

NODNAM: BLOCK

;REMOTE NODE NAME

3-14

ESTABLISHING A NETWORK CONNECTION
3.4.3

Reading the Task Name

The read task name function of MTOPR returns the unique task name that
is associated with your end of the logical link.
If you had defaulted
the task name in the network file specification, the call returns the
monitor-supplied
task
name.
In
DECnet-20,
the
default or
monitor-supplied task name is actually a unique number.
The following arguments must be placed in the specified accumulators:
ACl:

The JFN of the logical link

AC2 :

.MORTN (function code)

AC3:

A byte pointer to the location where the task name is
be stored

The monitor call returns an updated pointer in AC3 and the
stored as specified.

task

to
name

Example
Target tasks, especially those that perform utility functions,
often
default their task names because they do not expect to be addressed
other than generically.
If a connected source task wishes to initiate
a second connection to your particular target task, the connected task
requires your unique task name.
You can first retrieve the monitor
assigned name using a program segment as follows:
GTDTNM: MOVE
MOVE I
HRROI
MTOPR
ERJMP

Tl,NETJFN
T2, . MORTN
T3,TSKNAM
JSYSXX

;GET NETWORK JFN
;SET UP FUNCTION
;POINTER TO TASK NAME
;ISSUE THE CALL
;JSYS ERROR

TSKNAM: BLOCK

;LOCAL TASK NAME

Once retrieved, the task name can be sent to the connected source task
via a data transfer or interrupt message (see Sections 4.1.1 ~nd
4.2.1) .

3-15

ESTABLISHING A NETWORK CONNECTION
3.4.4

Reading the User Name

The read user name function of MTOPR is valid only for target tasks.
It returns the source task's ASCII user identification supplied in the
connect initiate message.
The following arguments must be placed in the specified accumulators:
ACl:

The JFN of the logical link

AC2:

.MORUS (function code)

AC3:

A byte pointer to the
location
identification is to be stored

where

the

user

The monitor call returns with an updated pointer in AC3 and the user
identification stored as specified.
If no user identification was
supplied by the source task, AC3 continues to point to the beginning
of the string and a null is returned as the only character.
Example
A target task may include code to reject connect initiate requests
from all but a select group of userids. The following program segment
retrieves the userid of the current connect request:
GTUSID: MOVE
MOVEI
MOVE
MTOPR
ERJMP
CAMN
JRST

Tl,NETJFN
T2, .MORUS
T3,UIDPTR

iGET NETWORK JFN
iSET UP FUNCTION
iPOINTER TO USERID
iISSUE THE CALL
iJSYS ERROR
iCHECK IF ANY USERID
iNO - REJECT

JSYSXX
T3,UIDPTR
REJECT

check if userid is valid

USERID: BLOCK
UIDPTR: POINT

iSOURCE USERID
iUSERID POINTER

7,USERID

3-16

ESTABLISHING A NETWORK CONNECTION
3.4.5

Reading the Password

The read password function of MTOPR is valid only for target tasks.
It returns the source task's password supplied in the connect initiate
message.
The following arguments must be placed in the specified accumulators:
ACl:

The JFN of the logical link

AC2:

.MORPW (function code)

AC3:

A byte pointer to the location where the password is to
be stored. Passwords may be binary; therefore, the byte
pointer should accommodate 8-bit bytes unless you know
that the password is ASCII.

The monitor call returns with an updated pointer in AC3 and the source
task's password stored as specified. AC4 contains the number of bytes
in the string; a zero value indicates that no password was supplied
by the source task.
Example
In addition to screening a source task's userid, a target task may
require the submission of a password before confirming a connect
request. Whereas a userid is usually permanent, a password can be
changed periodically to ensure security.
The following program
segment retrieves the password submitted by a source task In its
connect request. The two tasks have agreed to use ASCII passwords:
GTPSWD: MOVE
MOVE I
MOVE
MTOPR
ERJMP
JUMPE

Tl,NETJFN
T2, . MORPW
T3,PWDPTR

;GET NETWORK JFN
;SET UP FUNCTION
;POINTER TO PASSWORD
;ISSUE THE CALL
;JSYS ERROR
;REJECT IF NO PASSWORD

JSYSXX
T4,REJECT

check for valid password

PWDPTR: POINT
PASSWD: BLOCK

7,PASSWD

;PASSWORD POINTER
;SOURCE PASSWORD

3-17

ESTABLISHING A NETWORK CONNECTION
3.4.6

Reading the Account String

The read account string function of MTOPR is valid only for target
tasks.
It returns the ASCII account string supplied by the source
task in the connect initiate message.
The following arguments must be placed in the specified accumulators:
ACl:

The JFN of the logical link

AC2:

. MORAC (function code)

AC3:

A byte pointer to the location where the
is to be stored

account

string

The monitor call returns with an updated pointer in AC3 and the source
task's account string stored as specified. If no account string was
supplied by the source task, AC3 continues to point to the beginning
of the string and a null is returned as the only character.
Example
A target task that includes a cost distribution of its services may
set up a chart of accounts and require each connecting task to supply
an account identification. with this information the target task can
control access, set budgets, check overruns, and provide billing data.
The following program segment retrieves the account string supplied in
a connect initiate message:
GTACCT: MOVE
MOVEI
MOVE
MTOPR
ERJMP
CAMN
JRST

Tl,NETJFN
T2,.MORAC
T3,ACCPTR

;GET NETWORK JFN
;SET UP FUNCTION
;POINTER TO ACCT NO.
;ISSUE THE CALL
;JSYS ERROR
;CHECK IF ANY ACCT NO.
;NO - REJECT

JSYSXX
T3,ACCPTR
REJECT

process the account number

ACCTNO: BLOCK
ACCPTR: POINT

;ACCOUNT STRING
;ACCT NO. POINTER

7,ACCTNO

3-18

ESTABLISHING A NETWORK CONNECTION
3.4.7

Reading the Optional Data

The read optional data function of MTOPR returns the
supplied in any of the connect or disconnect messages.

optional

data

The following arguments must be placed in the specified accumulators:
ACl:

The JFN of the logical link

AC2:

.MORDA (function code)

AC3:

A byte pointer to the location where the optional user
data is to be stored.
This field. may be binarYi
therefore, the byte pointer should accommodate 8-bit
bytes unless you know that the data is ASCII.

The monitor call returns with an updated pointer
in AC3 and the
optional data stored as specified. AC4 contains the number of bytes
in the data string;
a zero value indicates that no optional data was
supplied.
Example
The user level protocol, agreed to by two corresponding tasks, may
state that optional user data will always accompany a connect reject
message.
The following program segment will retrieve optional user
data in binary:
GTDATA: MOVE
MOVE I
MOVE
MTOPR
ERJMP
JUMPE

JSYSXX
T4,NODATA

iGET NETWORK JFN
iSET UP FUNCTION
iPOINTER TO USER DATA
;ISSUE THE CALL
iJSYS ERROR
iBRANCH IF NO DATA

DATPTR: POINT
USRDAT: BLOCK

8,USRDAT
4

iUSER DATA POINTER
iUSER DATA

Tl,NETJFN
T2,.MORDA
T3,DATPTR

3-19

ESTABLISHING A NETWORK CONNECTION
3.4.8

Reading the Object Type

The read object type function of MTOPR is valid only for target tasks.
It returns the object type that was used by the source task to address
this connection. The result indicates whether the local task was
addressed by its generic object type or its unique network task name.
The following arguments must be placed in the specified accumulators:
ACI:

The JFN of the logical link

AC2:

.MORCN (function code)

The monitor call returns with the object type in AC3. A zero object
type indicates that the taraet task was addressed by its unique
network task name; a nonzero value indicates that it was addressed by
its generic object type.
Example
Assume for example that the services of a target task depend on
whether a source task connects to it by generlc object type or by
unique task name. The following program segment retrieves the object
type used in the connect initiate message:
GTOBJT: MOVE
MOVEI
MTOPR
ERJMP
JUMPE
OBJCON:

;GET NETWORK JFN
;SET UP FUNCTION
;ISSUE THE CALL
;JSYS ERROR
;TEST TYPE OF CONNECT
;CONNECTED BY OBJECT TYPE

Tl,NETJFN
T2,.MORCN
JSYSXX
T3,TSKCON

TSKCON:

~CONNECTED

3-20

BY TASK NAME

ESTABLISHING A NETWORK CONNECTION
3.4.9

Reading the Object-Descriptor

The read object-descriptor function of MTOPR is valid only for
target
tasks.
It returns the unique identification of the source task.
This
identification is in the format of object-descriptor and the contents
depend on the DECnet implementation on the remote host.
In addition,
if the source task is running on a system that provides fo! group and
user codes, this information is also returned.
If the source task is
on a DECnet-20 host,
the data returned to the target task is
TASK-taskname.
The following arguments must be placed in the specified accumulators:
ACl:

The JFN of the logical link

AC2:

.MOROD (function code)

AC3:

A
byte
pointer
to
the
location
where
object-descriptor of the source task is to be stored

the

The monitor call returns with an updated pointer in AC3 and the
object-descriptor stored as specified.
In addition, if the source
host system uses group and user codes, AC4 contains the following:
AC4:

The group code in the left half and the user code in
right half

the

If the source host system does not provide for group or user codes, or
if none was provided in the connect initiate message, AC4 contains
zeros.
Example
A target task can retrieve the unique identification
task with the following program segment:
GTOBJD: MOVE
MOVEI
HRROI
MTOPR
ERJMP
JUMPN

OBJDES: BLOCK
GRPCOD: BLOCK
USRCOD: BLOCK

Tl,NETJFN
T2, . MOROD
T3,OBJDES

the

JSYSXX
T4,[HRRZM T4,USRCOD
HLRZM T4,GRPCOD
JRST .+1]

iGET NETWORK JFN
iSET UP FUNCTION
iPOINTER TO OBJ. DESC.
iISSUE THE CALL
iJSYS ERROR
iSAVE USER CODE
iSAVE GROUP CODE
iRETURN

5
1
1

iOBJECT-DESCRIPTOR
iGROUP CODE
iUSER CODE

3-21

source

ESTABLISHING A NETWORK CONNECTION
3.4.10

Reading the Segment Size

The read segment size function of MTOPF returns the maximum segment
size that can be used over this link. The local task can use this
value to determine the optimum size of data records being transmitted
over the link.
The following arguments must be placed in the specified accumulators:
AC1:

The JFN of the logical link

AC2:

.MORSS (function code)

The maximum segment size, in bytes, is returned in AC3. If the link
has not been established, the monitor call takes the error return.
Example
A task can retrieve this value with a
following:

program

segment

such

GTSGSZ: MOVE
MOVEI
MTOPR
ERJMP
MOVEM

Tl,NETJFN
T2,.MORSS
JYSXX
T3,SEGSIZ

iGET NETWORK JFN
;SET UP FUNCTION
iISSUE THE CALL
iJSYS ERROR
iSTOFE SEGMENT SIZE

SEGSIZ: BLOCK

;MAX SEGMENT SIZE

3-22

the

ESTABLISHING A NETWORK CONNECTION
3.5

ACCEPTING OR REJECTING A CONNECTION

When the target task has decided to accept or reject the connection,
it must inform the network software with a monitor call or by
transmitting data.
Two MTOPR monitor call functions are provided:
.MOCC to accept a connection and return data, and .MOCLZ to reject the
connection and return data along with a specific reject reason.
If no
data or specific reject reason is to be returned, the target task can
accept or reject the connection implicitly, without using either of
the
two MTOPR functions.
This is explained in the following
subsections.

3.5.1

Accepting the Connection

Connections can be accepted either explicitly or implicitly.
You can accept a connection explicitly by sending a connect confirm
message to the source task with the .MOCC function of MTOPR. This
method allows you to include up to 16 bytes of optional data in the
connect confirm message.
The following arguments must be placed in the specified accumulators:
ACl:

The JFN of the logical link

AC2:

.MOCC (function code)

AC3:

A byte pointer to any data to be returned

AC4:

The count of bytes in the dat q string. A zero indicates
no data.
The maximum amount of data is 16 bytes.

You can accept a
following:

connection

implicitly

one

the

•

Issuing an output monitor call such as BOUT, SOUT, or SOUTR to
the network JFN

•

Issuing an input monitor call such as BIN, SIN, or SINR to the
network JFN

•

Placing yourself in an input or output wait state

Performing one of these operations does not
optional data.

3.5.2

performing

allow

you

send

any

Rejecting the Connection

Connections can be rejected either explicitly or implicitly.
You can reject a connection explicitly by sending a connect reject
message to the source task with the .MOCLZ function of MTOPR.
This
method allows you to include a reject code as well as up to 16 bytes
of optional data in the connect reject message.

3-23

ESTABLISHING A NETWORK CONNECTION

The following arguments must be placed in the specified

accumulator~:

ACl:

The JFN of the logical link

AC2:

A reject code in the left half and .MOCLZ
half

AC3:

A byte pointer to any data to be returned

AC4:

The count of bytes in the data string. A zero indicates
no data. The maximum amount of data is 16 bytes.

the

right

The reject code in AC2 is a 2-byte, NSP-defined decimal number
indicating the reason that a target task is rejecting a connection. A
list of these codes, applicable to both user and system tasks, appears
in Appendix A.
You can reject a connection implicitly by closing the JFN of the
logical link before accepting the connection either explicitly or
implicitly. To close the JFN, use the CLOSF monitor call.
When the
CLOSF call is used, the source task will see a reject code of 38 (user
aborted). You must reopen the JFN to receive subsequent connect
initiate messages.

3.5.3

Examples

The following program segment will send a connect confirm
the source task that requested the connection:
ACCEPT: MOVE
MOVE I
SETZ
MTOPR
ERJMP

message

;GET THE NETWORK JFN
iCODE TO ACCEPT
iFLAG NO OPT. DATA
iISSUE THE CALL
iJSYS ERROR

Tl,NETJFN
T2,.MOCC
T4,
JSYSXX

To include up to 16 bytes of ASCII user data with the connect
message, modify the above segment as follows:
iGET THE NETWORK JFN
iCODE TO ACCEPT
iPOINTER TO USER DATA
iUSER DATA BYTE COUNT
iISSUE THE CALL
iJSYS ERROR

ACCEPT: MOVE
MOVEI
MOVE
MOVEI
MTOPR
ERJr.1P

Tl,NETJFN
T2,.MOCC
T3,tPOINT 7,MSGC]
T4,"'D16

MSGC:

/OPEN UNTIL 10 PM/

ASCIZ

JSYSXX

3-24

confirm

ESTABLISHING A NETWORK CONNECTION
The following program segments will send a connect reject message to
the source task that requested the connection.
The reason for the
rejection is coded as 34 (access not permitted). With no user data,
the instruction sequence is:
REJECT: MOVE
MOVE I
HRLI
SETZ
MTOPR
ERJMP

Tl,NETJFN
T2, .MOCLZ
T2,.DCX34
T4,

iGET THE NETWORK JFN

iCODE TO REJECT
iADD REJECT CODE 34
iFLAG NO USER DATA
iISSUE THE CALL
iJSYS ERROR

JSYSXX

Because reject code 34 is somewhat general, you may want to include
ASCII user data to clarify the rejection.
You can modify the above
sequence as follows:
REJECT: MOVE
MOVE I
HRLI
MOVEI
MOVE
MTOPR
ERJMP

Tl,NETJFN
T2, .MOCLZ
T2, . DCX34
T3,[POINT 7,XPWD]
T4,"D14

XPWD:

/WRONG PASSWORD/

ASCIZ

;GET THE NETWORK JFN
iCODE TO REJECT
iADD REJECT CODE 34
iPOINTER TO REJECT MSG
;REJECT MSG BYTE COUNT
iISSUE THE CALL
iJSYS ERROR

JSYSXX

For longer program segments that include sequences similar to those in
this chapter, see Figures 5-1 and 5-2.

3-25

CHAPTER 4
TRANSFERRING INFORMATION OVER THE NETWORK

Once a network connection has been established, the task at either end
of the logical link can send information to the task at the other end.
DECnet-20 provides for two types of information exchange:
•

Data transfers

•

Interrupt messages

Data transfers are primarily used by network tasks to move large
blocks of data.
Interrupt messages are used by network tasks to
exchange small amounts (16 bytes or less) of high priority data that
are not sequentially related to the main data flow.
Data transfers and interrupt messages are discussed in
of this chapter.

4.1

the

remainder

TRANSFERRING DATA

Data transfers over a logical link involve the segmentation and
restructuring of data at both the logical and physical link levels.
The network software accepts data from the user program,
segments it
to conform to the maximum segment size allowable on that logical link,
precedes each segment with a header, and passes these segments to the
physical link management layer.
This layer segments the data to
conform to the maximum segment size allowable on the physical link and
precedes each segment with a header to form a packet.
These packets
are then sent over the physical line to the destination node.
At the
destination node the reverse procedure takes place: headers are
stripped and segments re-assembled.
Data transfers on a logical link can take one of two forms:
logical
messages or continuous byte streams.
The logical message format
provides for the transmission of information in discrete logical units
called records, or messages.
Data transmitted in this format can be
retrieved by the receiving task on a message-by-message basis.
The continuous byte stream format does not have any end-of-message
indicators.
Data transmitted in this format is presented to the
receiving task as a continuous stream of data.
The receiving task
must reconstruct the original messages via some prearranged protocol
agreed to by both user tasks.

4-1

TRANSFERRING INFORMATION OVER THE NETWORK
The logical message format allows for simpler user retrieval routines
at the expense of not taking full advantage of the monitor's buffering
capabilities.
The continuous byte stream format
permits
more
efficient use of resources but requires the user to write routines to
reconstruct the original messages.

4.1.1

Sending Data

You can send data to another task with the SOUT, BOUT, or SOUTR
monitor call.
In general, use SOUTR to send data in the logical
message format and SOUT and BOUT to send data as ~ continuous byte
stream.
The exclusive use of SOUTR usually implies that both tasks have agreed
to exchange information in the form of messages with some stated
maximum length. Each use of the SOUTR monitor call results in the
transmission of a logical message terminated with an end-of-message
indicator. A DECnet-20 receiving task can then retrieve the message
with the SINR (read record) monitor call (see Section 4.l.2).
The exclusive use of SOUT or BOUT usually implies that both tasks have
agreed to exchange information in the form of a continuous byte
stream. You can repeatedly fill your data buffer and execute the SOUT
monitor call.
Each SOUT transmits a buffer'S worth of data to the
destination node where it is presented to the receiving task.
A
DECnet-20 target task can then use the SIN and BIN (read data) monitor
calls (see Section 4.1.2) to retrieve as many bytes at a time as it
can handle in its data buffer. Normally, you would include a count
byte at the beginning of each logical data group to provide the
receiving task with a means to reconstruct the logical data.
You can also intermix the use of SOUT and SOUTR when you send data to
a receiving task. For example, assume that the program you write has
a data buffer limited to 300 bytes. The receiving task has a 1000
byte buffer and requires that data be sent to it in logical message
format. You can send an 800 byte logical message by sending two SOUTs
for 300 bytes each followed by a SOUTR for 200 bytes. The receiving
task can then retrieve the entire message by using a SINR for 800
bytes or more.

4.1.2

Receiving Data

You can retrieve data from the network using the SINR, SIN, or BIN
monitor calls. In general, use SINR to retrieve logical messages and
SIN to retrieve data from a continuous byte stream.
The exclusive use of SINR usually implies that tasks have agreed to
exchange information in the form of messages with some stated maximum
length. Each SINR monitor call results in the retrieval of one
logical message.
The sending task must have sent the message using
the SOUTR monitor call (see Section 4.l.l).

4-2

TRANSFERRING INFORMATION OVER THE NETWORK
The exclusive use of SIN usually implies that tasks have agreed
to
exchange information in the form of a continuous byte stream.
You can
retrieve as many bytes at a time as your data buffer can handle.
If
your data buffer is 300 bytes in length; you can execute a SIN for 300
bytes and fill the buffer with data.
The manner
in which you then
reconstruct the original logical messages depends on the user-level
protocol agreed to by both tasks.
For example,
if each message is
preceded by a count byte, you can use the BIN monitor call to read the
first byte and obtain the number of bytes in the message and then
issue a
SIN for
that number of bytes to retrieve the message.
A
subsequent BIN would read the number of bytes in the next message.
You can intermix the use of SIN and SINR when you wish to retrieve
data from the network.
However, a few precautions are in order where
multiple messages are concerned.
A SIN monitor call does not
recognize an end-of-message
(EOM)
indicator
if one is present.
Therefore, if you issue a SIN for
300 bytes and the link buffer
contained the last 200 bytes of a logical message (sent with a SOUTR),
you will retrieve those 200 bytes plus the first 100 bytes of the next
message.
The SIBE monitor call is useful here because it will return
the number of bytes of the current message that are available in the
link buffer
(merely checking for an EOM is not sufficient).
You can
then issue a SIN for that number of bytes and not encroach on the
succeeding message.
As the coding sample below illustrates, it is important to test the
condition of the input buffer (using the SIBE JSYS) before attempting
to read data.
An interrupt can occur on the data channel when data is
available,
but can also occur because of a disconnect event.
An
interrupt on a data channel indicates one of four states.
1.

Data available, disconnect event (disconnect initiate)

Data available, no disconnect event ("normal" case)

No data, disconnect event (disconnect initiate)

No data, no disconnect event (spurious interrupt)

All four states must be handled in the user code, with the aid of
SIBE JSYS and .MORLS function of the MTOPF JSYS.
PAUSE:

WAIT

iWAIT FOR NETWORK INTERRUPT

READ INCOMING DATA
THIS ROUTINE IS EXECUTED WHEN AN INTERRUPT OCCURS
ON THE PSI CHANNEL INDICATING THAT DATA MAY BE
AVAILABLE
NOTE THAT THE SIBE MONITOR CALL IS USED TO CHECK THAT
DATA ACTUALLY EXISTS FOR THE USER TASK.
THIS IS A
RECOMMENDED PROCEDURE TO FOLLOW TO GUARANTEE THAT
DATA IS AVAILABLE FOR THE PROCESS.

4-3

the

TRANSFERRING INFORMATION OVER THE NETWORK
;

GOTSOM: MOVE Tl,NETJFN
SIBE
JRST READ
MOVEI T2,.MORLS
MTOPR
ERJMP NOGOOD
TXNN T3,MO%CON
JRST NOCNCT
DEBRK

;GET NETWORK JFN
;INPUT BUFFER EMPTY?
;NO, GO TO READ ROUTINE
;YES, CHECK LINK STATUS
;ISSUE THE CALL
;UNLIKELY ERROR HERE
;STILL CONNECTED?
;NO, CONNECTION IS GONE
;YES, HAVE READ ALL AVAILABLE
;DATA. WAIT FOR MORE.
THIS ROUTINE IS EXECUTED WHEN THE INPUT BUFFER FOR
THE LOGICAL LINK CONTAINS DATA. THE NUMBER OF BYTES
IN THE INPUT BUFFER WAS RETURNED IN AC2 BY THE SIBE
MONITOR CALL.

;

READ:

MOVNI T3, 0 (T2)
MOVE T4,T3
MOVE T2,INPTR
SIN

;GET NEG OF COUNT
;SAVE COUNT FOR ECHO
;WHERE TO PUT DATA
;GET THE DATA

NOW SEND IT BACK DOWN THE NETWORK LINE
MOVE T2,INPTR
MOVE T3,T4
SOUTR
JRST GOTSOM

;POINT TO DATA JUST READ
;RECOVERY BYTE COUNT
;WRITE A MESSAGE TO LINK
;PROCESS MORE INPUT

Should the SIN or SOUT fail, you should read the
closing the link.

4.1.3

link

status

before

Summary of Procedures - Source and Target Tasks

The following summarizes procedures for target and source tasks:
Target Task
STEP 1:

Issue a GTJFN on a SRV:

file specification.

STEP 2:

Issue an OPENF to become available on the network.

STEP 3:

Set up the software interrupt system with a SIR, AIC, EIR,
and MTOPR (function . MOACN) , in that order.
You must
execute the MTOPR JSYS last, or interrupts may be lost.

STEP 4:

Issue the WAIT JSYS to wait for an interrupt.

STEP 5:

Process interrupts on the connect channel.

4-4

TRANSFERRING INFORMATION OVER THE NETWORK
STEP 6:

Process interrupts on the data channel when they occur.
Check with SIBE to see if input is waiting and read all of
the input.
Always do another SIBE before the DEBRK since data arriving
while you are processing an interrupt will not generate
another interrupt.
If no input is waiting, check to see if the link is still
connected
(.MORLS function of MTOPR, check for MO%CON).
If
the link is connected, you have received a
spurious
interrupt and should:
Go to STEP 6
If the link is not connected, you have received a DISCONNECT
INITIATE
Go to STEP 7

STEP 7:

The link is disconnected.
Issue a CLOSF on
either halt the program or return to STEP 1.

the

JFN,

and

Source Task
STEP 1:

Issue a GTJFN on a DCN:

file specification.

STEP 2:

Issue an OPENF to establish the link.
The OPENF sends a
connect initiate;
success of the OPENF does not mean the
link is established.

STEP 3:

Use the .MORLS function of MTOPR to read
then wait for connect confirm or reject.

STEP 4:

Transfer data with SOUT or SOUTR until done.

STEP 5:

Use CLOSF to break the link, setting CZ%ABT
clean-up routines if necessary.

link

and

status

and

performing

4.1.3.1 Special SINR/SOUTR Considerations - If you have enabled a
channel for data interrupts, a SINR or SOUTR will block forever if it
is interrupted and a disconnect initiate has arrived.
You cannot
simply dismiss the interrupt with DEBRK, because the SINR or SOUTR
will hang rather than fail.
You must force the SINR or SOUTR to complete by (1) setting the user
mode bit
(bit 5) of the return PC word, and/or (2) modifying the PC
word's return address.
You can then safely dismiss the interrupt.
A user program can determine whether it was interrupted out of user
code or monitor code by examining bit 5 of the PC word.
Bit 5 "on"
indicates user code;
bit 5 "off"
indicates monitor code.
(The
address contained in the PC word is always in user code, however.)
If you modify the PC word, you should also set a flag to indicate that
an abnormal branch has occurred.
It may also be useful to check T3
for the count of bytes remaining after the SOUTR.

4-5

TRANSFERRING INFORMATION OVER THE NETWORK
4.2

TRANSFERRING INTERRUPT MESSAGES

Although data transfers over a logical link are guaranteed to be
received at the other end in the same order in which they were sent,
it is occasionally necessary to bypass the normal flow of data and to
send data that is to be delivered immediately. Events such as errors
or status changes in one task or the other are situations that justify
bypassing the normal data flow.
The logical link management level, NSP, allows for the transmission
and
reception of short high-priority messages called interrupt
messages.
An interrupt message
is
sent
and
accounted
for
independently of any buffered data messages anc its delivery is
guaranteed to be prompt. Interrupt messages are limited to 16 bytes
in length and therefore are not very useful for exchanging data. They
are most effectively used as event indicators and usually require the
subsequent exchange of data by the two processes owning the logical
link. In this respect, they closely resemble software interrupts.
Consequently, DECnet-20 provides the network task with a monitor call
function to enable an interrupt channel for the receipt of an
interrupt message.
(See Section 3.3.)

4.2.1

Sending Interrupt Messages

A network task communicating over a logical link can initiate an
interrupt message at any time.
Whether DECnet-20 will send the
message over the link depends on conditions at the other end.' If the
task at the other end has not acknowledged a previous interrupt
message, the sending task is notified by an error message.
If the
other task is not enabled for interrupt messages, the link will not
accept the message.
To send an interrupt message, use the .MOSIM
monitor call.

function

the

MTOPR

The calling sequence expects the following:
ACl:

The JFN of the logical link

AC2 :

.MOSIM (function code)

AC3:

A byte pointer to the message

AC4:

The count of bytes in the interrupt message.
' c bytes.
message length is .LU

The maximum

Example
The following program segment can be used to send an interrupt message
to another task:
SNDMSG: MOVE
MOVEI
HRROI
MOVEl
MTOPR
ERJMP

Tl,NETJFN
T2, . MOSIM
T3,MSG
T4, . . D14

MSG:

/CLOSING AT 6PM/

ASCIZ

;GET NETWORK JFN
iSET UP FUNCTION
iPOlNTER TO MESSAGE
iBYTE COUNT
iISSUE THE CALL
iJSYS ERROR

JSYSXX

4-6

TRANSFERRING INFORMATION OVER THE NETWORK
4.2.2

Receiving Interrupt Messages

If the protocol used by network tasks includes interrupt messages,
each task should provide a way to be notified asynchronously when
messages arrive.
The .MOACN function of the MTOPR monitor call allows
a network task to enable specific channels for software interrupts
(see Section 3.3). One of these interrupts signals the arrival of an
interrupt message.
When a remote task sends your task an interrupt message,
the
appropriate channel presents a software interrupt to your task.
To
read the interrupt message, use the
.MORIM function of the MTOPR
monitor call.
The calling sequence expects the following:
ACl:

The JFN of the logical link

AC2:

.MORIM (function code)

AC3:

A byte pointer to the receiving
message length is 16 bytes.

buffer.

The

maximum

The call returns with an updated pointer in AC3, the message stored in
the buffer, and the count of bytes received in AC4.
Because interrupt messages are used to signal
important asynchronous
events,
it is recommended that a task receiving an interrupt message
read the interrupt message promptly.
Furthermore, DECnet-20 does not
acknowledge an interrupt message until the task reads it.
This means
that each network task is limited to one outstanding interrupt message
and until that message is read, no others will be accepted.
Example
The following program segment retrieves an interrupt message:
INTRPT: MOVE
MOVEI
MOVE
MTOPR
ERJMP

Tl,NETJFN
T2,.MORIM
T3,[POINT 8,MSGBUF]

MSGBUF: BLOCK

JSYSXX

;GET NETWORK JFN
iSET UP FUNCTION
;POINTER TO MESSAGE
;ISSUE THE CALL
iJSYS ERROR

;MESSAGE BUFFER

For longer program segments that include sequences similar to those in
this chapter, see Figures 5-1 and 5-2.

4-7

CHAPTER 5
CLOSING A NETWORK CONNECTION

Either of the two connected tasks can close a network connection.
A
connection can be closed normally, thereby preserving the integrity of
any data in transit; or, a connection can be aborted without regard
to any undelivered data.

5.1

CLOSING A CONNECTION NORMALLY

A normal close is usually accomplished with the CLOSF monitor call
specifying a network JFN in ACI.
The CZ%ABT bit in ACI must be off.
All buffered data that is in transit at the time is delivered
(unless
the remote task executes an abort before the CLOSF has completed) .
The network JFN is then closed.
An MTOPR call with function code .MOCLZ also disconnects the logical
link and completes the delivery of all buffered data; however, it
does not close the JFN. This method of closing a link is only used if
it is necessary to send user data (up to 16 bytes) to the remote task.
In order to send user data and also close the JFN, the .MOCLZ function
must be followed by a CLOSF call.
The calling sequence for the MTOPR call is:
ACl:

The JFN of the logical link

AC2:

0 in the left half and .MOCLZ in the right half

AC3:

A byte pointer to the user data.

AC4:

The count of bytes in the user data.
bytes.

If the byte
over 8, bytes are truncated to eight bits.
The maximum

size

The network does not have explicit protocol for a normal close.
That
is, no one specific network control message is available to both
disconnect a logical link and also automatically have all data
correctly delivered. When you use the MTOPR or CLOSF monitor call to
close a network connection, you are actually turning over control of
the link to the local NSP.
It is the job of the local NSP to ensure
that all outstanding data packets have been properly acknowledged
before sending the disconnect message to the remote NSP.
The remote NSP, in turn, notifies the remote
protocol in effect at the remote node.

5-1

task

according

the

CLOSING A NETWORK CONNECTION
If the remote node is a DECnet-20 node, the NSP task receiving the
disconnect message sets the MO%SYN bit in the remote task's link
status to reflect that the link has been closed normally.
If the
remote task is not in the process of reading data, it is issued a data
interrupt. If the remote task issues a SIBE call, it will be informed
that no bytes are available.
If the remote task attempts to read
data, it will receive an end-of-file indication. In any case, reading
the link status with the .MORLS function of MTOPR will indicate that
the MO%SYN bit has been set.
Example
To close a logical link after delivering all the data
transit, use a program segment such as the following:
CLOSE: MOVE
CLOSF
ERJMP

Tl,NETJFN

currently

iGET NETWORK JFN
iISSUE THE CALL
iJSYS ERROR

JSYSXX

To close a logical link as above and also include ASCII user data for
the target task, a program segment such as the following can be used:
CLOSED: MOVE
MOVEI
MOVE
MOVEr
MTOPR
ERJMP
CLOSF
ERJMP

Tl,NETJFN
T2,.MOCLZ
T3,[POINT 7,MSG]
T4,"D14

JSYSXX

iGET NETWORK JFN
iSET UP FUNCTION
iPOINTER TO MESSAGE
iBYTE COUNT
iISSUE THE CALL
iJSYS ERROR
iCLOSE THE JFN
iJSYS ERROR

MSG:

IBE BACK AT 6PMI

iUSER DATA

5.2

ASCIZ

JSYSXX

ABORTING A CONNECTION

You can abort a logical link with the CLOSF monitor call by specifying
both the CZ%ABT bit and the network JFN in ACI. All buffered data in
transit is discarded and the network JFN is closed.
This operation
can result in the loss of data and should only be used in a fatal
error condition.
The .MOCLZ function of MTOPR, used to normally close a logical link in
Section 5.1, can be used to abort a logical link if you insert a
nonzero code in the left half of AC2. This method of aborting a link
should only be used if it is necessary to send the remote task a
specific reason code for the abort, up to 16 bytes of user data, or
both. The .MOCLZ function with the abort option discards all buffered
data in transit and closes the linki however, it does not close the
network JFN.
To close the JFN, the MTOPR call must be followed by a
CLOSF call with the CZ%ABT bit set in ACI.

5-2

CLOSING A NETWORK CONNECTION

The calling sequence for the MTOPR call is:
ACl:

The JFN of the logical link

AC2:

A reason code, nn, in the left half
right half

AC3:

A byte pointer to the user data

AC4:

The count of bytes in the user data.
bytes

The reason code (nn) in the left half of AC2 is
codes listed in Appendix A.

and

.MOCLZ

the

The maximum

one. of

the

nonzero

With either the CLOSF or MTOPR monitor call, the local NSP sends a
disconnect message to the remote NSP which, in turn, notifies the
remote task according to some established protocol.
If the remote node is a DECnet-20 node, the NSP task receiving the
disconnect message sets the MO%ABT bit in the remote task's link
status to reflect that the link has been aborted.
If the remote task
is not in the process of reading data, it is issued a data interrupt.
Any attempts to read data will result in an I/O error.
Reading the
link status with the .MORLS function of MTOPR will indicate that the
MO%ABT bit has been set and the right half of AC3 will contain a
disconnect code if one was given.

Example
To abort a logical link immediately without completing the delivery of
any data in transit, use a program segment such as the following:
ABORT: MOVE
TLO
CLOSF
ERJMP

iGET NETWORK JFN
iSET ABORT BIT
iISSUE THE CALL
iJSYS ERROR

Tl,NETJFN
Tl, (CZ%ABT)
JSYSXX

To abort a logical link as above and also include a specific reason
code and user data, use a program segment such as the following:
ABORTD: MOVE
MOVE I
HRLI
MOVE
MOVE I
MTOPR
ERJMP
TLO
CLOSF
ERJMP

Tl,NETJFN
T2, . MOCLZ
T2, . DCX9
T3, [POINT 7, MSGX]
T4,"'D16

JSYSXX

iGET NETWORK JFN
iSET UP FUNCTION
iCODE FOR USER ABORT
iPOINTER TO MESSAGE
iBYTE COUNT
iISSUE THE CALL
iJSYS ERROR
iSET ABORT BIT
iCLOSE THE JFN
iJSYS ERROR

MSGX:

/RESTART XMISSION/

iUSER DATA

ASCIZ

JSYSXX
Tl, (CZ%ABT)

5-3

CLOSING A NETWORK CONNECTION
If the target task has the MO%ABT bit set in the link status word, the
target task must use CZ%ABT or the CLOSF will fail. An example of a
program segment using CZ%ABT follows:
MOVE
CLOSP
ERJMP

5.3

Tl,NETJFN
MOVE Tl,NETJFN
TLO
Tl,(CZ%ABT)
CLOSF
JRST JSYSXX
JRST .+1]

ilf fail, then
iuse CZ%ABT

SOURCE AND TARGET TASK CODING EXAMPLES

Figures 5-1 and 5-2 are examples
programs.

5-4

coding

for

source

and

target

CLOSING A NETWORK CONNECTION
Get JFN for Network Connection
MOVX
HRROI
GTJFN
ERJMP
MOVEM

Tl,GJ%SHT
T2,[ASCIZ/DCN:NODEA-TASK-TARGET.SOURCE/]
NOGOOD
Tl,OURJFN

iFailed, Probably out of resources
iSuccessful, save our JFN

;

iOPENF to create the Logical Link
MOVX

T2,<FLD(~D7,OF%BSZ)+OF%WR+OF%RD>

OPENF
ERJMP

NOGOOD

iOpen for read and
iwrite

iFailed

Wait for network connect to succeed or fail
i

MOVX
Tl,~DlOOO
iWait before checking status
DISMS
MOVE
Tl,OURJFN
iCheck line status
MOVX
T2,.MORLS
MTOPR
ERJMP NOGOOD
TXNE
T3,MO%CON
;Connected?
JRST
HELLO
iYes, proceed to HELLO
TXNE
T3,MO%WCC
iNo, are we waiting still?
JRST
CHKST
iYes, delay some more
If we get here, target process or network rejected cannot attempt
JRST
NOGOOD
iWe lose

CHKST:

Send data to Target task
i

HELLO:

MOVE
HRROI

Tl,OURJFN
T2, [ASCIZ/Hello Target!

SETZM
SOUTR
ERJMP

/]
NOGOOD

iNetwork went away

CLOSF to disconnect logical link
MOVE
CLOSF
ERJMP

Tl,OURJFN
MOVE Tl,OURJFN
Tl,CZ%ABT
TXO
CLOSF
JFCL
JRST .+1]

iFailed, use CZ%ABT
; to close link
iDon't Care if it fails

HALTF

iStop source task

iInclude what you wish to do on failure of logical link
NOGOOD
OURJFN: BLOCK

1
Figure 5-1

Example of Source Task Coding

5-5

CLOSING A NETWORK CONNECTION

Get JFN for Network Connection
START:

MOVX
HRROI
GTJFN
ERJMP
MOVEM

TI,GJ%SHT
T2,[ASCIZ/SRV: .TARGET/]
NOGOOD
TI,OURJFN

i Fa il ed, Probably out of resources
iSuccessful, save our JFN

Start setting up interrupt system for network JFN
MOVX
MOVE
SIR
MOVX
AIC
EIR

TI,.FHSLF
iSet up interrupt system first
T2, [LEVTAB"CHNTAB]
iSet interrupt system tables
T2;3Bl
iEnable channels 0 and 1
iActivate interrupt channels
iEnable for interrupts

OPENF to make us available to the network
MOVX

T2,<FLD(A D7 ,OF%BSZ)+OF%WR+OF%WR+OF%RD>

OPENF
ERJMP

NOGOOD

iOpen for read and
iwrite

iFailed

Finish setting up interrupt system for network JFN

PAUSE:

MOVE
MOVEI
MOVX
MTOPR

TI,OURJFN
iSet up Connect and Data Interrupts
T2, . MOACN
T3,<FLD(O,MO%CDN)+FLD(I,MO%DAV)+FLD(.MONCI,MO%INA)>

WAIT

iWait for Interrupts

LEVTAB: PC

iLevel I PC address

o
o
CHNTAB: 1"HELLO
I, , READIT
REPEAT AD34 ,<O>

iOn connect go to HELLO
iOn data interrupt try to read it
iZero fill rest of table

PC:

iLevel I PC save location

BLOCK

;
i

Process interrupt on Connect channel

HELLO:

MOVE
MOVX
SETZB
MTOPR
ERJMP
DEBRK

TI,OURJFN

iAlways accept the connection

T2, .MOCC

T3,T4

iNo optional data

NOGOOD

iSomething blew up
iDone, wait some more

Figure 5-2

Example of Target Task Coding

5-6

CLOSING A NETWORK CONNECTION

Process interrupt on Data channel
i

READIT: MOVE
SIBE
JRST
MOVX
MTOPR
ERJMP
TXNN
JRST
DEBRK

Tl,OURJFN

iAny data?

READ
T2,.MORLS

iYes, Process it
iNO, See if link still connected

NOGOOD
T3,MO%CON
DISCON

;An error here is not likely, but ...
iLink Still Connected?
;No, process link down
iYes, then wait for another interrupt

READ:

T2,BUFFER
T3,"'DIOOO

iPut data into buffer
i-Size of buffer
iRead the data
iShouldn't happen
iStore a zero byte

HRROI
MOVNI
SINR
ERJMP
SETZM
IDPB
HRROI
PSOUT
JRST

NOGOOD
Tl
Tl,T2
Tl,BUFFER
READIT

iOutput the message
iProcess any more input

Process disconnect on link
i

DISCON: MOVE
CLOSF
ERJMP

JRST

Tl,OURJFN

iClose our JFN

MOVE Tl,OURJFN
iTry CLOSF with CZ%ABT
TXO
Tl,CZ%ABT
CLOSF
JFCL
iDon't care if it fails
JRST .+1]
START
iStart over

Include what you wish to do on failure
NOGOOD:
i

BUFFER: BLOCK
OURJFN: BLOCK

"'DIOOO
1

Figure 5-2 (Cont.)

iBuffer save location
;OURJFN save location

Example of Target Task Coding

5-7

PART III
TERMINAL USER'S GUIDE

CHAPTER 6
TOPS-20 DECnet-20 EXEC COMMANDS

As a nonprivileged terminal user, you communicate with the system by
using the TOPS-20 Command Language (EXEC).
This chapter assumes that
you are familiar with the most frequently used TOPS-20 commands
(both
for
timesharing and batch).
TOPS-20 commands that relate directly to
DECnet functions are described in this chapter.
NOTE
If you have had little experience with
the TOPS-20 Command Language, refer to
the list of suggested documents in the
Preface of this manual.
As an absolute
minimum, you should read the following
manuals before continuing with this and
the following chapter:
TOPS-20 User's Guide
TOPS-20 Commands Reference Manual
TOPS-IO/TOPS-20
Batch
Reference
Manual
You should know the name of your local node and the names of all
remote nodes with which you will communicate.
If remote nodes require
a user name, password, or account, you will need to know the specific
way in which this information must be formatted.
Your installation
should have the basic user's manuals for all systems accessible to you
via DECnet.
If you need help, see your system manager or operator.
The TOPS-20 operating system in
allows you to do the following:

conjunction
using

the

with

DECnet

TOPS-20

software

•

List accessible DECnet nodes
DECNET command.

INFORMATION

•

List the destination for your queued output using the
INFORMATION JOB-STATUS command.

•

Direct queued output to an accessible DN200 or IBM-type remote
station using the TOPS-20 SET LOCATION command or the TOPS-20
/DESTINATION-NODE: node switch for queue-class commands.

TOPS-20

To delete files from an accessible DECnet node and to transfer files
to or from an accessible DECnet node, use the Network File Transfer
(NFT) program.
(The NFT program is described in Chapter 7, Network
File Transfer.)

6-1

TOPS-20 DECnet-20 EXEC COMMANDS
6.1

INFORMATION COMMAND

The INFORMATION command has two options that give DECnet
INFORMATION DECNET and INFORMATION JOB-STATUS.

6.1.1

information:

Information DECnet

INFORMATION DECNET lists the accessible DECnet nodes.
The format of the INFORMATION DECNET command is as follows:
@INFORMATION (ABOUT) DECNET NODES
Example:
~

@infORMATION (ABOUT) decnet~
Local DECNET node: KL2137
Accessible DECNET nodes are:
D2102A

DN200

KLI031

KL2102

(Note that NODES is assumed as the default if omitted.)

6.1.2

Information Job-Status

INFORMATION JOB-STATUS lists the destination for your queued output if
you have used the SET LOCATION command to specify a DN200 or IBM-type
remote station as that destination.
The format of the INFORMATION JOB-STATUS command is as follows:
@INFORMATION (ABOUT) JOB-STATUS
Example:
@)

@INFORMATION (ABOUT) JOB-STATUS~
Job 41, User SKOGLUND, MISC:<SKOGLUND), Account 341, TTY225
Located at DN200
@

6.2

SET LOCATION COMMAND

The SET LOCATION command instructs the TOPS-20 operating system to
regard
the specified DN200 or IBM-type remote station as the
destination for your queued output.
(When you log in, the destination
for your queued output is your local host.) Note that print requests
for
a DN200 or IBM-type remote station must conform
to
the
capabilities of that remote station.
The format of the SET LOCATION command is:
@SET LOCATION (TO) node::

6-2

TOPS-20 DECnet-20 EXEC COMMANDS
where:
node: :

The name of the DN200 or IBM-type remote station that
becomes the destination for your queued output.
If no
node name is entered, the node name defaults to the
name of your local host.

Example:
@set location dn200::~
@print test.txt~
[Job TEST Queued, Request-ID 550, Limit 27]
@information (ABOUT) output-requests
Printer Queue:
Job Name
Req
Limit
User
TESTI
87
5
HORAN
On Unit:0/Dest:DN200
Started at 16:24:43, printed 0 of 5 pages
The INFO OUTPUT command
LOCATION command.

above

illustrates

the

effect

the

SET

If you give the INFORMATION JOB-STATUS command immediately following
the SET LOCATION command, you can check to be sure your logical
location has changed before you continue:

@set locATION (TO) dn200::~
@i j~
Job 62, User CIRINO, Account 341, TTYI06
Located at DN200
Remember that the request remains in the queue until it is honored.
If it appears that the request is being ignored, use the INFORMATION
DECNET command to see if the DN200 is still available.
If it is
available,
repeat the INFORMATION DECNET command later;
if it is not
available, check with your operations staff if the job is critical.
(The DN200 may require manual loading.)
Printed on the DN200 printer are the contents of the file TEST. TXT:
This is a test file!
You can also use the SET LOCATION command to direct requests to a
DN200 or IBM-type remote station.
If the operator is not at the
terminal of the remote station, the response to your PLEASE request
will be delayed.
The example below shows the input and output at both
the local site and the remote station:
Typed on the user's terminal at the local site is:
@set location dn200::

GD
@infORMATION (ABOUT)

joB-STATUS

Job 33, User CIRINO, Account 341, TTYI06
Located at DN200
@please turn printer on~
[PLSOPN Operator at DN200 has been notified at 15:21:09]

6-3

TOPS-20 DECnet-20 EXEC COMMANDS
Output to the console at the remote site is:
KL2l02: :OPR)
KL2l02::
15:21:09
<8)

--Message from Timesharing User-JOB 33 CIRINO at Termin~l 106
PLEASE turn printer on

Input by the remote operator is:
KL2l02::0PR) RESPOND 8 PRINTER IS
KL2l02: :OPR)

ON~

The answer received at the host site is:
[Operator Response Received at 15:21:58]
PRINTER IS ON

6.3

/DESTINATION-NODE SWITCH

The /DESTINATION-NODE switch is used with the PRINT command to direct
output to the specified DN200 or IBM-type remote station. When this
switch is used with the SUBMIT command, the log file is directed to
the specified remote station.
The format for the /DESTINATION-NODE switch is as follows:
/DESTINATION-NODE:node: :
where:
node: :

The name of the remote
directed.

station

which

output

Example:
@ PRINT

6.4

FOO.BAR/DESTINATION-NODE:DN200::~

ADDITIONAL FEATURES AVAILABLE TO NONPRIVILEGED USERS

The Network File Transfer Program described in chapter 7 can be run by
a nonprivileged user.
Chapter 8 describes the SETHOST program that uses
DECnet-20's
task-to-task communications capabilities.
This program allows a
privileged or nonprivileged user at a terminal to log in to a remote
host on the same network as the user's local host.
All users may use the SPEAR program to type or print network error and
event
logging
reports.
See
the SPEAR manual, order number
AA-J833A-TK.

6-4

CHAPTER 7
NETWORK FILE TRANSFER

7.1

OVERVIEW

The Network File Transfer utility allows you to access or delete files
residing
on
DECnet
hosts
that
provide network file access
capabilities. NFT is a task-to-task utility consisting of an active
task NFT
(DCN:) and a server task FAL (SRV:).
By using NFT, you can
delete files from a remote host and transfer sequential files between
your local host and a remote host;
FAL checks for requests made by
NFT.
The NFT and FAL programs communicate using the Data Access
Protocol (DAP).
All network file transfers must be direct requests between the local
host and one remote host.
Files can be transferred from your local
host to a remote host or from a remote host to your local host.
The files deleted or transferred using NFT can be text, program, data,
control, or any other sequential files.
Some file formats cannot be
transferred between TOPS-20 systems and non-TOPS-20 systems.
See
Section 7.2.3, which discusses the NFT COpy command,
for more
information on this subject.
NFT does not include network file spooling.
Unless you are using the
wildcard feature, you can make only one file transfer request at a
time and that request must be for only one file to be transferred.
(See Section 7.2.l.)

7.1.1

Specifying File Access Information

Each file deletion or transfer request must include a valid user
identification, account,
and password for the system to be accessed.
The FAL at the remote host is responsible for verifying your access to
the requested file and subsequently honoring or rejecting yourrequest.
The requirements of the remote node determine the values you
specify in access information switches or in response to prompts for
access information.
This security measure is necessary to protect a
node's files from unauthorized access or accidental deletion.
You
must enter either the particular access parameter required by the
remote node, or a carriage return if the remote node does not require
a parameter or has an established default value.

7-1

NETWORK FILE TRANSFER
NFT prompts you for access information (user, account, password) when
you type the first NFT command that requires such information. If the
access is successful, all subsequent file requests to the node
addressed will use the access information that you provided in
response to the prompt. If you supply access information by using the
SET DEFAULTS command as the first NFT command, or if you have set
defaults for the node in an NFT.INIT file in your logged-in directory,
you will not be prompted for that access information. Whether you
supply access information in response to a prompt from NFT, by the SET
DEFAULTS command typed to your terminal, or by SET DEFAULTS commands
in an NFT.INIT file, the values will be remembered. The NFT.INIT file
is read each time you run NFT.
Access information entered in response to a prompt or with a SET
DEFAULTS command remains effective until changed with another SET
DEFAULTS command. Access information switches are used to override
default values already established. Switch values are effective only
for the command in which entered.

7.2

NFT COMMANDS

You call the NFT program by typing NFT or R NFT in response to the
TOPS-20 operating system prompt. After you type NFT and press RETURN,
the NFT program prints the prompt NFT>.
The list of valid NFT
commands follows:
COpy
DELETE
DIRECTORY
EXIT
HELP
INFORMATION
PRINT
SET
SUBMIT
TAKE
TYPE
The file specifications for remote files must have the format required
by the operating system at the remote host. The operating systems and
corresponding formats include the following:
Operating system

File Specifications Format

TOPS-20

device:<directory>filnam.type.gen

VMS

device: [username]filnam.extigen

RT, RSTS

device: [UIC]filnam.ext

RSX, lAS

device: [UIC]filnam.extigen

7-2

NETWORK FILE TRANSFER
7.2.1

SET DEFAULTS Command

The SET DEFAULTS command establishes the default access nformation to
be used with all subsequent NFT commands for the specif ed node.
The
values established with the SET DEFAULTS command rema n in effect
until you exit from NFT or change the values with another SET DEFAULTS
command.
The SET DEFAULTS command does not prompt for omitted
information.
However, NFT does prompt for required omitted access
information switches at the time you type the first command that
requires a switch not previously set with a SET DEFAULTS command.
Access information values may be changed for a specific command by
including the desired access information switch. After the command
containing the switch has been executed, the access information values
revert to the previously established default values.
The format of the SET DEFAULTS command is as follows:
NFT>SET DEFAULTS (FOR NODE) node: :/switches
where:
node: :

is the node name to which
assigned.

/switches

are any combination of access information switches
(see
Table 7-1)
and,
in addition,
the switch
/OSTYPE:operating-system.
Valid values for
the
operating-system argument are TOPS-10, TOPS-20, RSX,
RSTS, VMS, or lAS.

the

default

values

are

Examples:
@NFT~

NFT>SET DEFAULTS (FOR NODE)

cp
NFT>SET DEFAULTS (FOR NODE)

ALPHA::/USER:JONES/OSTYPE:VMS~

DELTA::/USER:CLEMENS/PASSWORD:TOPS20~

GO
NFT>SET DEFAULTS (FOR NODE)
NFT>

GAMMA::/USER:RElLLY/ACC:UETP~

You can place SET DEFAULTS commands in an initialization file that
will be read when you run NFT.
The initialization file must be in
your logged-in directory and must be called NFT.lNlT.
Access
information established in the NFT.lNlT file may be changed by typing
a SET DEFAULTS command, or may be overridden by an access information
switch.
The SET DEFAULTS command you type at the terminal will be
effective for the current NFT session unless you change or override
it.
The access information switch is effective only for the command
in which it is specified.

7-3

NETWORK FILE TRANSFER
Following is an example of an NFT.INIT file currently in use.
The
INFORMATION DECNET command included at the end provides a convenient
way to check the currently available nodes whenever you run NFT.
SET DEFAULTS KL2l02::/USER:PTAYLOR/ACCOUNT:34l/0STYPE:TOPS20
SET DEFAULTS KLI031::/USER:PTAYLOR/ACCOUNT:341/0STYPE:TOPS20
SET DEFAULTS SYS880::!USER:GUEST/ACCOUNT:FOO/OSTYPE:RSXll/PASS:DUMB
SET DEFAULTS KL4097::/USER:REILLY.PTAYLOR/ACCOUNT:34l/0STYPE:TOPS20
SET DEFAULTS KL2l37: :/USER:REILLY/ACC:UETP
INFORMATION DECNET
You may clear the default access information for a node by typing
the
SET DEFAULTS command without specifying any access information.
To
clear the default access information for a node other
than the node
where your logged-in directory is located,
the node name must be
included.
If you omit node name J the system assumes the node to be
the node where your logged-in directory is located.
Two examples are shown below.
In Example 1 there is no NFT.INIT file
in the logged-in directory.
In Example 2 there is an NFT.INIT file
with default access information for four nodes as shown.
The NFT.INIT
file also includes the INFORMATION DECNET command.
Including this
command in the NFT.INIT file saves you from having to type the command
at the beginning of each NFT session.
Note in the first example that
the default access information is available for the node where your
logged-in directory is located even though you have not given a SET
NFT establishes these parameters each time the NFT
DEFAULTS command.
or R NFT command is given.
When you exit from NFT, all default access information as cleared or
set in the NFT run from which you have exited is lost.
If you run NFT
again and
type the INFORMATION DEFAULTS command before any SET
DEFAULTS commands are given the response will always be either the
default access information for the node where your logged-in directory
is located
(no NFT.INIT file) or defaults given by the SET DEFAULTS
commands in the NFT.INIT file.
Example 1.
@NFT@)

CJD

CEQ
~

NFT)inFORMATION (ABOUT) deFAULTS~
Node KL2102: :/USER:CIRINO/ACCOUNT:341/0STYPE:TOPS20

GD
NFT)set deFAULTS (FOR NODE)~

NFT)inFORMATION (ABOUT) deFAULTS~
Node KL2102: :/OSTYPE:TOPS20
NFT)

7-4

NETWORK FILE TRANSFER
Example 2.
@NFT ( RET )
Accessible DECNET nodes are:

DN20A

DN200

KLl03l

KL2l02

KS4097

NFT>inFORMATION (ABOUT) deFAULTS~
Node KL2l02::/USER:PTAYLOR/ACCOUNT:34l/0STYPE:TOPS20
Node KLl03l::/USER:P:TAYLOR/ACCOUNT:34l/0STYPE:TOPS20
Node KL4097::/USER:REILLY.PTAYLOR/ACCOUNT:341/0STYPE:TOPS20
Node SYS880::/USER:GUEST/ACCOUNT:FOO/OSTYPE:RSX

GD
NFT>set deFAULTS (FOR NODE)~

NFT>inFORMATION (ABOUT) deFAULTS~
Node KL2l02: :/OSTYPE:TOPS20
Node KLl03l::/USER:PTAYLOR/ACCOUNT:34l/0STYPE:TOPS20
Node KL4097:/USER:REILLY.PTAYLOR/ACCOUNT:34l/0STYPE:TOPS20
Node SYS880::/USER:GUEST/ACCOUNT:FOO/OSTYPE:RSX

NFT>set deFAULTS (FOR NODE)

KLl03l::~

NFT>inFORMATION (ABOUT) deFAULTS~
Node KL2l02::/0STYPE:TOPS20
Node KLl03l::/0STYPE:TOPS20
Node KL4097::/USER:REILLY.PTAYLOR/ACCOUNT:34l/0STYPE:TOPS20
Node SYS880::/USER:GUEST/ACCOUNT:FOO/OSTYPE:RSX
NFT>

7.2.2

INFORMATION Command

The INFORMATION command has two options:

DEFAULTS and DECNET.

The INFORMATION DEFAULTS command displays the current settings of
default switches for a specified node.

the

The format of the INFORMATION command is as follows:
NFT>INFORMATION (ABOUT) DEFAULTS
NFT displays the information about defaults in the following format:
node::/USER:userid/ACCOUNT:account-string/OSTYPE:ostype
where:
node: :

is the name of the node for which the
listed have been set.

defaults

userid

is the default
specified node.

account-string

is the default account at the specified node.
7-5

user

identification

the

NETWORK FILE TRANSFER
ostype

is the operating system at the specified node.

Example:
@NFT~

GD
NFT> INFORMATION (ABOUT)

DEFAULTS@)

Node KL2l02::/USER:SKOGLUND/ACCOUNT:34l/0STYPE:TOPS20
NFT>
The INFORMATION DECNET command displays the list of accessible
nodes.

DECnet

The format of the INFORMATION DECNET command is as follows:
NFT>INFORMATION (ABOUT) DECNET
Example:
@NFT~

•

NFT> INFORMATION (ABOUT) DECNET~
Accessible DECNET nodes are:
DN20A
NFT>

7.2.3

KLl03l

KL2l02

COpy Command

The COpy command transfers files from the local node to a remote node
or transfers files from a remote node to the local node.
Note that
only the remote node should be specified.
The format of the COpy command is as follows:
Local-to-Remote
NFT>COPY (FROM)

filespecl/switches (TO) REMOTE::filespec2/switches

Remote-to-Local
NFT>COPY (FROM) REMOTE::filespecl/switches (TO)

filespec2/switches

where:
REMOTE: :

is the node name of the remote
the file is transferred.

filespecl

is the file specification of the file to
be
transferred.
The specification must be in the
format required by the operating system at REMOTE::.

filespec2

is the file specification to be given to the
transferred file.
The specification must be in the
format required by the operating system at REMOTE::.

/switches

are one or more of the
7-1, as required.

7-6

switches

host

from/to

defined

which

Table

NETWORK FILE TRANSFER
Table 7-1
COpy Command Switches
Access Information Switches
(valid also with
DIRECTORY, DELETE, SUBMIT, and TYPE commands)

SET

DEFAULTS,

/USER:userid
Sets the user identification associated with the node
specified.
Provides the access control information only;
it does not provide the directory name.
/ACCOUNT:account
Sets the account associated with the user identification at
the node specified. Account must be an ASCII string of 1 to
16 characters.
/PASSWORD:password
Sets the password associated with the user identification at
the node specified.
Password must be an ASCII string of 1
to 8 characters.
Processing Mode Switches
/ASCII
Sets the file processing mode to ASCII.
/IMAGE
Sets the file processing mode to IMAGE.
IMAGE indicates
that the file is sent or received exactly as stored on disk.
/MACYll
Sets the file processing mode to MACYll.
This switch is
required to transfer PDP-II object code.
The MACYll file
format is produced by a TOPS-IO/20 PDP-II cross-assembler.
Record Length Switches (used only in combination with one
processing mode switches)

the

records

/FIXED:nn
Defines a file as consisting of fixed length records
bytes.
/VARIABLE:nn
Defines a file as consisting of variable length
maximum size of nn bytes.

7-7

NETWORK FILE TRANSFER
DECnet-20 Version 2.1 ASCII-mode file transfers require neither
processing-mode nor record-length switches.
To understand which
switches you should use when executing any other type of network file
transfer, you should understand the file systems of the two machines
involved in the transfer.
The TOPS-20 file system stores data in units of 512 36-bit words,
called pages.
Descriptive information about the file is stored in a
special "header" page called the File Descriptor Block (FDB).
Record
formats and attributes are not stored in the FDB. Only the programs
which access the file know whether the record format is undefined,
stream, fixed, variable, VFC, etc.
Only accessing programs know
whether the items in a record are characters (SIXBIT, ASCII, EBCDIC,
etc.) or fixed or floating numbers.
The following information is, however, kept in the FDB; BYTE SIZE and
LENGTH IN BYTES. This lack of knowledge about the file's format makes
heterogeneous non-ASCII file transfer somewhat complex.
You have
noticed that there are file switches for TOPS-20 files such as /VAR
and /MACYll. These formats are not native to TOPS-20, nor are they
produced or read by any TOPS-20 utility. Following is a description
of each of these file formats. These descriptions should allow you to
design your data transfer techniques to take full advantage of the
file transfer capabilities of DECnet.
1.

NO FILE FORMAT SWITCHES ON EITHER FILE.
If the file transfer is TOPS-20 to TOPS-20, the FDB and the
entire file are copied in page size records.
All FDB
information is retained, and files with holes retain the
holes.
This is the most efficient homogeneous file transfer
format; the files are read and written with PMAPs.
If the file transfer is not 20 to 20 and the file's byte size
is 7 or 36 the data mode defaults to ASCII, otherwise it
defaults to /IMAGE.

TOPS-20 STREAM ASCII FILE FORMAT (/ASCII)
Stream ASCII files contain a continuous stream of 7 bit ASCII
characters.
Logical records are delimited by any of the
following characters: ESC, Z, DCl, DC2, DC3, DC4, DLE, FF,
VT, LF. The line numbers in line numbered files are ignored
by NFT/FAL.
Nulls
are
stripped
by
NFT/FAL.
Both
/ASCII/FIX:n and /ASCII/VARIABLE:n are processed as /ASCII
except that records longer than n characters are split into
two records.

TOPS-20 Image File Format (/IMAGE)
Image format files are considered to be streams of bytes.
The bytes are all of the same size from 1 to 36 bits. There
is no concept of records or record lengths.

TOPS-20 MACYll File Format (/MACYll)
The MACYll file format is the format of object files produced
by the MACYll and DNMAC cross assemblers. An object file
produced by MACYll can be copied to an RSX or VMS system,
task built, and run successfully.

7-8

NETWORK FILE TRANSFER

A MACYll file is a 36-bit byte file containing variable
length records of the following format.
Four bytes are
stored in each 36-bit word:
[<2 ZERO BITS><BYTE 2><BYTE 1><2 ZERO BITS><BYTE 4><BYTE 3>].
Each record looks like this:
Byte o <1>
sync byte
Byte 1 <0>
null follows sync
Byte 2 <cnt>
low order of (length of "Data" in bytes)+4=[n]
Byte 3 <cnt>
high order of (length of "Data" in bytes)+4=[n]
Byte 4 <data>
Byte n
(last byte of "Data")
Byte n+l
checksum byte (two's complement add with carry ignored);
checksum includes all bytes in record including header
6 Nulls followed by next record (The nulls are ignored)
5.

TOPS-20 Variable Length Record File
/IMAGE/VARIABLE:n)

Format

(/VARIABLE:n

A TOPS-20 variable length file suitable for transfer to or
from a VMS or RSX type file system consists of a sequence of
variable length 8-bit byte records. The first two bytes of
each record contain the byte count of the data in the
remainder of the record (Low order byte first, high order
byte second).
Four bytes are stored in each 36-bit word as
follows:
[<BYTE l><BYTE 2><BYTE 3><BYTE4><4 ZERO BYTES>]
6.

TOPS-20
MACYll
(/MACYll/VAR:n)

variable

Length

Record

File

Format

A TOPS-20 MACYll variable length file consists of a sequence
of variable length 8-bit byte records where each record
starts on a word or half word boundary and the first two
bytes of each record contain the count of the data in the
remainder of the record. The count is stored low order byte
first, high order byte second. Four bytes are stored in each
36-bit word as follows:
[<2 ZERO BITS><BYTE 2><BYTE 1><2 ZERO BITS><BYTE 4><BYTE 3>]
7.

TOPS-20
MACYll
(/MACYll/FIX:n)

Fixed

Length

Record

File

Format

A TOPS-20 MACYll fixed length record file consists of a
sequence of 8-bit bytes stored in 36-bit words where the
length of each record is arbitrary (remember that TOPS-20
does not store the record length anywhere). This is the
format of task files (.TSK) produced by TKB20 (the fixed
record size must be 512). A task file produced by TKB20 can
be copied by NFT to an RSX system and run provided that PIP
is used on the RSX system to make the copied task file
contiguous.
If the last record is only a record fragment, then different
target systems may act differently. Refer to the discussion
for each target system. Four bytes are stored in each 36-bit
word as follows:
[<2 ZERO BITS><BYTE 2><BYTE 1><2 ZERO BITS><BYTE 4><BYTE 3>]

7-9

NETWORK FILE TRANSFER

TOPS-20 Fixed
/IMAGE/FIX:n)

Length

Record

File

Format

(/FIX:n

A TOPS-20 fixed length file suitable for transfer to or from
a VMS or RSX type file system consists of a sequence of 8-bit
bytes. Since TOPS-20 does not store the record size in the
FDB, it can be considered to be any length. If the last
record is only a record fragment, then different target
systems may act differently. Please refer to the section for
each target system. Four bytes are stored in each 36-bit
word as follows:
[<BYTE O><BYTE l><BYTE 2><BYTE 3><4 ZERO BITS>]

NFT file specification defaults
The following table shows, for each field in a file specification,
whether wildcards can be used, whether it can be defaulted, and if it
can, what the default is.
LOCAL FILE SPECIFICATION (after logical name defaulting)
NODE::

Default is the local node
(Local node cannot be
specified explicitly)

No wildcards allowed

DEVICE:

Default is DSK: **

No wildcards allowed

Default is PS:

Wildcards allowed *

FILE-NAME.

Must be supplied in source
file specification, will default
to the name of the source file
if omitted from destination file
specification

Wildcards allowed

. FILE-TYPE

If not supplied in source
file specification it is null:
will default to the type of the
source file if omitted from the
destination file specification

Wildcards allowed

.VERSION

Default is most recent version
for existing file, or next
version for new file

Wildcards allowed

REMOTE FILE SPECIFICATION
NODE::

Default is local node

No wildcards allowed

DEVICE:

No default is provided,
the remote node performs the
defaulting: for TOPS-20 remotes
the default is PS: ***

No wildcards allowed

7-10

NETWORK FILE TRANSFER
(DIRECTORY)

No default is provided,
the remote node performs the
defaultingi for TOPS-20 remotes
the default is the argument of
tne IUSER: switch supplied with
the node

Wildcards allowed *

FILE-NAME.

Must be supplied in source
file specificationi will default
to the name of the source file
if omitted from destination file
specification ****

Wildcards allowed

. FILE-TYPE

If not supplied in source
file specification it is null;
will default to the type of the
source file if omitted from the
destination file specification

Wildcards allowed

.VERSION

No default is provided,
the remote node performs the
defaulting

Wildcards allowed

* If the directory is wildcarded,
the access control information
(/USER:, IACCOUNT:, IpASS:) must be valid for every directory
included in the wildcard specification. The user is NOT prompted
for this information when a new directory is accessed.
** A local file can be on any of the
CDP, CDR, PLT, MTA, TTY, and NUL.

following

devices:

DSK,

LPT,

*** A remote file must be on a disk device.
If the remote file device
is
a
logical
name,
the logical name will be processed
appropriately for that node, except that NFT-20 will always insert
file name and file type.
**** The files .i* and .*i* cannot be copied to or from lIs or VAXs.
Examples:
When a sequential file transfer is between two DECSYSTEM-20s, you may
allow all fields except the filespec fields to be defaulted by
omitting the switches and the node specification that represents the
local node.
Each COpy command in the first three examples is valid for a TOPS-20
to TOPS-20 transfer.
LOCAL is the name of the local nodei REMOTE is
the name of the remote node.
Example 1.
@NFT~

NFT) COpy (FROM)

GQ
*.MAC.* (TO)

PS:(USER)ABC.MAC.3
PS:(USER)XYZ.MAC.7

=)
=)

REMOTE: :*.MAC.*~

REMOTE::PS:(USER)ABC.MAC.3 [OK]
REMOTE::PS:(USER)XYZ.MAC.7 [OK]

The system responds, in this case, by naming all transferred files
ending in .MAC. This use of the wildcard function is permitted only
if both nodes support wildcarding.

7-11

NETWORK FILE TRANSFER
Example 2.
@NFT@)

~
~

GD
NFT> COpy (FROM)

ZOOM. * . * (TO) .REMOTE:: ZOOM. * @)

PS:<USER>ZOOM.EXE.4 => REMOTE::PS:<USER>ZOOM.EXE.l [OK]
PS:<USER>ZOOM.MAC.6 => REMOTE::PS:<USER>ZOOM.MAC.4 [OK]
In the above example, the system interprets the wildcard designation
for
file type,
transfers the two files beginning with the file name
ZOOM, and defaults the unspecified FROM node name to the local node
name.
Note also the complete file specification inserted by the
system in both examples. You did not need to type the structure (PS:)
or user «USER».
Example 3.
@NFT~

GD
NFT> COpy (FROM)

REMOTE: :ABC. TXT. 3 (TO)

ABC. TXT~

REMOTE::PS<USER>ABC.TXT.3 => PS:<USER>ABC.TXT.3 [OK]
In this example, the file is being transferred from the remote to the
local node, whereas in the firs~ two examples the files were being
transferred from the local to the remote site.
Example 4.
NFT~

NFT> COPY TPARS.MAC SY5l01: :DBO:TPA.RS.MAC~
TPARS.MAC.l => SY5l0l::DBO:TPARS.MAC;1 [OK]
NFT> DIRECTORY SY5l0 1: : DBD: * . MAC C§:)
SY5l0l::DBO:[200,200]
TPARS.MAC;li P7756DO

6 11264(8)

l5-Aug-79 17:02:07

The above example differs from the first three examples in two ways.
First, a file is being copied from the local system to a non-TOPS-20
system.
(SY5l0l is an RSX operating system.) Second, guidewords are
not used.

7-12

NETWORK FILE TRANSFER
Specifying Destination File Processing Mode
For each source file processing mode specified, there is a default
destination file processing mode.
This default value will be assumed
if no destination file processing mode switch is specified.
The
defaults are:
Specified Source Mode
/ASCII
/ASCII/FIXED
/ASCII/VARIABLE
VMS print file
format
/IMAGE
/IMAGE/FIXED
/IMAGE/VARIABLE
/MACYll
/MACYll/FIXED
/MACYll/VARIABLE

Default Destination Mode/Record Length

(TO)
(TO)
(TO)

/ASCII or /ASCII/VARIABLE
/ASCII
/ASCII

(TO)
(TO)
(TO)
(TO)
(TO)
(TO)
(TO)

/ASCII
/IMAGE
/IMAGE/FIXED
/IMAGE/VARIABLE
/IMAGE/VARIABLE
/IMAGE/FIXED
/IMAGE/VARIABLE

TOPS-20 NFT permits only the following source/destination
file
processing mode combinations when transferring a file TO a remote
system:
Local Mode

Remote Mode

/ASCII

(TO)

/ASCII

/ASCII
/IMAGE
/IMAGE/FIXED
/IMAGE/VARIABLE
/MACYll
/MACYll/VARIABLE
/MACYll/FIXED
/MACYll/IMAGE

(TO)
(TO)
(TO)
(TO)
(TO)
(TO)
(TO)
(TO)

/ASCII/VARIABLE
/IMAGE
/IMAGE/FIXED
/IMAGE/VARIABLE
/IMAGE/VARIABLE
/IMAGE/VARIABLE
/IMAGE/FIXED
/IMAGE

TOPS-20 NFT permits only the following source/destination
file
processing mode combinations when transferring a file FROM a remote
system:
Remote Mode
/ASCII
/ASCII/FIXED
/ASCII/VARIABLE
/IMAGE
/IMAGE
/IMAGE/FIXED
/IMAGE/FIXED
/IMAGE/VARIABLE
/IMAGE/VARIABLE
/IMAGE/VARIABLE

Local Mode

(TO)
(TO)
(TO)
(TO)
(TO)
(TO)
(TO)
(TO)
(TO)
(TO)

/ASCII
/ASCII
/ASCII
/IMAGE
/MACYll/IMAGE
/IMAGE/FIXED
/MACYll/FIXED
/IMAGE/VARIABLE
/MACYll/VARIABLE
/MACYll

7-13

NETWORK FILE TRANSFER
7.2.4

DELETE Command

The DELETE command deletes files from a remote node.
The format of the DELETE command is as follows:
NFT>DELETE (REMOTE FILES) node::filespec/switches
Example:
@ nftC§)

•

NFT> information (ABOUT) decnetC§)
Accessible DECNET nodes are:
KL2102, KLI031, KS4097, DN200,
DN20A
NFT> delete KL2102: :sep.txtC§)
Access information for node KL2102::/USER:cirino/ACCOUNT:341
Password: password ~
KL2102: :PS:<CIRINO>SEP.TXT.5 [OK]
NFT>
If no access information values have been established before the
DELETE command, NFT will prompt for the required access information
unless you supply switches with the DELETE command.
These switches
are effective only for the command in which you specify them.
Note
that if the remote node is running TOPS-20, no expunge is done.

7.2.5

DIRECTORY Command

The DIRECTORY command returns a directory listing of the files at the
specified node.
The system prints the directory heading and then
lists the files in alphabetic order.
For each file the following
information is listed:
•

Name, type, generation number

•

Protection code

•

Size in pages

•

Length in bytes and byte size (in parentheses)

•

The date and time the file was
modified, the date last modified

originally

created

or,

The directory heading (node, structure, directory name) and the file
name, type, and generation number are always in the format required by
the remote site. All other information is listed in TOPS-20 format.
The format of the DIRECTORY command is as follows:
NFT>DIRECTORY (OF REMOTE FILES) node: :filespec/switches
If no access information values have been established before the
DIRECTORY command, NFT will prompt for the required access information
unless you supply switches with the DIRECTORY command.
These switches
are effective only for the command in which you specify them.

7-14

NETWORK FILE TRANSFER
Several examples follow.
The environment of the DIRECTORY command
influences the input/output associated with the command.
Therefore,
each example is preceded by the conditions that would call for
the
input as shown and result in the output as shown.
Example 1.
Conditions:
The NFT DIRECTORY command is for one file on your
own logged-in directory.
There is no NFT.INIT file.
The
DIRECTORY command is the first command given in this NFT session.
NFT knows USER and ACCOUNT because you logged in on this node.
NFT always prompts for password unless it has been established
with a SET DEFAULTS command. NFT does not print passwords.
@NFT~

NFT>dirECTORY (OF REMOTE FILES) login.cmd~
Access information for node
KL2l02: :/USER:KAMANITZ/ACCOUNT:341
Password:password~

KL2l02: :PS:<KAMANITZ>
LOGIN.CMD.7;P777700
NFT>

1 39(36)

l4-Sep-79 14:34:01

Example 2.
Conditions:
Same as Example 1 except that an NFT TYPE command is
given before the DIRECTORY command.
There is no prompt for the
password after the DIRECTORY command is given.
The TYPE command
was the first command and the password was entered in response to
the prompt following
the TYPE command.
NFT remembers the
password.
NFT>type switch.ini~
Access information for node
KL2l02: :/USER:KAMANITZ/ACCOUNT:341
Password:password~

EDIT/SAVE:5/ISAVE:5
~

NFT>dirECTORY (OF REMOTE FILES)
KL2l02: :PS:<KAMANITZ>
LOGIN.CMD.7;P777700
NFT>

1 39(36)

7-15

l4-Sep-79 14:34:01

NETWORK FILE TRANSFER
Example 3.
Conditions: The DIRECTORY command is for the complete directory
on another TOPS-20 node that is a member of your network. You
have an account for node KS4097.
There is no NFT.INIT file.
The
DIRECTORY command is the first command given that requires access
to node KS4097.
A prompt is given for each access information
parameter.
@NFT~

NFT> DIRECTORY (OF REMOTE FILES) KS4097:: (Rl:l )
Access information for node KS4097::
User : CRUGNOLA~
Account: 341~
password:password(RET)
KS4097::PS:<CRUGNOLA>
CALEND.EXE.1;P777700
DIDDLE.ZZZ.1;P777700
LA36.CMD.1;P777700
LOGIN.CMD.2;P777700
MAIL.TXT.1;P770400
PTYCON.ATO.1;P777700
SWITCH.INI.2;P777700
VT50.CMD.1;P777700
VT52.CMD.1;P777700
ZIP.Q.1;P777700
NFT>

5
1
1
1
1
1
1
1
1
1

2560 (36)
6(36)
74(7)
21(7)
175(7)
1220(7}
39(7)
28(7}
60(7)
45(7)

10-Apr-78 11:23:48
6-Aug-79 15:51:41
13-Mar-78 16:39:48
13-Mar-78 16:36:23
26-Jul-79 13:01:46
19-May-78 13:34:26
18-May-78 15:33:10
13-Mar-78 16:37:44
13-Mar-78 16:38:49
14-Jun-78 17:06:25

Example 4.
Conditions:
Same as Example 3 except that the DIRECTORY command
uses the wildcard feature to request all files of type .CMD.
@ NFT~

(ESC)
~

NFT> DIRECTORY (OF REMOTE FILES) KS4097::*. CMDGID
Access information for node KS4097::
User: CRUGNOLA~
Account: 341~
Password: password~
KS4097::PS:<CRUGNOLA>
LA36.CMD.1;P777700
LOGIN.CMD.2;P777700
VT50.CMD.1:P777700
VT52.CMD.1;P777700
NFT>

1
1
1
1

7-16

74(7)
21(7}
28(7)
60(7)

13-Mar-78
13-Mar-78
13-Mar-78
13-Mar-78

16:39:48
16:36:23
16:37:44
16:38:49

NETWORK FILE TRANSFER,
Example 5.
Conditions: Two NFT Directory commands are directed to an RSX
node that is a member of your network. You have an account on
SY5101. Your logged-in directory has an NFT.INIT file with a SET
DEFAULTS command that establishes values for USER, ACCOUNT,
PASSWORD, and OSTYPE for SY5101. The INFORMATION DECNET command
is also included in the NFT.INIT file.
The DIRECTORY command is
the first command given that requires access to SY5101.
The
directory heading and file specifications are in RSX format.
All
other output is in TOPS-20 format.
All values apply to the
remote directory.
The first DIRECTORY command is for all files
on structure DKO:. The second command is for all files of type
.CMD on structure DBO:. The wildcard feature is allowed because
it is implemented by RSX.
@NFTC§)

NFT>iNFORMATION (ABOUT) decnet~
Accessible DECNET nodes are: DN20H
SY5101

KLI031 KL2102 KL4114

NFT>dlRECTORY (OF REMOTE FILES)
S Y5101: : DK 0: [200, 200]
INSTALL.CMDi17iP775600

SY5101::~

1 1536(8)

27-Dec-78 17:44:26

NFT>diRECTORY (OF REMOTE FILES)
SY5101::DBO:[200,200]
MERGE.C MD ili P565600
FLOPPY.CMDili P565600
PLO.CMDili P565600
PLOT.CMDiliP565600
COPIES. CMD i3i P775600
NFT>

7.2.6

1
1
1
1
1

512(8)
512(8)
512(8)
1024(8)
512(8)

12-May-78 15:45:35
12-May-78 15:45:36
12-May-78 15:45:36
12-May-78 15:45:37
7-Sep-79 16:45:14

See

example

EXIT Command

The EXIT command ends NFT execution.
command which follows.

7.2.7

SY5101::DBO:*.CMD~

the

HELP

HELP Command

The HELP command displays the HELP file for NFT.
The HELP file
contains a description of all NFT commands and switches. The example
that follows illustrates both the EXIT and HELP commands. CTRL/O was
typed after the first two sentences of the HELP file.
The file is
approximately 4 pages and you can read it at your convenience.
Example:
$R NFTG£)
NFT>HELPG!D
NFT - Network file transfer program

7-17

6-Apr-81

NETWORK FILE TRANSFER

NFT is the user interface to the network file transfer system.
The services NFT provides are actually performed by a FAL (File
Access Listener) process at the accessed node.
"'0 •••

NFT> EXIT~
$

7.2.8

PRINT Command

The PRINT command allows an ASCII file to be printed.at a remote node.
The network file transfer system does not check to determine that the
request i~ honor~d .. This command is valid only for files that support
remote fIle prIntIng. Note that the file must be on the remote node
and be in the format required by the remote node. The print spooling
facility must be available at the remote node.
The format of the PRINT command is as follows:
G)
t
NFT>prINT (REMOTE FILES) node: :filespec/switches
where:
node: :

is the node name of the remote host where the file
located.

filespec

is the file specification of the remote file.

/switches

are the access information switches.

7.2.9

SUBMIT command

The SUBMIT command allows a Batch control file or command file on a
remote node to be submitted to the Batch input queue or command file
processor at that node. The network file transfer system does not
check to determine that the request is honored. This command is valid
only for nodes that support remote command file submission. Note that
the file must be on the remote node and be in the format required by
the remote node. The batch or command file facility must be available
at the remote node.
The format of the SUBMIT command is as follows:
(

ESC )

NFT>suBMIT (REMOTE FILES) node::filespec/switches
where:
node: :

is the node name of the remote host where
is located.

filespec

is the file specification of the remote file.

/switches

are the access information switches.

7-18

the

file

NETWORK FILE TRANSFER
7.2.10

TAKE Command

The TAKE command allows commands to be executed from a command file.
The format of the TAKE command is as follows:
NFT)TAKE (COMMANDS FROM)
filespec2/switches

filespecl

(LOGGING OUTPUT ON)

where:
filespecl

is the file specification of the local command file.

filespec2
(OPTIONAL)

is the file specification of the local
logging output (default is to TTY) .

file

for

When commands are executed that cause a prompt for access information,
the command file execution is momentarily suspended, and you are given
the prompt for the access information at your terminal.
After you
enter the required access information, the command file execution is
resumed.
This feature allows you to omit passwords from your command
files.
TAKE Command Switches
/DISPLAY

display program output and commands
during command file execution.

/NODISPLAY

suppress terminal output during command
file
execution.
Information is still recorded in the
log file.

7.2.11

terminal

TYPE Command

The TYPE command displays the file specified on
file is transferred in ASCII.

your

terminal.

The

The format of the TYPE command is:
NFT)TYPE (REMOTE FILES) node: :filespec/switches

7.3

NFT ERROR MESSAGES

In the course of running NFT, you may receive error messages.
NFT
error messages preceded by % are warning messages. Warning messages
may indicate errors or may give you information.
You respond to them
by taking the indicated action or adjusting your procedures on the
basis of the information given.
Error messages preceded by ?
are
fatal error messages.
Except where otherwise stated, fatal errors can
be handled by you alone, or by you with the help of a more experienced
user.
In most messages, both the cause of the error and the action required
are apparent from the text of the message. Where this is not the
case, this chapter includes interpretive text following the message.

7-19

NETWORK FILE TRANSFER
7.3.1

NFT Warning Messages

%File attributes do not match processing mode
The file attributes at the remote site do not match those
specified in the COpy command. This message will be received
only if you are reading a file at a remote node running an
operating system other than TOPS-20.
%No local node specified, assuming destination file is local
%No local node specified, assuming source file is local
%No remote node specified, assuming destination file is remote
%Password found in command or
access

NFT.INIT

file

which

has

world

read

Remove the password switches from the command file or change
file's protection.

the

%Remote OS type different from that specified with SET DEFAULT

7.3.2

NFT Fatal Error Messages

?Byte size of local file is unusable, 7 assumed
?Cannot do requested file format conversion
Check the allowable source/destination
combinations (Section 7.2.3).

file

processing

mode

?Cannot establish requested mode for input
?Cannot establish requested mode for output
?Cannot get JFN for logical link

- TOPS-20 text for JSYS error

?Cannot open command file
Examine the file specification of your TAKE file for errors.
?Cannot open logging file

Examine the file specification of your LOG file for errors.
?Cannot open logical link

- TOPS-20 text for JSYS error

?Cannot open PS:NFT.INIT
?Command JSYS failed, type CONTINUE to try again
?EOF detected on logical link
?Error during TAKE file, aborting TAKE command
?Error getting list of available nodes
?Error processing PS:NFT.INIT, aborting processing

7-20

NETWORK FILE TRANSFER

?File is not ASCII
?Illegal destination processing mode
?Illegal switch:

switch

?Invalid account string
?Invalid destination processing mode
?Invalid password
?Invalid record length
?Invalid SET command
?Invalid switches for local file
?Invalid switches for remote file
?Invalid switch terminator
?Invalid use of wild cards
?Invalid user-id
?Length of account string exceeds 39 characters
?Length of password string exceeds 39 characters
?Length of userid string exceeds 39 characters
?Local status - error text, which includes (MAC:nl MIC:n2 STV:n3)
The error text corresponds to the octal numbers nl, n2, and n3,
which are error codes defined in the DAP architecture. Nl is the
MACRO or functional group reason for the error message.
N2 is
the specific type of error status. N3 is the secondary error
status, whose value depends upon which operating system was
running in the remote node. If TOPS-20 was running in the remote
node, n3 is the JSYS error code.
If an RMS-based operating
system, such as VMS, was running in the remote node, n3 is the
RMS device error code.
?Logical link reception error - reason text
The logical link was aborted for the reason specified
text.

reason

?Logical link transmission error - reason text
The logical link was aborted for the reason specified
text.

?Logical link was aborted during initial connection - reason text
The logical link was aborted for the reason specified
text.
?Remote file attributes not supported

7-21

reason

NETWORK FILE TRANSFER

?Remote node is not responding
?Remote node refused connection

- disconnect reason text

?Remote status - error text, which includes (MAC:nl MIC:n2 STV:n3)
The error text corresponds to the octal numbers nl, n2, and n3,
which are error codes defined in the DAP architecture. NI is the
MACRO or functional group reason for the error message.
N2 is
the specific type of error status. N3 is the secondary error
status, whose value depends upon which operating system was
running in the remote node. If TOPS-20 was running in the remote
node, n3 is the JSYS error code.
If an RMS-based operating
system, such as VMS, was running in the remote node, n3 is the
RMS device error code.
?Remote system does not support default mode
?Remote system does not support file submission
The NFT SUBMIT command is not implemented at the remote node.
?Remote system does not support requested mode
?Remote system does not support spooling option
?Remote system does not support wildcard operations
?Remote to Remote transfers not supported
This message is displayed if you use the NFT COpy command
transfer a file from one remote node to another remote node.
?Syntax error in node name or error
error text

local

file

specification

?Syntax error is node name or local file not found
?Syntax error in remote file name - error text
?TOPS-20 text for JSYS error
This message consists of any appropriate JSYS error message
specifically covered in other messages in this list.

7-22

not

NETWORK FILE TRANSFER
7.3.2.1 Internal NFT Program Errors - These fatal errors should not
occur.
If anyone of these errors does occur, you will need the help
of your Software Support Specialist. These errors are internal to the
NFT program.
?Cannot abort close logical link in LLCLOS
?Dap message buffer is full
?Function not implemented
?GLXINI - Unable to obtain run-time systems
?Invalid argument block length for

?Invalid link index
?Logical link not open in

D$CLOS
LLCLOS

?Too many links requested

7-23

D$INIT
D$OPEN
D$FUNC

CHAPTER 8
SETHOST (REMOTE LOGIN CAPABILITY)

8.1

SETHOST PROGRAM

SETHOST allows a user at a terminal on a TOPS-20 system (running on a
DECSYSTEM 2040S or 2060)
to log in to a remote TOPS-20 host in a
DECnet network.
This chapter describes the user of SETHOST in
conjunction with a server task on a TOPS-20 host.
SETHOST defines a network source task and establishes a task-~o-task
network connection between the source task and a target task at the
remote host.
SETHOST passes source terminal input to the network
connection and passes the remote host's output to the source terminal.
The program also provides for a special escape character by which the
user can exit normally from SETHOST and return to TOPS-20 (EXEC)
command level at the local node.
Finally, SETHOST monitors the
network connection and handles any unexpected break in the connection.

8.2

LOGGING IN TO A REMOTE HOST USING SETHOST

You invoke SETHOST by entering some form of the SETHOST command in
response to the TOPS-20 prompt at your terminal.
SETHOST expects you
to specify the remote host's node-name and a special escape character
to be used to exit from SETHOST.
If you do not specify a special
escape character, SETHOST uses
~RL/Y)
by default.
To specify the remote host', s node-name and use
(CTRL/Y)
as the special
escape character, use the following SETHOST command format:
@SETHOST node-name
SETHOST sets
~TRL/Y)
following message:
[Type

as the special escape character and

prints

the

to return to node node-name]

where node-name is the name of your local host.
If you enter an
invalid node name
(or if no physical connection exists), SETHOST
prints:
?Connection broken.
and terminates processing.

Reason:

39:

No path to destination node

You are returned to EXEC command level.

8-1

SETHOST (REMOTE LOGIN CAPABILITY)
To specify a different special escape
following SETHOST command formats:

character,

use

one

the

@R SETHOST
or
@SETHOST
SETHOST then prompts for the special escape character:
Escape character (

~n/y)

Press the control key (~TRL/)
while you also type one of the
following characters: A, B, D, E, G, H, K, N, P, V,. X, Z; then type
~ .
However, do not enter a control character you will use on the
local or remote host. In addition, if vou have enabled the traooina
of any control character, you cannot"use that control character as· the
SETHOST escape character.
If you enter only ~ , SETHOST uses
~TRL/Y)
as the special escape character.
If you did not enter a node name, as shown in the two SETHOST
lines above, SETHOST prompts you for one as follows:

command

Host name:
Enter the remote host's node name.
If you enter ~ , SETHOST
reissues the prompt until you enter a valid node name or a
~TRL~.
If you enter an invalid node name, SETHOST responds by printing an
error message and terminating processing.
After a successful connection to the remote host, SETHOST prints the
remote host's standard -banner message on your terminal. After the
banner message is printed, you may perform any function - such as
logging in - which is permitted by the remote host.

8.3

EXITING FROM A REMOTE HOST USING SETHOST

To exit normally from the remote host, type the special escape
character selected (or defaulted)
in the initial SETHOST dialogue.
(See Section 8.2 for SETHOST's response and your possible actions when
an abnormal disconnection occurs.) When you enter the special escape
character, SETHOST prints the following message on your terminal:
[Connection broken, back at node node-name,
Type CONTINUE to resume connection.]
You may continue SETHOST execution from the point of the interrupt
entering the CONTINUE command. SETHOST responds:

%Reconnecting to remote node ...
At this point, the connection is restored and the
connected to the remote host.

8-2

terminal

again

SETHOST (REMOTE LOGIN CAPABILITY)
NOTE
It is strongly recommended that you log
off the remote system before breaking
the network connection between the local
system and the remote system.
Jobs
detached on -20s by other than a DETACH
command will autologout after 5 minutes.
In addition, if you do not intend to
resume the connection
(by typing the
CONTINUE command), use the TOPS-20 RESET
command
to break the logical link.
Failure to do this limits the number of
available links for other jobs.

8.4

CONTROLLING SCROLLING ON A REMOTE NODE

The default characters that start and stop scrolling on the
node sometimes differ from those that do so on the local host.

remote

(CTRL/S)
On the local host,
is the default character that stops
(CTRL/O)
is the default character that starts
scrolling,
and
(CTRL/Q)
whether
Typing
causes scrolling to resume
scrolling.
(CTRL/S)
or because the system
scrolling stopped because you typed
paused at the end of a page on your terminal.

When you have used SETHOST to log in at a remote node,
~TRL/S)
still
stops scrolling, and
~TRL/0
still causes scrolling to resume after
you have typed
~RL/S)
However,
DECnet-20 does not pass these
characters to the remote node.
It is the local host that recognizes
these characters and controls scrolling upon receiving them, even when
the display on the terminal is from a remote node. Also, if you have
entered terminal pause mode on the remote node, and the system has
paused because a display has reached the end of a page,
«TRL/~
is
the default character for starting scrolling again.
Typing
~TRL/0
(since it is not passed to the remote node) has no effect in this
case.
In addition, when you are in terminal-pause mode on the remote
node,
(CTRL/~
is the default character that the remote node
recognizes for both starting and stopping scrolling.
You can use the TERMINAL PAUSE command to cause the
«T~/~
character
to stop and start scrolling on the local host as well as on the remote
node.
You can also use the TERMINAL PAUSE command to assign any two
char ac ter s of your choos ing
except
~TRL/S)
and
(CTRL/O)
for
controlling scrolling;
to do so:
1.

Enter a TERMINAL command that defines which keys
and stop scrolling.

Use SETHOST to log in at a remote node.

Again enter the same TERMINAL command
step 2.

that

you

will

start

entered

To cause these TERMINAL commands to be in effect when you log in at
the local host and remote node, you can enter them into the LOGIN.CMD
file in each of those nodes.
Example 4 in Section 8.5 demonstrates this procedure.
8-3

SETHOST (REMOTE LOGIN CAPABILITY)

8.5

SAMPLE TERMINAL SESSIONS USING SETHOST

The examples in this section illustrate uses of SETHOST.
Example 1.
The following example shows user KAMANITZ at a terminal on system
KL2102.
He first logs in to KL2102, then uses SETHOST to connect to
the remote system KL2137.
By entering the remote system's node name
on the SETHOST command line, KAMANITZ allows SETHOST to use
~Tn/D
as the special escape character.
He then logs in to system KL2137 as
user CRUGNOLA, performs functions on system KL2137, and logs off
KL2137. After logging off of system KL2137, he presses
~TRL/Y)
to
return to system KL2102.
From KL2102, he issues a LOGOUT command to
log off system KL2102.
KL2102 Development System, TOPS-20 Monitor 5.1(5012)
@.LOGIN KAMANITZ password 341GD
Job 16 on TTY106 19-5ep-79 14:41:15
@.SETHOST KL2137~
[Type Ay to return to node KL2102]
KL2137 Load-Test System, TOPS-20 Monitor 5.1(5012)
@LOGIN CRUGNOLA password 341~
Job 12 on TTY50 19-5ep-79 14:41:27
.

(User performs functions on system KL2137.)

@LOGOG!!)
Killed Job 12, User CRUGNOLA, Account 341, TTY50,
at 19-5EP-79 14:41:49, Used 0:00:02 IN 0:00:21
(User enters

here which is not echoed.)

[Connection broken, back at node KL2102,
Type CONTINUE to resume connection]
@LOGOG!!)
Killed Job 16, User KAMANITZ, Account 341, TTY 106,
at 19-5EP-79 14:46:53, Used 0:00:01 IN 0:05:37

8-4

SETHOST (REMOTE LOGIN CAPABILITY)
Example 2.
In the following example, user KAMANITZ logs in to system KL2102a
Then, he uses SETHOST to connect to system KL2137 and specifies
<CTRL/B) as the special escape character. Once he is connected to
KL2137,
he logs on as user CRUGNOLA and begins listing his directory.
While system KL2137 is printing information about his directory, he
presses <CTRL/B) to gain the attention of SETHOST on system KL2102.
From KL2102, he enters CONTINUE in response to the EXEC prompt and
SETHOST reconnects to system KL2137.
System KL2137 resumes printing
information about his directory.
(Note that the directory listing
does not contain the lines that would have printed during the time
used to escape from and return to system KL2137.) User KAMANITZ then
logs off system KL2137, returns to system KL2102, and logs off system
KL2102.
KL2102 Development System, TOPS-20 Monitor 5.1(5012)
@LOGIN KAMANITZ password 341~
Job 62 on TTYI06 19-5ep-79 14:50:59
@SETHOST~

Escape character (
(CTRL/V)
Host name:KL2137~

(User enters

(CTRL/B)~)

KL2137 Load-Test System, TOPS-20 Monitor 5.1(5012)
@LOGIN CRUGNOLA password 341~
JOB 13 ON TTY50 19-5ep-79 14:53:09
@VDIRG£)
PS:<CRUGNOLA)
5 (User enters
CALEND.EXE.l;P777700
echo. )
[Connection broken, back at node KL2102,
Type CONTINUE to resume connection]

~TRL/8)

•

@CONTINUE~

Reconnecting to node ...
10-6-AUG-79 15:51:41
LA36.CMD.liP777700
LOGIN.CMD.2;P777700
MAIL.TXT.l;P770404
SWITCH.INI.2iP777700
VT50.CMD.1iP777700
VT52.CMD.l;P777700
ZIP.Q.li P 777700

1 74(7)
1 21(7)
1 175(7)
1 39 (7)
1 28(7)
1 60(7)
1 45 (7)

13-MAR-78 15:39:48
13-MAR-78 15:36:23
26-JUL-79 13:01:46
18-MAY-78 15:33:10
13-MAR-78 15:37:44
13-MAR-78 15:38:49
14-JUN-78 17:06:25

TOTAL OF 13 PAGES IN 9 FILES
@LOGOG£)
Killed Job 13, User CRUGNOLA, Account 341, TTY 50
at 19-5ep-79 14:55:45, Used 0:00:03 IN 0:02:36
(User enters

It does not echo.)

[Connection broken, back at node KL2102,
Type CONTINUE to resume connection]
@LOGO~

Killed Job 62, User KAMANITZ, Account 341, TTY 106,
at 19-5ep-79 14:56:53, Used 0:00:01 IN 0:05:37

8-5

It does not

SETHOST (REMOTE LOGIN CAPABILITY)
Example 3.
This example shows the use of SETHOST to log in to a remote host that
is not an adjacent node in the network.
The network is configured
according to the following diagram:

HOST
KL~~

HOST
KL4097

HOST

KL~~

User CRUGNOLA on host KL4097, a DEC SYSTEM 2040S or 2060, wants to log
in to host KL2137, also a DECSYSTEM 2040S or 2060.
To do so, he first
logs in to host KL4097.
Then, he uses SETHOST to establish a network
connection to host KL2102, which is running DECnet-20 Version 3.0, and
uses the default special escape character.
Once the connection to
host KL2102 is established, user CRUGNOLA logs in to host KL2102 as
user KAMANITZ.
From host KL2102, KAMANITZ uses SETHOST to establish a
network connection to host KL2137, specifying
0w~
as the special
escape character.
Note that a different special escape character must be used for
the
connection between hosts KL2102 and KL2137.
If the same special
escape character were used for both network connect,ions,
SETHOST on
KL4097 would trap the special escape character and return control of
the user's terminal to host KL4097.
This would interrupt the
connection between hosts KL4097 and KL2102.
Once this occurred, no
means would exist to gain access to host KL2102 on the existing
connection.

8-6

SETHOST (REMOTE LOGIN CAPABILITY)
After the network connection is established between hosts KL2102 and
KL2137,
user KAMANITZ logs in to host KL2137 as user OSMAN. OSMAN
performs some functions on host KL2137,
tnen logs off and enters
@~~
to return to host KL2102.
Once at host KL2102, user KAMANITZ
logs off and enters
~Tn/Y)
to return to host KL4097.
Once there,
user CRUGNOLA logs off.
KL4097 Load-Test System, TOPS-20 Monitor 5.1(5012)
@LOG CRUGNOLA password 341~
Job 7 on TTY33 25-Sep-79 10:18:05
@SETHOST KL2102~
[TYPE
~RL/Y)
TO RETURN TO NODE KL4097]
KL2102 Development System, TOPS-20 Monitor 5.1(5012)
@LOG KAMANITZ password 341~
Job 42 on TTY217 25-Sep-79 10:19:17
@SETHOST~

Escape character ( (crRL/Y)
Host name:KL2137~

(User enters

(CTRL/B)

KL2137 - Gus The Languages System, TOPS-20 Monitor 4(3046)
@.LOG OSMAN password~
Job 20 on TTY214 25-Sep-79 10:20:58

(User performs functions on host KL2137)

@LOGO~

Killed Job 20, User OSMAN, Account MONITOR, TTY 214
at 25-Sep-79 10:21:30, Used 0:00:02 in 0:00:31
(User enters

It does not echo.)

[Connection broken, back at node KL2102,
Type CONTINUE to resume connection]
@.LOGO~

Killed Job 42, User KAMANITZ, Account 341, TTY 217
at 25-Sep-79 10:23:18, Used 00:00:01 in 0:05:00
(User enters

~TRL/Y)

•

It does not echo.)

[Connection broken, back at node KL4097,
Type CONTINUE to resume connection]
@LOGO~

Killed Job 7, User CRUGNOLA, Account 341, TTY 33,
at 25-Sep-79 10:26:31, Used 0:00:08 in 0:07:26
Example 4.
The following example demonstrates how to cause pressing the "a" key
to start scrolling and the "b" key to stop scrolling on both the local
host and the remote node. User KAMANITZ logs in to system KL2102.
He
uses the TERMINAL command to define the keys that will control
scrolling. He uses SETHOST to connect to system KL2137 as user
CRUGNOLA,
and types the same TERMINAL command that he typed while
logged in at system KL2102.
He performs functions on system KL2137,
and as he does so, types the letter "a" any time he needs to start
scrolling and the letter "b" any time he needs to stop scrolling.
He
logs off system KL2137 and types
~RL/Y)
to return to system KL2102.

8-7

SETHOST (REMOTE LOGIN CAPABILITY)
He performs functions on system KL2l02, and again types the letter "a"
any time he needs to start scrolling and the letter "b" any time he
needs to stop scrolling.
Finally, he issues a LOGOUT command to log
off system KL2l02.
KL2l02 Development System, TOPS-20 Monitor 5.l{50l2)
@.LOGIN KAMANITZ password 34l~
Job 16 on TTY106 19-5ep-79 14:41:15

GD
~

J
J
@terMINAL (MODE IS) pauSE (ON) chaRACTER 142 AND UNPAUSE ON l4l~
J

@SETHOST KL2l37~
[Type
~TRLI~
to return to node KL2l02]
KL2l37 Load-Test System, TOPS-20 Monitor 5.1(5012)
@LOGIN CRUGNOLA password 341~
Job 12 on TTY50 19-5ep-79 14:41:27

@terMINAL (MODE IS)

pauSE (ON)

chaRACTER 142 AND UNPAUSE ON l4l~

(The user performs functions on system KL2l37, and as he does so,
types the letter "a" any time he needs to stop scrolling and the
letter "b" any time he needs to start scrolling.)
@LOGO~

KILLED JOB 12, USER CRUGNOLA, ACCOUNT 341, TTY 50,
AT 19-5EP-79 14:41:49, USED 0:00:02 IN 0:00:21
(User enters

here which is not echoed.)

[Connection broken, back at node KL2l02, Type CONTINUE to
connection]

resume

(The user performs functions on system KL2l02, and as he does so,
types the letter "a" any time he needs to stop scrolling and the
letter "b" any time he needs to start scrolling.)
@LOGO@)
KILLED JOB 16, USER KAMANITZ, ACCOUNT 341, TTY 106,
AT 19-5EP-79 14:46:53, USED 0:00:01 IN 0:05:37

8-8

APPENDIXES

APPENDIX A
DISCONNECT OR REJECT CODES

The disconnect or reject codes in Table A-I are defined by NSP and are
sent and retrieved by network tasks with the network functions of the
MTOPR monitor call.
Table A-I
Disconnect or Reject Codes
Symbol Value

.DCXO
.DCXl
.DCX2
.DCX3
.DCX4
.DCX5
.DCX6
.DCX7
.DCX8
.DCX9
.DCXll
.DCX2l

11
21

.DCX24
.DCX32
.DCX33
.DCX34
.DCX35
.DCX36
.DCX37
.DCX38
.DCX39
.DCX40
.DCX4l
.DCX42
.DCX43

24
32
33
34
35
36
37
38
39
40
41
42
43

1
2
3
4
5
6
7
8
9

Meaning
No special error
Resource allocation failure
Destination node does not exist
Node shutting down
Destination process does not exist
Invalid name field
Process too busy
Unspecified error
Third party aborted the logical link
User abort (asynchronous disconnect)
Undefined error code
Connect initiate (CI) with illegal destination
address
Flow control violation
Too many connections to node
Too many connections to destination process
Access not permitted
Logical link services mismatch
Invalid account
Segment size too small
Process aborted
No path to destination node
Link aborted due to data loss
Destination logical link address does not exist
Disconnect confirmation
Image data field too long

A-I

APPENDIX B
OECnet OBJECT TYPES

The object types listed in Table B-1 are taken from the Network
Services Protocol, Version 3.2 documentation. Object type codes are
expressed in decimal.
DECnet-20 will, in addition, recognize a number
of object names in place of object types.
Object names that are
currently supported are shown in Table B-1.
Object type 0 (TASK) can only be used by a source task in order to
address a target task.
Object types 1 through 127 can be used by any
system task;
however, the task must have WHEEL or OPERATOR privileges
enabled.
Object types 128 through 255 are available to all network
tasks.
Table B-1
DECnet Object Types
Object
Type
Code

Object
Name
TASK

2
3-4

5
6
7
8-14
15
16
17
18
19
20-62
63
64-127
128-255

NRM

FAL
NCU

Function
General task, user process
File Access (FAL/OAP-Version 1)
unit Record Services
Reserved for DECnet use
RSX-llM Task Control-Version 1
Reserved for DECnet use
Node Resource Manager
Reserved for DECnet use
RSX-llM Task Control-Version 2
System TALK Utility
File Access (FAL/DAP-Version 4)
RSX-llS Remote Task Loader
NICE process
Reserved for DECnet use
DECnet Test Tool (DTR)
Reserved for DECnet control
Reserved for customer extensions

B-1

APPENDIX C
GLOSSARY

asynchronous transmission

Transmission in which the time intervals
between transmitted characters may be of
unequal length because each character
contains its own start and stop bits.
start/stop
This is also
known
as
transmission.

computer network

An interconnection of computer systems,
I/O
devices,
and
communications
facilities.

connect

The process of creating a logical link.

connect password

A 1- to 39-character password used to
validate access privileges between tasks
on a network.

DAP (Data Access Protocol)

A set of standardized
formats
and
procedures that facilitate the creation,
deletion, transfer, and access of files
between a user process and a file system
existing in a network environment.

data transmission

The sending of data from one computer to
another over a physical link, or from
one task to another over a logical link.

DDCMP

Digital Data
Communications
Message
Protocol.
A formal set of conventions
designed
to
provide
error-free,
seauential transmission of data over
physical links.

disconnect

The process of closing a logical link.

DMCll

A
single
line
microprocessor-based
interface to the network.
The DMCll is
a synchronous Direct Memory Access DMA
device.

DN20

A communications front end.

DNMAC

The DNMAC program is the cross assembler
for PDP-II macro source files.

C-l

GLOSSARY
down-line loading

Transmitting a program's memory image
over a logical link and loading and
starting the program on a computer at
another node.

DTE20

The hardware interface between the KLIO
main processor in a DECSYSTEM-2040S/2060
and the PDP-II processor in the DN20
communications front end.

duplex

Simultaneous independent transmission in
both directions.
Also referred to as
full-duplex or two-way simultaneous.

_- .... _.a..a._ ....
FAL (File Access ......r.;c::~~n~r'
I

'T'h~
J,..a.,I. ......

J<I:ar. nrnnr::>m
1::"'&""'':::7.''''''''''''

......

~ ......

roc::;r!oc::
... '-"-"..&.."""'-....,

1"\1"\
::>
'V ............

T)J<lf""1"\O+4JJ.-I"' ...... ' - ' -

hl"\C::+.1."',-,"-"_

and acts as the target for requests made
by the NFT programs residing on remote
DECnet
hosts.
The FAL program is
responsible for determining a user's
access privileges to a requested file
and the subsequent honoring or rejecting
of the request.
full-duplex

See duplex.

half-duplex

Transmission in either direction, but
not in both directions simultaneously.
Also referred to as two-way alternate.

host computer

A computer at a network node
that
primarily
provides services such as
computation, data base access, special
programs, or programming languages to
other nodes in the network.

interrupt message

A high-priority message used to inform
another task of some significant event.

local node

A relative term indicating the node at
which your task is executing or at which
your terminal is logged in.

local NSP

NSP executing in the local node.

local task

A task executing at a local node.

logical link

A virtual data path between two tasks in
a
network
that
permits
them
to
communicate.
A
physical
link
can
contain many logical links.

loop-back

A
mode
of
operation
where
data
transmitted
by
a
network task is
reflected at some point
along
the
communication path and is returned to
the originating task.

modem

In networks, a
device
that
computer
signals
capable
of
transmitted over telephone lines
known as a dataset) •

C-2

makes
being
(also

GLOSSARY
MOP

Maintenance
Operation
Protocol.
A
formal set of messages and rules used to
load and dump computer memory as well as
test a communications link between two
adjacent nodes.

NCP

NCP is the name of the network control
program that processes network control
commands. For DECnet-20, NCP is part of
the program, NMLT20.

network

An interconnected or interrelated group
of nodes.
In this manual, network is
synonymous with computer network.

network dialogue

An exchange of information
tasks in a network.

network task

A task engaged in, or willing to engage
in,
a
network
dialogue.
In NSP
documentation, a network task is also
referred to as a network object.

NFT (Network File Transfer)

A program that allows you to access or
delete files residing on DECnet hosts
that
provide
network
file
access
capabilities. NFT initiates the service
requests that will be carried out by the
FAL program.

NICE protocol

NICE is the acronym for the Network
Information
and
Control
Exchange
protocol that enables various DIGITAL
computers to access the information and
control facilities of remote nodes on
the same network.

NMLT20

The Network Management Layer running
under TOPS-20. NMLT20 provides network
management functions for DECnet-20.

node

An endpoint of any branch of a network,
or a junction common to two or more
branches of a network.
A node is a
processor plus communications software
and constitutes one end of a physical
link in a network. In this manual, the
DECSYSTEM-20 and
any
communications
front ends are all considered nodes.

node name

A 1- to 6-character
name
uniquely
identifying a node within a network.
Node names can be any combination of the
characters A through Z, and 0 through 9.
A node name must contain at least one
alphabetic character.

node number

A number uniquely
within a network.

C-3

between

identifying

two

node

GLOSSARY

NSP

Network Services Protocol. A formal set
of conventions used in DECnet to perform
network management and
to
exchange
messages over logical links. NSP also
refers to the software that implements
the NSP protocol.
(In the text, NSP
refers to the software; NSP protocol is
used to refer to the protocol.)

packet

A group of bits, comprising data and
control
information,
which
is
transmitted as a composite whole over a
physical link.
The data, control, and
possibly error control information are
arranged in a specified format.

physical link

A communications
path
between
two
adjacent nodes. This can be in the form
of a dial-up line, leased line, radio,
satellite link, or a channel-to-channel
connector such as a DTE.

protocol

A formal set of conventions or rules
governing the format and relative timing
of message exchange.

remote node

A node in a network
local node.

remote NSP

NSP executing in a remote node.

remote task

A task executing in a remote node.

server task

Also known as a
target
task,
an
alternate designation for a task that
has declared itself willing to accept a
network connection, usually to provide
some system service.

source node

The node at which the request for a
connection is initiated or from which a
message is transmitted.

source task

The task in which the request for a
connection is initiated or from which a
message is transmitted.

synchronous transmission

Transmission in which time intervals
between transmitted characters are of
equal length. Multiple characters can
be transmitted without start or stop
bits following an initial synchronizing
sequence.

target node

Also known as a server task, the node at
which the request for a connection is
accepted or rejected or to which a
message is transmitted.

target task

Any task that has
declared
itself
willing to accept a network connection.

C-4

that

not

your

INDEX

Aborting a network
connection, 5-2
notification of, 5-2
reason code, 5-2
Accepting a connection,
3-23
Access information switches,
7-7
IACCOUNT, 7-7
IPASSWORD, 7-7
IUSER, 7-7
Accessible nodes,
listing, 7-6
Accessing files,
on remote hosts, 7-1, 7-2
Account string,
reading the, 3-18
IACCOUNT switch, 7-7
IASCII switch, 7-7
Asynchronous transmission,
defined, C-l

Batch file,
for remote node, 7-18
BIN monitor call, 2-5, 4-2,
4-3
BOOT monitor call, 2-5
BOUT monitor call, 2-5, 4-2
.BTBEL function of BOOT,
2-5
.BTCLI function of BOOT,
2-5
.BTCPN function of BOOT,
2-5
.BTDMP function of BOOT,
2-5
.BTIPR function of BOOT,
2-5
.BTLDS function of BOOT,
2-5
.BTLOD function of BOOT,
2-5
.BTRMP function of BOOT,
2-5
.BTROM function of BOOT,
2-5
.BTSTS function of BOOT,
2-5
.BTTPR function of BOOT,
2-5

Changing output destination,
6-2 to 6-4
Clearing interrupts, 3-11
CLOSF,
with CZ%ABT, 5-3
CLOSF monitor call, 2-5,
5-1 to 5-4
CLOSF monitor call,
example, 5-3 to 5-5, 5-7
with CZ%ABT, 5-2, 5-3
Closing a logical link, 5-1,
5-2
Closing a network
connection, 5-1
NSP control, 5-1
Closing a network JFN,
5-1 to 5-3
Coding examples,
source task, 5-5
target task, 5-6, 5-7
Command file,
executing, 8-19
passwords omitted, 8-19
Commands, NFT, See NFT commands
Communications front end,
1-2
Computer network,
defined, C-l
Connect,
defined, C-l
Connect confirm message,
3-23
explicit, 3-23
implicit, 3-23
Connect event interrupt,
3-11
Connect initiate message,
3-1, 3-10
Connect password,
defined, C-l
Connect reject message,
explicit, 3-23
implicit, 3-24
reading data in, 3-19
reject code, 3-24
Connection,
establishing a, 3-1
Console front end, 1-2
COpy (NFT command), 7-6 to 7-13
examples, 7-11, 7-12
switches, 7-7

Index-l

INDEX (CONT.)

Creating a logical link,
example, 5-5
CZ%ABT flag bit for CLOSF,
5-2, 5-3

DAP protocol, 1-3, 7-1
DAP protocol,
defined, C-7
Data,
segmentation of, 4-1
sending, 4-2
Data available interrupt,
3-11
Data transfers,
continuous stream, 4-1
general, 4-1
logical messages, 4-1
Data transmission,
defined, C-l
DCN: ,
network device, 2-2, 3-1
DCN: device,
a ttr ibutes, 3-6
decriptor, 3-5
file specification, 3-5
hostname field, 3-5
objectid, 3-5
task name, 3-5
.DCXO disconnect code, A-I
.DCXl disconnect code, A-I
.DCXll disconnect code, A-I
.DCX2 disconnect code, A-I
.DCX2l disconnect code, A-I
.DCX24 disconnect code, A-I
.DCX3 disconnect code, A-I
.DCX32 disconnect code, A-I
.DCX33 disconnect code, A-I
.DCX34 disconnect code, A-I
.DCX35 disconnect code, A-I
.DCX36 disconnect code, A-I
.DCX37 disconnect code, A-I
.DCX38 disconnect code, A-I
.DCX39 disconnect code, A-I
.DCX4 disconnect code, A-I
.DCX40 disconnect code, A-I
.DCX4l disconnect code, A-I
.DCX42 disconnect code, A-I
.DCX43 disconnect code, A-I
.DCX5 disconnect code, A-I
.DCX6 disconnect code, A-I
.DCX7 disconnect code, A-I
.DCX8 disconnect code, A-I
.DCX9 disconnect code, A-I
DDCMP,
defined, C-l
DEBRK monitor call, 5-6
example, 5-6

DECnet,
object types, B-1
DECnet-20,
and terminal users, 6-1
capabilities, 1-2
monitor calls, 2-5
options, 1-1
programmer interface, 1-3
protocols, 1-1
software, 1-1
structure: 1-2
user interface, 1-3
DECnet-20 concepts, 2-1
network as an I/O device,
2-1
network JFNs, 2-3
task a file, 2-1
DECSYSTEM-2040S/2060
structure, 1-2
Defaults,
file processing modes,
7-10
task name, 3-15
DELETE (NFT command), 7-14
Deleting files,
on remote hosts, 7-1,
7-14
Demultiplexing, 2-3
/DESTINATION-NODE switch,
6-4
example, 6-4
Digital Data Communications
Message Protocol, See
DDCMP
Digital Network
Architecture, See DNA
DIRECTORY (NFT command) ,
7-14 to 7-17
Disconnect,
defined, C-l
Disconnect codes,
table of, A-I
with MTOPR, 5-3
Displaying files,
from remote node, 7-19
DMCll,
defined, C-l
DN20,
defined, C-l
DNA, 1-1
DNMAC,
defined, C-l
Down-line loading,
defined, C-2
DTE,
defined, C-2
interface, 2-2
Duplex,
defined, C-2

Index-2

INDEX (CONT.)

Enabling for interrupts,
3-11, 3-12
Error messages,
NFT, 7-19 to 7-23
Establishing a network
connection, 3-1
Examples,
aborting a logical link,
5-3, 5-4
CLOSF monitor call,
5-3 to 5-5, 5-7
connect confirm, 3-24
COPY, 7 -11, 7 -12
CZ%ABT flag bit, 5-3
DCN: specification, 3-8
DEBRK monitor call, 5-6
deleting remote files,
7-14
/DESTINATION-NODE switch,
6-4
enabling interrupts, 3-12
EXIT (NFT command), 7-18
GTJFN monitor call, 5-5
HELP (NFT command), 7-17
INFORMATION (NFT command) ,
7-6
INFORMATION (TOPS-20
command), 6-2
listing remote directory,
8-15 to 8-17
.MOACN function, 3-12,
5-6
.MOCC function, 3-24, 5-6
.MOCLZ function, 3-25, 5-2
.MORAC function, 3-18
.MORCN function, 3-20
~MORDA function, 3-19
.MORHN function, 3-14
.MORIM function, 4-7
.MORLS function, 4-4,
5-7
.MOROD function, 3-21
.MORPW function, 3-17
.MORSS function, 3-22
.MORTN function, 3-15
.MORUS function, 3-16
.MOSIM function, 4-6
MTOPR monitor call, 3-12,
3-13 to 3-22, 3-24, 3-25,
4-6, 4-7, 5-5 to 5-7
network file
specification, 3-8
OPENF monitor call, 5-5,
5-6
PLEASE, 6-3
processing interrupts,
5-7
programming, 5-5 to
5-7

Examples (Cont.)
reading host name, 3-14
reading logical link
status, 3-13
sending user data, 3-24,
3-25
SET DEFAULTS, 7-3
SET LOCATION, 6-3
SIBE monitor call, 5-7
SINR monitor call, 5-7
source task coding,
5-5
SOUTR monitor call, 5-5
SRV: specification, 3-8
target task coding, 5-6,
5-7
using CZ%ABT, 5-3, 5-7
using MO%CDN, 3-12
using MO%DAV, 3-12
using MO%INA, 3-12
using . MOACN, 3-12
WAIT, 3-12, 5-6
Executing command file,
7-19
EXIT (NFT command), 7-17
Exiting,
from NFT, 7-17

FAL object name, B-1
FAL P r og r am , 7 -1
and DAP, 7-1
defined, 7-1, C-2
responsibilities of, 7-1
File processing mode,
for local source files,
7-13
for remote source files,
7-13
File processing modes (NFT) ,
default destination modes,
7-13
restrictions on, 7-13
File specification,
examples, 3-7
field lengths, 3-4 to 3-7
network, 3-3
Filespec format,
for remote operating
systems, 7-2
/FIXED switch, 7-7
Full-duplex,
defined, C-2

Index-3

Generic task identification,
2-3

INDEX (CONT.)

Glossary, C-l to C-4
GTJFN,
file specification, 3-3
GTJFN monitor call, 2-3,
2-5, 3-1, 3-3, 5-5, 5-6
example, 5-5
filespec, 3-3
for source task, 5-5
for target task, 5-6

Half-duplex,
defined, C-2
HELP (NFT command), 7-17, 7-18
Host computer,
defined, C-2
Host name,
reading, 3-14

/IMAGE switch, 7-7
INFORMATION (NFT command),
7-5
examples, 7-6
Information switches,
/ACCOUNT access, 7-6
INFORMATION (TOPS-20
command), 6-2
Interface,
programmer, 1-3, 2-4
terminal user's, 1-3
Interrupt,
connect pending, 3-11
data available, 3-11
message available, 3-11
Interrupt messages,
defined, C-2
limit, 4-6
receiving, 4-7
sending, 4-6
Interrupts,
clear ing, 3-11
enabling for, 3-11, 3-12
example of coding, 5-6
processing, 5-6, 5-7
setup for, 5-6

Link data base, 3-9
Link status, 3-10
Link, See Logical link
or Physical link
Listing accessible nodes,
7-6
Listing directory,
examples, 8-15 to 8-17
on remote node, 7-14 to 7-16
Listing nodes,
for file transfer, 7-6
Local node,
defined, C-2
Local NSP,
defined, C-2
Local task,
defined, C-2
Logical link, 2-2
assigned, 3-1
closing a, 5-1 to 5-3
creating a, 5-5
defined, C-2
JFN of, 3-9
Logical link data,
reading, 3-12
Logical link data base,
3-12
Logical link status, 3-13
flag bits, 3-13, 5-2
reading, 3-13
Logical links,
quotas, 3-10
segment size, 4-1
Loop-back,
defined, C-2

JFN,
closing d network, 5-2, 5-3
Job status,
information about, 6-2

Index-4

/MACYll switch, 7-7
Messages,
NFT, 7-19 to 7~23
MO%ABT link status bit,
3-13, 5-3
MO%CDN link status bit,
3-11
using, 3-12
MO%CON link status bit,
3-13
MO%DAV field for .MOACN
function, 3-11, 3-12
MO%DAV link status bit,
3-11

INDEX (CONT.)

MO%DAV link status bit
(Cont.)
using, 3-12
MO%EOM link status bit,
3-13
MO%INA field for .MOACN
function, 3-11, 3-12
MO%INA link status bit,
3-11
using, 3-12
MO%INT link status bit,
3-13
MO%LWC link status bit,
3-13
MO%SRV link status bit,
3-13
MO%SYN link status bit,
3-13, 5-2
MO%WCC link status bit,
3-13
MO%WFC link status bit,
3-13
.MOACN function of MTOPR,
2-6, 3-11, 3-12, 5-6
example, 3-12, 5-6
MO%CDN field, 3-12
.MOANT Function of MTOPR,
2-6
.MOCC function of MTOPR,
2-6, 3-23, 5-6
.MOCIA interrupt control
value, 3-11
.MOCLZ function of MTOPR,
2-6, 3-23, 3-25, 5-1,
5-2
abort, 5-2
example, 5-2
followed by CLOSF, 5-1
normal close, 5-2
Modem,
defined, C-2
.MONCI interrupt control
value, 3-11
Monitor calls,
BIN, 2-5, 4-2, 4-3
BOOT, 2-5
BOUT, 2-5, 4-2
CLOSF, 2-5, 5-1 to 5-4, 5-7
facilities, 2-4
for receiving data, 4-2
for sending data, 4-2
functions, 2-5
GTJFN, 2-3, 2-5, 3-1, 3-3,
5-5, 5-6
MTOPR, 2-5, 2-6,
3-11 to 3-25, 4-6, 4-7
network related, 2-5
NODE, 2-5, 2-6
OPENF, 2-5, 3-1, 3-9, 5-5

Index-5

Monitor calls (Cont.)
SIBE, 2-5, 4-3
SIN, 2-5, 3-10, 4-3
SINR, 2-5, 3-10, 4-3
SOU T, 2 - 5, 4 - 2
SOUTR, 2-5, 4-2, 5-5
Monitor calls used, 1-3
MOP,
defined, C-3
.MORAC function of MTOPR,
2-6, 3-18
.MORCN function of MTOPR,
2-6, 3-20
.MORDA function of MTOPR,
2-6, 3-19
.MORHN function of MTOPR,
2-6, 3-14
.MORIM function of MTOPR,
2-6, 4-7
example, 4-7
.MORLS function of MTOPR,
2-6, 3-13, 4-3 to 4-5,
5-2, 5-3, 5-7
example, 3-13, 4-4, 5-7
.MOROD function of MTOPR,
2-6, 3-21
.MORPW function of MTOPR,
2-6,3-17
.MORSS function of MTOPR,
2-6, 3-22
.MORTN function of MTOPR,
2-6, 3-15
.MORUS function of MTOPR,
2-6, 3-16
.MOSIM function of MTOPR,
2-6, 4-4
example, 4-6
.MOSNH Function of MTOPR, 2-6
MTOPR monitor call, 2-5,
2-6, 3-11 to 3-25, 5-5
calling sequence,
3-11 to 3-25, 4-4,
4-5, 5-1, 5-3
example, 3-12 to 3-25, 4-6,
4-7, 5-6 to 5-7
functions, 2-6
Multiplexing, 2-3

NCP,
defined, C-3
NCU object name, B-1
.NDCIC function of NODE,
2-6
.NDCLP function of NODE,
2-6
.NDFLP function of NODE,
2-6

INDEX (CONT.)

.NDGLI function of NODE,
2-6
.NDGLN function of NODE,
2-6
.NDGNM function of NODE,
2-6
.NDGNT function of NODE,
2-6
.NDGVR function of NODE,
2-6
.NDSIC function of NODE;
2-6
.NDSLN function of NODE,
2-6
.NDSLP function of NODE,
2-6
.NDSNM function of NODE,
2-6
.NDSNT function of NODE,
2-6
.NDVFY function of NODE,
2-6
Network,
defined, C-3
Network access, 2-1
Network connection,
aborting a, 5-2
accepting, 3-23
closing a, 5-1
normal close, 5-1, 5-2
rejecting, 3-23
specifying, 3-5 to 3-7
Network dialogue,
defined, C-3
Network facilities, 2-4
Network file access, 7-1
Network File Transfer, See
NFT program
Network JFNi 2-3, 3-1
closing a, 5-2, 5-3
obtaining a, 3-2
Network Job File Number,
See Network JFN
Network task,
defined, C-3
NFT program, 1-1, 1-3, 7-1
to 7-23
and DAP, 7-1
and NFT.INIT, 7-2 to 7-4
changing access
information, 7-2, 7-3
commands, list of, 7-2
COpy command, 7-6 to 7-13
default access
information, 7-3
defined, 8-1, C-3
DELETE command, 7-14
DIRECTORY command,
7-14 to 7-17

NFT program (Cont.)
EXIT command, 7-17
fatal error messages,
7-20 to 7-22
file processing modes,
7-13
HELP command, 7-17, 7-18
INFORMATION command, 7-5
internal NFT errors, 7-23
listing accessible nodes,
7-6
listing remote directory,
7-14 to 7-17
NFT.INIT file example,
7-4
protocol for, 1-3
processing mode switches,
7-7
record length switches, 7-7
running, 7-2
SET DEFAULTS command, 7-3 to
7-5
SUBMIT command, 7-18
TAKE command, 7-19
transferring files,
7-6 to 7-13
TYPE command, 7-19
warning messages, 7-20
NFT.INIT file, 7-3, 7-4
example of, 7-4
procedure when none, 7-16
NICE protocol
defined, C-3
NMLT20,
defined, C-3
Node,
defined, C-3
Node identification, 2-4
name, 2-4
number, 2-4
NODE monitor call, 2-5, 2-6
functions, 2-6
Node name, 2-4
defined, C-3
Node number, 2-4
defined, C-3
NRM object name, B-1
NSP, 2-6, 3-24, 4-6, 5-1,
5-2, A-I
NSP protocol,
defined, C-4

Object descriptor,
reading the, 3-21
Object descriptors, 2-4
OBJECT names,
FAL, B-1

Index-6

INDEX (CONT.)

OBJECT names (Cont.)
NCU, B-1
NRM, B-1
TASK, B-1
Object type,
reading the, 3-20
Object types, 2-3, B-1
Object types,
table of, B-1
Obtaining a network JFN,
example, 5-5
OPENF monitor call, 2-5,
3-1, 3-9, 5-5
example, 5-5, 5-6
for network connection,
3-10
for target task, 3-9
Opening a network JFN, 3-9
Optional data,
reading the, 3-19
Output destination,
changing, 6-2 to 6-4
specifying, 6-2 to 6-4

Packet,
defined, C-4
formation of, 4-1
PASSWORD,
reading the, 3-17
/PASSWORD switch, 7-7
Physical link, 2-2
defined, C-4
segment size, 4-1
PLEASE,
example, 6-3
PRINT (TOPS-20 command),
DESTINATION-NODE switch,
6-4
Printing files,
specifying output
destination, 6-4
Processing mode switches,
7-7
/ASCII, 7-7
/IMAGE, 7-7
/MACYll, 7-7
Programmer interface, 1-3,
2-4
Programmer interface,
MACRO, 2-4
monitor calls, 2-4
Protocols,
collectively, 1-1
DAP, 1-3
defined, C-4

Quota of open links, 3-10
job, 3-10
system, 3-10

Reading host name, 3-14
Reading link status, 3-13
Reading logical link data,
3-12
Reading task name, 3-15
Reading the account string,
3-18
Reading the object
descriptor, 3-21
Reading the object type,
3-20
Reading the optional data,
3-19
Reading the password, 3-17
Reading the segment size,
3-22
Reading ~ser name, 3-16
Reason code for aborting a
connection, 5-3
Receiving interrupt
messages, 4-7
Record length switches, 7-7
/FIXED, 7-7
/VARIABLE, 7-7
Reject codes, 3-23 to 3-25
sending data with,
3-23 to 3-25
table of, A-I
Rejecting a connection,
3-23 to 3-25
Remote file transfer,
7-6 to 7-13
Remote node,
defined, C-4
Remote nodes,
deleting files from, 7-1, 7-14
displaying files from,
7-19
listing directory from,
7-14 to 7-17
submitting Batch file to,
7-18, 7-19
transferring files
to/from, 7-6 to 7-13
Remote NSP,
defined, C-4
Remote task,
defined, C-4
Retrieval of source task
attributes, 3-7
RJE option, 1-1

Index-7

INDEX (CONT.)

Scrolling, SETHOST and, 8-3, 8-7,
ov-v
0

Segment size,
of logical links, 4-1
of physical links, 4-1
reading the, 3-22
Segmentation of data, 4-1
Sending data, 4-1, 4-2
effect of buffer size on,
4-2
example, 5-5
monitor calls for, 4-2
segmenting, 4-1
Sending interrupt messages,
4-6
Server task,
defined, C-4
SET DEFAULTS, 7-3 to 7-5
and NFT.INIT, 7-3
example, 7-3
SET LOCATION, 6-2 to 6-4
example, 6-3
SETHOST program, 8-1 to 8-8
controlling scrolling with,
8-3, 8-7, 8-8
exiting with, 8-2, 8-3
login with, 8-1, 8-2
sample terminal sessions with,
8-4 to 8-8
SIBE monitor call, 2-5, 4-3
before DEBRK, 4-3
example, 5-7
use with interrupt, 4-3
SIN monitor call, 2-5, 3-10,
4-3
SINR monitor call, 2-5,
3-10, 4-3
example, 5-7
Source node,
defined, C-4
Source task, 2-1, 3-1
Source task,
attributes, 3-6
defined, C-4
file specification, 3-5
identification, 3-21
unique task name, 3-5
Source task coding,
example of, 5-5
SOUT monitor call, 2-5, 4-2
use with SOUTR, 4-2
SOUTR monitor call, 2-5,
4-2, 5-5
example, 5-5
Specifying a network
connection, 3-5
account, 3-6
descriptor, 3-5
host name, 3-5

Specifying a network (Cont.)
object name, 3-5
object type, 3-5
password, 3-6
task name, 3-5
userdata, 3-7
userid, 3-6
Specifying a target task,
3-3
Specifying output
destination, 6-2 to 6-4
SRV: ,
descriptor, 3-4
file specification, 3-3
network device, 2-1, 3-1
objectid, 3-3
task name, 3-4
SUBMIT (NFT command), 7-18
Submitting Batch file,
to remote node, 7-18
Switches,
/ACCOUNT, 7-7
/ASCII, 7-7
access information, 7-7
/DESTINATION-NODE, 6-4
/FIXED, 7-7
for file transfer, 7-7
/IMAGE, 7-7
in DELETE (NFT command) ,
7-14
in DIRECTORY (NFT
command), 7-14
in SUBMIT (NFT command) ,
7-18, 7-19
in TYPE (NFT command),
7-19
/MACYll, 7-7
NFT COpy command, 7-6, 7-7
/PASSWORD, 7-7
processing mode, 7-7
record length, 7-7
/USER, 7-7
/VARIABLE, 7-7
Synchronous transmission,
defined, C-4
System,
overview, 1-1 to 1-3

Index-8

TAKE (NFT command), 7-19
Target node,
defined, C-4
Target task, 2-1, 2-2, 3-1
defined, C-4
file specification, 3-3
retrieval source task
attributes, 3-7
unique task name, 3-4

INDEX (CONT.)

Target task coding,
example of, 5-6, 5-7
Task,
remote, C-4
server, C-4
source, 2-1, 3-1, C-4
target, 2-1, 3-1, C-4
Task identification,
gener ic, 2-3
unique, 2-4
Task name,
reading the, 3-15
TASK object name, B-1
Task-to-task capabilities,
1-2
Terminal user,
accessing DECnet
information, 6-1
Terminal user's interface,
1-3
Terminal users,
remote login for, 8-1 to
8-8
transferring files, 6-1
Throughput,
increasing, 3-10
TOPS-20 commands,
INFORMATION, 6-2
relating to DECnet-20,
6-1
Transferring files, 7-6 to 7-13
by terminal user, 6-1
default destination modes,
7-13
giving file processing
mode, 7-13
required specifications,

7-13
restrictions, 7-13
Transferring information
over the network, 4-1 to 4-7
See
also Sending data
TYPE (NFT command), 7-19

Unique task identification,
2-4, 3-15
monitor supplied, 3-15
User data,
with connect confirm
message, 3-24
User name,
reading, 3-16
User notificataion of abort,
5-3
IUSER switch, 7-7
USERID,
reading the, 3-16

IVARIABLE switch, 7-7

WAIT,
example of, 5-6
for interrupts, 5-6
Waiting for connect,
example, 5-5
Warning messages,
NFT, 7-20

Index-9

DECnet-20 User's Guide
AA-J679A-TM

READER'S COMMENTS
/

NOTE:

This form is for document comments only. DIGITAL will use comments submitted on
this form at the company's discretion. If you require a written reply and are eligible to
receive one under Software Performance Report (SPR) service, submit your comments on an SPR form.

Did you find this manual understandable, usable, and well-organized? Please make suggestions for improvement.

Did you find errors in this manual? If so, specify the error and the page number.

Please indicate the type of reader that you most nearly represent.

D Assembly language programmer
D Higher-level language programmer
D Occasional programmer (experienced)
D User with little programming experience
D Student programmer
D Other (please specify)~~~~~~~~~~~~~~~~~~~~~
Name __________________________________ Date ____________________
Organization

Telephone __________________

Street ____________________________________________
City ____________________~ State ______ Zip Code _ __
or Country

I
I
I

-~.- _gD;tgTear - F~.ldHoere and Ta~ - - - - - - - - - -- - - - - - - - - - - - ~ -111--------~~~~;:;~~ ---:'1
~

if Mailed in the
United States

BUSINESS REPLY MAIL
FIRST CLASS PERMIT NO. 33 MAYNARD MASS.
POSTAGE WILL BE PAID BY ADDRESSEE

SOFTWARE PUBLICATIONS

200 FOREST STREET MR01-2/L 12
MARLBOROUGH, MA 01752

I
1
1
1

I
I
1
1
1

I
I
1
1

I
1
1

-- - -

Do Not Tear - Fold Here and Tape

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I1
1
1
1
1

I
1
1

1
1

I
I
I
1
1

I
I

(IJ

1.5
I..J

I::::
1 0

1°
I~
I's

1<
I:;
IU
1

I
I
1