Digital PDFs

AA-5091B-TM

May 1980

308 pages

Original

9.7MB

Document:	TOPS-20 DECnet-20 Programmers Guide Jan80
Order Number:	AA-5091B-TM
Revision:	0
Pages:	308
Original Filename:	AA-5091B-TM_TOPS-20_DECnet-20_Programmers_Guide_Jan80.pdf

OCR Text

TOPS-20 DECnet-20
Programmer's Guide and
Operations Manual
AA-50918-TM

January 1980

This manual describes DECnet-20, a product that together with
TOPS-20 provides the DECSYSTEM-20 family of computers
with a communications interface to DIGITAL's corporate
network, DECnet.
This manual supersedes TOPS-20 DECnet-20 Programmer's
Guide and Operations Manual, Order Number AA-5091A-TM.

OPERATING SYSTEM:

TOPS-20 Version 4
DECnet-20 Version 2

SOFTWARE:

Software and manuals should be ordered by title and order number. In the United States, send orders to the nearest
distribution center. 0 utside the United States, orders shou Id be directed to the nearest DIG I TAL Field Sales Office
or representative.
NORTHEAST/MID-ATLANTIC REGION

CENTRAL REGION

WESTERN REGION

Technical Documentation Center
Cotton Road
Nashua, N H 03060
Telephone: (800) 258-1710
New Hampshire residents: (603) 884-6660

Technical Documentation Center
1050 East Remington Road
Schaumburg, Illinois 60195
Telephone: (312) 640-5612

Technical Documentation Center
2525 Augustine Drive
Santa Clara, California 95051
Telephone: (408) 984-0200

digital equipment corporation • marlboro, massachusetts

First Printing, September 1978
Revision, January 1980

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 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.
The following are trademarks of Digital Equipment Corporation:
DEC
DECUS
Digital Logo
PDP
UNIBUS
VAX

DECnet
DECsystem-10
DECSYSTEM-20
DECwriter
DIBOL
EduSystem

lAS
MASSBUS
PDT
RSTS
RSX
VMS
VT

CONTENTS

Page
xi

PREFACE
PART I INTRODUCTION
CHAPTER

CHAPTER

SYSTEM OVERVIEW

1-1

1.1
1.2
1.3
1.3.1
1.3.2
1.3.3
1.3.4
1.4
1.5
1.6
1.7

DECnet
DECnet-20 OPTIONS
DECnet-20 STRUCTURE
Hardware Level
Physical Link Control Level
Logical Link Control Level
User or Application Level
DECnet-20 CAPABILITIES
DECnet-20 PROGRAMMER INTERFACE
DECnet-20 OPERATOR INTERFACE
DECnet-20 TERMINAL USER'S INTERFACE

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

CONCEPTS AND FACILITIES

2-1

2.1
2.1.1
'"',.1..,
, '"'
2.1.3

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

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

2.1.4
2.2

PART II PROGRAMMER'S GUIDE
CHAPTER

ESTABLISHING A NETWORK CONNECTION

3-1

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

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 Network Connection
Limit on Open Links
ENABLING FOR NETWORK INTERRUPTS
Example
READING LOGICAL LINK DATA
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

3-2
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

iii

CONTENTS (CONT.)

Page

CHAPTER

3.4.9
3.4.10
3.5
3.5.1
3.5.2
3.5.3

Reading the Object-Descriptor
Reading the Segment Size
ACCEPTING OR REJECTING A CONNECTION
Accepting the Connection
Rejecting the Connection
Examples

3-21
3-22
3-23
3-23
3-23
3-24

TRANSFERRING INFORMATION OVER THE NETWORK

4-1

4.1
4.1.1
4.1.2
4.2
4.2.1
4.2.2

TRANSFERRING DATA
Sending Data
Receiving Data
TRANSFERRING INTERRUPT MESSAGES
Sending Interrupt Messages
Receiving Interrupt Messages

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

CLOSING A NETWORK CONNECTION

5-1

5.1
5.2
5.3

CLOSING A CONNECTION NORMALLY
ABORTING A CONNECTION
SOURCE AND TARGET TASK CODING EXAMPLES

5-1
5-2
5-4

PART III OPERATOR'S GUIDE
CHAPTER

RUNNING DECnet-20

THE NETWORK CONTROL PROGRAM
DECnet-20 STARTUP PROCEDURES
Automatic Startup on a DECSYSTEM-2020
Automatic Startup on a DECSYSTEM-2040,
2050, 2060
Manual Startup on a DECSYSTEM-2020
6.2.3
Manual Startup on a DECSYSTEM-2040,
6.2.4
2050, 2060
6.3
NCP COMMAND SUBSET OF OPR
6.3.1
Data Base Commands
6.3.1.1
Defining the Bootstrap Programs (2040,
2050, 2060)
6.3.1.2
Defining the Loading Node (2040, 2050,
2060)
6.3.1.3
Defining the Default Load File (2040,
2050, 2060)
6.3.1.4
Defining the Default Dump File (2040,
2050, 2060)
6.3.1.5
Defining the Protocol (2040, 2050, 2060)
Initiating Logging (all models)
6.3.1.6
6.3.1.7
Terminating Logging (all models)
Setting Logging Interval (all models)
6.3.1.8
Enabling Local Loopback (2020)
6.3.1.9
6.3.1.10
Disabling Local Loopback (2020)
Controlling Automatic Reloading
6.3.1.11
(2040,2050,2060)
6.3.1.12
Controlling Automatic Dumping
(2040,2050,2060)
6.3.2
Action Commands
6.3.2.1
Loading a Node (2040, 2050, 2060)
6.3.2.2
Dumping a Node (2040, 2050, 2060)

6.1
6.2
6.2.1
6.2.2

6-1
6-2
6-4
6-4
6-7
6-10
6-10
6-11
6-13
6-13
6-13
6-14
6-14
6-15
6-15
6-16
6-16
6-16
6-17
6-17
6-18
6-18
6-18
6-19

CONTENTS (CONT.)

Page
6.3.2.3
6.3.2.4
6.3.2.5
6.3.2.6
6.3.2.7
6.3.2.8
6.3.2.9
6.3.2.10
6.3.2.11
6.3.2.12
6.3.2.13
6.3.2.14
6.3.3
6.3.3.1
6.3.3.2
6.3.3.3
6.3.3.4
6.4
6.5
6.5.1
6.5.2
6.5.3
6.5.4

Checking NETCON's Request Queue (all
models)
Displaying Line Statistics (all models)
Exiting from NCP Subset (all models)
Loading a Line Controller (2020)
Dumping a Line Controller (2020)
Starting a Line (all models)
Starting a Line for Controller Loopback
(2020)
Starting a Line for Cable Loopback
( 2020)
Stopping a Line (all models)
Performing a Loopback Test
(2040,2050,2060)
Interrogating Node Status (all models)
Interrogating Line Status (all models)
Miscellaneous Commands
Setting and Displaying Executor Node
(all models)
Turning Event/Error Logging On or Off
(2040,2050,2060)
Getting Another Copy of the TOPS-20
Command Processor (all models)
Executing NCP Commands From a File
(all models)
RESTART PROCEDURES
OPERATOR MESSAGES
NETCON Command Responses
NETCON Warning Messages
NETCON Fatal Error Messages
Other Error Messages

6-19
6-20
6-20
6-20
6-21
6-21
6-21
6-22
6-22
6-22
6-23
6-23
6-23
6-23
6-24
6-24
6-24
6-25
6-26
6-26
6-28
6-29
6-30

PART IV TERMINAL USER'S GUIDE
CHAPTER

CHAPTER

COMMUNICATING WITH THE SYSTEM

7-1

7.1
7.1.1
7.1.2
7.2
7.3
7.4

INFORMATION COMMAND
Information DECnet
Information Job-Status
SET LOCATION COMMAND
/DESTINATION-NODE SWITCH
ADDITIONAL FEATURES AVAILABLE TO
NONPRIVILEGED USERS

7-2
7-2
7-2
7-2
7-4

NETWORK FILE TRANSFER

8-1

8.1
8.1.1
8.2
8.2.1
8.2.2
8.2.3
8.2.4
8.2.5
8.2.6
8.2.7
8.2.8
8.2.9

OVERVIEW
Specifying File Access Information
NFT COMMANDS
SET DEFAULTS Command
INFORMATION Command
COpy Command
DELETE Command
DIRECTORY Command
EXIT Command
HELP Command
SUBMIT Command
TAKE Command

8-1
8-1
8-2
8-2
8-5
8-6
8-11
8-11
8-14
8-14
8-15
8-15

7-4

CONTENTS (CONT.)

Page
8.2.10
8.3
8.3.1
8.3.2
8.3.2.1

TYPE Command
NFT ERROR MESSAGES
NFT Warning Message
NFT Fatal Error Messages
Internal NFT Program Errors

8-15
8-16
8-16
8-16
8-18

PART V GENERATING DECnet-20
9

USING THE CONFIGURATION TOOLS

9-1

9.1
9.2
9.3
9.3.1
9.3.1.1
9.3.1.2
9.4
9.5

CONFIGURATION OVERVIEW
PREPARING TO USE THE CONFIGURATION TOOLS
THE CONFIGURATION TOOLS AND RELATED FILES
The NETGEN Program
Features
NETGEN Terms and Concepts
CONFIGURING FOR TASK-TO-TASK CAPABILITY
CONFIGURING FOR REMOTE JOB ENTRY

9-1
9-3
9-4
9-5
9-5
9-6
9-10
9-23

INSTALLING DECnet-20

10-1

10.1
10.2
10.2.1
10.3
10.3.1
10.3.2
10.3.3
10.3.4
10.3.5

INSTALLATION PROCEDURE
INSTALLATION VERIFICATION PROCEDURE
Verification Procedure Messages
INSTALLATION CERTIFICATION PROCEDURE
Loopback Connector
Local-NCP Test
Line Loopback Test
Remote-NCP Test
Remote and Local Node Network File
Transfer Test
DN200 Tests (2040/50/60 with Remote Job
Entry Station Only)
DECnet Error and Event Logging Test

10-1
10-12
10-18
10-20
10-21
10-26
10-35
10-40

APPENDIX A

DISCONNECT OR REJECT CODES

A-I

APPENDIX B

DECnet OBJECT TYPES

B-1

APPENDIX C

NETWORK EVENT AND ERROR LOGGING

C-l

OVERVIEW
SYSERR ENTRIES
NETCON Load Entry (event 201)
Node Load Entry (event 202)
Node Dump Entry (event 203)
Hardware Error Entry (event 210)
CHKll Diagnostic Entry (event 220)
Line Status Entry (event 230)

C-l
C-2
C-2
C-4
C-5
C-6
C-8
C-9

APPENDIX D

BIBLIOGRAPHY

D-l

APPENDIX E

GLOSSARY

E-l

CHAPTER

10.3.6
10.3.7

10-48
10-51
10-54

PART VI APPENDIXES

C.l
C.2
C.2.1
C.2.2
C.2.3
C.2.4
C.2.5
C.2.6

CONTENTS (CONT • )

Page
APPENDIX F
F.l
F.2
F.2.1
F.2.2
F.3
F.4
F.4.1
F.4.2
F.5
F.5.1
F.5.2
F.6
F.6.1
F.6.2
F.6.3
APPENDIX G
G.l
G.2

SAMPLE PROGRAMS FOR REMOTE LOGIN

F-l

INTRODUCTION
NRT20 PROGRAM
NRT20 Initialization Routines
NRT20 Operations
STNRT PROGRAM
NRTSRV PROGRAM
NRTSRV Initialization Routines
NRTSRV Operations
INSTALLATION PROCEDURES
Restoring Files from the Distribution
Tape
Editing the PTYCON.ATO File
USING THE REMOTE LOGIN CAPABILITY
Logging in to a Remote Host Using NRT20
Exiting from a Remote Host Using NRT20
Sample Terminal Sessions Using NRT20

F-l
F-l
F-2
F-2
F-3
F-4
F-4
F-5
F-6

TKB20 AND VNP20 WARNING AND ERROR MESSAGES

G-l

TKB20 AND VNP20 WARNING MESSAGES
TKB20 AND VNP20 FATAL ERROR MESSAGF.S

G-2
G-2

F-6
F-7
F-7
F-8
F-9
F-9

Index-l

INDEX

FIGURES
FIGURE

1-1
1-2
2-1
2-2
3-1
5-1
5-2
6-1
6-2
10-1
10-2
10-3
C-l
C-2
C-3
C-4
C-5
C-5.1
C-5.2
C-6
C-7

DECnet-20 on a DECSYSTEM-2040, 2050, 2060
DECnet-20 on a DECSYSTEM-2020
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
Startup Dialogue for TOPS-20 DECnet-20 on a
DECSYSTEM-2020
Startup Dialogue for TOPS-20 DECnet-20 on a
DECSYSTEM-2040, 2050, 2060
Installing DECnet-20 Software
Verifying the DECnet-20 Software
Certifying the DECnet-20 Software
Common Header Section for SYSERR Entry
SYSERR Entry for a NETCON Load
SYSERR Entry for a Node Load
SYSERR Entry for a Node Dump
SYSERR Entry for Hardware Detected Failures
Log Data for KMCll/DUPll
Sub-device Table for Hardware Option
DUPll (003)
SYSERR Entry for CHKll Diagnostic Entry
SYSERR Entry for Line Statistics

vii

1-2
1-3
2-1
2-2
3-2
5-5
5-6
6-5
6-8
10-3
10-14
10-23
C-2
C-3
C-4
C-5
C-6
C-7
C-8
C-9

CONTENTS (CONT.)

Page

TABLES
TABLE

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

8-1
10-1

A-I
B-1
C-l

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
NCP Command Summary
COpy Command Switches
SENDER Message Types and Destinations
Disconnect or Reject Codes
DECnet Object Types
Line Counter Types

viii

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

8-7
10-19

A-I
B-1

C-IO

REVISION HISTORY
Enhancements and Changes

This revision reflects the software as of Version 2 of DECnet-20.
major enhancements and changes to the software include:

The

•

Increase in the maximum number of physical links supported for
DECSYSTEMs-2040j2050j2060 to 8.

•

Addition of the network file transfer utility (all models).

•

Support of up to l28K of memory in increments of 32K
DN20 communications front end.

•

Provision
for
on-site
DECSYSTEMs-2040j2050j2060.

generation

for support of the
• Provision
synchronous DMA device)
and

KDP
the

for

DECnet-20

the
for

line controller
(4-1 ine
DN200
(remote job entry

station).
•

Extension of error and event logging capabilities to include
hardware detected errors and CHKll diagnostic messages.

•

Inclusion of additional
terminal user.

•

Addition of new commands and tools
maintainable product than Version 1.

features

The contents of this reVlSlon supersede the
DECnet-20 Version 1 manual.

for

nonprivileged

the
to

provide

entire

contents

NOTES
Chapters 1 through 5 in both the Version
1 and the Version 2 manuals cover the
same topics.
Chapter
6 in the Version 2
manual
describes "Running DECnet-20," which was
described in Chapter 7 of the Version 1
manual.

the

Chapters 7 through 10 in the Version 2
manual are new chapters and therefore
have no counterparts in the Version 1
manual.
All changes from TOPS-20 Version 3A,
DECnet-20 Version 1 are marked with
change bars. Chapters 7 through 10 are
marked with change bars in the Table of
Contents only.

PREFACE

This manual includes information about configuring,
installing,
programming, and operating DECnet-20. As such, it is directed to the
following audience:
•

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.

system operator responsible for loading and starting the
• The
network software under the
monitor.
This person
TOPS~20

should be experienced in TOPS-20 operations
with computer networks.

and

familiar

•

The system manager or system programmer responsible for
installing the network software and generating the new system.
This will probably be the person who installed the TOPS-20
monitor.

•

The terminal user responsible for network tasks that do not
require the enabling of capabilities. All timesharing users
should be familiar with the TOPS-20 Command Language.

This manual is also intended to be of use to field and corporate
software service personnel engaged in the installation and support of
the product.
The manual is organized into five parts as follows:
Part I, the Introduction, contains an overview of DECnet-20 and a
discussion of system concepts, network options and network facilities.
Part II, the Programmer's Guide, contains the programming facilities
that the MACRO programmer must use in order to perform the following
network functions:
using

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.

•

Terminating a network connection
standard monitor calls.

•

Controlling
functions.

the

connection

using

network

using

network-related

and

monitor

Part III, Operator's Guide, contains system loading procedures,
DECnet-20 operator commands, recovery procedures, control procedures,
and network-related error messages.
These procedures include a number
of examples printed in two colors for clarity. Terminal input is
shown in red; system output is shown in black.
Part IV, Terminal User's Guide, contains TOPS-20 commands available to
nonprivileged users. All network-related TOPS-20 commands, including
user-interaction with the file transfer utility (NFT), are described.
Examples are given in the form previously explained.
Part V, Generating DECnet-20, discusses the concepts, features, terms,
and commands that are related to on-site configuration of a DECnet-20
system as well as the procedures for
installing, verifying,
and
certifying the DECnet-20 system.
Part VI contains the appendixes.
The following are suggested guidelines for using this manual:
•

I
I

Application programmers should read Parts I and
appendixes.

operators should read Parts I
• System
appendixes.

and

II,

and

the

III,

and

the

• Terminal users should read Parts I and IV.
System managers and system programmers should read the entire
• manual.
DECnet-20 runs under the TOPS-20 monitor on all the DECSYSTEM-20
models.
Both the application programmer's and the nonprivileged
user's interface to DECnet-20 are the same regardless of the system
model.
However,
there are differences in the installation and
operation procedures between the DECSYSTEM-2020 and the other systems.
Therefore,
this manual uses the term DECSYSTEM-20 only when referring
to all models.
Specific systems are referred to by their model
designations, such as DECSYSTEM-2020 or DECSYSTEM-2040, 2050, 2060.
The following documents are either referenced in this
prove useful in implementing DECnet-20 facilities.

manual

TOPS-20 Monitor Calls User's Guide

DEC-20-0MUGA-A-D

TOPS-20 Monitor Calls Reference Manual

AA-4166D-TM

TOPS-20 Software Installation Guide

AA-4195G-TM

TOPS-20 Operator's Guide

AA-4176D-TM

TOPS-20 Operator's Command Language
Reference Manual

AA-H600A-TM

TOPS-20 Commands Reference Manual

AA-5115B-TM

TOPS-20 User's Guide

AA-4179C-TM

xii

may

TOPS-IO and TOPS-20 Batch Reference
Manual

AA-H374A-TK

TOPS-IO and TOPS-20 SYSERR Manual

AA-D533A-TK

TOPS-20 UETP Procedures/Reference
Manual

AA-D606B-TM

TOPS-20 System Manager's Guide

AA-4169F-TM

xiii

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 thes~
systems can be interconnected to form computer networks.
DECnet is based on sets of rules
(protocols)
known collectively as
DIGITAL Network Architecture, or DNA.
These protocols govern the
execution of major network chores, such as transferring messages and
data over physical lines, using error detection and retransmission to
guarantee the integrity of data transfer, multiplexing 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

DECnet-20 task-to-task capability is required on all DECSYSTEM-20
systems
before
an
option
can
be
added.
Currently,
DECSYSTEMs-2040/50/60 with a
l28K DN20 communications front end
support up to eight task-to-task lines.
The DECSYSTEM-2020 supports
two task-to-task lines. Task-to-task communication requires a minimum
of one synchronous line.
In addition to multiline support, the
capabilities of DECnet-20 include the Network File Transfer
(NFT)
utility.
One additional option
systems:
•

available

for

DECnet

the

2040/50/60

RJE-20 Version 1. 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
maintained remotely by the host system.

A DECnet site may choose to
task-to-task and RJE.

divide

the

use

No options are available for the DECSYSTEM-2020.

1-1

its

lines

between

SYSTEM OVERVIEW
1.3

DECnet-20 STRUCTURE

DECnet-20 is a software product that extends the facilities of TOPS-20
so that tasks running on any member of the DECSYSTEM-20 family of
computers can communicate with other tasks in a computer network.
When DECnet-20 is running on a DECSYSTEM-2040,
2050, or
2060,
the
network software resides partly in the main processor with the TOPS-20
monitor and partly in a separate processor
(the DN20)
designed to
handle network communications functions.
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 main processor communicates with either front
end
through
a
DTE
hardware interface.
Figure 1-1 shows a
DECSYSTEM-2040, 2050, 2060, a DTE, and a DN20 communications front
end.
The major protocol levels are also shown.
When DECnet-20 is running on a DECSYSTEM-2020,
the network
resides entirely in the main processor;
there is no
communications front end.
Figure 1-2 shows a DECSYSTEM-2020
location of the major protocols.

software
separate
and the

DECnet-20 has a multilayer structure;
each layer,
or
corresponds
to
one or more protocols in the DIGITAL
Architecture (DNA).

level,
Network

remote node

DECSYSTEM-2040, 2050 or 2060

User
task
NETCON
Operator
task

DN20

driver

Monitor Call
Interface

DDCMP
NSP

TOPS-20

NSP
DTE Driver

DTE

DTE Driver

Network
Utilities

MR-S-598-80

Figure 1-1

DECnet-20 on a DECSYSTEM-2040, 2050, 2060

1-2

SYSTEM OVERVIEW

DECSYSTEM-2020

NETCON

User
task

Operator
task

Monitor Call
Interface

NSP
TOPS-20

DDCMP
Line
driver

Hardware
HClrliware

remote
nodes

MR-S-599-80

Figure 1-2

1.3.1

DECnet-20 on a DECSYSTEM-2020

Hardware Level

The lowest level of DNA protocol used in DECnet-20 is the hardware
level. This level is implemented by line drivers that are tailored to
the types and characteristics of the physical lines, modems, and modem
control
interfaces.
The
hardware level controls transmission
techniques (synchronous or asynchronous, serial or parallel, full- or
half-duplex), character synchronization, and modem operation.
In
Figures 1-1 and 1-2, this level is represented by the line drivers.

1.3.2

Physical Link Control Level

The next higher level of DNA protocol is the physical link control
level.
This level is implemented by the Digital Data Communications
Message Protocol (DDCMP).
DDCMP maintains control over the hardware
level by using a l6-bit Cyclic Redundancy Check (CRC-16) to detect
errors, retransmitting to correct errors, and numbering messages to
ensure sequential data transfer.
The next higher level of protocol,
therefore, can be assured of a sequential and error-free data path.
In Figure 1-1, the physical link control level is represented by the
DDCMP layer
in the DN20.
The two DTE drivers, each in their
respective CPUs, perform DDCMP-like functions to control the flow of
NSP messages between the host computer and its communications front
end.
In Figure 1-2, the DECSYSTEM-2020 does not have a communications front
end and therefore the DDC~lP level is implemented entirely in the host
computer.

1-3

SYSTEM OVERVIEW
1.3.3

Logical Link Control Level

The next higher level of DNA protocol used in DECnet-20 is the logical
link control level as defined by the Network Services Protocol (NSP).
NSP controls the flow of data between tasks in a network.
This
involves
creating and terminating logical links
(communications
paths), multiplexing logical links into physical links, segmenting and
collecting long messages, and ensuring end-to-end delivery of data in
proper sequence.
Logical links are described in detail in Chapter 2.
When DECnet-20 is running
protocol is implemented
main processor and in the
this level is represented
the DN20. When DECnet-20
protocol is implemented
Figure 1-2.

on a DECSYSTEM-2040, 2050, or 2060, the NSP
both in the TOPS-20 monitor running in the
communications front end.
In Figure 1-1,
by the NSP code in the main processor and in
is running on a DECSYSTEM-2020,
the NSP
entirely in the main processor as shown in

NSP in the main processor provides the TOPS-20 user with programmable
access to the DECnet environment via the TOPS-20 file system monitor
calls.
NSP also resolves the byte-size differences between the 36-bit
word structure of the main processor and the 8-bit byte structure
required by the network.
Additional NSP protocol and
network
utilities in the communications front end (or in the main processor in
the case of the DECSYSTEM-2020) perform the bulk of the NSP control
functions.

1.3.4

User or Application Level

DECnet and its first three levels of protocol
(hardware,
DDCMP,
and
NSP)
provide for
the exchange of data between network tasks.
How
these tasks interpret this data involves a user level of protocol.
In
both Figures 1-1 and 1-2, this user level is represented by the user
tasks running on the DECSYSTEM-20. The user level of protocol is
responsible for interpreting and acting on the data exchanged.

1.4

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 adjacent nodes in a network.
The local task accomplishes this by using the TOPS-20 file system
monitor calls to open,
read and write information, and close files
using a pseudo-device representing the network.
Below this user level, and transparent to the user,
the network
protocol takes over. NSP software running in the main processor (and
in the communications front end when part of the system)
manages the
actual transfer of data over a logical link.
User data is first
reformatted into network-compatible segments and then transferred over
the logical link. NSP also generates the appropriate control messages
to open and close network connections.

1-4

SYSTEM OVERVIEW
A special network control task called NETCON is started at system
initialization and runs under
the system program SYSJOB.
NETCON
accepts operator commands (and command files)
through the operator
interface program ORION and the operator command parser OPR. Operator
commands to NETCON will:
•

Down-line load network software into the communications
end of a DECSYSTEM-2040, 2050, 2060.

•

Load network software into the synchronous line controller
the DECSYSTEM-2020.

•

Up-line dump the communications front end of a DECSYSTEM-2040,
2050, 2060 into a TOPS-20 file.

•

Dump the synchronous line
into a TOPS-20 file.

•

Log pertinent network load, dump, and line status
into the TOPS-20 SYSERR file.

•

Display line statistics for
network.

•

Start and stop DECnet-20 lines on all DECSYSTEM-20 models.

•

btart a line in cao~e-loopback
(DECSYSTEM-2020).

•

Perform
a
loopback
(DECSYSTEM-2040/50/60) •

controller

test

any

line

the

any

front

DECSYSTEM-2020
information
node

controller-loopback

designated

the

mode
line

Operator commands are described in Chapter 6.

1.5

DECnet-20 PROGRAMMER INTERFACE

Using DECnet-20, a MACRO programmer 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 logical links.
Several network-specific functions have been added to the MTOPR
monitor call to provide the user with some form of logical link
management.
These new functions are described in subsequent chapters.

1.6

DECnet-20 OPERATOR INTERFACE

Operator commands to the network control program, NETCON,
fall
into
two classes:
generic DECnet commands and TOPS-20-specific DECnet
commands.

1-5

SYSTEM OVERVIEW
Generic DECnet commands function the same on all DECnet computer
systems.
These are the LOAD NODE and DUMP NODE commands to down-line
load and up-line dump the communications front end,
the SHOW QUEUE
command to check the status of any queued NETCON requests, the SHOW
COUNTS command to display line counter information, the SET EXECUTOR
command to specify which node is to process subsequent commands, the
SHOW STATUS commands, the SET STATE command, and the LOOP LINE command
to loop a standard test message a specific number of times.
TOPS-20-specific DECnet commands are extensions to the generic DECnet
commands necessary for the implementation of DECnet under TOPS-20. On
the DECSYSTEM-2040, 2050, and 2060, the SET NODE command establishes
operating characteristics and the SET SECONDARY (TERTIARY)-LOAD-FILE
command specifies the secondary (tertiary) bootstrap programs to be
used for down-line loading the communications front end. On the
DECSYSTEM-2020, the LOAD LINE and DUMP LINE commands load and dump the
integral line controller.
On all models,
the INITIATE LOGGING,
TERMINATE LOGGING, and SET LOGGING-INTERVAL commands control the
recording of DECnet-20 line statistics.

1.7

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
describe the TOPS-20 Command Language in detail.
Part IV of this manual describes EXEC commands that are specific to
DECnet-20.
It also includes Network File Transfer (NFT).
NFT may be
used by the nonprivileged user.
NFT gains access to the files and
devices on other nodes through the Data Access Protocol (DAP) of the
DNA, but this interaction is transparent to you.
Your concern is the
function and format of the NFT commands.

1-6

CHAPTER 2
CONCEPTS AND FACILITIES

2.1

SYSTEM CONCEPTS

The basic concept of DECnet-20 is that the network is to be treated as
just another 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 request network functions.
This concept is represented graphically in Figure 2-1.
The local
NSP
code
interfaces with the TOPS-20 monitor to provide the user with
network access using many of the same monitor calls that are used
to
access local peripherals.
Figure
2-1
shows this
local NSP cede
residing
in the main processor
of
a
DECSYSTEM-2020.
In
a
DECSYSTEM-2040,
2050,
2060,
the NSP code resides in both the main
processor and in the communications front end.
The communications
front
end,
if present, is transparent to both local and remote user
tasks.
DECSYSTEM-2020

I
User
program
B

TTY; driver

User
program

TOPS-20
MONITOR
CALLS

- -

•
•
•

I
C

MTA: driver

I
User
program

DSK: driver

NSP code

r- , - I
, SRV:

I
line
,
L D.£N ~d~er~

. . .~~.~. I

MxEm

i---=- ~~t:~'k
MR-S-600-80

Figure 2-1

The Network as an I/O Device

To initiate a dialogue with a target task, a
source
task
identifies
the target task as a file on the network device DCN:.
The source task
then proceeds to open the network file, write to it, read from it, and
eventually close it,
very much as if it were a file residing on a
local auxiliary storage facility.

2-1

CONCEPTS AND FACILITIES
To declare itself as being available for a connection by a source
task,
a target task identifies itself as a file on the network device
SRV:. When the SRV:
file is opened, 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.
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 communications on
a network.
Physical links connect network nodes and logical links
connect network tasks.
A physical link connects two network nodes and can take one of several
forms.
In Figure 2-2, the physical link between nodes ABLE and ABLER
is the DTE interface, a hardware device between a DECSYSTEM-2040,
2050, 2060 and its communications front end.
The physical link
between nodes ABLER and BAKER 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.
ABLE

ABLER

'0-

BAKER

- - ---'
N2 O

~
DECSYSTEM-2040, 2050 or 2060

-~--------. ~

~ ____ physical

GJ
~~

links

CHARLY

u~' 1-4---t-~-+--+-- - - -

~I u~"J

\~IO-9-iC-al-l-in-k--------~
DECSYSTEM-2020
PDP-11

Figure 2-2

MR-S-601-80

Logical and Physical Links

2-2

CONCEPTS AND FACILITIES
DECnet-20, running on a DECSYSTEM-2020, supports two physical links to
the network as shown at node BAKER in Figure 2-2.
DECnet-20, running
on a DECSYSTEM-2040, 2050, 2060, supports up to eight physical
links.
One physical link to the network is shown at node ABLER in Figure 2-2.

A physical link can support one or more logical links.
A logical link connects two network tasks.
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.
The simultaneous sharing of a physical link by multiple logical
links
is referred to as multiplexing.
Among
the
functions of NSP 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.
In Figure 2-2, the logical links between users A and D, Band E, and C
and F, are multiplexed and span two physical links: ABLE to ABLER and
ABLER 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 analogous to the job file
number (JFN) assigned to all input and output files being processed by
TOPS-20 tasks.
In the TOPS-20 file system, a JFN is associated with a
file
specification.
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) .

2-3

CONCEPTS AND FACILITIES
Object types 1 through 127 are reserved for DECnet utilities and
control programs.
Object types 128 through 255 are available for
user-written installation-dependent network utilities. Object type 0
is reserved for addressing tasks by their unique task name. Appendix
B contains the current list of DECnet object types.
The use of object descriptors is dependent upon the implementation of
NSP on the remote node.
If the remote node is running a system other
than TOPS-20 DECnet-20, read the DECnet manuals for the system being
used.
In DECnet-20, object descriptors can be used with object types
128 through 255 if so designed into the user program.
A unique task name, on the other hand, 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

Each node in a network is identified by a unique node name and a
unique node number.
The node name must be one to six alphanumeric
characters; the node number must be a positive integer between 2 and
127, inclusive.
When DECnet-20 is installed on a DECSYSTEM-2040,
2050, 2060, the main processor and the DN20 communications front end
are each considered separate network nodes. Each, therefore, must
have a unique name and number.
Whenever a source task requests a connection to a target task, the
source task must supply the local NSP with the name of the target
node. The local NSP uses this node name to generate the destination
address of the NSP message that requests a connection to the target
task. Sending this request for connection to a target task is the
first step in establishing a logical link.
During the installation procedures for DECSYSTEM-2040j2050j2060, the
ma1n processor
(host) is given an identifying name and octal number.
During on-site configuration, as part of the NETGEN procedure, the
DN20 and the DN200, if present, are given node names and numbers.
Within the same network, all identifying names and numbers must be
unique.
See Chapters 9 and 10 for the procedures for assigning node
names and node numbers.

2.2

NETWORK FACILITIES

The TOPS-20 programmer can implement the task-to-task function of
DECnet-20 using MACRO programs or subroutines. Specifically, a subset
of the TOPS-20 file system monitor calls acts as the interface between
the programmer and DECnet-20.
These network-related monitor calls
allow the MACRO programmer to:
•

Declare a network task as willing to accept connections.

•

Initiate a request for a connection to another network task.

2-4

CONCEPTS AND FACILITIES
•

Accept or reject a
network task.

request

for

connection

from

•

Transmit data to and receive data from another network task.

•

Interrogate the status of a logical link.

•

Retrieve the connect attributes of a network task.

•

Exchange high priority interrupt messages
length) with other network tasks.

•

Disconnect a network connection.

(up to 16

another

bytes

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
fully
described in the DECSYSTEM-20 Monitor Calls Reference Manual.
TOPS-20
usage information for these calls is found in the DECSYSTEM-20 Monitor
Calls
User's
Guide.
DECnet-20 usage
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
Monitor
Call
GTJFN
OPENF
BIN
*BOOT
SIN
SINR
BOUT
SOUT
SOUTR
SIBE
CLOSF
MTOPR
*NODE

Network Function

Get a network JFN
Open a network connection
Receive a data byte
Provide maintenance and utility functions for
communications 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)

* BOOT 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 DECSYSTEM-20 Monitor Calls
Reference Manual.

2-5

CONCEPTS AND FACILITIES
Table 2-2
BOOT Monitor Call Functions Used in DECnet-20
Code

Symbol

Support*

.BTROM

a&b

1
2

.BTLDS
.BTLOD

a&b
a&b

3
4
5
6
7
10
11
12
13
14
15
16
17
20
21
22
23

.BTDMP
.BTIPR
.BTTPR
.BTSTS
.BTBEL
.BTRMP
.BTKML
.BTKMD
.BTRLC
.BTCLI
.BTCPN
.BTSTA
.BTSSP
.BTSTP
.BTSDD
.BTRDD
.BTCHN

b
a&b
a&b
a&b
b
a&b
a
a
a
a&b
a&b
a
a
a
a
a
a

.BTSLS

Purpose
Puts line or DTE in MOP mode
and activates the front-end ROM
a: DN22
b: DN20/2l or console front end
Load secondary bootstrap
Loads the front end
a: DN22
b: DN20/2l 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
Load KMCll
Dump KMCll
Return line counters
Convert line-id to port number
Convert port number to line-id
Set station polling status
Set line startup priority
Set station polling priority
Send DDCMP message
Receive DDCMP message
Assign a software interrupt
channel
Set line service type

* Support indicates the hardware system on which these calls are
valid:
(a) for DECSYSTEM-2020 and (b) for DECSYSTEMs-2040/50/60.

Table 2-3
MTOPR Monitor Call Functions Used in DECnet-20
Code

Symbol

24
25
26
27
30
31
32
33
34
35
36
37
40

. MOACN
.MORLS
.MORHN
. MORTN
.MORUS
. MORPW
. r-iORAC
• MORDA
. MORCN
.MORIM
.MOSIM
. MOROD
.MOCLZ

41
42

.MOCC
.MORSS

Purpose
Set interrupt assignments
Read link status
Read host name
Read task name
Read user identification
Read password
Read account string
Read 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

2-6

CONCEPTS AND FACILITIES
Table 2-4
NODE Monitor Call Functions Used in DECnet-20
Code

Symbol

5
6
7

.NDSLN
.NDGLN
.NDSNM
.NDGNM
.NDSLP
.NDCLP
.NDFLP
.NDSNT

.NDGNT

.NDSIC

.NDCIC

13
14
15

.NDGVR
.NDGLI
.NDVFY

1
2
3

Purpose
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-7

PART II

PROGRAMMER'S GUIDE

CHAPTER 3
ESTABLISHING A NETWORK CONNECTION

In order 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 as a file on device
SRV:.
The target task must then open that SRV: file in order to have
a logical link assigned to it by NSP.
The task should also set up
some
form
of
software
interrupt
mechanism
to be informed
asynchronously of the arrival of a connect initiate message from a
source task. Whenever a connect initiate message arrives, the 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 as a file on device DCN:.
It must then
open that DCN: file
to have a logical link assigned and to have a
connect initiate message sent to the target task.
A TOPS-20 task, if it so desires, 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
during the establishing of a network connection.

that

takes

place

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 NSP task 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 NSP task
at node BOSTON to send a connect initiate message to node DALLAS.
The NSP task 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 individual steps are explained in
chapter.
3-1

detail

the

rest

this

ESTABLISHING A NETWORK CONNECTION

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

r:;\ 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-80

Figure 3-1

3.1

Establishing a Network Connection

OBTAINING A NETWORK JFN

The first step in establishing a network logical link is to obtain a
Job File Number (JFN) for a network file on either the SRV: or DCN:
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 via the
terminal, accessed from memory, or (in the long form) developed by a
combination of both methods.

3-2

ESTABLISHING A NETWORK CONNECTION
The general format of a GTJFN file specification in TOPS-20 is:
dev:<directory>filename.filetype.generation;T;P;A
When you use the GTJFN call to obtain a network JFN in DECnet-20,
network file specification takes the following form:

the

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.

;T;P;A

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 as a decimal number or an object name
(see Appendix B).
The numbers 1 through 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.

is a subfield separator that is required
descriptor is specified.

(hyphen)

3-3

only

the

ESTABLISHING A NETWORK CONNECTION
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).
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 •

• (period)

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

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

3-4

imposed

task

file

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:AljA2 ••.
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 specifiep.

(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)

is a separator character
taskname is specified.

taskname

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-~

and

required

only

ESTABLISHING A NETWORK CONNECTION
;Al;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 1 to 16
contiguous
alphanumeric
ASCII
characters (including the hyphen,
dollar
sign,
and
underscore)
identifying the source task.
Example:
;USERID:ALIBABA

;PASSWORD:password

where password consists of 1 to a
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 1 to a octal triplets
representing
the
required
password.
Each triplet represents
an a-bit byte.
Example:
BPASSWORD:123056002

;CHARGE:acctno

where acctno consists of 1 to 16
contiguous
alphanumeric
ASCII
characters (including the hyphen,
dollar
sign,
and
underscore)
representing the source
task's
account identification.
Example:
;CHARGE:ACCT-13C

3-6

ESTABLISHING A NETWORK CONNECTION
iDATA:userdata

where userdata consists of 1 to 16
contiguous
alphanumeric
ASCII
characters (including the hyphen,
dollar
sign,
and
underscore)
representing user data.
Example:
iDATA: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.

iBDATA:userdata

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

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

iA l iA2 •••

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

descriptor

its

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

task

had

included

SRV:128-PARTl
The DALLAS task would then have to modify its specification to:
DCN:BOSTON-128-PART1.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 avail itself of the utility but
not caring which copy of the program completes the connection, can use
the specification:
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 OPENFmonitor call: ~h~ monitor
passes control to the appropriate device handler, which for the SRV:
and DCN: devices is the local NSP task. The events that occur when a
network file is opened depend on whether the file represents a target
task or a source task.

Opening a Target Task JFN

3.2.1

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 local NSP performs the following:

•

Constructs a link data base for this connection.

•

Places the target task on a list of available connections.

Subsequently, when a connect initiate message is
source task, the local NSP performs the following:

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 Network Connection

An OPENF monitor call for a JFN that represents a network connection
implies a request for a connection to a target task. The local NSP
task performs the following:

•

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 via a connect interrupt.
NOTE
The successful completion of the OPENF
monitor call for
a network connection
does not necessarily mean that a connect
confirm message has been received by the
local NSP.
The source task should read
the
link status
(Section 3.4.1)
to
ensure that a connection
has
been
completed.

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.

I
I

The system quota of open links varies according to the amount of 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 etror code is returned.
When DECnet-20 is generated on a DECSYSTEM-2040,
2050,
2060,
the
maximum number of logical links is set for
the individual site
according to the site's configuration.
See Chapter 9 in this manual.

3.3

ENABLING FOR 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 after 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 software provides a function of the MTOPR monitor call that
allows 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 expects
the following monitor call arguments to be placed 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

80-88
89-817
818-826

Mo~cnN

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 channel numbers are 0-5 and 23-35, decimal.

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 I
MOVX
MTOPR
PAUSE: WAIT

Tl,.FHSLF
T2,[LEVTAB"CHNTAB]

iIDENTIFY CURRENT PROCESS
iSPECIFY TABLE ADDRESSES
iDEFINE PSI SYSTEM TABLES
iSET BITS FOR CHAN 0,1,2
T2,7B2
iACTIVATE CHANNELS 0,1,2
iENABLE THE SYSTEM
Tl,NETJFN
iGET NETWORK JFN
T2,.MOACN
iSET UP FUNCTION
T3,<FLD(0,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

3.4

READING LOGICAL LINK DATA

Associated with each open logical link is a link data base, created
and maintained by the local NSP.
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 via network
functions of 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
information regarding the status of the logical link.

36-bit

The calling sequence expects the following monitor call
be placed in the specified accumulators:
ACl:

The JFN of the logical link

AC2:

.MORLS (function code)

word

arguments

The monitor call returns the following information in AC3:
AC3:

Flag bits in the left half and a disconnect code
right half

the

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 a connect
is waiting for a connect confirm
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 the local NSP has received a connect confirm
message from the target node or task.
To ensure that a connection
really exists, you can use a coding sequence such as:
CHKCON: MOVE
MOVE I
MTOPR
ERJMP
TXNE
JRST
TXNE
JRST
TXNN
JRST
JRST

Tl,NETJFN
T2,. MORLS

iGET NETWORK JFN
iSET UP FUNCTION
iISSUE THE CALL
iJSYS ERROR
iNOW CONNECTED?
iYES
iNO, WAITING FOR CC?
iYES, WAIT A
iSECOND AND
iTRY AGAIN
iNO, EVER CONNECTED?
iNO, CI REJECTED
iYES, LINK WAS ABORTED
iOK, CONTINUE

JSYSXX
T3,MO%CON
CNCTED
T3,MO%WCC
[MOVEI Tl,~DlOOO
DISMS
JRST CHKCON]
T3,MO%LWC
REJECT
ABORT

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

The calling sequence expects the following monitor call
be placed in the specified accumulators:

name

the

arguments

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 with an updated pointer in AC3 and
name stored as specified.

the

node

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

iREMOTE 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 calling sequence expects the following monitor call
be placed in the specified accumulators:

arguments

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 with an updated pointer in AC3 and
name stored as specified.

the

task

Example
Target tasks, especially those that perform utility functions,
often
default their task names because they do not expect to be addressed
otner tnan 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
MOVEI
HRROI
MTOPR
ERJMP

Tl,NETJFN
T2, • MORTN
T3,TSKNAM
JSYSXX

iPOINTER TO TASK NAME
iISSUE THE CALL
iJSYS ERROR

TSKNAM: BLOCK

iLOCAL TASK NAME

iGET NETWORK JFN
iSET UP FUNCTION

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 and
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 calling sequence expects the following monitor call
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

arguments

the

user

where

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 user ids. The following program segment
retrieves the userid of the ~urrent connect request:
GTUSID: MOVE
MOVEI
MOVE
MTOPR
ERJMP
CAMN
JRST

Tl,NETJFN
T2, • MORUS
T3,UIDPTR

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

JSYSXX
T3,UIDPTR
REJECT

check if userid is valid

USERID: BLOCK
UIDPTR: POINT

:SOURCE USERID
:USERID 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 calling sequence expects the following monitor call
be placed in the specified accumulators:

arguments

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,

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 ln its
connect request.
The two tasks have agreed to use ASCII passwords:
GTPSWD: MOVE
MOVEI
MOVE
MTOPR
ERJMP
JUMPE

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

Tl,NETJFN
T2, • MORPW
T3,PWDPTR
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 calling sequence expects the following monitor call
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

arguments

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

iGET NETWORK JFN
iSET UP FUNCTION
iPOINTER TO ACCT NO.
iISSUE THE CALL
iJSYS ERROR
iCHECK IF ANY ACCT NO.
iNa - REJECT

JSYSXX
T3,ACCPTR
REJECT

process the account number

ACCTNO: BLOCK
ACCPTR: POINT

iACCOUNT STRING
iACCT 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

The calling sequence expects the following monitor call
be placed in the specified accumulators:

arguments

data
to

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 stringi
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
MOVEI
MOVE
MTOPR
ERJMP
JUMPE

DATPTR: POINT
USRDAT: BLOCK

Tl,NETJFN
T2,.MORDA
T3,DATPTR

iGET NETWORK JFN
iSET UP FUNCTION

iPOINTER TO USER DATA
iISSUE THE CALL
iJSYS ERROR
iBRANCH IF NO DATA

JSYSXX
T4,NODATA

8,USRDAT

iUSER DATA POINTER
iUSER DATA

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 calling sequence expects the following monitor call
be placed in the specified accumulators:
ACI:

The JFN of the logical link

AC2:

.MORCN (function code)

arguments

The monitor call returns with the object type in AC3. A zero object
type indicates that the target 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 targ~t 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
MOVE I
MTOPR
ERJMP
JUMPE
OBJCON:

TI,NETJFN
T2,.MORCN

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

JSYSXX
T3,TSKCON

;CONNECTED BY TASK NAME

TSKCON:

3-20

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 for 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 calling sequence expects the following monitor call
be placed in the specified accumulators:

arguments

the

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 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

the

right half
If the source host system does not provide for group or user codes, or
if none were provided in the connect initiate message, AC4 contains
zeros.
Example
A target task can retrieve the unique identification
task with the following program segment:

the

GTOBJD: MOVE
MOVE I
HRROI
MTOPR
ERJMP
JUMPN

Tl,NETJFN
T2,. MOROD
T3,OBJDES
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

OBJDES: BLOCK
GRPCOD: BLOCK
USRCOD: BLOCK

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 MTOPR returns the maximum segment
size that can be sent over this link.
The maximum segment size that
can be sent over a logical link is a function of the buffering
capabilities of the remote node and the particular implementation of
DECnet that is running on the remote node.
The local task can use
this value to determine the optimum size of data records being
transmitted over the link.
The calling sequence expects the following monitor call
be placed in the specified accumulators:
ACl:

The JFN of the logical link

AC2:

.MORSS (function code)

arguments

The monitor call returns with the maximum segment size, in bytes,
in
AC3.
If the link has not been established, the monitor call takes the
error return.
Example
The maximum segment size for a source task
is transmitted to the
target NSP in the connect initiate message.
The target NSP, in turn,
returns the target task's maximum segment size in the connect confirm
message that is sent back to the source NSP.
Each task can then
retrieve this value with a program segment such as the following:
GTSGSZ: MOVE
MOVEI
MTOPR
ERJMP
MOVEM

Tl,NETJFN
T2,.MORSS

iGET NETWORK JFN
iSET UP FUNCTION

JYSXX
T3,SEGSIZ

iISSUE THE CALL
iJSYS ERROR
iSTORE SEGMENT SIZE

SEGSIZ: BLOCK

iMAX SEGMENT SIZE

3-22

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 local NSP, via the monitor, of its intention.
Two
MTOPR monitor call functions are provided:
.MOCC to accept a
connection and return some data, and .MOCLZ to reject the connection
and return some 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 via the .MOCC function of the MTOPR monitor
call.
This method allows you to include up to 16 bytes of optional
data in the connect confirm message.
The calling sequence expects the following monitor call
be placed in the specified accumulators:

arguments

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 data string. A zero indicates
no data.
The maximum amount of data is 16 bytes.

You can accept a
operations that
operations are:

connection implicitly by performing one of the
These
NSP recognizes as indicating acceptance.

•

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

When NSP senses one of the above conditions, it assumes that you are
accepting the connection and sends a connect confirm message to the
source task.
The connect confirm message sent by NSP does not allow
for optional data;
if you must return optional data, use the explicit
acceptance.

3.5.2

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 via the
.MOCLZ function of the MTOPR
monitor call. 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 calling sequence expects the following monitor call
be placed in the specified accumulators:

arguments

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 NSP
senses that the logical link's JFN has been closed in response to a
connect initiate message, NSP sends a connect reject message to the
source task with a reject code of 38
(user aborted).
In this
situation, you must reopen the JFN in order 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

Tl,NETJFN
T2,. MOCC
T4,

message

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

JSYSXX

To include up to 16 bytes of ASCII user data with the connect
message, modify the above segment as follows:
ACCEPT: MOVE
MOVE I
MOVE
MOVEI
MTOPR
ERJMP

Tl,NETJFN
T2,.MOCC
T3,[POINT 7,MSGC]
T4, . . D16

MSGC:

/OPEN UNTIL 10 PM/

ASCIZ

iGET THE NETWORK JFN
iCODE TO ACCEPT
iPOINTER TO USER DATA
iUSER DATA BYTE COUNT
iISSUE THE CALL
iJSYS ERROR

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

;GET THE NETWORK JFN
;CODE TO REJECT
;ADD REJECT CODE 34
;FLAG NO USER DATA
;ISSUE THE CALL
;JSYS ERROR

Tl,NETJFN
T2,. MOCLZ
T2, . DCX34
T4,
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
MOVEI
HRLI
MOVE
MOVE
MTOPR
ERJMP

XPWD:

ASCIZ

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

;GET THE NETWORK JFN
;CODE TO REJECT
;ADD REJECT CODE 34
;POINTER TO REJECT MSG
;REJECT MSG BYTE COUNT
;ISSUE THE CALL
;JSYS ERROR

JSYSXX

/WRONG PASSWORD/

Figures 5-1 and 5-2 are examples, in program context, of some
programming sequences described in this chapter.

3-25

the

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 three general types of information exchange:
•

Data transfers

•

Interrupt messages

•

Network utility 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.
Network utility
messages include link control messages,
link service messages,
and
ACK/NAK messages.
Data transfers and interrupt messages are discussed in the remainder
of this chapter.
Network utility messages are
internal
to the
DECnet-20 software and transparent to the user network tasks~
they
are described in the Network Services Protocol
(NSP) functional
specification listed in the bibliography of Appendix D.

4.1

TRANSFERRING DATA

Data transfers over a logical link involve the segmentation and
restructuring of data at both the logical and physical link levels.
The local NSP accepts data from the user program,
segments it to
conform to the maximum segment size allowable on that logical link,
precedes each segment with an NSP header,
and passes these NSP
segments to the physical link management, DDCMP.
DDCMP, in turn,
segments the input from NSP to conform to the maximum segment size
allowable on the physical link, precedes each segment with a DDCMP
header to form a packet, and sends these packets over
the physical
media to the destination node.
At the destination node the reverse procedure takes place.
DDCMP
strips each packet of its DDCMP header and passes the packet data to
the local NSP.
The local NSP reassembles the NSP segments, strips off
the NSP headers, and passes the data to the receiving task.
Data transfers on a logical link can take one of two
messages or continuous byte streams.

4-1

forms:

logical

TRANSFERRING INFORMATION OVER THE NETWORK
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 with NSP taking care of delimiting each
logical unit.
The continuous byte stream format,
on the other hand, does not
implement any end-of-message indicators.
Data transmitted in this
format is presented to the receiving task as a continuous stream of
data with no indication by NSP of the end of one message and the
beginning of another.
The receiving task must reconstruct the
original messages via some prearranged protocol agreed to by both user
tasks.
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 allows NSP and DDCMP
to pack data buffers without regard for
the ends of messages;
however, the user retrieval routines must then analyze the input
stream and reconstruct the original logical messages.

4.1.1

Sending Data

You can send data to another task with either the SOUT or the SOUTR
monitor call.
In general,
use SOUTR to send data in the logical
message format and SOUT to send data as a continuous byte stream.
The exclusive use of SOUTR usually implies that both you and the other
task 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.1.2).
The exclusive use of SOUT or BOUT usually implies that both you and
the other task 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 you are programming a task
with 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-2

TRANSFERRING INFORMATION OVER THE NETWORK
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 both you and the other
task 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.1.1).
The exclusive use of SIN usually implies that both you and the other
task 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. A
SIN monitor call does not recognize an end-of-message 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.
You can then issue a SIN for
that
number of bytes and not encroach on the succeeding message.
The SIBE monitor call should also be used just prior to dismissing a
data available interrupt;
this is to ensure that you have read all
input currently in the buffer.
Failure to test for an empty buffer
can result in loss of a data interrupt.
If data from the network
arrives while the program is at interrupt level, no interrupt is given
because the program has not yet dismissed the first interrupt. SIBE
should always precede DEBRK to ensure no data is lost.

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.

4-3

TRANSFERRING INFORMATION OVER THE NETWORK
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 and 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 via 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.
message length is 16 bytes.

The maximum

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

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

MSG:

/CLOSING AT 6PM/

ASCIZ

;GET NETWORK JFN
;SET UP FUNCTION
;POINTER TO MESSAGE
;BYTE COUNT
;ISSUE THE CALL
;JSYS ERROR

JSYSXX

4-4

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 asynchronously notified of the
messages' arrival.
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 one 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]
JSYSXX

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

MSGBUF: BLOCK

;MESSAGE BUFFER

Figures 5-1 and 5-2 are examples, in program context, of some
programming sequences described in this chapter.

4-5

the

CHAPTER 5

CLOSING A NETWORK CONNECTION

A network connection can be closed by either of the
two connected
tasks.
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.
If the byte
over 8, bytes are truncated to eight bits.

AC4:

The count of bytes in the user data.
bytes.

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 via 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

currently

;GET NETWORK JFN
;ISSUE THE CALL
;JSYS ERROR

Tl,NETJFN
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
MOVEI
MTOPR
ERJMP
CLOSF
ERJMP

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

JSYSXX

;GET NETWORK JFN
;SET UP FUNCTION
;POINTER TO MESSAGE
;BYTE COUNT
;ISSUE THE CALL
;JSYS ERROR
;CLOSE THE JFN
;JSYS ERROR

MSG:

/BE BACK AT 6PM/

;USER 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 link;
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:
ACI:

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 maximum
one

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 via 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

TI,NETJFN
T I, (C Z %ABT)

iGET NETWORK JFN
iSET ABORT BIT
iISSUE THE CALL
iJSYS ERROR

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
MOVEI
HRLI
MOVE
MOVEI
MTOPR
ERJMP
TLO
CLOSF
ERJMP

MSGX:

ASCIZ

TI,NETJFN
T2, • MOCLZ
T2, . DCX9
T3, [POINT 7,MSGX]
T4,"'DI6

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

/RESTART XMISSION/

iUSER DATA

JSYSXX
TI, (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
CLOSF
ERJMP

5.3

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

iIf fail, then
iuse CZ%ABT

SOURCE AND TARGET TASK CODING EXAMPLES

Figures 5-1 and 5-2 are examples of coding for
source and target
programs, respectively.
The examples present, in context, many of the
program segments given as examples in Chapters
3,
4,
and
5.
The
examples are not complete programs that can be executed.

5-4

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

OPENF 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
MOVX
Tl,~D1000
iWait before checking status
DISMS
MOVE
Tl,OURJFN
iCheck link status
MOVX
T2,.MORLS
MTOPR
ERJMP NOGOOD
TXNE
T3,MO%CON
iConnected?
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 attpmpr
JRST
NOGOOD
iWe lose

CHKST:

Send data to Target task
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

;Include 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

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

iFailed, Probably out of resources
iSuccessful, save our JFN

Start setting up interrupt system for network JFN
MOVX
MOVE
SIR
l-10VX
AIC
EIR

Tl,.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(~D7,OF%BSZ)+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

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

WAIT

;Wait for Intetrupts

LEVTAB: PC

iLevel 1 PC address

CHNTAB:

l"HELLO
l"READIT
REPEAT ~D34,<O>

iOn connect go to HELLO
iOn data interrupt try to read

BLOCK

iLevel 1 pc save location

o
o

pc:
i

iZero fill rest of table

Process interrupt on Connect channel

HELLO:

MOVE
MOVX
SETZB
MTOPR
ERJMP
DEBRK

Tl,OURJFN
T2,.MOCC
T3,T4

iAlways accept the connection

NOGOOD

iSomething blew up
iDone, wait some more

Figure 5-2

iNo optional data

Example of Target Task Coding

5-6

CLOSING A NETWORK CONNECTION

Process interrupt on Data channel
READIT: MOVE
SIBE
JRST
MOVX
MTOPR
ERJMP
TXNN
JRST
DEBRK

Tl,OURJFN

iAny data?

READ
T2,. MORLS

iNO, See if link still connected

NOGOOD
T3,MO%CON
DISCON

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

HRROI
MOVNI
SINR
ERJMP
SETZM
IDPB
HRROI
PSOUT
JRST

T2,BUFFER
T3,"'DIOOO

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

READ:

NOGOOD
Tl
Tl,T2
Tl,BUFFER
READIT

iYes, Process it

iOutput the message
iProcess any more input

Process disconnect on link
DISCON: MOVE
ERJMP

JRST

Tl,OURJFN

iClose our JFN

iTry CLOSF with CZ%ABT
MOVE Tl,OURJFN
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:

•

BUFFER: BLOCK
OURJFN: BLOCK

"'DIOOO
1

Figure 5-2 (Cont.)

,Buffer save location
iOURJFN save location

Example of Target Task Coding

5-7

PART III

OPERATOR'S GUIDE

CHAPTER 6
RUNNING DECnet-20

The Operator Command Language program, OPR, provides the operator with
one command language to communicate with several TOPS-20 components,
including the DECnet-20 control program, NETCON.
OPR identifies
commands to NETCON when you type "NCP" (Network Control Program).
You
may type NCP followed by the NCP command as shown below:
$OPR
OPR)NCP SHOW STATUS LOCAL
OPR)
08:18:33
NCP request # 5 [SHOW STATUS LOCAL]
Status of local node as of 17-May-79 08:18:33
Node Name is 2102, # 64, System = 2102 Development System,
TOPS-20
Routing Version = 3.0.0, Communications Version = 3.0.0
State is On, Default Host = Unknown
Function Completed Successfully

or, you may ENTER NCP as shown below:

OPR)ENTER NCP
NCP)SHOW STATUS LOCAL
NCP)
08:19:10
NCP request # 6 [SHOW STATUS LOCAL]
Status of local node as of 17-May-79 08:19:10
Node Name is 2102, # 64, System = 2102 Development System,
TOPS-20
Routing Version = 3.0.0, Communications Version = 3.0.0
State is on, Default Host = Unknown
Function Completed Successfully
NCP)

6-1

RUNNING DECnet-20
aPR processes NCP commands for syntax only
(for correct format and
presence of required keywords,
for example).
Commands that are
syntactically acceptable are passed by aPR to ORION,
the operator
control program.
ORION, in turn, forwards the NCP commands to NETCON,
the program that controls the processing and execution of NCP
commands.
Specifically,
it is the NCP (processing) module of NETCON
that receives the commands from ORION. When processing is complete,
the NCP module passes all but the simplest commands to the NICE module
on the executor node.
Unless changed using the SET EXECUTOR command,
the executor node will be the node where NETCON is running.

6.1

THE NETWORK CONTROL PROGRAM

DECnet-20 operations are controlled by the TOPS-20 program called
NETCON.
NETCON exists only as an executable file, NETCON.EXE. The
control file and the three major source programs used in building
NETCON
are
on the DECnet-20 distribution tape as NETCON.CTL,
respectively.
Within the NETCON
NETPAR.MAC, NCP.MAC, and NCU.MAC,
program, command processing is accomplished by the NCP module;
command execution is accomplished by the NCP module or the NICE
module,
sometimes referred to as the Network Control Utility (NCU).
As an operator you interact with NCP through aPR.
The NCP module
interacts with the NICE module.
NCP commands are directed:
•

To the NETCON program itself
(an example would be the SHOW EXECUTOR command)

•

To the network
(an example would be the LOAD REMOTE command)

•

To a specific operating system and executed locally
(an example would be SET LOCAL LOOPBACK ENABLED command)

It is the commands directed to the network that require the use of the
Network Information and Control Exchange (NICE) protocol implemented
in the NICE (NCU) module of NETCON.
Through the use of a common
protocol, NICE,
the user is relieved of all concern with differences
in implementations among the various families of DIGITAL computers.
Any node that is a member of a given network can access the
information and control facilities of a remote node on the same
network if the following conditions are met:
•

The node owning the information or facilities permits access

•

The node owning the information or facilities has
the required NICE function

implemented

If a remote node is not able to honor a request, the system responds
"1
Request failed,"
followed by a message. A complete list of NCP
command responses is given in Section 6.5.1.

6-2

RUNNING DECnet-20
Examples:
NCP)LOOP LINE KDP_O_O
NCP)
15:36:10
NCP request # 11 [LOOP LINE KDP_ 0 _0]
?
Request failed, Invalid function or option
(The current executor was the host
node.
Before the LOOP LINE command, the user should
have given the command SET EXECUTOR with the
node name of the DECnet-20 communications front
end. )

* * * * *
NCP)SHO COU LIN DTE-l
NCP)
15:23:41
NCP request # 8 [SHOW COUNTS LINE DTE20 _
? Request failed, Insufficient status

(The line id should have been a valid lineid on
the executor node.)

Not all DECnet systems implement all possible functions.
Note that
communication is still possible within the restrictions of the set of
commands implemented by the remote node.
You can refer to the manuals
specific to the operating systems of the nodes in your network to
determine the capabilities of their operating systems.
(Within
operating
systems
further
restrictions
are
possible due to
insufficient memory.)
At the network planning level, the system manager may find it
advisable to limit some of the available NCP commands to specific
privileged users or groups.
The tasks that NETCON performs on any given system depends on the
configuration of the specific system. Given the device drivers and
optional hardware required, NETCON can perform the following tasks.
For the DECSYSTEM-2020, NETCON can:

• Load a synchronous line controller

• Dump a synchronous line controller
• Control the state of a synchronous line

• Display the status of NCP requests
• Display line status and activity
•

Control the logging of network events and line counters in the
SYSERR file

•

Start a line in cable-loopback or controller-loopback mode

6-3

RUNNING DECnet-20
For the DECSYSTEM-2040, 2050, 2060, NETCON can:

I
I

•

Set up the load and dump
front end

•

Set up the load and dump parameters for
station

•

Load a communications front end

•

Load a remote job entry station

•

Dump a communications front end

•

Dump a remote job entry station

•

Display the status of NCP requests

•

Display line status and activity

•

Control the logging of network events and line counters in the
SYSERR file

•

Turn event/error logging ON/OFF at either the line level (line
drivers
logging
messages
to NICE)
or
the NICE level
(forwarding of messages to host)

•

Perform loopback test on designated line

•

Define an adjacent node other than the host node as
that will load or dump a target node

•

Specify the protocol to be used by the communicating nodes

6.2

parameters

for

the
a

communications

remote

job

entry

the

node

DECnet-20 STARTUP PROCEDURES

The procedure for loading and starting DECnet-20 depends on the
of the DECSYSTEM-20.

model

On the DECSYSTEM-2040, 2050, 2060, there is a communications front-end
processor that must be loaded.
This occurs automatically when TOPS-20
is loaded or it can be performed manually at any time after TOPS-20 is
loaded.
On the DECSYSTEM-2020, there is no separate DECnet-20 communications
front-end processor to be loaded.
The standard DECSYSTEM-2020 monitor
supports DECnet.
Therefore, whenever you load TOPS-20, you are also
automatically loading DECnet-20 support code and support for the
synchronous line controller.

6.2.1

Automatic Startup on a DECSYSTEM-2020

The automatic startup of DECnet-20 on a
DECSYSTEM-2020 is merely a
function
of loading the TOPS-20 monitor.
The DECnet code
is
integrated with the TOPS-20 code.
Figure 6-1 is a sample of what you
might see when bringing up TOPS-20 with DECnet-20 on a DECSYSTEM-2020.
Note that the ORION program runs under SYSJOB, the NETCON program runs
as a separate job, and the OPR subjob runs under PTYCON.

6-4

RUNNING DECnet-20
(Mount the PS: disk pack on drive O.
the DECSYSTEM-2020 control panel.)

Then press the BOOT

button

BT SW
[PS MOUNTED]
System restarting, wait •••
ENTER CURRENT DATE AND TIME:

lO-OCT-/9 900

YOU HAVE ENTERED WEDNESDAY, 10-OCTOBER-1979 9:00AM,
IS THIS CORRECT (Y,N) Y
WHY RELOAD? TIS
RUN CHECKD? N
RUNNING DDMP
SYSJOB 4(10) STARTED AT 10-OCT-79 0900
RUN SYS:ORION
RUN SYS:QUASAR
RUN SYS:MOUNTR
RUN SYS: INFO
RUN SYS:MAILER
RUN SYS:MAPPER
RUN SYS:LPTSPL
RUN SYS:CDRIVE
RUN SYS:SPRINT
RUN SYS:FAL
JOB 0 ILOG OPERATOR XX OPERATOR
ENA
LOGIN PSEUDO
A ESET
ESET LOGIN CONSOLE
"ESET OPERATOR
PTYCON
GET SYSTEM:PTYCON.ATO
A

JOB 1 ILOG OPERATOR XX OPERATOR
ENA
RUN SYS:BATCON

JOB 2 ILOG OPERATOR XX OPERATOR
ENA
RUN SYS:NETCON

I
Figure 6-1

Startup Dialogue for TOPS-20 DECnet-20 on a
DECSYSTEM-2020

6-5

RUNNING DECnet-20
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ

2:
1:
0:
0:
1:
2:
0:
1:
2:
0:
0:
1:
2:
0:
1:
0:
1:
0:
0:
0:
0:
2:
2:

10/10-INSTALLATION-TEST SYSTEM, TOPS-20 MONITOR 4(3100)
10/10-INSTALLATION-TEST SYSTEM, TOPS-20 MONITOR 4(3100)
10/10-INSTALLATION-TEST SYSTEM, TOPS-20 MONITOR 4 (3100)
@LOG OPERATOR OPERATOR
@LOG OPERATOR OPERATOR
@LOG OPERATOR OPERATOR
JOB 1 ON TTY43 10-0CT-79 09:00:42
@ENA
JOB 2 ON TTY44 10-0CT-79 09:00:42
JOB 3 ON TTY45 10-0CT-79 09:00:43
$"ESET LOGIN PSEUDO
@ENA
$"ESET LOGIN CONSOLE
$RUN SYS:BATCON
$"ESET OPERATOR
$PTYCON
PTYCON> GET SYSTEM:PTYCON.ATO
PTYCON>SILENCE
@ENA
$RUN SYS:NETCON

[From OPERATOR on line 45: SYSTEM IN OPERATION]
SJ 0: PTYCON.LOG.l
SJ 0: PTYCON> WALL
SJ 0: OPR(O)
3
OPERATOR
OPR
SJ 0: PTYCON> CONN OPR
SJ 0: [CONNECTED TO SUBJOB OPR(O)]
Figure 6-1 (Cont.)

0:0:6

Startup Dialogue for TOPS-20 DECnet-20 on a
DECSYSTEM-2020

6-6

RUNNING DECnet-20
6.2.2

Automatic Startup on a DECSYSTEM-2040, 2050, 2060

On a DECSYSTEM-2040, 2050, 2060, the automatic
involves a number of related operations.

startup

DECnet-20

One of the first programs executed when TOPS-20 is loaded is SYSJOB, a
system process that starts up other system processes.
SYSJOB executes
the command file PS:<SYSTEM>SYSJOB.RUN.
You edit this file to include
startup commands for the NETCON program (see Chapter 10). NETCON has
already been described at the beginning of this chapter.
ORION is the
operator's interface to NETCON.
Network commands from the operator
are parsed by the operator command parser (OPR)
and then passed to
ORION which, in turn, forwards them to NETCON.
The SYSJOB.RUN file also starts a PTYCON job and executes the
PTYCON.ATO command file.
In Chapter 10, the PTYCON.ATO file is edited
to include starting the subjob OPR.
OPR,
in turn, executes the
NCP.CMD file which sets up the DECnet-20 data base and loads the
communications front-end.
Figure 6-2 is an example of a startup
dialogue for
bringing up TOPS-20 with DECnet-20 on a DECSYSTEM 2040,
2050, or 2060. The example is taken from an operating system running
TOPS-20 Version 4 with DECnet Version 2, including the RJE option.
Prior to the example, the procedures you will follow in Chapters 9 and
10
(DECnet configuration,
installation,
and acceptance) have been
accomplished. Startup procedures for your system may show differences
according to your site's hardware and software;
for example, the
availability of extended addressing and cache memory hardware depends
on the model selected for your site.

6-7

RUNNING DECnet-20
Then, press the ENABLE rocker
(Mount the PS: disk pack on drive O.
switch while pressing the DISK rocker switch on the console front
end. )
RSX-20F YB13-41 6:34 21-SEP-79
[SYO: REDIRECTED TO DBO:]
[DBO: MOUNTED]
KLI
VERSION VB12-12 RUNNING
KLI
KLIO SIN: 2136., MODEL B, 60 HERTZ
KLI -- KLIO HARDWARE ENVIRONMENT:
MOS MASTER OSCILLATOR
EXTENDED ADDRESSING
(Note: Extended addressing
INTERNAL CHANNELS
is a Model B feature only.)
CACHE
(Note: Cache memory is available
only on DECSYSTEMs-2050/2060.)
KLI
MICROCODE VERSION 231 LOADED
KLI
ALL CACHES ENABLED
LOGICAL MEMORY CONFIGURATION.
ADDRESS SIZE INT TYPE CONTROLLER
000000000 128K
4
MA20 0 __ 1
004000000 768K
4
MF20 11
KLI
KLI

CONFIGURATION FILE WRITTEN
BOOTSTRAP LOADED AND STARTED

[PS MOUNTED]
System restarting, wait ..•
ENTER CURRENT DATE AND TIME:

9-0CT-79 1204

YOU HAVE ENTERED TUESDAY, 9-0CTOBER-1979 12:04PM,
IS THIS CORRECT (Y,N) Y
WHY RELOAD? TIS
RUN CHECKD? N
RUNNING DDMP
SYSJOB 4(10) STARTED AT 9-0CT-79 1204
RUN SYS:ORION
RUN SYS:QUASAR

*****
9-0CT-79 12:04:39 - TGHA V2 IS RUNNING FOR THE FIRST TIME.

*****
RUN SYS:MOUNTR
RUN SYS:INFO
RUN SYS:MAILER
RUN SYS:MAPPER
RUN SYS:LPTSPL
RUN SYS:LPTSPL
RUN SYS:LPTSPL
RUN SYS:CDRIVE
RUN SYS:SPRINT
RUN SYS:FAL
Figure 6-2

(Note: this example shows that
three line printer spoolers are
controlled by this system's
monitor--one for RJE station.)

Startup Dialogue for TOPS-20 DECnet-20 on a
DECSYSTEM-2040, 2050, 2060

6-8

RUNNING DECnet-20

A
A

JOB 0 /LOG OPERATOR XX OPERATOR
ENA
ESET LOGIN PSEUDO
ESET LOGIN CONSOLE

"ESET OPERATOR
PTYCON
GET SYSTEM:PTYCON.ATO

JOB 1 /LOG OPERATOR XX OPERATOR
ENA
RUN SYS:BATCON

JOB 2 /LOG OPERATOR XX OPERATOR
ENA
RUN SYS:NETCON

SJ
SJ
SJ
SJ
SJ
SJ

SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ

0:
0:

10/9-INSTALLATION-TEST SYSTEM, TOPS-20 MONITOR 4(3117)

2:
1:
0:
2:
1:
0:
2:
1:
0:
2:
1:
0:
1:
0:
0:
0:
0:

@LOG OPERATOR OPERATOR
@LOG OPERATOR OPERATOR
@LOG OPERATOR OPERATOR
JOB 2 ON TTY207 9-0CT-79 12:04:51
JOB 1 ON TTY206 9-0CT-79 12:04:52
JOB 3 ON TTY205 9-0CT-79 12:04:53
@ENA
@ENA
@ENA
$RUN SYS:NETCON
$RUN SYS:BATCON
$AESET LOGIN PSEUDO
$AESET LOGIN CONSOLE
$AES ET OPERATOR
$PTYCON
PTYCON> GET SYSTEM:PTYCON.ATO
PTYCON> SILENCE

[From OPERATOR on line 210: SYSTEM IN OPERATION]
SJ 0: PTYCON.LOG.1
SJ 0: PTYCON> WALL
SJ 0: OPR(O)
3
OPERATOR
OPR
TI
SJ 0: PTYCON> CONN OPR
SJ 0: [CONNECTED TO SUBJOB OPR(O)]
SJ 2:
0:29:45
NCP REQUEST
1 [LOAD NODE DN20A]
SJ 2:
FUNCTION COMPLETED SUCCESSFULLY
Figure 6-2 (Cant.)

0: 0: 1

Startup Dialogue for TOPS-20 DECnet-20 on a
DECSYSTEM-2040, 2050, 2060

6-9

RUNNING DECnet-20
6.2.3

Manual Startup on a DECSYSTEM-2020

To manually start DECnet-20 on a DECSYSTEM-2020, you must load the
KMCll line controller with the file COMIOP.KMC.
This file was
restored to the directory <SUBSYS> from the DECnet-20 distribution
tape during the installation procedure in Chapter 10.
From an enabled
TOPS-20 prompt, enter the following dialogue:
$OPR~

OPR>ENTER NCP~
NCP>LOAD CONTROLLER KDP_O FROM PS:<SUBSYS>COMIOP.KMC~
NCP>EXIT~

6.2.4

Manual Startup on a DECSYSTEM-2040, 2050, 2060

To manually start DECnet-20 on a DECSYSTEM-2040, 2050, 2060, you must
load the communications front end with DECnet-20 software.
The
following sequence of commands identifies the load and dump files,
loads the front end,
and starts logging line statistics.
From an
enabled TOPS-20 prompt, enter the following dialogue:
$OPR~

OPR>ENTER NCP~
NCP>SET EXECUTOR hostnodename~
NCP>SET SECONDARY-LOAD-FILE DTE20 PDP-II PS:<SUBSYS>DTEMPS.BIN~
NCP>SET TERTIARY-LOAD-FILE DTE20 PDP-II PS:<SUBSYS>DTEMPT.BIN~
NCP>SET NODE nodename SERVER servername DTE20_1~
NCP>SET NODE nodename PROTOCOL-TYPE NETWORK-SERVICES-PROTOCOL(Hu)
NCP>SET NODE nodename LOAD-FILE PS:<SUBSYS>nodename.SYS~
NCP>SET NODE nodename DUMP-FILE PS:<SUBSYS>nodename.DMP~
NCP>LOAD NODE nodename~
NCP>
hh:mm:ss NCP REQUEST # n [LOAD NODE nodename]
Function completed successfully
NCP>INITIATE LOGGING LINE-COUNTERS KDP_O_O nodename~
NCP>EXIT~

$
where:
hostnodename

is the node
processor.

nodename

is the node name assigned to the communications front
end.
See Section 9.4, Configuring for Task-to-Task.

servername

is the node name assigned to the host processor.
See
the NODE command in the editing of the 4-CONFIG.CMD
file in Chapter 10.

name

assigned

the

main

NOTE
If the front-end data base is intact and
correct as set up during the loading of
the LOAD
TOPS-20, you need only enter
NODE
node name
command
to
start
DECnet-20.

6-10

central

RUNNING DECnet-20
6.3

NCP COMMAND SUBSET OF OPR

To use the NCP commands, you must first run the OPR program and access
the NCP subset of commands.
In order
to run OPR you should be
ENABLEd;
if not, you will receive the following message:
@OPR~

10:31:42
@

--Insufficient Privileges Enabled--

ENABLE before running OPR:

@ENABLE

(CAPABILITIES)~

$OPR~

OPR)ENTER (COMMAND SUBSET)
NCP>

NCP~

The NCP commands fall into three general categories:
•

Data base commands -

to build or change the load, dump,
operating,
and logging parameters in
a node's network data base.

•

Action commands -

to load and dump nodes or lines,
alter
line states, control loopback
testing, monitor network requests,
and
display
line
status
and
statistics.

•

Miscellaneous commands - to change the location of the NCP
command
processor,
and
to turn
EVENT/ERROR logging on or off.

Some NCP commands are system-dependent;
in the following command
descriptions,
such commands are flagged with the appropriate model
numbers.
NOTE
For compatibility with other
DECnet
systems,
the keyword NODE in any NETCON
command may be replaced with the keyword
REMOTE.
The table that follows
is an alphabetized list of available NCP
commands with their applicable keywords and arguments.
See the
description of each command for system-dependencies.

6-11

RUNNING DECnet-20
Table 6-1
NCP Command Summary

KEYWORDS and/or Arguments

Command
DISABLE

EVENT-LOGGING

KNOWN
LINE

LINES }
lineid

DUMP

CONTROLLER
NODE

ctlrid
node name

filespec
[filespec J

ENABLE

EVENT-LOGGING

KNOWN
LINE

LINES }
lineid

INITIATE

LOGGING

LINE-COUNTERS lineid

LOAD

CONTROLLER
NODE

ctlrid
node name

filespec
[filespec]

*LOOP

LINE

lineid

COUNT xx

EXECUTOR
LOCAL

nodename
LOOPBACK

EXIT
node name

rI
XEO

LENGTH yy

PUSH

WITH ZEROES
ONES

RETURN
SET

LOGGING-INTERVAL
NODE

{ENABLED
DISABLED
LINE-COUNTERS nminutes
nodename

AUTO-DUMP

lineid}
lineid

{~~~!~i~ol

jENABLED l
lDISABLED f
DUMP-FILE
filespec
LOAD-FILE
filespec
PROTOCOL-TYPE NETWORK-SERVICES-PROTOCOL
SERVER
servernode
lineid
cpu type
filespec
lineid
~CABLE-LOOPBACK
CONTROLLER-LOOPBACK

AUTO-LOAD

SECONDARY-LOAD-FILE devtype
STATE
LINE

t~~INTENANCE

SHOW

TERTIARY-LOAD-FILE

devtype

cpu type

COUNTS
EXECUTOR
QUEUE
STATUS

LINE

lineid

NCP-REQUESTS
~KNOWN
LINE
lLOCAL

LINES
lineid \

TAKE
TERMINATE

OFF
filespec

filespec
LOGGING

LINE-COUNTERS lineid

nodename

*The LOOP LINE command may contain any combination of the three
keywords COUNT, LENGTH, and WITH.

6-12

RUNNING DECnet-20
6.3.1

Data Base Commands

6.3.1.1 Defining the Bootstrap Programs (2040, 2050, 2060) The
following two commands specify the secondary and tertiary bootstrap
programs to be used when a request to load a node is received.
The format of the commands is:
SET
SET

SECONDARY-LOAD-FILE
TERTIARY-LOAD-FILE

devtype cputype filespec
devtype cpu type filespec

where:
devtype

specifies the type of line device (on the target node)
which NETCON will be loading the bootstrap program.
can be the DTE20 or DMCll.

cpu type

specifies the type of CPU the bootstrap
loaded into.
This is the PDP-II.

filespec

specifies the appropriate secondary
program to be loaded.

If the node to be loaded
following commands:

communications

program
tertiary

front

over
This

will

bootstrap

end,

use

the

SET SECONDARY-LOAD-FILE DTE20 PDP-II PS:<SUBSYS>DTEMPS.BIN
SET TERTIARY-LOAD-FILE DTE20 PDP-II PS:(SUBSYS>DTEMPT.BIN
If the node to be loaded is a remote
DN200, use the following commands:

job

entry

station

such

SET SECONDARY-LOAD-FILE DMCll PDP-II PS:<SUBSYS>SECDMC.SYS
SET TERTIARY-LOAD-FILE DMCll PDP-II PS:<SUBSYS>TERDMC.SYS

6.3.1.2 Defining the Loading Node (2040, 2050, 2060) - The SET NODE
SERVER command is used to specify the adjacent node that will perform
the load or dump operation.
The format of the SET NODE SERVER command is:
SET NODE targetnode SERVER servernode serverlineid
where:
targetnode

is the name of the
dumped.

servernode

is the name of the node adjacent to the targetnode
that will perform the loading or dumping.

6-13

node

that

will

loaded

RUNNING DECnet-20
serverlineid

is the identification of the line or
interface on
the servernode that connects to the targetnode.
The
format of serverlineid is:

where:

dey

(underscore)
ctlr
(underscore)
unit

is the type of device on
the
servernode
that
interfaces
or
connects to the targetnode.
This
can be DTE20, DMCll, DUPll, or KDP.
(DUPlls are not supported for
all
configurations.)
is a required separator character.
is the number of
device controller.

the

specific

is an optional separator character,
required if unit is specified.
is the specific line unit on a
device.

KDP

6.3.1.3 Defining the Default Load File (2040, 2050, 2060) - The
SET
NODE LOAD-FILE command is used to specify the default load file for a
node.
The format of the SET NODE LOAD-FILE command is:
SET NODE targetnode LOAD-FILE PS:<SUBSYS>targetnode.SYS
where:
targetnode

is the name of the node that is to be loaded.

6.3.1.4 Defining the Default Dump File (2040, 2050, 2060) - The
SET
NODE DUMP-FILE command
is used to specify a default dump file for a
node.
The format of the SET NODE DUMP-FILE command is:
SET NODE targetnode DUMP-FILE PS:<SUBSYS>targetnode.DMP
where:
targetnode

is the name of the node that is to be dumped.

6-14

RUNNING DECnet-20
6.3.1.5 Defining the Protocol (2040, 2050, 2060) - The
SET
NODE
PROTOCOL-TYPE command is used to specify the protocol to be followed
by nodes when communicating.
The format of the SET NODE PROTOCOL-TYPE command is:
SET NODE targetnode PROTOCOL-TYPE protocol type
where:
targetnode

is the name of the node
dumped.

that

being

loaded

protocoltype

is the specific protocol to be followed
target and server nodes when communicating.

or
the

NOTE
Version 2 of DECnet-20 restricts the
following command variable as shown:
protocol type

NETWORK-SERVICES-PROTOCOL
RSX20F-QUEUED-PROTOCOL
(Only NETWORK-SERVICES-PROTOCOL is
currently supported.)

6.3.1.6 Initiating Logging (all models) - The
INITIATE
LOGGING
commaqd is used to enable the periodic recording of line activity at a
node.
For a DECSYSTEM-2040/50/60 this command is restricted to the
DN20-side of the DTE. This means that the nodename parameter can not
be the host's node name.
(See Section 6.3.2.4.) The line statistics
are requested by NETCON and are recorded in the form of SYSERR entries
to the TOPS-20 ERROR.SYS file.
SYSERR entries are described in detail
in Appendix C.

The format of the INITIATE LOGGING command is:
INITIATE LOGGING LINE-COUNTERS (FOR LINE) lineid (ON NODE) nodename
where:
lineid

identifies the line for which the
recorded. The format of lineid is:

statistics

are

being

where:

node name

dev

is the device type:

ctlr

is the controller number.

uni

is the unit number.

DMCll, DUPll, KDP, or DTE20.

is the name of the node at the particular end
being recorded.
This means that a line
statistics reported from either end.

Both lineid and nodename are required entries.

6-15

of the line
may have its

RUNNING DECnet-20
6.3.1.7 Terminating Logging (all models) - The
command
is used to stop the recording of
specified line and node.

TERMINATE
LOGGING
line activity at the

The format of the TERMINATE LOGGING command is:
TERMINATE LOGGING LINE-COUNTERS (FOR LINE)

lineid

(ON NODE) nodename

See Section 6.3.1.6 for a definition of lineid and nodename.

6.3.1.8 Setting Logging Interval (all models) - The
SET
LOGGING-INTERVAL command is used to specify how often NETCON will log
line statistics.
This interval applies to all
lines enabled for
logging.
If this command
is not given, the default interval is 60
minutes.
The format of the SET LOGGING-INTERVAL command is:
SET LOGGING-INTERVAL (FOR)

LINE-COUNTERS (TO) n

(MINUTES)

where:
n

is the number of minutes between requests for line counters.

6.3.1.9 Enabling Local Loopback (2020) - The
SET
LOCAL
LOOPBACK
ENABLED command is used to inform the local NSP that a particular line
is going to be operated in loopback mode.
One effect of this is that
data being exchanged over local logical links (connections between
tasks on the same node) is not routed entirely in the software but
is
actually sent to the line controller. Whether the data is reflected
in the controller itself or in the cable beyond is determined by the
SET STATE LINE commands described in Sections 6.3.2.9 and 6.3.2.10.
Another effect of the SET LOCAL LOOPBACK ENABLED command is
local
NSP
now
expects to receive a
reflection of
initialization message sent when the line is activated.

that the
any node

The format of the SET LOCAL LOOPBACK ENABLED command is:
SET LOCAL LOOPBACK ENABLED lineid
where:
lineid

is a required entry and identifies the line to be operated
in loopback mode.
The format of lineid is described in
Section 6.3.1.6.
NOTE
The line identified by lineid must be
turned off before issuing this command.
See the SET STATE LINE OFF command
in
Section 6.3.2.11.

6-16

RUNNING DECnet-20
6.3.1.10 Disabling Local Loopback (2020) - The SET LOCAL
LOOPBACK
DISABLED command
is used to inform the local NSP that a particular
line is no longer being operated in loopback mode.
The effects of
loopback operation described
in Section 6.2.1.9 are no longer in
effect.
The format of the SET LOCAL LOOPBACK DISABLED command is:
SET LOCAL LOOPBACK DISABLED lineid
where:
lineid

is a required entry and
identifies the line that
is no
longer
in loopback mode.
The format of lineid is described
in Section 6.3.1.6.
NOTE
The line identified by lineid must be
turned off before issuing this command.
See the SET STATE LINE OFF command
in
Section 6.3.2.11.

6.3.1.11 Controlling Automatic Reloading (2040,2050,2060) - The
SET
NODE AUTO-LOAD command controls whether or not the communications
front end is automatically reloaded after a front-end crash.
The format of the SET NODE AUTO-LOAD command is:

SET NODE nodename AUTO-LOAD'ENABLED
(DISABLEDj
where:
node name

identifies the DECnet-20 communications front
which you are setting the autoload control.

ENABLED

causes the DECnet-20 communications front end to be
automatically reloaded after a front-end crash.
When
the system is initially loaded, ENABLED is in effect.

DISABLED

causes the DECnet-20 communications front end not to be
automatically reloaded after a front-end crash.

6-17

end

for

RUNNING DECnet-20
6.3.1.12 Controlling Automatic Dumping (2040,2050,2060) - The
SET
NODE AUTO-DUMP command controls whether or not the communications
front end is automatically dumped after a front-end crash.
The format of the SET NODE AUTO-DUMP command is:
SET NODE nodename AUTO-DUMP{ENABLED }
DISABLED
where:
node name

identifies the communications front end for
are setting the autodump control.

which

ENABLED

causes the communications front end to be automatically
dumped after a front-end crash. When the system is
initially loaded, ENABLED is in effect.

DISABLED

cause the communications front
end
not
automatically dumped after a front-end crash.

you

Action Commands

6.3. 2

6.3.2.1 Loading a Node (2040, 2050, 2060) - The LOAD NODE
command
loads and starts a
target node with a specified or default program
file.
The format of the LOAD NODE command is:
LOAD NODE targetnode

[FROM

(F~LE)

filespec]

where:
targetnode

is the name of the node that is to be loaded.

filespec

is the file specification for the specific program to
be loaded.
If filespec is not included, the default
load file specification defined in Section 6.3.1.3 is
used.
If neither file specification is specified, the
system replies:
REQUEST #n [LOAD NODE targetnode]
CONFIGURATION DATA BASE ERROR
where n is the NCP request number that NETCON
to the LOAD NODE command.
NOTE
Version 2 of DECnet-20 restricts the
following command variable as shown:
targetnode

- the node name assigned to
the communications front
end.

6-18

assigned

RUNNING DECnet-20
6.3.2.2 Dumping a Node (2040, 2050, 2060)
initiates a memory dump operation.

- The

DUMP

NODE

command

The format of the DUMP NODE command is:
DUMP NODE targetnode

[TO filespec]

where:
targetnode

is the name of the node that is to be dumped.

filespec

is the file
specification for
the dump file.
If
filespec is not included, the default dump file defined
in Section 6.3.1.4 is used.
NOTE
Version 2 of DECnet-20 restricts the
following command variable as shown:
targetnode

- the node name assigned to
the communications front
end.

Checking NETCON's Request Queue (all models) ~ The SHOW QUEUE
checks NETCON's queue of network requests and displays both
those that are currently in process and those not yet started.

6.3.2.3
command

The format of the SHOW QUEUE command is:
SHOW QUEUE (OF) NCP-REQUESTS
The response will first list those requests that are in
then those not started yet, if any.
hh:mm:ss
NCP requests
#3 - DUMP
NCP requests
#4 - LOAD

in progress:
NODE DN20
on the queue but not yet started:
NODE DN20

If there are no outstanding requests, the response is:
hh:mm:ss

There are no outstanding NCP requests.

6-19

progress

and

RUNNING DECnet-20

6.3.2.4 Displaying Line Statistics (all models) - The
SHOW
COUNTS
command displays line statistics for
a specified line.
For
a
DECSYSTEM-2040/50/60, the capability of displaying line statistics is
limited to the DN20. A request to display line statistics when the
executor is the host node will receive an error response as described
in Section 6.1.
See Section 6.3.3.1 for details on changing the
executor of a NETCON command.
The format of the SHOW COUNTS command is:
SHOW COUNTS LINE lineid
where the format of lineid is the same as in Section 6.3.1.6.
Assuming you are logged in at the host node
(a
example), the following is a possible example:

DECSYSTEM-2050,

for

NCP)SET EXECUTOR DN20A
NCP)SHOW COUNTS LINE DMCll_l_O
NCP)
10:30:46
NCP request # 32 [SHOW COUNTS LINE DMCll_l_O]
Counts for line DMCll_l_O_O, as of 5-Jun-79 10:30:45
Seconds since zeroed
2488
Blocks received
978
Blocks sent
978
Retran, line errors
3
Received line errors
o
Retran, not line errors
o
Receive timeouts
3
Function completed successfully
NCP)

6.3.2.5 Exiting from NCP Subset (all models) - The
RETURN
command
returns you to operator command level, OPR).
Typing EXIT or CTRL/C to
the OPR) prompt then returns you to TOPS-20 command level.
If you
wish, you may type a CTRL/C to the NCP) prompt and return directly to
TOPS-20 command level. Typing EXIT will also return you to TOPS-20
command level.

LOAD
CONTROLLER
6.3.2.6 Loading a Line Controller (2020) - The
command loads and starts a communications line controller from a
specified file.
The format of the LOAD CONTROLLER command is:
LOAD CONTROLLER ctlrid (FROM) filespec
where:
ctlrid

identifies the
ctlrid is:

controller

6-20

being

loaded.

The

format

RUNNING DECnet-20
where:
dev

is the device type, KDP

ctlr is the controller number
filespec

is the file specification for the specific program
loaded.
The distributed program is COMIOP.KMC.

Both ctlrid and filespec are required entries.

6.3.2.7 Dumping a Line Controller (2020) - The
DUMP
CONTROLLER
command initiates a memory dump of a communications line controller to
a specified file.
The format of the DUMP CONTROLLER command is:
DUMP CONTROLLER ctlrid

(TO)

filespec

where:
The

ctlrid

identifies the controller being dumped.
ctlrid is described in Section 6.3.2.6.

filespec

is the identification of the file receiving the

format

Both ctlrid and filespec are required entries.

6.3.2.8 Starting a Line (all models) - The SET STATE LINE ON command
initializes the DDCMP line protocol on a specified line.
The local
NSP, notified that the line is active,
sends a node initialization
message over the line.
The format of the SET STATE LINE ON command is:
SET STATE LINE lineid ON
where:
lineid

is a required entry and identifies the line being started.
The format of lineid is described in Section 6.3.1.6.

6.3.2.9 Starting a Line for Controller Loopback (2020) - The
SET
STATE LINE CONTROLLER-LOOPBACK command initializes the DDCMP line
protocol and results in a node initialization message being sent as in
Section 6.3.2.8.
In addition, the line controller represented by the
devctlr portion of lineid is notified to
internally reflect any
messages that are directed to the specified line.
The format of the SET STATE LINE CONTROLLER-LOOPBACK command is:
SET STATE LINE lineid CONTROLLER-LOOPBACK
where:
lineid

is a required entry and identifies the line that is to be
started in controller loopback mode.
The format of lineid
is described in Section 6.3.1.6.
6-21

RUNNING DECnet-20
6.3.2.10 Starting a Line for Cable Loopback (2020) - The SET
STATE
LINE CABLE-LOOPBACK command
initializes the DDCMP line protocol and
results in a node initialization message being sent as
in Section
6.3.2.8.
When a loopback connector is placed on the line to reflect
data,
the synchronous line unit's
internal clock provides
the
necessary synchronization to correctly receive the reflected data,
replacing the modem clock.
The format of the SET STATE LINE CABLE-LOOPBACK command is:
SET STATE LINE lineid CABLE-LOOPBACK
where:
lineid

is a required entry and identifies the line that
is to be
started
in cable loopback mode.
The format of lineid is
described in Section 6.3.1.6.

6.3.2.11 Stopping a Line (all models) - The SET
STATE
LINE
command terminates
the DDCMP line protocol on a specified line.
line is no longer available for transmitting data.

OFF
The

The format of the SET STATE LINE OFF command is:
SET STATE LINE lineid OFF
where:
lineid

is a
required entry and
identifies
the
line
being
deactivated.
The format of lineid is described in Section
6.3.1.6.

6.3.2.12 Performing a Loopback Test (2040,2050,2060) - The LOOP LINE
command performs a
loopback test on a specified line on the current
EXECUTOR node.
The communications front end should be the current
EXECUTOR.
To determine the current EXECUTOR node,
use the SHOW
EXECUTOR command (Section 6.3.3.2).
To change the current EXECUTOR
node, use the SET EXECUTOR command (Section 6.3.3.1).
The format of the LOOP LINE command is:
LOOP LINE 1 ineid COUNT count LENGTH length WITH { ZEROES}
MIXED
ONES
where:
lineid

specifies the line being tested;
for the definition of lineid.

count

Specifies the number of blocks of data to be used
the test.
This number must be entered in octal.

length

specifies the length of each block of test data.

ZEROES
MIXED
ONES

specifies that the test data will be made up
zeroes,
all ones,
or mixed ones and zeroes.
these keywords must be entered.

6-22

see

Section

6.3.1.6
in

of all
One of

RUNNING DECnet-20
6.3.2.13 Interrogating Node Status (all models) - The
SHOW
STATUS
LOCAL commands display the status of the node that is processing the
command. The node that is processing the command (EXECUTOR node)
can
be determined by using the SHOW EXECUTOR command (Section 6.3.3.1).
Use the SET EXECUTOR command (Section 6.3.3.1) to change the EXECUTOR
node.
The format of the SHOW STATUS LOCAL command is:
SHOW STATUS LOCAL
The response includes date,
time,
node name,
node number,
the
operating system, the routing and communications versions of NSP being
used, the state of the node, and the default host node, if known.

6.3.2.14 Interrogating Line Status (all models) - The SHOW STATUS LINE
commands display the status of all or specific lines on the node that
is processing the commands.
The node that is processing the command
(Executor node)
can be determined by using the SHOW EXECUTOR command
(Section 6.3.3.2).
Use the SET EXECUTOR command (Section 6.3.3.1)
to
change the EXEUCTOR node.
The formats of the SHOW STATUS LINES commands are:
SHOW STATUS LINE lineid
and
SHOW STATUS KNOWN LINES
where:
lineid

Identifies the specific line for which the status is
being
requested.
See
Section
6.3.1.6 for
the
definition of lineid.

KNOWN LINES

requests the status of all lines known to the EXECUTOR
node.
KNOWN LINES is not available for 32K DN20s.

6.3.3

Miscellaneous Commands

6.3.3.1 Setting and Displaying Executor Node (all models) - The
SET
EXECUTOR command specifies which node
is to process subsequent
commands. The default executor node at system startup is the physical
The SHOW EXECUTOR command
node at which your login occurred.
indicates which node is currently processing your commands.
The format of the SET EXECUTOR command is:
SET EXECUTOR nodename
where:
nodename

is the name of the node that is to
NETCON commands.

The format of the SHOW EXECUTOR command is:
SHOW EXECUTOR

6-23

process

subsequent

RUNNING DECnet-20
The response takes the form:
Current EXECUTOR is node nodename

6.3.3.2 Turning Event/Error Logging On or Off (2040,2050,2060) - In
the DECnet communications front end (the DN20) the line drivers (DTE,
report hardware errors and protocol error thresholds
KDP, DMC)
(DDCMP) •
Event/error logging is supported for DECSYSTEMs-2040/50/60
with 128K words in the DN20 DECnet-20 communications front end.
The NICE task in the DN20 acts as a concentrator for messages coming
from all processes, and forwards these messages to NETCON in the host
computer.
Thus there are two ways to control
the
flow
of
event-logging messages:
the drivers can be notified to send or not
send messages to the NICE task in the DN20;
the NICE task can be
notified to forward or not forward the messages to NETCON.
To enable or disable event logging at the line level
(messages
longer sent to the NICE task in the DN20), the command format is:

{LINE line id }
' ENABLE }
EVENT-LOGGING
{
DISABLE
KNOWN LINES
To enable or disable the forwarding
NETCON, the command format is:
ENABLE }
{

event-logging

messages

EVENT-LOGGING

DISABLE /

When a DISABLE EVENT-LOGGING command is given with a line parameter,
the messages are lost from the time of DISABLE to the time you ENABLE
EVENT-LOGGING. When a DISABLE EVENT-LOGGING command is given without
a line parameter, all event/error messages are lost until another
ENABLE EVENT-LOGGING command is given.
The command to enable or disable the forwarding of event-logging
messages to NETCON is independent of the on/off setting of the lines.

6.3.3.3 Getting Another Copy of the TOPS-20 Command Processor
(all
models) - The PUSH command gives you another copy of the TOPS-20
command processor.
The format is:
PUSH

6.3.3.4 Executing NCP Commands From a File
(all models) - The TAKE
command will accept any file specification of a file containing NCP
commands.
The default file type is .CMD. The format is:
TAKE filespec

6-24

RUNNING DECnet-20
6.4

RESTART PROCEDURES

The NETCON
sequence:

process

can

restarted

with

the

following

command

@ENABLE~
$'ADVISE OPERATOR~

TTY213, EXEC
TTY2, aPR
TTY211, FAL
TTY210, NETCON
TTY207, BATCON
TTY205, PTYCON
TTY: 210~
[Pseudo-terminal, confirm]~
Escape character is <CTRL)E, type <CTRL)A? for help
OPERATOR job 3 NETCON
LINK FROM OPERATOR, tty 3
[Advising]
(CTRLiC)

$ RESET( RlT)
$RUN SYS:NETCON~
~TRLiE)
; (Note:
AE does not echo on terminal)
[Advice terminated]
$DISABLE~
@

When NETCON is restarted all
knowledge of
the network
is lost.
Therefore you must repeat all commands to identify the various DN20
(and DN200) data base elements.
(See Section 6.3.1.)
If the ORION process fails while the NETCON process
following NETCON warning message is displayed:
% NETCON:
Whenever this
command.
The ORION
sequence:

running,

the

ORION is not running
occurs,

process

can

ORION
be

must

restarted

reloaded

using

the

AESPEAK

with

following

command

the

@ENABLE~

;enable capabilities
$AESPEAKG!D
;give AESPEAK command
[PLEASE TYPE SYSJOB COMMANDS - END WITH AZ] ;
KILL SYS:ORION~
;restart ORION
RUN SYS:ORION~
(CTRLi l)
;end the AESPEAK command
$'DISABLE~
;disable capabilities

In addition, because the new copy of ORION has no knowledge of
NETCON's location,
NETCON must also be reloaded.
The initialization
routine in NETCON sends a message to ORION identifying itself.

6-25

RUNNING DECnet-20
6.5

OPERATOR MESSAGES

When running DECnet-20, there are a number of messages that can appear
at the operator's console.
Some of these abort NETCON and stop
network processing; others are warnings and allow NETCON to continue.
Still others merely confirm network commands.
DECnet-20-related
messages can be categorized as follows:

6.5.1

•

Responses (normal or error)
NETCON commands

resulting from

•

Warning messages
operations

temporary

•

Fatal error messages that reflect
enough to abort the NETCON process

•

Error messages from the NETCON command parser
(OPR)
due to
problems in parsing commands or forwarding commands through
ORION to NETCON

due

the

inhibitions
program

execution

network

problems

severe

NETCON Command Responses

All NCP commands that are processed by the NICE module of the NETCON
program are assigned a Request Number and placed in the NCP-REQUEST
queue.
The user receives a meaningful response and the Request
Number.
Currently,
some commands that are not processed by the NICE
module respond only with the NCP prompt to indicate the program is
ready for the next command.
Examples of commands with the NCP prompt
as the only response are SET EXECUTOR, SET LOGGING-INTERVAL,
and SET
LINE. All SHOW commands are followed by a response and time stamp (no
Request Number).

6-26

RUNNING DECnet-20

Following are examples of each of the three types of responses.
NCP>set executor 2102
NCP>
(NCP prompt only)
NCP>show executor
NCP)
16:33:11
Current EXECUTOR is node 2102
(Response and time stamp)
NCP>show sta kn Ii
NCP>
16:33:52
NCP request #23

[SHOW STATUS KNOWN LINES]

Status as of 18-0ct-79 16:33:51
Line ID

State

Adjacent Node

DTE20_0_0
Off
DTE20_1_0
Off
DTE20_2_0
Off
DTE 2 0_3_0
Off
Function completed successfully

NCP)
(Response, Hequest Number, and time stamp)
If the NSP link disappears, the message that is output is:
NSP link died

If a command cannot be successfully completed,
one of the
following messages may be displayed and NCP will prompt for the
next command.

Invalid function or option

NCU process not available

No room for new entry

In all of the following situations, NETCON continues to operate.
If the condition cannot be remedied by retrying, refreshing data
files, or correcting hardware problems, report it to the Software
Services representative or submit a Software Performance Report
(SPR) •
File I/O error
This message is due to either a file read error or
a disk
write error.
For a read error, try to restore a good copy
of the file.
For a write error, have the hardware problem
corrected.

6-27

RUNNING DECnet-20

Line protocol error
DTE20 (or DN200)
hardware problem occurred
during
a
down-line load operation or a problem with the bootstrap ROM
in the communications front end.
Configuration data base error
Invalid or missing entries in the network data base.
Invalid file
One of the load or bootstrap files cannot be found or is not
in the correct format.

Invalid server id
Invalid node id
The command specifies a node name that does not follow
naming convention for nodes.
(See Section 2.1.4.)

the

Line communications error

An error occurred in the DTE20 (or DN200) hardware or
system was generated that cannot fit in available memory.

Line in wrong state
Invalid line id
The line identification given as an argument
command is invalid.
(See Section 6.3.1.2.)

the

NCP

Network communications error
Normally this message means that NETCON cannot communicate
with the NICE process on a node. The problem could be at
either end (resource problems, for example).

I
6.5. 2

NETCON Warning Messages

NETCON warning messages are displayed whenever unexpected conditions
arise during the execution of network control functions or network
utilities. NETCON continues to run and the condition will either
disappear due to improved system resources or will worsen to the point
of a fatal error message. Warning messages are preceded by a line
containing the time of day in the format hh:mm:ss.

I
I

% NETCON:

Could not open any JFNs for the NCU task

% NETCON:

Could not create a PIn for receiving ORION messages

% NETCON:

Could not send "HELLO" message to ORION

% NETCON:

Could not set up PIn interrupt channel

% NETCON:

No more free pages available

6-28

RUNNING DECnet-20
% NETCON:

Attempt to return an illegal page address

% NETCON:

Attempt to return a page that is already on the free list

% NETCON:

No more free space available

% NETCON:

Attempt to return a free block outside the free pool area

% NETCON:

Attempt to return space already marked as in the free pool

% NETCON:

ORION is not running

% NETCON:

Failed to successfully send a message to OPR

% NETCON:

Unimplemented NETCON command

% NETCON:

Unknown internal NETCON message type

% NETCON:

Exhausted table space for the known nodes

% NETCON:

All server JFNs in use

% NETCON:

NCU process halted prematurely

% NETCON:

Unknown message type received from ORION

% NETCON:

JSYS error

% NETCON:

Could not get name of local node

% NETCON:

Could not log line counters for communications line

% NETCON:

Could not initiate Logging Process

% NETCON:

Invalid line-id

% NETCON:

Could not open file

% NETCON:

Bad data in load file

The foregoing warning messages reflect potential or actual program
problems;
they should be reported via Software Performance Reports
(SPRs).

6.5.3

NETCON Fatal Error Messages

Whenever NETCON finds
itself in a situation where
it
cannot
effectively continue operation, a fatal error message is displayed at
the operator's console.
Fatal error conditions should be reported
to
the Software Services representative and documented via a Software
Performance Report (SPR).
The SPR should
include the text of the
error message as well as
information with which the error can be
reproduced.
The fatal error messages listed below are the result of some
internal
program error.
Since NETCON is no longer running, any attempt at
recovery must begin with reloading NETCON as described in Section 6.3.

6-29

RUNNING DECnet-20

NETCON:

Pushdown list overflow at location:

nnnnnn

NETCON tried to add an item to the
exceeded the specified list size.
?

NETCON:

list

and

NETCON tried to read data from an area that appears to
inaccessible.

Illegal memory read at location:

pushdown

nnnnnn

Illegal memory write at location:

nnnnnn

NETCON tried to write data to an area that appears
unavailable for writing.
?

NETCON:

Illegal instruction at location:

nnnnnn

NETCON tried to execute what it thought was an instruction
and found an invalid instruction code.
?

NETCON:

Machine size exceeded at location:

nnnnnn

NETCON ran out of some monitor resource while executing
JSYS operation.
?

NETCON:

I/O data error or parity error at location:

nnnnnn

NETCON encountered an unrecoverable data or
while reading a file or writing to disk.

parity

Fatal error at location:
NETCON encountered an
specified location.

NETCON:

error

nnnnnn

undetermined

fatal

error

the

Could not open topology server links.
This is possibly due to too many open network links.

Each of the above fatal error messages is followed
monitor error message or the following:

some

specific

(Unknown monitor error code)

6.5.4

Other Error Messages

Before a NETCON command is processed by NETCON, the command is handled
by both the OPR and ORION programs.
Each of these processes checks
the command for syntax and intent.

6-30

RUNNING DECnet-20
The following error messages are issued by aPR due to errors detected
by aPR.
In each case, the command is ignored and aPR prompts for the
next entry.
Reenter the command correctly.
?Invalid command "text"
This message occurs when aPR does not recognize the initial word
of the command line as a valid command name.
"text" is the word
that aPR tried to parse as a command name.
?Can't find file "filespec"
This message occurs when a file, specified
in a command line,
cannot be found.
"filespec" is the actual string submitted to
the GTJFN monitor call.

?Can't Open TAKE Command File
This message occurs when the command file
specified
in a
command cannot be opened.
(The OPENF monitor call failed.)
?Command error:

TAKE

string

This message occurs when a command line cannot be parsed.
String
is the text resulting from the translation of a JSYS error number
by the ERSTR monitor call.
The following messages are issued by aPR due
ORION.
In each case, recovery is possible.

errors

detected

hh:mm:ss No Processor for Object
This message occurs if NETCON is not running or if ORION has been
reloaded without reloading NETCON.
Reload NETCON as described in
Section 6.3 and reenter the command.
hh:mm:ss Insufficient Privileges Enabled
This message occurs if aPR is being run without having OPERATOR
or WHEEL privileges enabled.
The message is displayed when aPR
is first invoked; and again for each command submitted to OPR.
(ENABLE
Obtain
OPERATOR
or WHEEL privileges,
enable them
CAPABILITIES command), and rerun aPR.
The following messages are also issued by aPR due to errors detected
by ORION;
however,
the errors are due to communications problems
between aPR and ORION and should be
reported to the software
specialist.
hh:mm:ss Message Too Short
ORION received a message from
allowed minimum.

aPR

that

was

shorter

than

the

hh:mm:ss Bad Message Length
ORION received a message
specified in the message.

that

was

the

hh:mm:ss Illegal Message Type
ORION received a message with an illegal message type code.

6-31

length

RUNNING DECnet-20
hh:mm:ss Wrong ORION Message Version Number
ORION received a message specifying a
from that of the running version.

version

number

different

hh:mm:ss Unidentified Processor Type
ORION received a command intended
NETCON.

for

processor

other

than

hh:mm:ss Illegally Formatted Command Message
ORION received a command that it did not understand.
If the aPR program is started at a time when ORION is not running, the
initial message that aPR uses to identify itself to ORION cannot be
sent.
Information in the following
format
is displayed at the
operator's console;
the actual values will, of course, be different.
?Stop code - SOF - in module aPR on 13-0ct-77 at 15:04:06
Reason:
Send to ORION Failed
Program is aPR Version 1(12} using GLXLIB Version 1(20}
Last GLXLIB error:
0 (No errors yet) ,
Last TOPS-20 error:
601130 (Invalid index into system PID table)
Contents of the ACs

0/
4/
10/
14/

(Crash block starts at location 600000)

777777777777

400000

o
o
o

612000616

o
o
o

777731001321

Last 9 Stack Locations:

-l(P}/
-4(P}/
-7(P}/
HLT:401202/

o
o

-2(P}/
-5(P}/
-8(P}/

HALTF

6-32

o
o
o

-3(P}/
-6(P}/
-9(P}/

o
o
o

PART IV

TERMINAL USER'S GUIDE

CHAPTER 7
COMMUNICATING WITH THE SYSTEM

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 and TOPS-20 Batch Reference
Manual
You should know, or have readily at hand,
the node name of your
central processor and the name of all remote nodes with whom 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

with

DECnet

software

•

List accessible DECnet nodes
DECNET command.

using

the

TOPS-20

INFORMATION

•

List your logical DECnet node using
JOB-STATUS command.

the

TOPS-20

INFORMATION

•

Direct output to accessible DECnet nodes using the TOPS-20 SET
LOCATION command or the TOPS-20 DESTINATION-NODE:
node switch
for queue-class commands.

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
8,
Network
File Transfer.)

7-1

COMMUNICATING WITH THE SYSTEM
7.1

INFORMATION COMMAND

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

7.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~

Accessible DECNET nodes are:
DN20L, SYS880

1031, 2102,

4097,

DN200,

DN20A,

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

7.1.2

Information Job-Status

INFORMATION JOB-STATUS lists your logical node if your logical node is
not your physical node.
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 1031
@

7.2

SET LOCATION COMMAND

The SET LOCATION command instructs the TOPS-20 operating system to
regard the specified node as your logical node.
Your logical node
determines where your queued output goes.
When you log in, your
logical node is the same as your physical node. Currently, this
command is effective only when the specified node is controlled by the
local host.
For example, the SET LOCATION command is useful when you
wish to send several messages or print requests to the remote station
,nM') () ()'

\ UL' ~ V

v J •

7-2

COMMUNICATING WITH THE SYSTEM
The format of the SET LOCATION command is:
@SET LOCATION (TO)

node::

where:
node: :

The name of the node that becomes your
logical node.
If no node name is entered, the node name defaults to
the name of your physical node.

Example:
@set location dn200::~
@print test.txt~
[Job TEST Queued, Request-ID 550, Limit 27]
@

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
(The above example shows how abbreviation may be used.)
Remember that the request remains on 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 is:
This is a test file!
(the contents of the file TEST.TXT).
The SET LOCATION command may also be used to direct requests to the
local site's remote station (DN200).
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 user's terminal at host site:
@set location

dn200::~

@infORMATION (ABOUT)

joB-STATUS~

Job 33, User CIRINO, Account 341, TTYI06
Located at DN200
@please turn printer on~
[Operator Notified at 15:21:09 ••• Please wait for reply]

7-3

COMMUNICATING WITH THE SYSTEM

Output to console at remote site:
2102::0PR)
2102::
<8)
15:21:09

--Message from Timesharing User-JOB 33 CIRINO at Terminal 106
PLEASE turn printer on

Input by remote operator:
2102::0PR)RESPOND 8 PRINTER IS ON~
2102::0PR)
Answer received at host site:
[Operator Response Received at 15:21:58]
PRINTER IS ON

7.3

/DESTINATION-NODE SWITCH

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

The name of the node where output is directed.

Example:
@PRINT

7.4

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

ADDITIONAL FEATURES AVAILABLE TO NONPRIVILEGED USERS

The File Transfer Program described in the next chapter can be run
a nonprivileged user.

Appendix F describes three programs that use DECnet-20's task-to-task
communications capabilities.
These programs,
NRT20, NRTSRV,
and
STNRT, allow 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.
Appendix F describes the function and use of these three programs.
All users may use the SYSERR program to type or print
and event logging reports.
(See Section 10.3.7.)

7-4

network

error

CHAPTER 8
NETWORK FILE TRANSFER

8.1

OVERVIEW

The Network File Transfer {NFT} program allows you to access or delete
files
residing on DECnet hosts that provide network file access
capabilities.
These capabilities are usually provided by a File
Access Listener
(FAL) program.
NFT deletes files from a remote host
and transfers 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 UIle Lemole hosl.
Files can be transferred from YVUL ..LVCQ..L
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.
DECnet-20 does not support 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 8.2.1.}

8.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 the subsequent honoring or rejecting of your
request.
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.
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 type 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
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.)
8-1

NETWORK FILE TRANSFER
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.

8.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>.
If you want to see the list
of valid NFT commands, type the question mark character (?).
Example:
@NFT~

NFT>? one of the following:
COPY
DELETE
DIRECTORY
INFORMATION
SET
SUBMIT
NFT>

EXIT
TAKE

HELP
TYPE

NFT also offers the recognition feature of TOPS-20.
If you type an
NFT command after the NFT prompt and then press the ESCape key, NFT
displays one or more guidewords to prompt you for the next response.
Guidewords are enclosed in parentheses. After a guideword, type the
question mark character (?) to display the list of valid responses.
Additional guidewords and valid responses can be shown by repeating
the alternate use of the ESCape key and the question mark character
until all the input requirements for that command are satisfied.
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:

8.2.1

Operating system

File Specifications Format

TOPS-20

device:<directory>filnam.ext.gen

VAX/VMS

device: [username]filnam.extigen

RSX, RSTS and lAS

device: [UIC]filnam.extigen

SET DEFAULTS Command

The SET DEFAULTS command establishes the default access information to
be used with all subsequent NFT commands for the specified node.
The
values established with the SET DEFAULTS command remain 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.

8-2

NETWORK FILE TRANSFER
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 8-1)
and,
in addition,
the switch
/OSTYPE:operating system.
Valid values for
the
operating-system argument are TOPS20, RSXll, RSTS,
VMS, or lAS.

the

default

values

are

Examples:
@NFT~

(12':)

NFT)SET DEFAULTS '(FOR NODE)

GD
NFT)SET DEFAULTS '(FOR NODE)

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

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

NFT) SET DEF.l'd.!LTS • (FOR NODE) G.z'.,MM1\:: /l1SEP: REILLY/ACC: l1ETP~
NFT)
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.INIT. Values set in
an NFT.INIT file are effective until they are changed in the NFT.INIT
file.
Access information established in the NFT.INIT 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 run unless you change
or override it.
The access information switch is effective only for
the command in which it is specified.
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.
@type pS:<PTAYLOR)nft.init~
SET DEFAULTS 2102::/USER:PTAYLOR/ACCOUNT:341/0STYPE:TOPS20
SET DEFAULTS l031::/USER:PTAYLOR/ACCOUNT:341/0STYPE:TOPS20
SET DEFAULTS SYS880::/USER:GUEST/ACCOUNT:FOO/OSTYPE:RSXll/PASS:DUMB
SET DEFAULTS 4097::/USER:REILLY.PTAYLOR/ACCOUNT:341/0STYPE:TOPS20
SET DEFAULTS 2137::/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, the system assumes the node to be
the node where your logged-in directory is located.

8-3

NETWORK FILE TRANSFER
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 run.
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
DEFAULTS command. NFT establishes these parameters each time the NFT
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~

G:)

de~AULTS~

NFT>iJFORMATION (ABOUT)
Node 2l02::/USER:CIRINO/ACCOUNT:34l/0STYPE:TOPS20

GD
NFT)set deFAULTS (FOR NODE)~

NFT>iJFORMATION (ABOUT) de~AULTS~
Node 2l02::/0STYPE:TOPS20
NFT)

8-4

NETWORK FILE TRANSFER
Example 2.
@NFT~

Accessible DECNET nodes are:
DN20L

2102, 1031, 4097, DN200, DN20A,

NFT>i;FORMATION (ABOUT) de~AULTS~
Node 2l02::/USER:PTAYLOR/ACCOUNT:34l/0STYPE:TOPS20
Node 103l::/USER:P:TAYLOR/ACCOUNT:34l/0STYPE:TOPS20
Node 4097::/USER:REILLY.PTAYLOR/ACCOUNT:34l/0STYPE:TOPS20
Node SYS880::/USER:GUEST/ACCOUNT:FOO/OSTYPE:RSXll
@)

NFT>set djFAULTS (FOR

NODE)~
~

de'FAULTS~

NFT>in'FORMATION (ABOUT)
Node 2l02::/0STYPE:TOPS20
Node 103l::/USER:PTAYLOR/ACCOUNT:34l/0STYPE:TOPS20
Node 4097:/USER:REILLY.PTAYLOR/ACCOUNT:34l/0STYPE:TOPS20
Node SYS880::/USER:GUEST/ACCOUNT:FOO/OSTYPE:RSXll
\..2:~

NFT>set

de~AULTS (FOR NODE) 1031: :(Rt7)

.GD

NFT>inFORMATION (ABOUT) de FAULTS~
Node 2l02::/0STYPE:TOPS20
Node 103l::/0STYPE:TOPS20
Node 4097::/USER:REILLY.PTAYLOR/ACCOUNT:34l/0STYPE:TOPS20
Node SYS880::/USER:GUEST/ACCOUNT:FOO/OSTYPE:RSXll
NFT>

8.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.

8-5

defaults

NETWORK FILE TRANSFER
userid

is the valid user
specified node.

identification

account-string

is the valid account at the specified node.

ostype

is the operating system at the specified node.

the

Example:
@NFT~

NFT> INFORMATION '(ABOUT)

DEFAULTS~

Node 210A::jUSER:SKOGLUNDjACCOUNT:341jOSTYPE: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:
@NFTGD

GiD
NFT> INFORMATION 4(ABOUT) DECNET G!D
Accessible DECNET nodes are:
NFT>

8.2.3

1031, 2102, DN20A, DN20L

COpy Command

The COpy command transfers files from the local node to a remote
or transfers files from a remote node to the local node.

node

The format of the COpy command is as follows:
NFT>COPY (FROM) nodel::filespecljswitches (TO) node2::filespec2jswitches
where:
nodel::

is the node name of the source host from which the
file
is transferred.
The default node is the local
node.

filespecl

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

node2: :

is the node name of the destination host to which
the file
is transferred.
The default node is the
local node.

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 node::2.

jswitches

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

switches

defined

Table

NETWORK FILE TRANSFER
Table 8-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.
Userid must be an ASCII string of 1 to 16
characters.
/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.

8-7

NETWORK FILE TRANSFER
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 node;
REMOTE is
the name of the remote node.
Example 1.
@NFT~

GO
NFT>COPY'(FROM)

LOCAL::*.MAC~(TO) REMOTE::*.MAC~

LOCAL::PS:<USER>ABC.MAC=>REMOTE::PS:<USER>ABC.MAC [OK]
LOCAL::PS<USER>XYZ.MAC=>REMOTE::PS:<USER>XYZ.MAC [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.
Example 2.
@NFT~
(

ESt)

NFT>COPY 4(FROM)

(

ESC)

ZOOM. * 4(TO) REMOTE:: ZOOM. *GIQ

LOCAL::PS:<USER>ZOOM.EXE=>REMOTE::PS:<USER>ZOOM.EXE [OK]
LOCAL::PS:<USER>ZOOM.MAC=>REMOTE::PS:<USER>ZOOM.EXE [OK]
In the above example, the system interprets the wildcard designation
for
file type, transfers the two extant 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~

NFT>COPY

(FROM) REMOTE::ABC.TXT·(TO)

ABC.TXT~

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

8-8

NETWORK FILE TRANSFER

Example 4.
@NFT~

NFT>COPY TPARs.MAC/ASCII SYSlOl::DBO:TPARS.MAC/ASCII/VARIABLE:132~
TPARS.MAC => SYSlOl::DBO:TPARS.MAC [OK]
NFT>DIRECTORY

SYSlOl::DBO:*.MAC~

SYSlOl: :DBO: [200,200]
TPARS.MAC;1;P77S600

6 11264(8)

lS-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.
(SYSlOl is an RSX operating system.) Second, guidewords are
not used.
Note that this example includes the IASCII switch for the
TOPS-20 source node, and includes the /ASCII/VARIABLE:132 switches for
the RSX destination node.
Specifying File Processing Mode
When transferring files between TOPS-20 systems, you do not need to
specify the file processing mode because TOPS-20 has established
defaults based on file bytesize.
The defaults are:
File byte size

Default processing mode

7
all except 7

IASCII
/IMAGE

Specifying Source File Processing Mode
When transferring local files
to a non-TOPS-20 system,
you must
specify the local
(source)
file processing mode unless the file is
bytesize 7.
When transferring files from the RSTS, lAS, or RTll operating systems
to your local system, you must specify the remote (source) file
processing mode.
NOTE
Failure to match remote
(source)
file
processing switches with the actual data
mode of
the
remote
file
to
be
transferred
will
have unpredictable
results.

8-9

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:
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

8-10

NETWORK FILE TRANSFER
8.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:
@nft~

Accessible DECNET nodes are:
2102, 1031, 4097, DN200, DN20A
NFT>delete 2l02::sep.txt~
Access information for node 2l02::/USER:cirino/ACCOUNT:34l
Password:
2102::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.

8.2.5

DIRECTORY Command

The DIRECTORY comman~ rpturns a ~irpctnry listing of the files at
the
specified remote 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)

•

Tne aate ana tIme tne 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 aGcess 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.

8-11

NETWORK FILE TRANSFER
Several examples follow.
Both the environment and the timing of the
DIRECTORY command influence 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 run.
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 2l02::/USER:KAMANITZ/ACCOUNT:341
Password:
2102::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 2l02::/USER:KAMANITZ/ACCOUNT:341
Password:
EDIT/SAVE:5/ISAVE:5

•

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

1 39(36)

8-12

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 4097. There is no NFT.INIT file.
The
DIRECTORY command is the first command given that requires access
to node 4097. A prompt is given for each access information
parameter.
@NFT~

(EsC)

-T

NFT)DIRECTORY (OF REMOTE FILES) 4097::~
Access information for node 4097::
User: CRUGNOLA~
Account: 341~
Password:
4097::PS:<CRUGNOLA)
CALEND.EXE.1iP777700
DIDDLE.ZZZ.1i P777700
LA36.CMD.1iP777700
LOGIN.CMD.2iP777700
~AIL.TXT.1iP770400

PTYCON.ATO.1iP777700
SWITCH.INI.2iP777700
VT50.CMD.1iP777700
VT52.CMD.1~P777700

ZIP.Q.1iP777700
NFT>

5 2560(36)
1 6(36)
1 74(7)
1 21(7)
1 175(7)
11220(7)
1 39(7)
1 28(7)
1 60(7)
1 45(7)

10-Apr-78
6-Aug-79
13-Mar-78
13-Mar-78
26-Jul-79
19-May-78
18-May-78
13-Mar-78
13-Mar-78
14-Jun-78

11:23:48
15:51:41
16:39:48
16:36:23
13:01:46
13:34:26
15:33:10
16:37:44
16:38:49
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~

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

1
1
1
1

8-13

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 RSXll
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 5101. 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 RSXll 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 RSXll.
@NFT~

Accessible DECNET nodes are:

NFT>DIRECTORY (OF REMOTE FILES)
SY5101: :DKO: [200,200]
INSTALL.CMD;17;P775600

8.2.6

27-Dec-78 17:44:26

SY5101::DBO:*.CMD~

1512(8)
1512(8)
1512(8)
11024(8)
1512(8)

12-May-78
12-May-78
12-May-78
12-May-78
7-Sep-79

15:45:35
15:45:36
15:45:36
15:45:37
16:45:14

example

EXIT Command

The EXIT command ends NFT execution.
command which follows.

8.2.7

SY5101::~

1 1536(8)

NFT>DIRECTORY (OF REMOTE FILES)
SY5101: :DBO: [200,200]
MERGE.CMD;1;P565600
FLOPPY.CMD;1;P565600
PLO.CMD;1;P565600
PLOT.CMD;1;P565600
COPIES.CMD;3;P775600
NFT>

1031, 2102, 4114, DN20H, SY5101

See

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 NFT~
NFT>HELP~
NFT - Network file transfer program

8-14

23-Apr-79

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.
NFT>EXIT~

8.2.8

SUBMIT Command

The SUBMIT command allows a Batch control file to be submitted to the
Batch input queue at a specified remote 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.
The format of the SUBMIT command is as follows:
NFT>SUBMIT (REMOTE FILES) node::filespec/switches
where:

8.2.9

node::

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

the

filespec

is the file specification of the remote file.

/switches

are the access information switches.

file

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) filespecl (LOGGING OUTPUT ON) filespec2
where:
filespecl

is the file specification of the local command file.

filespec2

is the file specification
logging output.

the

local

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.

8.2.10

TYPE Command

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

your

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

terminal.

The

NETWORK FILE TRANSFER
8.3

NFT ERROR MESSAGES

In the course of running NFT, you will probably 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, interpretive text is supplied following the message.

8.3.1

NFT Warning Message
%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.

8.3.2

NFT Fatal Error Messages
?Cannot close logical link

- TOPS-20 text for JSYS error

?Cannot do requested file format conversion
Check the allowable source/destination file processing
combinations (Section 8.2.3).

mode

?Cannot establish requested mode for input
?Cannot establish requested mode for output
?Cannot get JFN for
error

logical

link ••• - TOPS-20

text

for

JSYS

?Cannot open command file
Examine the file specification of your .CMD 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
?Destination file must be specified
?Invalid account string
?Invalid destination processing mode
?Invalid password

8-16

NETWORK FILE TRANSFER
?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
?Logical link reception error
Check to see if your directory on the target system is
quota.

over

?Logical link transmission error
?Logical link was aborted ••. - disconnect reason text
?Logical link was terminated
?Remote file attributes not supported
?Remote node is not responding
?Remote node refused connection •.. - disconnect reason text
?Remote status ••. - error text
If your
network
includes nodes
running other
than
the
TOPS-20 Operating System, you may receive this message.
The
error text that follows
Remote
status will be
from
the
non-TOPS-20
operating
system.
Approximately
200 such
messages are possible.
Your
local NFT
repeats
this
"foreign" message verbatim.
You will need help from your
Software Support Specialist.
Because the error message
originates
in the operating system at the remote site, the
problem cannot be readily resolved.
?Remote system does not support default mode
?Remote system does not support file submission
The NFT SUBMIT command is
node.

not

implemented

the

remote

?Remote system does not support requested mode
?Remote to Remote transfers not supported
This message is displayed if you use
the COpy command
to
transfer a file from one remote node to another remote node.
?Source file must be specified
?TOPS-20 text for JSYS error
This message consists of any appropriate JSYS error message
not specifically covered in other messages in this list.

8-17

NETWORK FILE TRANSFER
8.3.2.1 Internal NFT Program Errors - These fatal errors should not
occur.
If anyone of these errors dries occur, you will need the help
of your Software Support Specialist.
These errors are internal to the
NFT program.
?Dap message buffer is full
?Invalid link index
?Logical link not established
?Invalid argument length
?Function not implemented

8-18

PART V

GENERATING DECnet-20

CHAPTER 9
USING THE CONFIGURATION TOOLS

If you are running DECnet-20 on a DECSYSTEM-2020, your only concern
with this chapter is Section 9.4.
This is the section that describes
how you create the needed directories and restore the task-to-task
files from the distribution tape.
You should ignore all references to
DN20 and DN200.
The steps you execute in Section 9.4 are Steps 4,
5,
and 6. Go now to Section 9.4.
Because of the several options now available in both hardware and
software, each DECnet node on a DECSYSTEM-2040, 2050, or 2060 has a
set of tools for customizing the DECnet configuration.
There are no
model dependencies.
Approximately three hundred files spread over two distribution tapes
are used to tailor the software for various DECnet-20 configurations.
The major file types and files are outlined in Section 9.3.
The tools for configuring the DECnet-20 front-end node (DN20 or
DN21)
for
single
or
multi-line
task-to-task are on the DECnet-20
Task-to-Task Distribution Tape.
A successfully installed TOPS-20
Operating System running a Version 4 monitor is a prerequisite to
on-site configuration for task-to-task capability.
Configuring for
task-to-task must precede configuring for RJE.
The system may be in
timesharing or standalone mode.
You will create two directories and one subdirectory on PS:
to store
temporarily the files needed for configuration.
You must use the
parameters given in the step-by-step procedures.
You will need at
least 3900 pages for working storage and 3900 pages for permanent
storage.
Ensure that space is adequate before you begin
the
procedures.

9.1

CONFIGURATION OVERVIEW

The logical steps in configuring the DECnet-20 communications front
end or remote station are summarized below. A detailed step-by-step
procedure is outlined in Section 9.4.
The purpose of the general
description
below
is
to acquaint you with the configuration
environment and thus provide a reference point for
the
information
that precedes the step-by-step procedure.

9-1

USING THE CONFIGURATION TOOLS
•

•

Create one directory
generation files:

and

one

sUbdirectory

for

DECnet

PS:<DNGEN>
PS:<DNGEN.CMDS>
The various files to be copied into these directories are on
the
distribution tape with the identical structure and
directory names.
•

Create one directory for documentation and source files:
PS:<DECNET>

•

Create one directory for example command and output files
acceptance testing.

for

•

Mount the appropriate distribution tape (Task-to-Task or RJE)
and use the DUMPER utility program to copy the directory
contents from the tape to the two created directories on disk.

•

Create a directory for your own customized files:
PS:<DN20-l>
or
PS:<DN200>

•

Prepare to build the customized directory.
Preparation
involves logical definitions, CONNECT and ACCESS commands, and
a TAKE of the appropriate .CMD file.
There are three
.CMD
files:
DN20BLD.CMD
Sets up the area for multiline task-to-task.
DN200BLD.CMD
Sets up the area for the RJE (DN200) option.
32KBLD.CMD
Sets up the area for a single
(32K front end).

line

task-to-task

DN20

NETGEN to define the configuration. This is the core of
• Run
configuration
procedure and the step that demands
the
preparation on your part.
•

Submit the .CTL file now in your customized directory to the
Batch system.
Output will be files for the system (DN20 or
DN200) generation and a .LOG file.

•

Inspect the .LOG file output by the batch
possible errors in the build process.

•

Continue or rerun NETGEN as indicated by the inspection of the
.LOG file.
(Use the NETGEN command RESTORE.)

9-2

job

check

for

USING THE CONFIGURATION TOOLS
•

Run VNP20.
image.

This program creates the system

(DN20

DN200)

•

The system image created by the VNP20 program now exists as
PS:(DN20-1> nodename.SYS
(or PS:(DN200> nodename.SYS if you
were configuring for RJE).
If a change in the structure name
or directory name or both is desired for your site, use the
COpy command to accomplish the change at this time.

The file named nodename.SYS is the LOAD-FILE for
the named network
node. This file will be set up for loading into the front end as part
of the installation procedure.
At the end of your first NETGEN run for the DN20, if no errors occur,
your system will include basic task-to-task capability.
A second run
is necessary to generate RJE.
In addition,
you must repeat the
configuration procedures whenever you change the network configuration
(add a line, add a node, or add an option, for example).
Network File Transfer (NFT) is a utility program that is part of the
basic DECnet task-to-task package.
No customizing is required for
NFT.

9.2

PREPARING TO USE THE CONFIGURATION TOOLS

Your configuration (and installation) procedures will run smoothly if
you are well-prepared.
It is strongly suggested that you observe the
guidelines below before you begin to use the configuration tools.
•

Read this entire
chapter.
Configuring
the
DECnet-20
communication
front
end
requires
an understanding of
parameters not normally of concern to you. Also,
terms used
in NETGEN have a specific meaning to the program.
All
parameters referenced in the configuration process will be
explained before a step-by-step procedure for configuring the
front-end.

•

Hardware parameters specifically entered or accepted
as
defaults MUST reflect the actual hardware in place at your
site.
Software parameters MUST be within the given range.
Accepting
defaults
for
software parameters 1S a
safe
procedure, but may not give optimum performance if you have a
high load average and the maximum number of lines.
Do NOT
enter a value other than the default without understanding the
tradeoffs described in the documentation.
(As previously
noted, all 32K systems must be configured exactly as described
in the BEWARE file.)

•

If you have any doubt about the value to type for a parameter,
check with your system manager.

•

You may find it helpful to make a written list of names,
symbols, numbers and text strings you will need for use at the
terminal.
You will need a node name for both the DECnet
communications front end and the host or central processor.

•

Read the DECnet-20 BEWARE file if there is one.

9-3

USING THE CONFIGURATION TOOLS

9.3

•

TOPS-20 Version 4 has a new operator command syntax and a new
operator
interface.
You can successfully complete procedures
by following the directions.
However, you will be better
prepared to handle unexpected situations if you are familiar
with the new OPR-ORION facilities under GALAXY.

•

You will use both DUMPER and the batch subsystem during
configuration.
Depending on your experience, you may wish to
review these programs.
Commands that check your progress
through the procedures may be helpful.

•

Set aside approximately
two
hours
for
your
on-site
configuration.
(Actual time may be less or more, depending on
you, the configuration, and your operating system.)
Secure a
terminal and location where you will not be interrupted.

THE CONFIGURATION TOOLS AND RELATED FILES

The term "configuration tools" refers to
DNMAC.

NETGEN,

TKB20,

VNP20,

and

Two standard TOPS-20 DUMPER-formatted magnetic tapes contain the files
needed.
The distribution tapes are the Task-to-Task Release Tape and
the DN200 RJE Release Tape.
(There is also a tape with unsupported
software for customer use.) The tapes contain the same information for
all systems with the same unbundled options.
You must use the task-to-task tape to set up your system for
task-to-task capability before you use the RJE tape (if this option is
purchased) •
The task-to-task tape contains all
the files needed to support
task-to-task capability for any configuration. Also included are the
network control task (NETCON) and its associated loader files,
and
required
.BWR,
.HLP, and .DOC files.
The major files and file types
that are used to build your specific DECnet configuration are:
•

PDP-II files for all modules needed for any configuration of
the DN2x.
This includes object modules, symbol tables, and
memory maps.

•

DN20BLD.CMD.
This is the command file
for
building a DN2x
front end for
single or multiple line task-to-task systems.
(For single line task-to-task systems of 32K words,
the
comparable file
is 32KBLD.CMD;
for RJE the command file is
DN200BLD.CMD.) When the commands in this file have been
executed,
your front-end directory will contain the following
files:
This is the control file for the batch
• BUILD-ALL.CTL.
job that follows the NETGEN program.
This file
• RSXIIS.TSK.
front-end memory image.

• RSXIIS.STB.
front end.
•

DNMAC.EXE. This is
source files.

sets

This is the symbol
the

cross

9-4

the

DN2x

for

the

table

file

for

the

assembler

for

PDP-II

macro

USING THE CONFIGURATION TOOLS

9.3.1

•

NETGEN.EXE.
This is the program that allows you to enter
parameters for your site.
These parameters will be used to
construct CETAB,
the data base for
the node
you
are
configuring.

•

TKB20.EXE.
This program
images from object files.

•

VNP20.EXE.

constructs

PDP-II

formatted

task

This program creates the front-end system image.

The NETGEN Program

NETGEN is the
interactive program that you use to
hardware and software for the node you are configuring.

describe

the

9.3.1.1 Features - NETGEN has default values for all values that you
type in by command or in response to a prompt. Where these values
represent the correct values for your configuration, you need only
type carriage return.
The program will assume the default for that
parameter.
If you type a? following the NETGEN prompt
responds with a list of valid commands.

(NETGEN»,

NETGEN>? Command name, one of the following:
Exit
CCBs
Exclude
Include
Flow-count
Help
NRM-pipes
Logical-links Node
RDBs
Password
RDB-size
SDBs
Save
SDB-size
Transmit-buffers
NETGEN>

the

program

Finished
Information
Number-of-nodes
Restore
Software-ID

Now you know the possible commands, but not the possible responses.
feature.
Type the command
NETGEN will continue to help you via the ?
Again type?
For example:
you wish to give and press the space bar.
NETGEN>include ? Device type, one of the following:
DMCll
DTE20
DUPll
Card-reader
KDP
Task
Line-printer
NETGEN>include
Assume you wish to inform NETGEN that your controller is a KDP.
Type
KDP.
Never assume you have completed a command.
Press the space bar
and again type?
The program responds with both a prompt for
more
information and the permissable range of values within which your
response must fall.
(Assuming the command has additional parameters
to be entered):
NETGEN>include kdp?
KDP Number, 0 to 2, decimal number
NETGEN>include kdp O~
Number of DUPII lines on this KDP(I-4}:
In the last example you could also respond by typing KDP<ESC>.
This
would give you the guideword (number), but not the valid limits of the
parameter.
For example:

~(number)

NETGEN>include kdp

9-5

USING THE CONFIGURATION TOOLS
Using? or <ESC> will not result
in confusing messages.
A typed
<ESC> that has no purpose, that is, no further response is necessary,
will have no effect.
A?
typed when the command has been completed
will result in the message shown below:
NETGEN>include dupll (number)

confirm with carriage return

Recognition input (typing <ESC> to cause completion of commands and
printing of guidewords)
is available in NETGEN.
This feature works
the same for NETGEN commands as for
TOPS-20 commands.
The added
information provided by the guidewords is even more helpful in NETGEN
because the commands will not be familiar to you.
In the
following
examples,
the same three instructions require more than twice as many
key strokes using full input rather than recognition input.
As you
read the recognition input, notice how the guidewords lead you to the
correct response.
Full input:
NETGEN>PASSWORD RECEIVE MARL~
NETGEN>SAVE PS:<DN20-l>NETGEN-CONFIG.IMAGE~
Recognition input:

NETGEN>Flow-count (for DN200 links is)

NETGEN>Password

NETGEN>Save

(for) Receive

(configuration on)

l4~

(is) MARL~

PS:<DN20-l>NETGEN-CONFIG.IMAGE~

9.3.1.2 NETGEN Terms and Concepts - To configure and
install your
TOP-20 DECnet-20 Version 2.0 subsystem you need to be familiar with
certain components you will normally be aware of indirectly if at all.
This section is to familiarize you with the hardware and software
terms used in NETGEN.
The actual values to be entered will be
explained later in the step-by-step procedure.
Hardware Terms:
All hardware terms you supply to NETGEN are DECnet-20 specific and
must be directly related to the node you are configuring.
You do not
include hardware attached to the console front end or hardware
attached to a communications front end running DN6x software.
DN20

The term DN20 is a generic term and
includes
both the DN20 and the DN2l, that is, DN20
refers to a DECnet-20 communications front
end.

KDP

The term KDP is a DECnet term that refers to
a combination of a KMCll (controller) and one
to four
DUPlls.
With the KMC the DUPll
functions as a direct memory access device
(DMA).
The interface is synchronous.
The
program
prompts you for
attached lines.
DUPlls with a
KMC
dL~
not
specified
separately with the INCLUDE command.

9-6

USING THE CONFIGURATION TOOLS
DUPll

This term is used in the NETGEN program to
indicate
DUPlls
running as a character
interrupt device, that is, without a KMCll.
A DUPll may be specified in an INCLUDE
command only when it exists without a KMC.

DMCll

The
DMCll
is
microprocessor-based
network.
The DMCll
device.

DTE20

The DTE20 referred to in the program is the
interface between the 2040,
2050, or 2060
processor and the DN20 front end.
The
parameter to be supplied to the program for
the DTE20 is the number by which the software
identifies the DTE, not the number of DTEs.
Since DTE
is (and must be)
the DTE that
connects the console front end with the main
processor, the parameter to be supplied will
usually be DTE 1. The exception will be the
case where your configuration has a front end
for
IBM
Emulation/Termination.
The two
communication front end interfaces to the
main processor would be DTE 1 and DTE 2.
Provided the data base contains the valid
number,
it does not matter which is 1 and
which is 2.

line
a
single
the
interface
to
is a synchronous DMA

Links

This term appears
in
response
to
the
INFORMATION
command.
The
value
is
established by the program and not by a
command you type.
Links refers to the total
number of physical links present in your
DECnet-20 subsystem.
If you have a KDP with
two lines, for example, you have
3 links:
one link controlled by DTE 1 to the main
processor, one link with the identification
KDP_O_O, and one link with the identification
KDP_O_l.

Node

Used as a command, this term refers to your
DECsystem-20 communications front end (or the
DN200 if you are configuring for
RJE).
The
NODE command takes several arguments.
As
used in the command NUMBER-OF-NODES,
the
reference is to the number of task-to-task
links plus 2 (allowance for expansion of the
network) .0

Line-printer
Card-reader

Line printer and card-reader parameters are
normally
specified
for
the
DN200
configuration only.
(If you believe you have
one or more of these devices on the DN20 when
you
do
not have RJE, check with your
manager. )

Software Terms:
The NETGEN program introduces software terms
(several of which are
acronyms)
that may not be familiar to you.
Or, you may be familiar
with the terms but unaware of the significance of the parameters you
enter associated with the terms.

9-7

USING THE CONFIGURATION TOOLS
The default values associated with the software terms will be
acceptable in most instances.
You can, however, alter the default
values to tailor your DECnet system to your particular needs.
Any
changes you make in the values must fall within the limits set by the
program.
Do not change default values if you do not fully understand
the implications of the change.
The software terms are explained in the order
in which they would
normally be entered or displayed.
The format used is the command
format unless the term is displayed only.
Node Name

This is the name for
the node being generated.
Within the network the node name must be unique.
In the next release it will be a requirement that
the node name include at least 1 alpha character.
You may wish to meet this requirement during this
generation.

Node Number

This term refers to the node identifying number.
It may be any decimal number in the range 2 to 127
provided it does not duplicate a number already
assigned to another node in the network.
Node
names and node numbers must be unique to establish
the
identify of a node in a unambiguous manner
when the name or number is used in a command by
the local or remote node.

Node Type

Node type must be either DN20 or DN200.
DN20 is
valid for task-to-task capability. DN200 is valid
for RJE.

Software-ID

This term identifies the
software
you
are
including as your DECnet subsystem.
Any text
string from 1 to 32 characters is valid.

Password Transmit

This is the password sent to the remote node
during an NSP initialization sequence.
This is an
optional parameter.
If given,
the
transmit
password must be a text string of 0-8 characters.

Password Receive

If specified, this password must be sent by the
remote node during an NSP node initialization
sequence.
The receive password must be a
text
string of 0-8 characters.
The receive password is
optional.
The default is null.

Logical-links

This term refers to the number of logical links
NSP should support.
Included are the logical
links for user tasks and utilities.
Be sure to
include logical links for
file
transfer.
The
permitted range is 12-63;
the default is 24.
The
cost of additional logical links is more memory
for more speed.

CCBs

This term is the acronym for Communication Control
Blocks.
The CCBs command sets the number of CCBs.
CCBs contain pointers to SDBs.
The number of CCBs
must be at least as large as the number of SDBs.
The permitted range is 10-200;
the default is 64.

9-8

USING THE CONFIGURATION TOOLS
RDBs

This term is the acronym for Receive Data Buffers.
RDBs are used for both transmitting and receiving
data segments.
The RDBs command sets the number
of
RDBs.
When
the number of simultaneous
exchanges between nodes exceeds the number of
RDBs,
a delay will occur before transmission can
be made.
This
parameter
depends
on
the
configuration of your network and the extent and
nature of your network activities.
Factors to
consider are:
number of nodes;
number of users;
the mix of interactive jobs to file
transfer;
peak and average load;
and the limits set by
available memory.
More RDBs improve throughput at
the expense of memory.
The permitted range is
6-200;
the default is 64.

RDB-size

This term refers to the size of the RDBs in bytes.
The size of the RDB determines the largest network
data segment your system can transmit or
receive
via the physical line protocol (DDCMP).
Large
buffer size is best for
file
transfer
serVice;
small buffer size (and hence more buffers) is best
for interactive traffic.
The permitted range
is
290-2082;
the default is 290.

SDBs

This term is the acronym for Small Data Buffers.
The SDBs command sets the number of SDBs.
SDBs
are used for internal storage of transmit data and
temporary data structures.
The number of SDBs
that can be used at one time is limited to the
number of CCBs you specify.
The permitted range
is 8-63;
the default is 32.

SDB-size

This term refers to the size in bytes of the SDBs.
The permitted range is 80-128. The default is 80.
SDB size, within the given limits, will have no
appreciable effect on performance.

Transmit-buffers

The
number
of
Transmit
buffers
specified
determines the number of transmit requests that

NSP will try to keep outstanding.

The

permitted

range is 2-16;
the default is 2. The tradeoff is
more memory for more speed.
Double buffering
is
generally acceptable.
Number-of-nodes

NRM Pipes
NRM Flow Count

This term refers to the number of nodes
in the
same network as the node you are configuring plus
2 to allow for expansion.
The permitted range
is
8-20;
the default is 12. The number-of-nodes
must be at least equal to the maximum number
of
lines plus 2.
The defaults currently set are adequate.
these parameters to be defaulted.

Allow

Estimated-Pool-Size
This parameter is calculated by the program and
appears
only in response to the INFORMATION
command.
Pool-size is calculated on the basis of
your specified configuration.

9-9

USING THE CONFIGURATION TOOLS
9.4

CONFIGURING FOR TASK-TO-TASK CAPABILITY

Files on the Task-to-Task Release Tape include all files
that are
needed to provide task-to-task capability for any DECSYSTEM-2020,
2040, 2050, or 2060. The DN20 files on tape are located in the
directory PS:<DNGEN> and the subdirectory PS:<DNGEN.CMDS>.
You create
identical directories on your system and then copy the entire contents
of the two directories to your system.
These two directories should
be saved as copied.
In addition, if you are running a DECSYSTEM-2040,
2050, or 2060, you create a separate directory that will contain only
those files specific to the DN20 system that you are generating.
This
directory is PS:<DN20-l>.
Once the directories are created and the files are restored from tape,
you proceed with the several steps that build the DN20 front end.
The
parameters that appear in example commands have been chosen to ensure
an efficient procedure:
space parameters allow for expansion and
actual and logical names permit inter-file referencing.
You should
not experience needless delays if you follow the directions exactly.
If you are upgrading from a previous version,
use <NEW-SYSTEM> and
<NEW-SUBSYS> for
the directories <SYSTEM> and <SUBSYS> respectively.
Files from the current version of the distribution tape should be
copied to empty directories, that is, not mixed with files of a prior
version.
(The previous version should be saved on tape or disk until
the
current
version
runs
successfully
in a normal working
environment.)
Because command and control files and logical definitions reference
other files, you should name and locate files as given in the text and
examples.
If indicated by your site's conventions,
file names and
locations may be changed after the configuration and installation
procedures have been successfully completed.
Be aware, however,
that
should you later wish to reconfigure the system or run validation or
certification tests for diagnostic purposes, references to files and
structures will need to be resolved.
A fully installed TOPS-20 operating system with a monitor
that is
Version 4.0 or later is a prerequisite to on-site configuration of the
DN20.
Log in as a user with OPERATOR or WHEEL privileges and continue
from
Step
1
for
DECSYSTEMs-2040/50/60, or from Step 4 for
DECSYSTEM-2020.
Step 1:

Create PS:<DNGEN>.

(DECSYSTEMs-2040/50/60 only)

Enter:
@ENABLE~

$AECREATE PS:<DNGEN>~
[New]
$$WORKING 1000~
$$PERMANENT 1000~
$$PROTECTION 774000~
$$PASSWORD DECNET~
$$DIRECT 4747~
$$USER 4747G!!)
$$MAXIMUM l~
$$GD

$DISABLE~
@

9-10

USING THE CONFIGURATION TOOLS
Step 2:

Create PS: <DNGEN. CMDS>.

(DECSYSTEMs-2040/50/60 only)

Enter:
@ENABLE~
$AECREATE PS:<DNGEN.CMDS>~

[New]
$$WORKING l50~
$$PERMANENT l50~
$$PROTECTION 774000~
$$DIRECT 4747~
$$FILES-ONLY~

$$~
$DISABLE~
@

Step 3:

Create PS: <DN20-l>.

(DECSYSTEMs-2040/50/60 only)

Enter:
@ENABLE~
$AECREATE PS:<DN20-l>~

[New]
$$WORK 750~
$$PERM 750~
$$USER 474 7(!D
$$PASSWORD xxx(RIU}
$$(!iD
$D I SABLE ( RET )
@

The password to the front-end directory (PS:<DN20-l»
be your own password for logging in to PS:.
Step 4:

Create PS:<DECNET>

Enter:
@ENABLE( RET )

$AECREATE PS:<DECNET>~
[New]
$$WORK 2000~
$$PERM 2000 ~
$$PROTECTION 774000~
$$USER 4747~
$$PASSWORD XXX~
$$~
$DISABLE~
@

9-11

to be built

may

USING THE CONFIGURATION TOOLS
Step 5:

Create PS:<UETP.DECNET>.

Enter:
@ENABLE~

$~ECREATE PS:<UETP.DECNET>~

[New]
$$WORK 100~
$$PERM 100~
$$FILES-ONLY~
$$USER 100~
$$DIRECT 474 7 ~
$$~
$DISABLE~
@

Step 6:
Use DUMPER to restore files from tape to disk.
Mount the
DECnet Version 2 distribution tape on an available drive.
(MTAO or
MTO is used in the examples.)
If you are running a DECSYSTEM-2020,
complete Step 6 and continue with Chapter 10.
NOTE
Restoring the save sets not related to
configuring the front end is done at
this time to avoid a second handling of
the tape.
Use the
INFORMATION SYSTEM-STATUS command
allocation is enabled for your system.
If your installation does not
feature:-

include

the

determine

tape

allocation

enabled

Enter:
@ENABLE~
$ASSIGN MTAO:~
$DUMPER~
DUMPER>TAPE MTAO:~
DUMPER>REWIND~

DUMPER>ACCOUNT (OF RESTORED FILES FROM)

SYSTEM-DEFAULT~

DUMPER>RESTORE (TAPE FILES) PS:<*>*.*.*
(Restores Documentation files.)

(TO)

<DECNET>~

DUMPER>RESTORE (TAPE FILES) PS:<*>*.*.*
(Restores Binary files.)

(TO)

<SUBSYS>~

DUMPER>RESTORE (TAPE FILES) PS:<*>*.*.*
(Restores Source files.)

9-12

(TO) <DECNET>(RET)

tape

USING THE CONFIGURATION TOOLS

NOTE
The next
RESTORE
command
DECSYSTEMs-2040/50/60 only.

for

GD
l

DUMPER>RESTORE (TAPE FILES) PS:<DNGEN>,PS:<DNGEN.CMDS>~
(Restores DN20 Generation files)

DUMPER>RESTORE~(TAPE FILES) PS:~*>*.*.* (TO) <UETP.LIB>~
(Restores the acceptance files.)
GK)

DUMPER>RESTORE~(TAPE FILES)

C~~_)
~

PS:<*>*.*.* (TO) <UETP.DECNET>~
(Restores the sample files for acceptance tests.)

DUMPER>REWIND~

DUMPER> EXITG!)
$DISABLE~
@

Or if your installation includes the tape allocation enabled feature:
Enter:
@ENABLE~

$MOUNT TAPE logical-name:~
[logical name: assigned to MTO]
NOTE
If you are working standalone and there
is no operator in attendance, go to the
operator's
console
and
enter
the
IDENTIFY command:
OPR>IDENTIFY tape-id REQ request-id
The request-id appears on the operator's
console.
The tape-id you type is MTAn.
The system associates
the
physical
device MTAn with your logical assignment
to MTn.

9-13

USING THE CONFIGURATION TOOLS
$DUMPER~

DUMPER>TAPE logical-name:~
DUMPER>REWIND ~

•

DUMPER>ACCOUNT (OF RESTORED FILES FROM)

SYSTEM-DEFAULT~

DUMPER>RESTORE (TAPE FILES) PS:<*>*.*.* (TO)
(Restores Documentation files.)

DUMPER>RESTORE (TAPE FILES)
(Restores Binary files.)

<DECNET>~

DUMPER>RESTORE (TAPE FILES)
(Restores Source files.)

PS:<*>*.*.* (TO)

<SUBSYS>~

<DECNET>~

NOTE
The next
RESTORE
command
DECSYSTEMs-2040/S0/60 only.

for

DUMPER>RESTORE (TAPE FILES) PS:<DNGEN>,PS:<DNGEN.CMDS>~
(Restores DN20 Generation files)

DUMPER>RESTORE (TAPE FILES) PS:<*>*.*.* (TO)
(Restores the acceptance files.)
~

<UETP.LIB>~

•

DUMPER>RESTORE (TAPE FILES) PS:<*>*.*.* (TO) <UETP.DECNET>~
(Restores the sample files for acceptance tests.)
DUMPER>REWIND~

DUMPER>EXIT( RET)
$DISMOUNT TAPE logical

name~

$DISABLE~

or any
The logical name used above may be your first or last name,
other valid string you will remember.
If you are installing a
DECSYSTEM-2020, go to Chapter 10 now.

9-14

USING THE CONFIGURATION TOOLS

Step 7:

Set up the build files.

Enter:
@DEFINE GEN:

PS:<DNGEN>,PS:<DNGEN.CMDS>~

This command defines the location
areas.
@DEFINE DN20:

the

release

distribution

PS:<DN20-1>~

This command defines
site-specific files.
@DEFINE DSK:

the

front-end

directory

created

for

DSK:,GEN:~

This command defines the file search association of DSK:
Step 8:

CONNECT to DN20:
and
performing an ACCESS.

establish

group

privileges

appropriate

for

Enter:
@CONNECT
Password:

DN20:~

XXX

@ACCESS DN20:~
Password:

XXX

The password is the same as that used in Step 3.
Step 9:

Tell the system to process the command file
your configuration.

with this step you begin work on configuration.
From this point on
files will be put to the directory <DN20-1>.
Therefore, a failure in
generation procedures may require that all
files be deleted
from
<DN20-1> and that you repeat all from Step 9.
If you are configuring a multiline task-to-task system with or without
the RJE option or a single line task-to-task system with more than 32K
of memory:
Enter:
@TAKE

DN20BLD.CMD~

If you are configuring a single line task-to-task system with only 32K
of memory:
Enter:
@TAKE

32KBLD.CMD~

9-15

USING THE CONFIGURATION TOOLS
The following files are now in the DN20:

directory, PS:<DN20-1>:

BUILD-ALL.CTL.l

(control file for the Batch job that
NETGEN)

RSXllS.STB

(symbol definition file)

RSXllS.TSK

(task image file)

follows

If you use the wrong file in this step, simply repeat the TAKE command
using the correct file.
Step 10:

Run the NETGEN program to define the system configuration.

Enter:
@netgen~

TOPS-20 Network Configuration for DN2x or DN200, Version:

V2.2-39

NOTE
If you are configuring a
32K DECnet-20
communications
front
end
and have
neglected to read the file DECNET.BWR.l,
do so now before you continue. Within
the beware file there is a memo with the
subject title "Configuration of Release
4 32Kw DN20s".
The beware file may be
printed
or
typed
from
PS:<DECNET>DECNET.BWR.l
(unless
you
elected to put the documentation save
set in a different directory).
Step 10.1:

Give the identifying parameters
following is an example entry.

for

your

Enter:
NETGEN>node name marl~
NETGEN>node number 67~
NETGEN>node type DN20~
NOTE
You could have taken advantage of NETGEN
features by using any of the following
for help:

9-16

DN20.

The

USING THE CONFIGURATION TOOLS

NETGEN>? Command name, one of the following:
Exit
Finished
CCBs
Exclude
Include
Information
Flow-count
Help
NRM-pipes
Number-of-nodes
Logical-links Node
RDBs
Password
RDB-size
Restore
SDBs
Save
SDB-size
Software-ID
Transmit-buffers
NETGEN>node ? Parameter, one of the following:
name
number
type
NETGEN>node name marl~
NETGEN>node number 67~
NETGEN>node type? Node type, one of the following:
DN20
DN200
NETGEN>node type DN20~
NETGEN>
You may need to use the <ESC> and?
in
later commands.
They will not always be
given in examples.
If you need more
help with a parameter or command, refer
back to Section 9.3.1.1.
You are now ready to examine the default values and
change them to reflect your planned configuration.
Step 10.2:

them

Adjust the current hardware parameters as required by
hardware at your site.

the

Check the current parameters.

NETGEN>info~

Node name is:
MARL
Node number is:
67
Software ID is: DECnet-20 V2
Transmit Password is: DECNET20 (default)
Receive Password is: (null) (default)
Logical links:
24 (default)
CCBs:
64 (default)
RDBs:
64 (default)
RDB-size:
290 (default)
SDBs:
32 (default)
SDB-size
80 (default)
Transmit buffers: 2 (default)
Node type is:
DN20
Number of nodes:
12 (default)
KDPs:
1 (default)
KDP_O has 1 lines,
DUPlls:
0 (default)
DMClls:
0 (default)
Physical links:
2 (default)
NSP link controlled by DTE_l, Task-to-Task
NSP link controlled by KDP_O_O, Task-to-Task
DTE20 number:
1 (default)
Line printers:
0 (default)
CRlls:
0 (default)
Tasks:
(defaulted)
72-Hour-Test
Topology-Notifier
NRM pipes:
3 (default)
NRM Flow-count:
16 (default)
Estimated Pool-size: 5504 bytes
NETGEN>
Step 10.3:

9-17

USING THE CONFIGURATION TOOLS
Example #1.
To include 3 lines controlled by the KDP, rather than the
1 indicated.
Enter:
NETGEN>exclude kdp O~
NETGEN>include kdp O~
Number of DUPll lines on this KDP(1-4): 3
NETGEN>
The KDP is first excluded and then included to permit you to specify
the changed number of lines and trigger the correct number of prompts
for link usage.
Example #2.

To include 3 DMClls and no KDPs.

Enter:
NETGEN>exclude
NETGEN>include
NETGEN>include
NETGEN>include
NETGEN>
Step 10.4:

kdp O~
dmcll O~
dmcll l~
dmc 11 2 ( RlT )

Check all current parameters.
input as in Example 2.)

(The output

Enter:
NETGEN)information~

Node name is:
MARL
Node number is:
67
Software ID is: DECnet -20 V2
Transmit Password is: DECNET20 (default)
Receive Password is: (null) (default)
Logical links:
24 (default)
CCBs:
64 (default)
RDBs:
64 (default)
RDB-size:
290 (default)
SDBs:
32 (default)
SDB-size
80 (default)
Transmit buffers: 2 (default)
Node type is:
DN20
Number of nodes:
12 (default)
KDPs:
0
DUPlls:
0 (default)
DMClls:
3
Physical links:
4
NSP link controlled by DTE_l, Task-to-Task
NSP link controlled by DMCll_O, Task-to-Task
NSP link controlled by DMCll_l, Task-to-Task
NSP link controlled by DMCll_2, Task-to-Task
DTE20 number:
1 (default)
Line printers:
0 (default)
CRlls:
0 (default)
Tasks:
(defaulted)
72-Hour-Test
Topology-Notifier
NRM pipes:
3 (default)
NRM Flow-count:
16 (default)
Estimated Pool-size: 5504 bytes
NETGEN>
9-18

shown

assumes

USING THE CONFIGURATION TOOLS

Make necessary additions and any desired changes in
parameters. The default parameters for software should be
adequate for the two examples.
Space permitting, you may
wish to increase the number of CCBs, SDBs, RDBs, and
logical links for the configuration with the three higher
speed DMClls.

Step 10.5:

If you are configuring a system with 32K, you must exclude either
72-Hour-Test or the Topolology-Notifier.

the

possible entries, depending on the network you plan, might be:
~

NETGEN>password ~(for) ?
Receive
Transmit

GJ
NETGEN>password

•

(is)

one of the following:

Receive password,

0 to 8 characters,

text string

(for) receive

CD
NETGEN>password

(for) receive

NETGEN>password

Password type,

(is) GUEST~

CG=)
.

(for) transmit

~
(is) MARL67\ RlT)

4 .

*********
Cf")

(f\c)

NETGEN>exclude
72-Hour-Test

NETGEN)exclude
NETGEN>

NETGEN>ccbs
NETGEN>ccbs
NETGEN>sdbs
NETGEN>sdbs
NETGEN>r dbs
NETGEN>rdbs
NETGEN>

-T

(from Configuration) task
Operator-Console

(fror.1 Configuration) task

*********
NUr.1ber of CCBs, 10 to

(type) ?

(type)

task type, one of the following:
Topology-Notification

72-Hour-Test~

200, decimal number

96~

Number of SOBs,

8 to 63, decimal number

40~

Number of ROBs,

6 to

200, decimal number

96~

9-19

USING THE CONFIGURATION TOOLS
Step 10.6: Examine the current parameters once again if you made
entries since Step 10.4.

any

The example below assumes you have added MARL67 and GUEST as the
transmit and receive passwords, respectively, rather than accept the
defaults.
Entry and response:
NETGEN>information~

Node name is:
MARL
Node number is:
67
Software ID is:
DECnet -20 V2
Transmit Password is: mar167
Receive Password is: guest
Logical links:
24 (default)
CCBs:
64 (default)
RDBs:
64 (default)
RDB-size:
290 (default)
SDBs:
32 (default)
SDB-size:
80 (default)
Transmit buffers: 2 (default)
Node type is:
DN20
Number of nodes:
12 (default)
KDPs:
0
DUPlls:
0 (default)
DMClls:
3
Physical links:
4
NSP link controlled by DTE_l, Task-to-Task
NSP link controlled by DMCll_O, Task-to-Task
NSP link controlled by DMCll_l, Task-to-Task
NSP link controlled by DMCll_2, Task-to-Task
DTE20 number:
1 (default)
Line printers:
0 (default)
CRlls:
0 (default)
Tasks:
(defaulted)
72-Hour-Test
Topology-Notifier
NRM pipes:
3 (default)
NRM Flow-count:
16 (default)
Estimated Pool-size: 5504 bytes
NETGEN>
Step 10.7:

When the output from the INFORMATION command accurately
reflects what you want your configuration to be, save the
completed NETGEN procedure.
Check very carefully:
Once
you have typed "FINISHED", correction procedures will
include returning to Step 9 or less.

Enter:
NETGEN>save ? output filespec

NETGEN>save pS:<DN20-1>NETGEN-CONFIG.IMAGE~
(Typing escape results in the output NETGEN-CONFIG.IMAGE
as the default file name.)

9-20

USING THE CONFIGURATION TOOLS
Step 10.8:

Type the commands FINISHED and EXIT.

Enter:
NETGEN>finished~

%Have you issued a SAVE command for this configuration?
NETGEN> ex i t ~
@

(The reminder above, given after you type finished, is given ONLY
if you did NOT save the completed NETGEN procedure.
The reminder
would not appear if Step 10.7 had been executed as given.)
The following files are now in your connected directory:
BUILD-ALL.CTL.l
CETAB.MAC.l
GBLDLX.MAC.l
GBLFLO.MAC.l
GBLNSP.MAC.l
NETGEN-CONFIG.IMAGE.l
NRMDAT.MAC.l
RSXIIS.STB.l
RSXIIS.TSK.l
Step 11:

Ensure that the DN20 directory contains only
files.

the

necessary

If the system notifies you that deleted files will be expunged, do NOT
begin the following sequence. Wait until the expunge is completed.
(The undelete will not function if the files have been expunged.)
Enter:
@jelete *.*~
@undel rsxlls.*~
@undel *.image~
@undel * .mac~
@undel build-all.ctl~
Step 12:

Submit the BUILD-ALL.CTL file to the batch system.

Enter:
@SUBMIT BUILD-ALL.CTL/TIME:15/0UTPUT:NOLOG/NOTIFY:YES~
[Job BUILD Queued, Request-ID #60 Limit 00:15:00]
The batch job should take from 10 to 15 minutes.
When
completed, the system will output the equivalent of:
[From SYSTEM:

the

job

Job BUILD Request # 60 Finished Executing at 14:47:31]

9-21

USING THE CONFIGURATION TOOLS
Step 13:

Type or print the BUILD-ALL. LOG file and
for errors.

examine

the

file

Interpret Batch system messages as follows:
? at the start of the message indicates a fatal error.
% at the start of a message indicates a warning.

at the beginning of a message indicates a comment.
Following successful completion of the Batch job, all files
that are
needed to construct the actual system have been created.
Only jobs
with fatal errors have failed to complete successfully.
Warning
messages may appear
for
any given configuration.
Undefined global
symbols, default symbols generated,
and possibly multiply-defined
global symbols may require no action on your part. All fatal errors
require repetition of some previous steps.
Interpret the fatal error
message given to determine the steps to be repeated.
(See Appendix G
for a complete list of error messages for TKB20 and VNP20.)
Consult
your Software Support Specialist if you are in doubt as to how to
proceed.
Step 14:

Run the VNP20 program.

Enter:
@VNP20~

This program runs in approximately 2 minutes of CPU time.
When VNP20 completes successfully, the
your terminal:

following

output

appears

•

information on free space within the core
pool, and the network pool

image,

the

•

a partition map of the created system front-end image

kernel

Your system now includes basic task-to-task capability.
To include
the RJE option,
continue with Section 9.5.
If you are generating a
system without the RJE option, go now to Chapter 10.
IN CASE OF ERRORS:
If errors prevent successful completion of a step in the configuration
process,
check all steps prior to the point of failure.
Specifically
check if user groups were set correctly in Steps 1, 2, and 3, and
if
the access command was correctly executed in Step 6.
If you have not
found your error, check Step 9.
Did you use the correct file for
the
TAKE command?
If so, next check the files that should be in the DN20
directory at the end of Step 9 and at the end of Step 10.8.
If an
error has not been found, check the NETGEN procedure for omissions or
errors and the BUILD-ALL. LOG file for error messages preceded by"?"
If a fatal error is found in the log file, delete the log file.
Go
back to the point of error and repeat all from that point.

9-22

USING THE CONFIGURATION TOOLS
9.5

CONFIGURING FOR REMOTE JOB ENTRY

image you
follow
the
same logical
steps you
To build the DN200
followed
to build
the DN20.
However, because of the differences in
hardware and functions, there will be some differences in files
used
and values you
specify.
These differences will be given under the
step number when they occur.
In all instances the name DN20 becomes DN200.
Steps I and 2.

(Creation of directories.)

You
have
already
created
the
directories
PS:<DNGEN>
PS:<DNGEN.CMDS>.
The
additional
files
needed
for
the
configuration will be added to these directories.
Step 3:

and
DN200

Create PS:<DN200>.

Enter:
@ENABLE~
$~ECREATE PS:<DN200>~

[New]
$$WORK 750~
$$PERM 750~
$$USER 4747~
.................
......
- ............

".-_ _

.........

:;>:;>l:h.00i'iU.hl."

1I.AA~

$$~
$DISABLE~
@

The password to the DN200 directory
password for logging in to PS:.
Step 4:

built

may

your

Use DUMPER to restore files from tape to disk.

The input tape is the DN200 RJE Release Tape.
If your installation does not include the tape allocation feature:
Enter:
@ENABLE~

$ASSIGN

MTAO~

$DUMPER~

DUMPER>TAPE MTAO~
DUMPER> REWIND ~

op
DUMPER>ACCOUNT (OF RESTORED FILES FROM)

DUMPER>RESTORE (TAPE FILES) PS:<*>*.*.*
(Restores Documentation files.)

SYSTEM-DEFAULT~

(TO)

<DECNET>(RET)

op
DUMPER>RESTORE (TAPE FILES) PS:<DNGEN),PS:<DNGEN.CMDS>(RH)
(Restores DN200 Generation files)
DUMPER>REWIND~

DUMPER>EXIT~
$DISABLE~
@

9-23

own

USING THE CONFIGURATION TOOLS
Or, if your installation includes the tape allocation feature:
Enter:
@ENABLE G£)
$MOUNT TAPE logical name:~
[logical name: defined as MTO:]
NOTE
If you are working standalone and there
is no operator in attendance, go to the
operator's
console
and
enter
the
IDENTIFY command:
OPR>IDENTIFY tape-id REQ request-id
The request-id appears on the operator's
console.
The tape-id you type is MTAn.
The system associates
the
physical
device MTAn with your logical assignment
to MTn.
$DUMPER G£)
DUMPER>TAPE logical

name:~

DUMPER>REWIND~

•

DUMPER>ACCOUNT (OF RESTORED FILES FROM)

DUMPER>RES~ORE

SYSTEM-DEFAULT~

(TAPE FILES) PS:<*>*.*.*(TO} <DECNET>G£)
(Restores Documentation files.)

DUMPER>RESTORE (TAPE FILES) PS:<DNGEN>,PS:<DNGEN.CMDS>~
(Restores DN200 Generation files)
DUMPER>REWIND ~
DUMPER>EXIT ~
$DISMOUNT TAPE logical name~
$DISABLE~
@

Step 5:

Set up the build files.

Enter:
@DEFINE GEN: PS:<DNGEN>,PS:<DNGEN.CMDS>~
@DEFINE DN200: PS:<DN200>~
@DEFINE DSK: DSK:,GEN:~

9-24

USING THE CONFIGURATION TOOLS
Step 6:

CONNECT to DN200: and establish group privileges by
performing an ACCESS.

Entry and response:
@CONNECT DN200:~
Password: xxx
@ACCESS DN200:~
Password: xxx
Step 7:

Tell the system to process the appropriate command file.

Your work on configuration begins with this step.
As was noted
in
configuring the DN20, a failure in procedures from this point on may
require that existing files be deleted from <DN200> and
that you
repeat all from Step 7.
Enter:
@TAKE
Step 8:

DN200BLD.CMD(RE~)

Run the NETGEN program to define the DN200 configuration.

Enter:
@NETGEN~

TOPS-20 Network Configurator for DN2x or DN200, Version:
Step 8.1:

Give the identifying parameters for the system.

Enter:
NETGEN>node name mar200~
NETGEN>node number 68~
NETGEN)node type dn200~

9-25

v2.2-39

USING THE CONFIGURATION TOOLS
Step 8.2:

Check the current parameters.

Enter:
NETGEN> info GD
Node name is:
MAR200
Node number is:
68
Software ID is:
DECnet -20 V2
Transmit Password is: DECNET20 (default)
Receive Password is:
(null) (default)
Logical links:
17 (default)
CCBs:
30 (default)
RDBs:
20 (default)
RDB-size:
290 (default)
'SDBs:
15 (default)
SDB-size:
80 (default)
Transmit buffers: 2 (default)
Node type is:
DN200
Number of nodes:
12 (default)
KDPs:
0 (default)
DUPlls:
0 (default)
DMClls:
1 (default)
Physical links:
1 (default)
NSP link controlled by DMCll_O, Task-to-Task
No DTE20
(default)
Line printers:
1 (default)
Line Printer #0 is an LPll
CRlls:
0 (default)
Tasks:
(defaul ted)
Operator-Console
NRM pipes:
6 (default)
NRM Flow-count:
4 (default)
Estimated Pool-size: 3320 bytes
NETGEN>
Note that the program has adjusted the default parameters
that probably will be most common to DN200 configurations.
Step 8.3:

Adjust the hardware parameters as required by
your site.

hardware

Possible additions/changes (ensure that your site requires or
them) might be:
To include a card reader
Enter:
NETGEN>include

card-reader~

To exclude the printer
Enter:
NETGEN>exclude

line-printer~

9-26

values

desires

USING THE CONFIGURATION TOOLS
To add a receive password, change the transmit password, or both
Enter:

NETGEN) password transmit (is)

MR200~

y
NETGEN) password receive (is)

TOMR~

(Use of passwords in communication between the front end and
remote station is not a DECnet-20 requirement but is an option.)
Step 8.4:

the

Check all current parameters if you made any changes or
additions.
(The output shown assumes a card reader was
added and transmit and receive passwords specified.)

Enter:
NETGEN) info~
MAR200
Node name is:
Node number is:
68
Software ID is:
DECnet -20 V2
Transmit Password is:
MR200
TOMR
Receive Password is:
Logical links:
17 (default)
CCBs:
30 (default)
RDBs:
20 (default)
RDB-size:
290 (default)
SDBs:
15 (default)
SDB-size:
80 (default)
Transmit buffer:
2 (default)
"1'DN200
Node type is:
Number of nodes:
12 (default)
KDPs:
o (default)
DUPlls:
o (default)
DMClls:
I (default)
Physical links:
1 (default)
NSP link controlled by DMCII_O, Task-to-Task
No DTE20
(default)
Line printers:
I
CRlls:
I
Tasks:
(defaulted)
Operator-Console
NRM pipes:
6 (default)
NRM Flow-count:
4 (default)
Estimated Pool-size: 3320 bytes
NETGEN)
Step 8.5:

When the output from the
INFORMATION command accurately
reflects your configuration,
save the completed NETGEN
procedure.

Enter:

NETGEN) save PS: <DN200)NETGEN-CONFIG. IMAGE ~

9-27

USING THE CONFIGURATION TOOLS
Step 8.6:

Type the commands FINISHED and EXIT.

Enter:
NETGEN>finished ~
NETGEN>exi t ~
@

Step 9:

Ensure that the DN200 directory contains only
files.

the

necessary

If the system notifies you that deleted files will be expunged, do NOT
begin the following sequence.
wait until the expunge is completed.
(The undelete will not function if the files have been expunged.)
Enter:
@delete *. * ~
@undel rsxlls.*~
@undel *.image~
@undel *.mac~
@undel build-all.ctl~
Step 10:

Submit the BUILD-ALL.CTL file to the Batch system.

Entry and response:
@SUBMIT BUILD-ALL.CTL/TIME:15/0UTPUT:NOLOG/NOTIFY:YES~
[Job BUILD Queued, Request-ID #61 Limit 15:00:00]
Step 11:

Type or print the BUILD-ALL. LOG file and
for errors.

Step 12:

Run the VNP20 program.

examine

NOTE
Be sure that you have configured ALL
nodes.
If,
for
example,
you have 3
DN200s in your configuration, you run
NETGEN once for the DN20 front end and
once for each of the DN200s.
(Each node
requires its own communications data
base. )

9-28

the

file

CHAPTER 10
INSTALLING DECnet-20

If you are installing a DECSYSTEM-2020, go to Section
are
installing
a
DECSYSTEM-2040/50/60,
continue
paragraph.

10.1.
If you
with
the next

Following the configuration of the DECnet-20 Version
2
(2040/50/60)
system, you have only a few critical but simple entries to make:

10.1

•

Set up the DECnet Software by copying several
files
from
PS:<DNGEN> to PS:<SUBSYS>,
and one site-specific front-end
file,
nodename.SYS
from
PS:<DN20-1>
to
PS:<SUBSYS>nnrlpn~mp.Svs.
(Tf
you confi~ured a DN200; also
copy
the
PS:<DN200>nodename.SYS
file
to
ps:<sURSVS>.nodename.SYS.)

•

Locate and check the file
SYSJOB.RUN on
this file if there are missing entries.

•

Locate and check the file 4-CONFIG.CMD on PS:<SYSTEM>.
Edit
this file to include the NODE nodename nodenumber command.

•

Locate and check the PTYCON.ATO file on PS:<SYSTEM> to include
starting the NETCON program.

•

Create an NCP.CMD file.

•

Create a DN200.CMD file

PS:<SYSTEM>.

(if your system includes a DN200).

INSTALLATION PROCEDURE

NOTE
If you are updating your
system from
TOPS-20 V3A DECnet VI to TOPS-20 V4
DECnet
V2,
commands
with
structure/directory
PS:<SYSTEM>
and
PS:<SUBSYS> should be
interpreted as
PS:<NEW-SYSTEM>
and
PS:<NEW-SUBSYS>.
You follow the same procedure
that you
used to
install TOPS-20 V4.
When the
new versions of TOPS-20 and
DECnet are
performing
satisfactorily,
the
old
versions can be saved and
<NEW-SYSTEM>
and
<NEW-SUBSYS>
can be copied to
<SYSTEM> and <SUBSYS> respectively.

10-1

Edit

INSTALLING DECnet-20
All text and examples assume that your directories
following conventions regarding contents:

the

or PS:<NEW-SYSTEM> for update-installation prior to checkout of
hardware/software

new

PS:<SYSTEM>

Contents:

conform

for original installation

monitor and data and program files used by the monitor
in normal operation

PS:<SUBSYS>
or PS:<NEW-SUBSYS>
Contents:

all the system programs a user would normally wish
run

If your installation chooses to locate files other than exactly as
suggested in text and examples, it is your responsibility to correctly
interpret procedures according to your
installation's file-location
scheme.
To do this you must remember the structure and directory
where files have been placed.
Responses illustrated as part of the procedures are examples only.
Because system files are system-dependent, the output you see may be
different.
For example, your site may not have four printers or a
card reader.
Figure 10-1 is a
flowchart of the installation procedure.
numbers on the chart correspond to step numbers in the text.

10-2

Step

INSTALLING DECnet-20

Step 9
Edit 4 - CONFIG. CMD
Enter node name
and node number

EditSYSJOB. RUN
• include job to run FAL
• include job to run NETCON

Step 1
Set up front end Software
• nodename. SYS to< SUBSYS >
• load files to < SUBSYS >

Set up DN200 Software
• node name. SYS to< SUBSYS >
• load files to < SUBSYS >

Step 2
Edit SYSJOB. RUN
• include job to run FAL
• include job to run NETCON

Include
RUN SYS: LPTSPL

Include
RUN SYS: CDRIVE

Step 3
Edit 4 - CONFIG. CMD
Enter node name and number
(central processor)

reate NCP. CMD
• Set up front end software
• Enter commands
• to LOAD front end
• to SHOW QUEUE NCP - REQUESTS

Step 5
Create DN200. CMD
Set up DN200
software

Step 7

Edit PTYCON. ATO
include TAKE DN200.CM

Edit SYSTEM. CMD
• start printer
• start card reader

MR-S-358-79

Figure 10-1

Installing DECnet-20 Software

10-3

INSTALLING DECnet-20
When you are logged in and enabled with OPERATOR or WHEEL privileges:
•

To install a DECSYSTEM-2040j50j60, perform Steps 1 through 7

•

To install a DECSYSTEM-2020, perform Steps 8 and 9 only

Step 1:

Set up the DECnet software.

If you have already executed any of the COpy commands listed below, do
not repeat them.
If you have not purchased the RJE option, do not
give the DN200-related commands.
For the communications front end:
$COPY (FROM) PS:<DN20-1>nodename.SYS (TO)

PS:<SUBSYS>nodename.SYS

The nodename parameter is the same as the response you gave to
the NETGEN command NODE NAME for the communications front end.
$COPY (FROM) PS:<DNGEN>DTEMPS.BIN

(TO) PS:<SUBSYS>DTEMPS.BIN

$COPY

(TOJ PS:<SUBSYS>DTEMPT.BIN

(FROM) PS:<DNGEN>DTEMPT.BIN

For the DN200 remote station:
$COPY PS:<DN200>nodename.SYS

(TO) PS:<SUBSYS>nodename.SYS

The nodename parameter is the same as the response
the NETGEN command NODE NAME for the DN200.

you

gave

If you are installing more than one DN200, each nodename.SYS file
must be copied from the appropriate directory to the <SUBSYS>
directory.
$COPY

(FROM) PS:<DNGEN>SECDMC.SYS

(TO) PS:<SUBSYS>SECDMC.SYS

$COPY

(FROM) PS:<DNGEN>TERDMC.SYS

(TO) PS<SUBSYS>TERDMC.SYS

Step 2:

Edit SYSJOB.RUN.

In Steps 2 through 7 you are editing
as duplication of commands, must be
each edit, use the EDIT command p :*
you prefer, use the TYPE command to
and again after you edit it.
A

SYSTEM files.
Any errors,
such
avoided. When you have completed
to check the entire file.
Or, if
check the file before you edit it

Enter:
$DEFINE EDITOR: SYS:EDIT.EXE~

GD
$CONNECT

l (TO DIRECTORY)

PS:<SYSTEM>~

~
(FILE) SYSJOB.RUN~

$EDIT

The system responds:
EDIT:

SYSJOB.RUN.l

*
10-4

INSTALLING DECnet-20

Enter:
*FJOBQD~

The system responds:
00800

JOB 0 /LOG OPERATOR XX OPERATOR

Enter:
*FQD@)
The system responds:

01600

JOB 1 \

LOG OPERATOR XX OPERATOR

Enter:

Continue until the response is:
%Search fails
Enter:
This command is to find the line number to insert for your entry.
You must judge by the line number of the last JOB number.
The
line number will probably be different from the example.

*p160(J:*@)
The response will be the entire last JOB series.
to:

01600
01700
01800
01900
02000
02100
02200
02300
02400
02500
02600
02700

It will

similar

JOB 1 \LOG OPERATOR XX OPERATOR
ENA
MFORK
RUN SYS:ORION
RUN SYS:QUASAR
RUN SYS:LPTSPL/NAME:L1
RUN SYS:LPTSPL/NAME:L2
RUN SYS:LPTSPL/NAME:L3
RUN SYS:LPTSPL/NAME:L4
RUN SYS:CDRIVE
RUN SYS:BATCON

If you are entering at the end of the file, line number5 will appear
automatically after you insert the first line;
if you are not at the
end, that is, there is at least one line following the last JOB
series, use the command *1.18.

10-5

INSTALLING DECnet-20
If the last JOB series found is as shown above

(lines 01600 to 02700),

Enter:
*i2800~

02800
02900
03000
03100
03200
03300
03400
03500
03600

JOB 2 \LOG OPERATOR XX

OPERATOR~

ENA~

RUN

SYS:FAL~

JOB 3 \LOG OPERATOR XX
ENAG!D
RUN SYS:NETCON~

OPERATOR~

*EU~

[SYSJOB. RUN. 3]
$
NOTE
If your configuration is to include RJE
(DN200), check to ensure that there is a
"RUN SYS:CDRIVE" command (if your remote
station will have a card reader).
Check
to ensure that there are as many "RUN
SYS:LPTSPL" commands as there are total
printers
(host site and RJE station
combined).
If SYSJOB.RUN does not meet
these requirements, edit the file
to
include the necessary statements.
Step 3:

Edit the 4-CONFIG.CMD.

Enter:

G)
$EDIT (FILE)

4-CONFIG.CMD~

The system responds:
EDIT:

4-CONFIG.CMD.9

*
Enter:
*I*~

The system responds:
18200
(or whatever number follows the last line now in the file)
Enter:
18200
18300

NODE nodename

nodenumber~

This the node name and node number of the host or central processor.
*EU~

10-6

INSTALLING DECnet-20
Step 4:

Create an NCP.CMD file.

Entries and responses:
$CREATE NCP.CMD~
INPUT: NCP.CMD.l
ENTER NCP~
00100
SET EXECUTOR servername~
00200
(servername is the node name for the host or
central processor)
SET SECONDARY-LOAD-FILE DTE20 PDP-II PS:<SUBSYS>DTEMPS.BIN~
00300
SET TERTIARY-LOAD-FILE DTE20 PDP-II PS:<SUBSYS>DTEMPT.BIN~
00400
SET NODE nodename SERVER servername DTE20_1~
00500
(servername is the node name for the host, nodename in this
and subsequent lines is the front-end node name)
SET NODE nodename LOAD-FILE PS:<SUBSYS>nodename.SYS~
00600
SET NODE nodename DUMP-FILE PS:<SUBSYS>nodename.DMP~
00700
SET NODE nodename PROTOCOL-TYPE NETWORK-SERVICES-PROTOCOL~
00800
LOAD NODE nodename~
00900
SHOW QUEUE NCP-REQUESTS~
01000
RETURNG!!)
01100
$
01200
*EU~

[NCP.CMD.l]
$

NOTE
The severname (host node name) that you
use
in the above commands must be
identical to the name used
in editing
the 4-CONFIG.CMD file in Step 3.
Step 5:

Create a DN200.CMD file if your system includes a DN200.

Entries and responses:
~CHt:ATE DN200 .CMD( RET )
INPUT: DN200.CMD.l
00100
ENTER NCP ~
00200
SET EXECUTOR servername ~

NOTE
The servername above is the node name of
the host or central processor.
00300
00400

SET SECONDARY-LOAD-FILE DMC PDP-II PS:<SUBSYS>SECDMC.SYS~
SET TERTIARY-LOAD-FILE DMC PDP-II PS:<SUBSYS>TERDMC.SYS~

10-7

INSTALLING DECnet-20

NOTE
If more than one DN200 is in your
configuration, repeat lines 500,600, and
700
which
follow.
Give
specific
parameters for each DN200.
set node nodename SERVER servername KDP_0_2

00500

NOTE
The servername above is the name of
DECnet communications front end.
controller number is the number of
front-end controller that controls
line to the DN200
(line 2 in
example).
The nodename in the above
all subsequent lines is the nodename
the DN200.

SET NODE nodename LOAD-FILE
00600
SET NODE nodename DUMP-FILE
00700
RETURN~
00800
$
00900
*EU(Ru)
Step 6:

PS:<SUBSYS>nodename.SYS~
PS:<SUBSYS>nodename.DMP~

Edit PTYCON.ATO

Entry and response:
$EDIT
Edit:

PTYCON.ATO~

PTYCON.ATO.5

*
Entry and response:

*FTAKE SYSTEM:SYSTEM.CMD~
01100 TAKE SYSTEM:SYSTEM.CMD

*
Entry and response for DN20 without DN200:
*I.!l~

01150 TAKE

SYSTEM:NCP.CMD~

*EU~

Entry and response for DN20 with DN200:
*I.! 2~
01120 TAKE
01140 TAKE
*EU (RET)

the
The
the
the
the
and
of

SYSTEM:NCP.CMD~
SYSTEM:DN200.CMD~

10-8

INSTALLING DECnet-20

NOTE
If your system does not include a DN200,
you
have completed the
installation
procedures.
Go to Section 10.2.
If
your
system
does
include a
DN200,
continue with Step 7.
Step 7:

Edit SYSTEM.CMD.

Entry and response:
$EDIT
Edit:

PS:<SYSTEM>SYSTEM.CMD~

SYSTEM.CMD

Print the file using edit and locate a logical place to insert one or
two commands.
The edit procedures in the example given may need to be
modified to fit the contents of your system's SYSTEM.CMD file.
The commands to be added are:
If the DN200 has a printer, enter:
START PRINTER 0/NODE:DN200::
If the DN200 has a card reader, enter:
START READER 0/NODE:DN200::
(The DN200::
given above represents the node name you
for the DN200 at generation time.)

10-9

specified

INSTALLING DECnet-20
Example:
$edit system.cmd~
Edit: SYSTEM.CMD.l
*p"":*~

00100
00200
00300
00400
00500
00600
00700
00800
00900
01000
01100
01200
01300
01400
01500

MOUNT STRUCTURE SNARK:
MOUNT STRUCTURE LANG:
MOUNT STRUCTURE MISC:
SET BATCH-STREAM 0 TIME-LIMIT 5
SET BATCH-STREAM 1 TIME-LIMIT 10
SET BATCH-STREAM 2 TIME-LIMIT 11000
SET BATCH-STREAM 3 TIME-LIMIT 11000
SET BATCH-STREAM 3 PRIORITY-LIMITS 20:63
SET BATCH-STREAM 0:2 PRIORITY-LIMITS 1:19
START BATCH-STREAM 0:3
SET PRINTER 0 PAGE-LIMIT 20000
SET PRINTER 1 PAGE-LIMIT 500
START PRINTER 0:1
START READER 0
DISABLE OUTPUT-DISPLAY ALL-MESSAGES /JOB

*i.-l! 2~

01420
START PRINTER 0/NODE:DN200::~
01440
TART READER 0/NODE:DN200::(Rlol)
*p1300: * ~
01300
START PRINTER 0:1
01400
START READER 0
01420
START PRINTER 0/NODE:DN200::
01440
START READER 0/NODE:DN200::
01500
DISABLE OUTPUT-DISPLAY ALL-MESSAGES /JOB
*eu~

[SYSTEM.CMD.2]
$

You have completed DECSYSTEM-2040/50/60 installation.
Section 10.2.
Step 8:

Edit SYSJOB.RUN

Continue

with

(DECSYSTEM-2020)

In Steps 8 and 9, you are editing system files. Any errors, such as
duplication of commands, must be avoided. When you have completed
each edit, use the EDIT command p"":* to check the entire file.
Or, if
you prefer, use the TYPE command to check the file before and after
you edit it.
Enter:
$DEFINE EDITOR: SYS:EDIT.EXE~
~
~

$CONNECT (TO DIRECTORY)

PS:<SYSTEM>~

GD
$EDIT (FILE)

SYSJOB.RUN~

The system responds:
EDIT:

SYSJOB.RUN.l

10-10

INSTALLING DECnet-20
Enter:
*FJOB~@)

The system responds:
JOB 0 /LOG OPERATOR XX OPERATOR

00800
Enter:

Continue until the response is:
%Search fails
Enter:
This command is to find the line number to insert for your entry.
You must judge by the line number of the last JOB number.
It
will probably be different from the example.
*p800:*~

The response will be the entire last JOB series.
to:
00800
00900
01000
01100
01200
01300
01400
01500

It will

similar

JOB 1 JLOG OPERATOR XX OPERATOR
ENA
~ESET LOGIN PSEUDO
~ESET LOGIN CONSOLE
"'ESET OPERATOR
PTYCON
GET SYSTEM:PTYCON.ATO

If you are entering at the end of the file, line numbers will appear
automatically after you insert the first line;
if you are not at the
end, that is, there is at least one line following the last JOB
series, use the command *1.18.
NOTE
Do NOT enter either of the jobs below if
they have already been entered.
If the last JOB series found is as shown above (lines 00800 to OlSOO),

10-11

INSTALLING DECnet-20
Enter:
*i1600~

01600
01700
01800
01900
02000
02100
02200
02300
02400

JOB 2 \LOG OPERATOR XX
ENAG£)
RUN SYS:FAL~

OPERATOR~

JOB 3 \LOG OPERATOR XX

OPERATOR~

ENA~

RUN SYS:NETCON~
\G!D
$

*EU~

[SYSJOB.RUN.3]
$
Step 9:

Edit the 4-CONFIG.CMD (DECSYSTEM-2020)

Enter:

$EDIT (FILE)

4-CONFIG.CMDCRET)

The system responds:
EDIT:

4-CONFIG.CMD.9

*
Enter:
*I*~

The system responds:
18200
(or whatever number follows the last line now in the file)
Enter:
18200

NODE nodename nodenumberG!D

This is the node name and node number
processor.

(decimal) of the host or central

18300
$
*EUG!D

10.2

INSTALLATION VERIFICATION PROCEDURE

The DECnet-20 installation verification procedure ensures that
appropriate DECnet-20 software modules have been installed.
verification procedure includes:
•

Checking for the existence of each required software module

•

Checking for the correct version
module

10-12

each

required

the
The

software

INSTALLING DECnet-20
The verification tests are run under
the User Environmental Test
Package
(UETP).
Before you begin the verification procedures, you
must satisfy the requirements of UETP.
Examine your login-directory.
The directory to which you
include the following two entries:

must

IPCF
USER GROUPS nnnn,lOO
The nnnn represents your assigned user group for normal activity.
The
100 that follows is required by UETP.
Use the TOPS-20 command BUILD
to add the two required subcommands.
Figure 10-2 is a
flowchart of the verification procedure.
numbers on the chart correspond to step numbers in the text.

10-13

Step

INSTALLING DECnet-20

Figure 10-2

Verifying the DECnet-20 Software

10-14

INSTALLING DECnet-20
Go to Step 1 when you are logged in with OPERATOR or WHEEL
enabled.
Step 1:

privileges

Redefine the logical name DSK:.

Redefine the logical name DSK:
to include the directories
<UETP.LIB>
and
<SUBSYS> as part of the file search sequence.
To verify the
execution of the command, use the INFORMATION LOGICAL-NAME command.
Enter:

$DEFINE (LOGICAL NAME)

$INFORMATION (ABOUT)

DSK:,<UETP.LIB>,<SUBSYS>~

DSK:

LOGICAL-NAMES~

The system responds:
DSK:
$
Step 2:

=> DSK:,(UETP.LIB>,<SUBSYS>

Connect to directory <UETP.RUN>.

Enter:

$CONNECT (TO DIRECTORY)
Step 3:

(UETP.RUN>(~T)

Ensure that <UETP.RUN> is empty.

Enter:

$DELETE (FILES)

*.*.*~

The system responds:
filenamel
filename2

[OK]
[OK]

$
(if files were found and deleted)
or:
%NO FILES MATCH THIS SPECIFICATION- * * *
$
(if the directory was empty).

10-15

INSTALLING DECnet-20
Step 4:

RUN the UETP program.

Enter:
$RUN

UETP~

The system responds:
[da-mon-yr hh:mm:ss USER ENVIRONMENT TEST PACKAGE]
UETP>
Step 5:

Enable the DECnet-20 verification test.

Enter:

UETP>ENABLE (TEST)
where:
prgnam

prgnam~

NETVFY for a DECSYSTEM-2040/50/60
VF2020 for a DECSYSTEM-2020
RJEVFY for DEC SYSTEM 2040/50/60 with
of remote station DN200

optional

addition

NOTE
If you are validating RJE,
NETVFY must
perform
successfully before you run
RJEVFY.
The system responds:
hh:mm:ss
UETP>
Step 6:

[ENABLE COMPLETED]

Begin the verification procedure.

The system confirms the BEGIN command and displays the messages
below as verification progresses.

shown

Enter:
UETP>BEGIN ~
The system responds:
hh:mm:ss
UETP>

[BEGIN COMPLETED]

START prgnam da-mon-yr hh:mm:ss message
MAJOR prgnam da-mon-yr hh:mm:ss message
END
prgnam da-mon-yr hh:mm:ss message
(prgnam is the name of the file enabled in Step 5.)
You may check the status of UETP at any time.
in Step 7.

10-16

.L t........

-. ..._ ...... _ .....

......... .-..

_ 1.-. _ ..... _

U::>I:::

LUI:::

f:Jl.UI.,.;I:::UUl.l:::

::>uuwu

'r'T _

INSTALLING DECnet-20

Step 7:

Check status of verification procedure.

Enter:
STATUS~

The system may respond:
[da-mon-yr hh:mm:ss]
TEST NAME
(FILE NAME)

STATUS TIMES TO TIMES ERROR
BE RUN
RUN
COUNT

prgnam.SUP

queued

START
TIME
da-mon-yr hh:mm:ss

UETP>
The status QUEUED means that the verification process is waiting to be
run.
STATUS may also be given as RUNNING or ENDED.
This status
output will be given automatically when status is ENDED.
When ENDED
is displayed, continue with Step 8.
If errors occur, refer to Section
10.2.1.
Step 8:

Exit from UETP

Entry and response:

~
EXIT (TO MONITOR)~
$

Step 9:

Stop and reload the system if test completed successfully.

Now that you have restored all the DECnet-20 software to the proper
directories, modified the appropriate command files, and verified the
software, you must first stop the system and reload
it to activate
DECnet-20.
Enter:

$ «TRl/\)

(does not echo)

The system responds:
PAR> (for DEC SYSTEM 2040/50/60)
KSlO> (for DECSYSTEM-2020)
Enter:
sh~

The system shuts down with appropriate messages.
To reload the DECSYSTEM-2040/50/60:
Press the ENABLE and DISK switches simultaneously.
To reload the DECSYSTEM-2020:
Press the BOOT switch.

10-17

INSTALLING DECnet-20
After the system completes printing loading
and
configuration
messages, the system displays ENTER CURRENT DATE AND TIME:.
Enter:
day-mon-yr hhmm (followed by carriage return)
The system repeats the date and time you have entered and
confirmation. Answer with Y or N, and repeat if necessary.

asks

for

The system then asks WHY RELOAD?
Type an abbreviation that indicates the reason for
the reload,
for example, CTF for certification. The answer you type here is
stored in the system error file and reported by SYSERR.
(If your
site has a code or standard abbreviation, use the appropriate
entry.)
The system asks:
RUN CHECKD?
Enter:
N~

The system now executes all the command files that load and start the
various system tasks.
These will now include the DECnet-20 tasks.

10.2.1

Verification Procedure Messages

Verification tests pass confirmation, event, and error messages to the
UETP program.
The various UETP elements route these messages to one
or more of the following:
•

your terminal

•

the file RUN. LOG

•

the file EXCEPT. LOG

In addition, batch generates a Batch Log file for each test run under
UETP.
This file is named prgnam.LOG, where prgnam is the name of the
DECnet-20 verification test.
This log file is appended to the file
prgnam.ERL if a test reports an error to UETP via the SENDER program.
Thus, if any test does not complete successfully, there are,
in
addition to the messages output to your terminal, three files that may
be used to discover the problem. The table that follows summarizes
message types and their destinations.

10-18

INSTALLING DECnet-20
Table 10-1
SENDER Message Types and Destinations
DESTINATION
MESSAGE
TYPE
START
MAJOR
MINOR
ERROR
END
LOG

TERMINAL EXCEPT. LOG
yes
yes
no
yes
yes
no

no
no
no
yes
yes
no

RUN.LOG

prgnam.ERL

yes
yes
yes
yes
yes
yes

no
no
no
yes
no
no

If a test executes successfully, the following messages will
to your terminal in the order given:

START prgnam date time

Start of verification

MAJOR prgnam date time

Verifying file:<UETP.LIB>DECNET.VFY

END

End of verification

prgnam date time

If errors occur, one or more of the following will
terminal:

sent

your

ERROR prgnam date time VERIFY program not available
The program VERIFY.EXE could not be found.
This program is
required to perform the verification.
If you have made no
errors, this probably indicates an error in
the
TOPS-20
installation procedures.
YOU CANNOT CONTINUE UNTIL THE VERIFY
PROGRAM IS IN <SUBSYS> or <NEW-SUBSYS>.
ERROR prgnam date time DECNET.VFY file (input to the
is not available.

VERIFY

program)

This probably indicates an error 1n your DECnet installation
CONTINUE UNTIL DECNET.VFY IS IN
YOU
CANNOT
procedures.
<UETP.LIB>.
ERROR prgnam date time ERRORS running VERIFY program
One or more files did not verify correctly.
Either a required
file is not present, a required file is in the wrong directory,
or the data is incorrect (determined by noting that the file's
checksum is different from that of the file shipped by DIGITAL).
Return to the DECnet installation procedure and correctly restore
the files that did not verify. If the files are not available,
notify your DIGITAL Software Specialist.
ERROR prgnam date time Verification procedure exceeded CPU time limit
This message indicates a problem with the verification
itself. Notify the DIGITAL Software Specialist.

procedure

ERROR prgnam date time Unknown error in VERIFY test
This message indicates conditions for which no specific
could be made. Consult the DIGITAL Software Specialist.

10-19

check

INSTALLING DECnet-20
10.3

INSTALLATION CERTIFICATION PROCEDURE

You have now determined that the correct version of each required
DECnet-20 software module has been installed.
In the certification
procedures you will ensure that the various components of your
DECnet-20 system function at a basic, minimal level.
The verification
and certification procedures are sometimes referred to as "acceptance
tests".
Together they confirm the acceptability of the installed
hardware and software to the extent successfully tested.
The certification tests to be run include:
1.

Local-NCP test

Line-loopback test

Remote-NCP test

Remote node file transfer test

DN200 test

Error and event logging test

The line-loopback test and the remote node file transfer test are run
as batch jobs under UETP.
For these two tests both general procedures
and error messages are the same as for the verification procedures you
have completed.
The other four
tests are run in production mode.
That is, you type commands to a program or you tell the program to
take the commands from a command file you create.
All files associated with installation verification and certification
of DECnet-20 Version 2 are in one of two directories, as follows:
Directories and
verification) :

files

for

DECSYSTEM-2040j50j60

PS:(UETP.LIB)
CHARS. TXT
DECNET.DAT
DNV2FT.APP
DNV2LN.CMP
DYNETS.EXE
NETVFY.VER
NULL.TXT
PICTUR.TXT
RJEVFY.VER
PS:(UETP.DECNET)
BRIEF.TXT
DETAIL.TXT
LOCAL-NCP.CMD
LOCAL-NCP-KL-EXAMPLE.CMD
.'fXT
REMOTE-NCP.CMD
REMOTE-NCP-20-EXAMPLE.CMD
.TXT
REMOTE-NCP-DN20-EXAMPLE.CMD
.TXT

10-20

certification

(and

INSTALLING DECnet-20
Directories and
verification} :

files

for

DECSYSTEM-2020

certification

(and

PS:<UETP.LIB>
DECNET.DAT
DNV2FT.APP
DNV2LL.CMP
DNWAIT.EXE
DYNETS.EXE
NULL.TXT
TESTT2.CMP
VF2020.VER
PS:<UETP.DECNET>
BRIEF.TXT
DETAIL. TXT
LOCAL-NCP.CMD
LOCAL-NCP-KS-EXAMPLE.CMD
.TXT
REMOTE-NCP.CMD
REMOTE-NCP-20-EXAMPLE.CMD
.TXT
Note that the <UETP.LIB> directory contains all control files, command
files to be edited to match your configuration, and original test data
files.
You will create several files to add to PS:<UETP.LIB> as you
perform the various tests.
These are the files that must be kept.
They will be needed to repeat certification procedures
if new
DECnet-20 hardware/software is brought on line.
They will be helpful
in constructing user application tests to test production programs
that normally run under batch.
(For additional
information on
constructing your own tests, refer to the TOPS-20 User Environment
Test Package Procedures/Reference Manual.)
The files on the <UETP.DECNET> directory contain sample command files
and sample output files.
They serve to help you understand what to do
and how to do it.
They may be saved or deleted,
according to your
needs, after the certification completes successfully.
Before you begin certification testing you must:
•

Have a suitable loopback connector for each line to be
(later you will be told at what point to install it)

•

Create certain files to
configuration

10.3.1

establish

values

specific

tested
to

your

Loopback Connector

In order to run the certification procedure for
DECnet-20 without
requiring another DECnet node to talk to, it is necessary to use some
form of echoing device.
A device known as a loopback connector may be
attached to the line interface in place of the modem.
All data
directed to the line will then be echoed back to the sender.

10-21

INSTALLING DECnet-20
Loopback connectors come in various models.
DECSYSTEM-20s with
communications hardware are supplied with the model loopback connector
that is suitable for the particular communications device being used.
Loopback connectors should be installed by DIGITAL Software Service or
Field Service representatives.
To test all DECnet lines in one run
(the line loopback test), you will need one connector for each line to
be tested.
Several of the acceptance tests may be run by
input or by using a command file;
some tests
others are not.
There are also system
flowcharts
(Figure 10-3) as an overview and
the tests.
(Connectors may span pages.)

10-22

either direct terminal
are run under UETP while
dependencies.
Use the
checklist as you perform

INSTALLING DECnet-20
Local-NCP Test (Section 10.3.2)

Line Loopback Test (Section 10.3.3)

Step 11

Step 3
Tum all lines off.

Step 12
Instaliloopback connector on line to be
tested.

LIN

Step 13
Enable loopback and start line for cable
loopback.

Step 14
Run UETP. Enable test and begin testing.

Ensure that PS:< UETP. RUN> is empty.

Steps 15 -16
Run UETP. Enable test and begin testing.

.
<

Remove connectors
)
• Reconnect system
normally
• Reload front end
• Log in with OPERATOR
or WHEEL privileges

• Remove connectors
• Reconnect system
normally
• Reload system
• Log in with OPERATOR
or WHEEL privileges

Figure 10-3

Certifying the DECnet-20 Software

10-23

INSTALLING DECnet-20

Remote - NCP Test (Section 10.3.4)

Step 2A: Direct Terminal Input
and/or
Step 2B: Command File Input

Step 1A: Direct Terminal Input
and/or
Step 1B: Command File Input

Remote and Local Network File Transfer Test (Section 10.3.5)
Step 1
Log in as a non - privileged user.
Step 2
Create an NFT. INIT file in
PS: < UETP. LIB >
Step 3
Check availability of nodes to be
tested
Step 4
Define file search association of DSK:
Step 5
Ensure that PS: < UETP. RUN> is empty.

Step 6
Run UETP. Enable test and
begin testing.

Check directory for
IPCF and USER GROUP
100, and check
define statements.

where error
occurred.
To
C
MR-S-3S7-79

Figure 10-3 (Cont.)

Certifying the DECnet-20 Software

10-24

INSTALLING DECnet-20

DN200 Tests (Section 10.3.6)

Contact
your
Software
Specialist.

y.;
I

Contact your
Software
Specialist re:
skewed output.

DECnet Error and Event Logging Test (Section 10.3.7)

MR-S-355-79

Figure 10-3 (Cant.)

Certifying the DECnet-20 Software

10-25

INSTALLING DECnet-20
10.3.2

Local-NCP Test

The commands to be executed for
the LOCAL-NCP test may be typed
directly at your terminal or entered by typing a TAKE command to NCP
via OPR.
If your host node is a DECSYSTEM-2040/50/60, go to Step lA if you wish
to use direct input to your terminal; go to Step IB if you wish to
use a command file.
If your host node is a DECSYSTEM-2020, go to Step 2A if you wish to
use direct input to your terminal; go to Step 2B if you wish to use a
command file.
Step
lA.
Local-NCP
(DECSYSTEM-2040/50/60)
Enter:

test

using

direct

terminal

input

@enaBLE (CAPABILITIES)~
$type ps:<uetp.decnet>local-ncp-kl-example.cmd~
Read the example file.
Refer to the seven commands below the second
line of asterisks.
To test YOUR local NCP, certain changes are
required:
The first command will be:
SET EXECUTOR your local host name
You entered the node name of your central processor
in the
4-CONFIG.CMD file
in Step 3 of the Installation Procedures
(Section 10.1). The node name in the SET EXECUTOR command
must agree with the node name in the 4-CONFIG.CMD file.
The SHOW STATUS LINE lineid command(s) must also be changed to
reflect your configuration. You include the line identification
of each DTE20 to be tested.
Follow the directions given in the example-file. Type the commands,
making the changes indicated.
If you wish to see what the output
should
look
like,
enable
and
type
the
file
PS:<UETP.DECNET>LOCAL-NCP-EXAMPLE.TXT.
This example is the result of
a TAKE command and includes a list of outstanding NCP requests in
response to the SHOW QUEUE NCP-REQUESTS command.
If you enter the
commands directly, you may not receive this list because your typing
speed is slower than the response speed. An example of direct entry
and response appears below.
Your typed input will differ in the SET
EXECUTOR and SHOW STATUS LINE commands.

10-26

INSTALLING DECnet-20
Example of direct entry and response:

@ENABLE

(CAPABILITIES)~

$OPR~

GD
~

OPR)DISABLE outPUT-DISPLAY (of) all-MESSAGES~
OPR)
12:56:17
--OUTPUT DISPLAY for OPR Modified-OPR)enter ncp~

,
,

NCP)set exeCUTOR 2102~

GD
NCP)show exeCUTOR~
NCP)
12:56:49

Current EXECUTOR is node 2102

NCP)show status lOCAL~
NCP)
12:57:10
NCP request # 2 [SHOW STATUS LOCAL]
Status of local node as of 16-Jul-79 12:57:10
Node Name is 2102, # 64, System = 2102 Development System,
TOPS-20 Routing Version = 3.0.0, Communications Version = 3.0.0
State is On, Default Host = Unknown
Function completed successfully

,.,

GD~

NCP) show STATUS knoWN lINES ~
NCP)
NCP request # 3 [SHOW STATUS KNOWN LINES]
12:57:54
Status as of 16-Jul-79 12:57:54
Line ID

State

DTE 2 0_0_0_0
DTE20_1_0_0
DTE20_2_0_0
DTE20_3_0_0

OFF
On
Off
Off

Function completed successfully

10-27

Adjacent Node
DN20A

INSTALLING DECnet-20

G) G)

OK)

DTE20_1~

NCP>sJow sJATUS l!NE
NCP>
12:58:41
NCP request # 4 [SHOW STATUS LINE DTE20 _

Status as of l6-Jul-79 12:58:41
Line ID

State

Adjacent Node

DN20A

Function completed successfully

arcr

NCP>shOW sTATUS
NCP>
12:59:20

li~E dte20_2~
NCP request # 5 [SHOW STATUS LINE DTE20 _ 2]

Status as of l6-Jul-79 12:59:20
Line ID

State

Adjacent Node

Function completed successfully

•

NCP>show qUEUE (OF) nCP-REQUESTS~
NCP>
12:59:52
There are no outstanding NCP requests.
NCp>exit~

. l
~
$dlsaBLE (CAPABILITIES)~
@

If you wish to repeat the LOCAL-NCP test using a command file,
Step lB; otherwise go to Section 10.3.3.
Step lB.

Local-NCP test using a .CMD file

(DECSYSTEM-2040/50/60)

The file LOCAL-NCP.CMD in the directory PS:<UETP.DECNET> contains the
commands to test the local NCP. One SET EXECUTOR command and two SHOW
STATUS LINE commands are given with dummy arguments.
These dummy
arguments
must
be edited to reflect the node name and line
identifications of YOUR configuration.
The number of SHOW STATUS LINE
commands must equal the number of DTE20 lines you wish to test. All
lines you plan to. use for network traffic should be tested.
The host
or central processor node name in the SET EXECUTOR command must be
identical to the name you entered in the 4-CONFIG.CMD file in Section
10.1.
The edite~ file should be output to PS:<UETP.LIB> as shown in the
example.
Use the EDIT command EU to remove line numbers when you exit
from EDIT.
Including the host node name in the output file name will
help identify it for future use.
10-28

INSTALLING DECnet-20

Example entries and responses:

@ENA~

$CONN

PS:<UETP.DECNET>~

$edit local-ncp.cmd.4 (OUTPUT AS) PS:<UETP.LIB>LOCAL-NCP-2102.CMD~
Edit: LOCAL-NCP.CMD.4
*p'" :*GID
00100
***********************************************************************
00200
THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY ONLY BE USED
00300
OR COPIED IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE.
00400
00500
COPYRIGHT (C) 1978,1979 BY DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS
00600
00700
00800
DECnet-20 V2 Local NCP test
00900
01000
To run this test start OPR in a job enabled with wheel or operator
01100
01200
privileges and enter the NCP command subset:
01300
@ENABLE
01400
01500
$OPR
OPR>ENTER NCP
01600
NCP>
01700
01800
Then elther enter:
01900
02000
NCP>TAKE REMOTE-NCP.CMD
02100
02200
02300
ito execute the statements in the command file or
!type the following commands by hand.
02400
02500
02600
!***********************************************************************
02700
02800
SET EXECUTOR host-node-name
02900
SHOW EXECUTOR
03000
SHOW STATUS LOCAL
03100
SHOW STATUS KNOWN LINE
03200
SHOW STATUS LINE line
03300
SHOW STATUS LINE line
03400
SHOW QUEUE NCP-REQUESTS
*shost-node-name$2102$2800~

02800
SET EXECUTOR 2102
*sline$DTE 20_0$3200,E~
03200
SHOW STATUS LINE DTE20_0
*sline$DTE 20_1$3300,E~
03300
SHOW STATUS LINE DTE20_1
*p2800: 3400~
02800
SET EXECUTOR 2102
02900
SHOW EXECUTOR
03000
SHOW STATUS LOCAL
03100
SHOW STATUS KNOWN LINE
03200
SHOW STATUS LINE DTE20_0
03300
SHOW STATUS LINE DTE20_1
03400
SHOW QUEUE NCP-REQUESTS
*eu~

[<UETP.LIB>LOCAL-NCP-2102.CMD.l]

10-29

INSTALLING DECnet-20
When you have exited from EDIT,
Enter:
CONN

PS:<UETP.LIB)~

$OPR~

OPR)ENTER NCP~
NCP)TAKE LOCAL-NCP-xxxx.CMD~
where xxxx is the node name of the local host
OUTPUT FOLLOWS
Enter:
NCP)EXIT~

Check your output as the test is being performed. No error messages
should be printed.
The output should have the same format as the file
LOCAL-NCP-KL-EXAMPLE.TXT in PS:<UETP.DECNET). This example is for
a
DECSYSTEM-2060 node with the node name 2102. Type the example file to
compare it with your output.
The output from your .CMD file should be
similar
in format to the example typed.
Node names and line
identifications may differ.
When the test completes successfully, go to Section 10.3.3.
Step 2A.

Local-NCP test using direct terminal input (DECSYSTEM-2020)

Enter:
G)

@enlBLE (CAPABILITIES)~
$type ps:<uetp.decnet)local-ncp-ks-example.cmd~
Read the example file.
Refer to the seven commands below the
second line of asterisks.
To test YOUR local NCP, certain
changes are required:
The first command will be:
SET EXECUTOR your local host name
The node name in the SET EXECUTOR command must agree
the node name in the 4-CONFIG.CMD file in PS:<SYSTEM).

with

The SHOW STATUS LINE lineid command(s) must also be changed to
reflect your configuration.
You include the line identification
of each DECnet-20 line to be tested.
For one line, your lineid
will be KDP_O_O.
For two lines, the lineids will be KDP_O_O and
KDP_O_l.

10-30

INSTALLING DECnet-20
Now, type the commands (six or seven commands depending on the number
of lines) shown in the example, making the changes indicated for node
name and lineids.
Check the output as the commands are being
performed.
There should be no error messages.
When the response to
the last command is complete, type EXIT following
the NCP prompt.
Compare your output with that of the example given below.
The name of
the 2020 node in the example is 4097.
The
4097 has two DECnet-20
lines.
The DISABLE OUTPUT-DISPLAY command in the example is needed
only if you are testing under timesharing.
If you fail to give
this
command, messages from OPR such as the one shown before the DISABLE
OUTPUT-DISPLAY command was executed will be scattered throughout
the
responses to your commands.
Example:
@ENA~
$opr~

OPR>disable output-display all messages~
OPR>
10:53:37
--MTA2: Volume DAVESS, ANSI labeled tape mounted-OPR>
10:53:42
--OUTPUT DISPLAY for OPR Modified-OPR>enter ncp~
NCP>set executor 4097~
NCP>show executor~
NCP>
10:54:42
Current EXECUTOR is node 4097
NCP>show status known lines~
NCP>
10:55:10
NCP request # 8 [SHOW STATUS KNOWN LINES]
Status as of 18-Jul-79 10:55:10
Line ID

State

Adjacent Node

KDP_O_O-n
KDP_O_l_O

On
On

2102

Function completed successfully
NCP>show status line kdp_O_O(RET)
NCP>
NCP request # 9 [SHOW STATUS LINE KDP _ 0 _ 0]
10:55:56
Status as of 18-Jul-79 10:55:56
Line ID

State

Adjacent Node

2102

Function completed successfully

10-31

INSTALLING DECnet-20
NCP>show status line kdp_O_l~
NCP>
10:56:44
NCP request # 10 [SHOW STATUS LINE KDP _

0 _ 1]

Status as of 18-Jul-79 10:56:43
Line ID

State

Adjacent Node

Function completed successfully
NCP>show counts line kdp_O_O~
NCP>
10:57:47
NCP request # 11 [SHOW COUNTS LINE KDP_ 0 _ 0]
Counts for line KDP_O_O_O, as of 18-Jul-79 10:57:47
Seconds since zeroed
27321
Blocks received
11493
Received line errors
0
Blocks sent
13158
Retran, line errors
0
Retran, not line erros
0
Resource errors
1
Function completed successfully
NCP>show counts line kdp_O_l~
NCP>
10: 58: 29
NCP request # 12 [SHOW COUNTS LINE KDP _ 0 _
Counts for line KDP_O_l_O, as of 18-Jul-79 10:58:29
Seconds since zeroed
27361
Blocks received
0
Received line errors
0
Blocks sent
0
Retran, line errors
0
Retran, not line errors
0
Resource errors
0

Function completed successfully
NCP>show queue
NCP>
10:59:13

ncp-requests~

There are no outstanding NCP requests.
NCP>exit~

If you wish to repeat the LOCAL-NCP test using a command file, go
to Step 2B; otherwise go to Section 10.3.3.

10-32

INSTALLING DECnet-20

Step 2B.

Local-NCP test using a .CMD file

(DECSYSTEM-2020)

The file LOCAL-NCP.CMD in the directory PS:<UETP.DECNET> contains
the commands to test the local NCP.
One SET EXECUTOR command and
two SHOW STATUS LINE commands are given with dummy arguments.
These dummy arguments must be edited to reflect the node name and
line identifications of YOUR configuration.
The number of SHOW
STATUS LINE commands must equal the number of KDP lines you wish
to test.
All lines you plan to use for network traffic should be
tested.
The host or central processor node name in the SET
EXECUTOR command must be
identical to the node name
in the
4-CONFIG.CMD file.
The edited file should be output to PS:<UETP.LIB> as shown in the
example.
Use the EDIT command EU to remove line numbers when you
exit from EDIT.
Including the host node name in the output file
name will help identify it for future use.
In the example below,
the node name is 4097.
There are
two DECnet-20 lines.
You
substitute the parameters
that are correct for your node.
In
editing the command SHOW STATUS LINE line, be sure to include the
",E" as shown in the example.
If you fail to do this, the lineid
will be substituted two times.
Example entries and responses:
raENA(RfT)

$CONN-PS:<UETP.DECNET)~

LOCAL-NCP.CM~

$EDIT
(OUTPUT AS) PS:<UE'l'P.LIB>LOCAL-NCP-4097.CMD~
Edit: LOCAL-NCP.CMD.4
*P-: *G0
00100
!***********************************************************************!
00200
!
00300
! THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY ONLY BE USED
00400
OR COPIED IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE.
00500
00600
!COPYRIGHT (C) 1978,1979 BY DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS
00700
DECnet-20 V2 Local NCP test
00800
00900
01000
01100
To run this test start OPR in a iob enabled with wheel or operator
01200
privileges and enter the NCP command subset:
01300
01400
@ENABLE
$OPR
01500
OPR)ENTER NCP
01600
NCP)
01700
01800
01900
!Then either enter:
02000
02100
NCP)TAKE LOCAL-NCP.CMD
02200
02300
ito execute the statements in the command file or
02400
!type the following commands by hand.
02500
!
02600
!***********************************************************************
02700

10-33

INSTALLING DECnet-20

02800
02900
03000
03100
03200
03300
03400

SET EXECUTOR host-node-name
SHOW EXECUTOR
SHOW STATUS LOCAL
SHOW STATUS KNOWN LINE
SHOW STATUS LINE line
SHOW STATUS LINE line
SHOW QUEUE NCP-REQUESTS

*shost-node-name$4097$2800~

02800

SET EXECUTOR 4097

*sline$KDP_0_0$3200,E~

03200

SHOW STATUS LINE KDP_O_O

*sline$KDP_0_l$3300,E~

03300
SHOW STATUS LINE KDP_O_l
*p2800: 3400~
02800
SET EXECUTOR 4097
02900
SHOW EXECUTOR
03000
SHOW STATUS LOCAL
03100
SHOW STATUS KNOWN LINE
03200
SHOW STATUS LINE KDP-D_O
03300
SHOW STATUS LINE KDP_O-1
03400
SHOW QUEUE NCP-REQUESTS
*eu~

[<UETP.LIB>LOCAL-NCP-4097.CMD.l]
$

When you have exited from EDIT,
Enter:
$CONN PS:<UETP.LIB>CRET)
$OPR~

OPR)ENTER NCP~
NCP)TAKE LOCAL-NCP-xxxx.CMD~
where xxx x is the node name of the local host
OUTPUT FOLLOWS
Enter:
NCP)EXIT~

To compare the output from your command file with an example, enable
and type the file
PS:<UETP.DECNET)LOCAL-NCP-KS-EXAMPLE.TXT.
This
example is the result of a TAKE command and includes a list of
outstanding NCP requests in response to the SHOW QUEUE NCP-REQUESTS
command. When you enter the commands directly, you may not receive
this list because your typing speed is slower than the response speed.
The output from your .CMD file should be similar
in format to the
example typed.
Node names and line identifications may differ.
There
should be no error messages.
When the test completes successfully,
continue with the next section.

10-34

INSTALLING DECnet-20
10.3.3

Line Loopback Test

You have now tested that NCP commands function on the local node.
Before you test NCP commands to a remote node, the line loopback test
is performed to ensure that the line(s) from your node out to the end
of the cable are functioning.
Step 1:

Log in as a user with WHEEL or OPERATOR privileges enabled.
This test
is run under UETP.
Therefore, use the directory to which you added
the IPCF and USER GROUPS 100 subcommands.
You should now be familiar
with the UETP responses.
Only the entries are given for this test.
If you need to review the UETP output, refer
to Step 7 in Section
10.2.
Step 2:

Establish the search list.

Enter:

$DEFINE (LOGICAL NAME)

DSK:

DSK:,PS:<UETP.LIB>~

NOTF.

The line loopback
test
is
system
dependent.
If
you
are testing a
DECSYSTEM-2040/50/60,
perform Steps 3
through
10.
If you are testing a
DECSYSTEM-2020, go to Step
11
and
perform Steps 11 through 21.
Step 3:

Create a file for the DN20 node name.

Create the file PS:<UETP.LIB>DNV2LN.NOD which specifies the name of
the DN20 to be tested.
The DN20 to be tested must be physically
connected to the system on which this test is run.
The name must be
entered on the first line of the file being created and the name must
not have terminating colons.
Exit from EDIT with the EDIT command EU
to remove the line numbers.
An example is given.
Substitute the name
of your DECnet-20 communications front end for
the DN20A in the
example.
Because the test cannot run without the file, both a
DIRECTORY and a TYPE command are entered for checking purposes.
Example:
$conn
$edit

ps:<uetp.lib>~
dnv2ln.nod~

%No such file type, Creating New file
Input: DNV2LN.NOD.l
00100
dn20a~
00200
$
*eu~

[DNV2LN.NOD.l]
$dir dnv21n.nod~
PS:<UETP.LIB>
DNV2LN.NOD.l
$type dnv2ln.nod~
dn20a
$
10-35

INSTALLING DECnet-20
Step 4:

Create the file PS:<UETP.LIB)DNV2LN.LIN

Create the file PS:<UETP.LIB)DNV2LN.LIN which specifies the DN20 lines
to be tested.
This file must contain a separate line of text for each
hardware line to be tested.
The
line of text
is
the
line
specification in the
form DDD_n-ID where DDD represents the device
type, n represents the controller number, and m represents
the line
number.
Valid device types are KDP and DMC.
(Because the DMC has
only one line, the form is DDD_n.) The device DUP is valid
for
32K
front ends only.
An example of a DNV2LN.LIN file creation follows.
You must substitute
the specifications of the hardware lines
in your configuration.
TEST72 in the front end requires that the line specifications be
in
uppercase as shown.
Because the test will not run without the created
file, the directory is checked and the file is typed.
Example:
$EDIT

DNV2LN.LIN~

%No such file type, Creating New File
Input: DNV2LN.LIN.l
00100
KDP_O_O~
00200
KDP_O_l~
00300
KDP_0_2~
00400
KDP_0_3~
00500
DMC_O~
00600
DMC_l~
00700
$
*EU(RET)
[DNV2LN.LIN.l]
$dir dnv2ln.lin~
PS:<UETP.LIB)
DNV2LN.LIN.l
$type dnv2ln.lin~
KDP_O_O
KDP_O_l
KDP_0_2
KDP_0_3
DMC_O
DMC_l
$
Step 5:

Ensure PS:<UETP.RUN) is empty.

Enter:
$CONNECT PS:<UETP.RUN)~
$DELETE *.*~
Step 6:

Run the UETP program.

Enter:
$RUN UETP~
UETP>

10-36

INSTALLING DECnet-20

Step 7:

Enable test and begin testing.

Enter:
DNV2LN/DEPTH:COMPREHENSIVE~
UETP>BEGIN~

UETP>ENABLE
Step 8:

Respond to aPR messages.

For each line to be tested, TWO messages are output to the operator's
console.
You will enter some commands and follow some given
directions.
Examples of the two messages follow.
Not all numbers and
names in the examples will duplicate what you see.
Job name (X in the
example) and line specification will reflect your testing parameters.
The DN20A in the example should be replaced by the name of your
DECnet-20 communications front end.
As each line is tested,
the
two
messages will be repeated until all
lines to be tested have been
addressed.
Example - first message:
aPR>
11:25:47

<3>
Batch-stream 0 for JOB #11
--Message from Batch User-Job X Reg #17 for MIERSWA
PLEASE TURN LINE OFF, CONNECT PLUG, TURN LINE ON: KDP_O_l

OPR>ENTER NCP~
NCP>SET EXECUTOR DN20A(RET)
NCP>SET STATE LINE KDP_O_l OFF~
NCP>
11:26:27
NCP request # 2 [SET STATUS LINE KDP_ 0 _ 1 OFF]
Function completed successfully
*** ATTACH LOOPBACK CONNECTOR NOW ***
*** RETURN TO CONSOLE AND CONTINUE ***

NCP>SET STATE LINE KDP_O_l ON~
NCP>
11:30:23
NCP request # 3 [SET STATUS LINE KDP_ 0 _
Function completed successfully
NCP>RETURNC§)
OPR>RESPOND 3 OKC§)
aPR>
{Test takes approximately 2 minutes}

ION]

Example - second message:
OPR>
11:32:46
User--

<4>

Batch-stream 0 JOB # 11 --Message from Batch
Job X Req # 17 for MIERSWA
PLEASE TURN LINE OFF: KDP_O_l

OPR)ENTER NCP~
NCP>SET EXECUTOR DN20A~
NCP>SET STATE LINE KDP_O_l OFF~
NCP>
NCP request # 4 [SET STATUS KDP_ 0 _ 1 OFF]
11:33:07
Function completed successfully
NCP>RETURNG!D
OPR>RESPOND 4 OKG!D
OPR>
10-37

INSTALLING DECnet-20
Step 9:

When the test ends, check the RUN. LOG file.

Enter:
$TYPE

RUN.LOG~

If the RUN.LOG file confirms the successful completion of the test
(each of the lines you tested), you have completed this test.
Go to
Section 10.3.4.
If there are errors, continue with the next step.
Step 10:

Check the DNV2LN.LOG file.

Enter:
$TYPE

DNV2LN.LOG~

Examine the output to determine the cause of the error.
If any of the
lines were successfully tested, repeat from Step 4 but include only
the line specifications for lines that failed.
If the test shows no
lines tested successfully,
repeat all steps beginning with the step
referenced as in error in DNV2LN.LOG.
Step 11:

Turn lines off.

The DECSYSTEM-2020 can be
communication lines.
This
your configuration.

configured with 1 or
2 KDP
DECnet
test is to be run once for each line in

Use the NCP command subset of OPR to turn all lines off.
if your configuration includes 2 KDPs,

For example,

Enter:
$OPR~

OPR)ENTER NCP~
NCP)SET STATE LINE KDP_O_O
NCP)SET STATE LINE KDP_O_l
NCP)EXITG!D
$
Step 12:

OFF~
OFF~

Install loopback connector.

Install a loopback connector on line to be tested.
for description of loopback connector procedure.
Step 13:

See Section 10.3.1

Enable loopback and start line for cable loopback.

Enter:
$OPR~

OPR)ENTER NCP~
NCP)SET LOCAL LOOPBACK ENABLED KDP_O_O~
NCP)SET STATE LINE KDP_O_O CABLE-LOOPBACKG!D
NCP)EXITG!D

10-38

INSTALLING DECnet-20

Step 14:

Ensure that PS:<UETP.RUN> is empty.

Enter:
$CONNECT PS:<UETP.RUN>~
$DELETE *.*~
Step 15:

Run the UETP program.

Enter:
$RUN UETP~
UETP>
Step 16:

Enable tests and begin testing.

Enter:
UETP>ENABLE
UETP>ENABLE

TEST72/DEPTH:COMPREHENSIVE~

DNV2LL/DEPTH:COMPREHENSIVE~
UETP>BEGIN~

Step 17:

Examine the output ftom UETP.

Only the DNV2LL test will end.
TEST72 will not end by itself.
If the
STATUS reads Ended and the ERROR COUNT reads
0,
the
test was
successful.
If 1 or more errors are shown, continue to the end of the
procedure,
then repeat the test.
If the test was successful,
continue.
Step 18:

Abort TEST72 and exit.

Enter:
TEST72/DEPTH:COMPREHENSIVE~
UETP>EXIT~

UETP>ABORT

$
Step 19:

Check the RUN.LOG file.

Enter:
$TYPE

RUN.LOG~

If the RUN.LOG file confirms the successful completion of the test, go
to Step 21.
If there are errors, continue with the next step.
Step 20:

Check the DNV2LL.LOG file.

Enter:
$TYPE

DNV2LL.LOG~

Examine the output to determine the cause of the error.
Do not go to
the next step.
Repeat the test from Step 1, or, if it is clear from
DNV2LL.LOG that the tests were enabled and begun, repeat from Step 14.

10-39

INSTALLING DECnet-20
Step 21:

Disable loopback testing for the first line.

Enter:
$OPR~

OPR>ENTER NCP~
NCP>SET STATE LINE KDP_O_O OFF~
NCP>SET LOCAL LOOPBACK DISABLED KDP_O_O~
NCP>EXIT~

$
You have completed the line loopback testing for 1 line.
If you
2 lines, repeat all from Step 12 (Install Loopback Connector).

10.3.4

have

Remote-NCP Test

The Remote-NCP test is executed in much the same way as the Local-NCP
test.
You use the OPR/NCP/ORION interface and may enter commands
directly to your terminal or indirectly with a command file.
In the previous two sections you have demonstrated that the Network
Control Program functions on the local node (Section 10.3.2), and that
the lines leading out of the local node are functioning
(Section
10.3.3).
The purpose of the Remote-NCP test is to demonstrate that
the OPR/NCP/ORION interface can be used to obtain information from the
device controllers on remote nodes.
Ensure that all loopback connectors are
connected normally.

removed

and

the

system

If your host node is a DECSYSTEM-2040/50/60,
reload the DECnet-20
front end and log in with WHEEL or OPERATOR privileges enabled. Go to
Step lA if you wish to use direct input to your terminal; go to Step
lB if you wish to use a command file.
If your host node is a DECSYSTEM-2020, reload the system and log in
with WHEEL or OPERATOR privileges enabled.
Go to Step 2A if you wish
to use direct input to your terminal; go to Step 2B if you wish to
use a command file.
Step lA.

Remote-NCP
test
using
(DECSYSTEM-2040/50/60)

direct

terminal

input

Enter:

@enaBLE~

$conn ps:<uetp.decnet>~
$type remote-ncp-dn20-example.cmd~
Read the example file.
Refer to the commands below the second line of
asterisks.
The "DN20" in the example SET EXECUTOR command is the node
name of the DECnet-20 communications front end.
You type the node
name you assigned to the communications front end in the NETGEN
procedures.
For the SHOW STATUS LINE and SHOW COUNTS LINE commands,
you type the line identification of each line in your configuration
that you wish to test.

10-40

INSTALLING DECnet-20
When you have executed the commands following the directions
in
the
example, compare the output with the example below.
The format should
be similar.
The node name and line identifications may differ.
The TAKE commands that precede the NCP commands
in the example are
given to suppress printing of system and OPR messages during output.
These commands are helpful if you are testing under
timesharing,
but
are not needed if you are testing standalone.
Example entry and responses:
Stake refuse~
OPR)take opr.cmd~
OPR)
08:56:18
--OUTPUT DISPLAY for OPR Modified-OPR)enter ncp~
NCP)set executor dn20a~
NCP)show executor~
NCP)
08:56:51
Current EXECUTOR is node DN20A
NCP)show status local~
NCP)
08:57:06
NCP request # 6 [SHOW STATUS LOCAL]
Status of local node as of 6-Aug-79 08:57:06
NOde Name is DN20A, # 0, SYS~~M = H~L 4 ~lELDTEST 3.0 l8-JUL-79
Routine version = 3.1.0, Communications Version = 3.1.0
State is On, Default Host = 2102
Function completed successfully
NCP)show status known lines~
NCP)
08:57:40
NCP request # 7 [SHOW STATUS KNOWN LINES]
Status as of 6-Aug-79 08:57:40
Line ID
DTE20_1_0_0
DMCll_O_O_O
DMCll_l_O_O
DMCll_2_0_0
KDP_O_O_O
KDP_O_l~

KDP_0_2_0
KDP_0_3_0

State

Adjacent Node

2102

Off
On
On
On
On
On
Off

SYS880

Function completed successfully

10-41

DN200

INSTALLING DECnet-20
NCP)show status line dmcll_O_O~
NCP)
08:58:42
NCP request # 8 [SHOW STATUS LINE DMCll_ 0 _ 0]
Status as of 6-Aug-78 08:58:41
Line ID

State

Adjacent Node

Function completed successfully
NCP)show status line kdp_O_O~
NCP)
08:59:18
NCP request # 9 [SHOW STATUS LINE KDP __ 0 _ 0]
Status as of 6-Aug-79 08:59:18
Line ID

State

Adjacent Node

SYS880

Function completed successfully
NCP)show counts line dmcll_O_O~
NCP)
08:59:52
NCP request # 10 [SHOW COUNTS LINE DMCll_ 0 _
Counts for line DMCll_O_O_O, as of 6-Aug-79 08:59:52
Seconds since zeroed
4296
Blocks received
0
Blocks sent
Retran, line errors
Received line errors
0
Retran, not line errors
Receive timeouts
0

°°
°

Function completed successfully
NCP)show counts line kdp_O_O~
NCP)
09: 00: 29
NCP request # 11 [SHOW COUNTS LINE KDP _
Counts for line KDP_O_O_O, as of 6-Aug-79 09:00:29
4334
Seconds since zeroed
Blocks received
1
1
Blocks sent
Retran, line errors
Received line errors
Retran, not line errors
Receive timeouts

°°°
°

Function completed successfully
NCP)show queue
NCP)
09:01:04

ncp-requests~

There are no outstanding NCP requests.
Ncp>exit~

End of REFUSE.CMD.l
$

10-42

0 _ 0]

INSTALLING DECnet-20
If you wish to see an example of the same commands
entered
with
a
command
file,
type
the
file
PS:<UETP.DECNET>REMOTE-NCP-DN20-EXAMPLE.TXT.
You will see one major
difference between direct and indirect entry.
When commands are given
using a command file, there will be a response to the SHOW QUEUE
NCP-REQUESTS command.
Because direct entry is at typing speed, the
responses follow the commands and there are no commands waiting in the
queue.
If you wish to repeat the REMOTE-NCP test using a command
continue with Step IBi
otherwise go to Section 10.3.5.
Step lB.

Remote-NCP test using a command file

file,

(DECSYSTEM-2040/50/60)

The file REMOTE-NCP.CMD in the directory PS:<UETP.DECNET> contains the
commands for the REMOTE-NCP test.
One SET EXECUTOR command, two SHOW
STATUS LINE commands, and two SHOW COUNTS LINE commands are given with
dummy arguments.
These arguments must be edited to reflect the node
name and line identifications of YOUR configuration.
The number of
both SHOW STATUS LINE and SHOW COUNTS LINE commands must equal the
number of lines you plan to use for network traffic.
The node name in
the SET EXECUTOR command must be identical to the node name assigned
to the DECnet-20 communications front end in the NETGEN procedures.
The edited file should be output to

example.
from EDIT.

PS:<UETP.LIB>

shown in the
when you exit
Including the DN20 node name in the output file will help

USe the EDIT command ED to remove .1.lIle

identify it for future use.

10-43

IlumDer~

INSTALLING DECnet-20

Example entries and responses:

remote-ncp.cmd.~OUTPUT AS) ps:<uetp.lib>remote-ncp-dn20a.cmd~

$edit
Edit: REMOTE-NCP.CMD.3
*p~:*~

00100
00200
00300
00400
00500
00600
00700
00800
00900
01000
01100
01200
01300
01400
01500
01600
01700
01800
01900
02000
02100
02200
02300
02400
02500
02600
02700
02800
02900
03000
03100
03200
03300
03400
03500
03600

***********************************************************************
THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY ONLY BE USED
OR COPIED IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE.
COPYRIGHT (C)

1978,1979 BY DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS

DECnet-20 V2 Remote NCP test
To run this test start OPR in a job enabled with wheel or operator
privileges and enter the NCP command subset:
@ENABLE
$OPR
OPR>ENTER NCP
NCP>
Then either enter:
NCP>TAKE REMOTE-NCP.CMD
ito execute the statements in the command file or
!type the following commands by hand.
!***********************************************************************
SET EXECUTOR node-name
SHOW EXECUTOR
SHOW STATUS LOCAL
SHOW STATUS KNOWN LINE
SHOW STATUS LINE line
SHOW STATUS LINE line
SHOW COUNTS LINE line
SHOW COUNTS LINE line
SHOW QUEUE NCP-REQUESTS

*snode-name$DN20A$2800~

02800
SET EXECUTOR DN20A
*sline$DMCll 0 0$3200,E~
03200
SHOW STATUS LINE DMCll_O_O
*sline$KDP 0 0$3300,E~
03300
SHOW STATUS LINE KDP_O_O
*sline$DMCll 0 0$3400,E~
03400
SHOW COUNTS LINE DMCll_O_O
*sline$KDP 0 0$3500,E~
03500
SHOW COUNTS LINE KDP_O_O
*p2800:3600~

02800
02900
03000
03100
03200
03300
03400
03500
03600

SET ~XECUTOR DN20A
SHOW EXECUTOR
SHOW STATUS LOCAL
SHOW STATUS KNOWN LINE
SHOW STATUS LINE DMCll_O_O
SHOW STATUS LINE KDP_O_O
SHOW COUNTS LINE DMCll_O_O
SHOW COUNTS LINE KDP_O_O
SHOW QUEUE NCP-REQUESTS

*eu~

[REMOTE-NCP-DN20A.CMD.l]

10-44

INSTALLING DECnet-20

When you have exited from EDIT,
Enter:
CONN PS:<UETP.LIB>~
$OPRG!D
OPR>ENTER NCP~
NCP>TAKE REMOTE-NCP-xxxx.CMD~
where xxxx is the node name of the DN20
OUTPUT FOLLOWS
Enter:
NCP>EXIT~

Check your output as the test is being performed.
No error messages
should be printed.
The output should have the same format as the file
REMOTE-NCP-DN20-EXAMPLE.TXT in PS:<UETP.DECNET>.
This example is for
a DECSYSTEM-2060 node with a DN20 node name of DN20A.
Type the
example file to compare it with your output.
When the test completes successfully, go to Section 10.3.5.
Step 2A.

Remote-NCP test using direct terminal input (DECSYSTEM-2020)

Enter:
~

@enJBLE (CAPABILTIES)~
$type ps:<uetp.decnet>remote-ncp-20-example.cmd~
Read the example file.
Refer to the nine commands below the second
line of asterisks.
To test YOUR local NCP, certain changes are
required:
The first command will be:
SET EXECUTOR your local host name
The node name in the SET EXECUTOR command must agree
the node name in the 4-CONFIG.CMD file in PS:<SYSTEM>.

with

For both the SHOW STATUS LINE and SHOW COUNTS LINE commands, type
the line identification(s) of the line(s) in your configuration
that you wish to test.
For one line, the lineid will be KDP_O_O.
For two lines, the lineids will be KDP_O_O and KDP_O_l.
Now, type the commands (seven or nine commands depending on the number
of lines) shown in the example, making the changes indicated for node
name and lineids.
Check the output as the commands are being
performed.
There should be no error messages.
When the response to
the last command is complete, type EXIT following the NCP prompt.
To compare
your
output
with
an
example,
type
the
file
PS:<UETP.DECNET>REMOTE-NCP-20-EXAMPLE.TXT.
This example is the result
of a TAKE command.
If you wish to repeat the LOCAL-NCP test using a
command file, go to Step 2B; otherwise go to Section 10.3.5.

10-45

INSTALLING DECnet-20
Step 2B:

Remote-NCP test using a command file

(DECSYSTEM-2020)

The file REMOTE-NCP.CMD in the directory PS:<UETP.DECNET) contains the
commands for the REMOTE-NCP test.
One SET EXECUTOR command, two SHOW
STATUS LINE commands, and two SHOW COUNTS LINE commands are given with
dummy arguments.
These arguments must be edited to reflect the node
name and line identifications of YOUR configuration.
The number of
both SHOW STATUS LINE and SHOW COUNTS LINE commands must equal the
number of lines you plan to use for network traffic.
The node name in
the SET EXECUTOR command must be identical to the node name specified
in the 4-CONFIG.CMD file in the installation procedures.
The edited file should be output to PS:<UETP.LIB) as shown in the
example.
Use the EDIT command EU to remove line numbers when you exit
from EDIT.
Example entries and responses:

$edit remote-ncp.cmd.2 (OUTPUT AS)
Edit: REMOTE-NCP.CMD.2

ps:<uetp.lib>remote-ncp.cmd~

*p-:*~

00100
00200
00300
00400
00500
00600
00700
00800
00900
01000
01100
01200
01300
01400
01500
01600
01700
01800
01900
02000
02100
02200
02300
02400
02500
02600
02700

***********************************************************************1
THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY ONLY BE USED
OR COPIED IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE.
COPYRIGHT (C)

1978,1979 BY DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS

DECnet-20 V2 Remote NCP test
To run this test start OPR in a job enabled with wheel or operator
privileges and enter the NCP command subset:
@ENABLE
$OPR
OPR>ENTER NCP
NCP>
!Then either enter:
NCP>TAKE REMOTE-NCP.CMD
!to execute the statements in the command file or
!type the following commands by hand.
!***********************************************************************!

10-46

INSTALLING DECnet-20
02800
02900
03000
03100
03200
03300
03400
03500
03600

SET EXECUTOR node-name
SHOW EXECUTOR
SHOW STATUS LOCAL
SHOW STATUS KNOWN LINE
SHOW STATUS LINE line
SHOW STATUS LINE line
SHOW COUNTS LINE line
SHOW COUNTS LINE line
SHOW QUEUE NCP-REQUESTS

*snode-name$4097$2800~

02800
SET EXECUTOR 4097
*sline$KDP_O_O$3200,Etlm)
03200
SHOW STATUS LINE 'KDP_O-D
*sline$KDP_0_l$3300,E~

03300

SHOW STATUS LINE KDP_O_l

*sline$KDP_0_0$3400,E~

03400

SHOW COUNTS LINE KDP_O_O

*sline$KDP_0_l$3500,E~

03500
SHOW COUNTS LINE KDP_O_l
*p2800: 3600GD
2800
SET EXECUTOR 4097
2900
SHOW EXECUTOR
3000
SHOW STATUS LOCAL
3100
SHOW STATUS KNOWN LINE
3200
SHOW STATUS LINE KDP_O_O
3300
SHOW STATUS LINE KDP_O_l
3400
SHOW COUNTS LINE KDP_O_O
3500
SHOW COUNTS LINE KDP_O_l
3600
SHOW QUEUE NCP-REQUESTS
*eu~

[<UETP.LIB)REMOTE-NCP.CMD.l]
$

When you have exited from EDIT,
Enter:
$CONN

PS:<UETP.LIB>~

$OPR~

OPR)ENTER NCP~
NCP)TAKE REMOTE-NCP.CMD~
OUTPUT FOLLOWS
Enter:
NCP)EXIT~

Check your output as the test is being performed.
No error messages
should be printed.
The output should have the same format as the file
REMOTE-NCP-20-EXAMPLE.CMD in PS:<UETP.DECNET). This example is for
a
DECSYSTEM-2020. Type the example file to compare it with your output.
When the test completes successfully, go to Section 10.3.5.

10-47

INSTALLING DECnet-20
10.3.5

Remote and Local Node Network File Transfer Test

This test ensures that the Network File Transfer
(NFT)
utility is
functioning.
The test is run under the control of the UETP program.
Step 1:

Log in as a nonprivileged user.
NOTE
If you are logging in to a directory other than the
one you used for the verification procedures, remember
to add the IPCF and USER GROUPS 100 parameters to the
login directory.
See Section 10.2 for help.

Step 2:

Create an NFT.INIT file in PS:<UETP.LIB).

The following example is for your guidance only. The parameters you
use in the NFT command SET DEFAULTS must describe each node to which
transfers will be made.
You must have access to at least one account
on each node to be tested.
USER, ACCOUNT, and PASSWORD must have the
values and format agreed upon by the remote node when the account was
opened.
The example assumes your file transfers will be between
2102, a DECSYSTEM-2060, and 4097, a DECSYSTEM-2020.

two

nodes:

Example:
@conn ps:<uetp.lib>~
@edit nft.init~
%File not found, Creating New file
Input: NFT.INIT.l
00100
set defaults 2102::/user:gunn/account:341/ostype:tops20/pass:zlinfm~
00200
set defaults 4097::/user:gunn/account:341/ostype:tops20/pass:zlinfm~
00300
$
*eu~

[NFT.INIT.l]
@type ps:<uetp.lib>nft.init~
set defaults 2102::/user:gunn/account:341/ostype:tops20/pass:zlinfm
set defaults 4097::/user:gunn/account:341/ostype:tops20/pass:zlinfm
@

See Chapter 8 if you need additional help
file.

10-48

creating

the

NFT.INIT

INSTALLING DECnet-20

Step 3:

Check availability of nodes to be tested.

Entry and response:
@info decnet ~
Accessible DECNET nodes are:
DN20L, SYS880

1031, 2102,

4097,

DN200,

DN20A,

NOTE
If the NFT test does not
complete
successfully the first time, it may be
necessary to return to this step.
(A
node may have lost its "accessible"
state.)
Step 4:

Define the file search association of DSK:.

Entries and responses:
@define utp:
@define dsk:
Step 5:

ps:<uetp.lib>~

dsk: ,utp:~

Connect to PS:<UETP.RUN> and
empty.

Entries and responses:
@connect ps:<uetp.run>~
@delete *. *G!D
DNV2FT.LOG.l [OK]
EXCEPT.LOG.l [OK]
RUN.LOG.1 [OK]
SEND.DAT.l [OK]
@expunge <uetp.run>~
PS:<UETP.RUN> [13 pages freed]

10-49

en~llrp

that

this

INSTALLING DECnet-20
Step 6:

Run UETP.

Entries and responses:
@run uetp~
[27-Sep-79 12:05:16

User Environment Test Package ]

UETP>enable dnv2ft/depth:application~
[12:06:01 ENABLE COMPLETED]
UETP>begin~

[12:06:09 BEGIN COMPLETED]
UETP>
START DNV2FT
12:06:35
status
[27-Sep-79 12:09:06]
Test
name

Depth

DNV2FT APP

END

Status

Cycle

Times
run

Error
count

Error
limit

Running

DNV2FT

Start
time
27-Sep-79 12:06:09

12:12:07

[All tests complete on processor # 2102]
[27-Sep-79 12:13:25]
Test
name

Depth

DNV2FT APP

Status

Cycle

Times
run

Error
count

Error
limit

Ended

12:06:35
12:06:51
12:07:03
12:08:57
12:09:42
12:10:22
12:11 51
12:12 05
12:12 07

IN IT
INIT
STPl
STP2
STP3
STPl
STP2
STP3
FIN

Start
time
27-Sep-79 12:06:09

UEPT>exit~
@dir~

PS:<UETP.RUN>
DNV2FT.LOG.l
EXCEPT.LOG.l
RUN.LOG.l
TOTAL OF 3 FILES
@type run.log~
START DNV2FT
MINOR DNV2FT
MINOR DNV2FT
MINOR DNV2FT
MINOR DNV2FT
MINOR DNV2FT
MINOR DNV2FT
MINOR DNV2FT
END
DNV2FT

27-Sep-79
27-Sep-79
27-Sep-79
27-Sep-79
27-Sep-79
27-Sep-79
27-Sep-79
27-Sep-79
27-Sep-79

10-50

o 00:025:25:51DNV2FT started
o 00:059:52:01DNV2FT finished step INIT
o 00:0813:07:19DNV2FT finished step STPl
o 00:1544:55:22DNV2FT finished step STP2
0:00:2157:25:28DNV2FT finished
0:00:2368:30:31DNV2FT finished
0:00:3193:04:20DNV2FT finished
0:00:3697:01:03DNV2FT finished
0:00:3797:39:22DNV2FT ended

step
step
step
step

STP3
STPl
STP2
STP3

INSTALLING DECnet-20
If the test ends with 0 errors, typing the RUN.LOG file
each node tested:

displays

for

finished STPI
finished STP2
finished STP3
The six lines confirm the
In the example, two nodes were tested.
If the error count is 1 or more,
successful completion of the test.
steps and errors are displayed
in
type the DNV2FT.LOG file.
All
detail.
This file will also be helpful if you plan to create your own
the
NFT test.
If you could not run UETP, check your directory for
IPCF and USER GROUP 100 entries and check your define statements.

10.3.6

DN200 Tests (2040j50j60 with Remote Job Entry Station Only)

This test demonstrates the use of Operator Commands (OPR) at the DN200
remote station console.
The
test
includes queueing output to be
printed by the printer at the remote station and executing a batch job
from the remote station.
The batch job includes reading the card
deck, executing the batch program, and printing the batch log.
Prior to this test, the DN200 must have been configured as part of the
local DECnet-20 system.
The DN200 must have been verified, powered on
and loaded.
Step 1:

Check the
console.

DN200

status

and

queue

status

Entries and Responses:
2102::0PR>SHOW
2102::0PR>
2102::
9:13:05

STATUS~

-- System Device Status --

Printer Status:
Unit
Node

Status

DN200

Idle

Reader Status:
Unit

Node

Status

DN200

2102::0PR>SHOW
2102::0PR>
2102::
9:13:40

Idle

Q~T-)

--The Queues are Empty--

2102::0PR>

10-51

operator's

INSTALLING DECnet-20

Step 2:

Print file on local and remote (DN200) printers and
(First ensure the DN200 is available.)

compare.

Entries and responses:

@infORMATION (ABOUT) decNET~
Accessible DECNET nodes are: 1031, 2102, 4097, DN200, DN20A, DN20L
@print ps:<uetp.1ib)pictur.txt~
[Job PICTUR Queued, Request-ID 89, Limit 54]
@print ps:<uetp.lib)pictur.txt/destination-node:dn200::~
[Job PICTUR Queued, Request-ID 90, Limit 54]

@iNFORMATION (ABOUT)
Printer Queue:
Job Name
Req#

OUTPUT-REQUESTS~

Limit

User

* PICTUR

90
54 CIRINO
Started at 10:55:21, printed 0 of 54 pages
6201DP
6
810 HARAMUNDANIS
DN6A
2
108 LNEFF
There are 3 Jobs in the Queue (1 in Progress)

The output is a geometric pattern.
easily seen.
Step 3:

On Unit:O
/Lower
/Lower

/Dest:DN200

/Forms:NARROW
/Forms:NARROW

Any errors in transmission will be

Prepare a card deck for submission to the DN200 card reader.

Keypunch entries:
$JOB username
$PASSWORD password
$TOPS20
@DEFINE DSK: DSK:,<UETP.RUN),<UETP.LIB)
@PRINT CHARS.TXT
$EOJ

10-52

INSTALLING DECnet-20
Step 4:

Read the deck on the DN200 card reader.

Output on DN200 console:
2102::0PR>SHOW STATUS~
2102::0PR>
2102::
9:27:13
-- System Device Status -Printer Status:
Unit
Node

Status

---------DN200

--------------Idle

Reader Status:
Unit
Node

Status

---------0
2102::0PR>
2102::
9:29:34
2102::
9:29;37
2102::0PR>
2102::
9:29:49
2102::
9:29:51
2102::
9:29:51
2102::0PR>
2102::
9:31:54
2102: :
9:31:54
2102::0PR>
2102::
9:32:56

DN200

--------------Idle

Reader 0 [DN200]

-- 1 Job: 7 Cards Spooled

Batch-Stream 2 --Begin-Job JB3047 Reg #38 for CIRINO

Batch-Stream 2 --End-Job JB3047 Reg #38 for CIRINO
Printer 0 [DN200]

--Started--

Printer 0 [DN200]
--Begin-Job CHARS Reg #39 for CIRINO

Printer 0 [DN200]
--End-Job CHARS Reg #39 for CIRINO
Printer 0 [DN200]
--Begin-Job JB3047 Reg #40 for CIRINO

Printer 0 [DN200]
--End-Job JB3047 Reg #40 for CIRINO

2102::0PR>
The SHOW STATUS command is given to check the
immediate availability
of the reader and printer.
All of the output that follows is
displayed without further action by the operator.
Reg #38 is for
the
read;
Reg #39 is for the printing of the CHARS.TXT file;
Reg #40 is
for the printing of the log file.

10-53

INSTALLING DECnet-20
Output on the DN200 printer is a five-page printout of the complete
character set extending margin to margin with each successive line
offset one space to the left.
The printout of the batch log file
completes the
job.
The log file printout should resemble the
following example:
Example:
9:29:35 STDAT
9:29:35 STMSG
9:29:35 STCRD
9:29:35 STCRD
9:29:35 STCRD
9:29:35 STCRD
9:29:35 STSUM
9:29:35 STSUM
9:29:35 STSUM

SPRINT version 104(4072) 2102 Development System,
TOPS-20 Monitor 4(3117)
[Job Input from Reader 0 [DN200]]
$JOB CIRINO
$PASSWORD
$TOPS20
$EOJ
End of job encountered
7 Cards Read
Batch job submitted
26-Sep-79

BATCON Version

9:29:37

104(4126)

GLXLIB Version

1(515)

Job JB3047 Req #38 for CIRINO in Stream 2
OUTPUT:
Log
Yes
UNIQUE:
RESTART: No
Input from
Output to
9:29:38 USER
9:29:38 MONTR
9:29:38 MONTR
9:29:42 MONTR
9:29:42 MONTR
9:29:42 MONTR
9:29:42 MONTR
9:29:42 MONTR
9:29:42 MONTR
9:29:44 MONTR
9:29:44 MONTR
9:29:46 MONTR
9:29:47 MONTR
9:29:47 BLABL
9:29:47 MONTR
9:29:48 MONTR
9:29:48 MONTR

10.3.7

=)
=)

TIME-LIMIT:
BATCH-LOG:
ASSISTANCE:
SEQUENCE:

0:05:00
Append
Yes
1624

PS:<CIRINO)JB304.CTL.l
PS:<CIRINO)JB3047.LOG.l

2102 Development System, TOPS-20 Monitor 4(3117)
@SET TIME-LIMIT 300
@LOGIN CIRINO 341
Job 50 on TTY222 26-Sep-79 09:29:42
@

[PS Mounted]
[CONNECTED TO PS:<CIRINO)]
@DEFINE DSK: DSK:,<UETP.LIB)
@@CONN <UETP.RUN)
@@PRINT CHARS.TXT
[Job CHARS Queued, Request-ID 39, Limit 54]
@

%FIN: :
Killed Job 50, User CIRINO, Account 341, TTY 222,
at 26-Sep-79 09:29:47, Used 0:00:00 in 0:00:05

DECnet Error and Event Logging Test

This test demonstrates the error and event logging features of DECnet.
While you were performing the previous tests, DECnet was writing
entries into the system log.
SYSERR can be used to examine these
entries.
Refer to Appendix C for a detailed description of SYSERR
entries.

10-54

INSTALLING DECnet-20

The following commands output to the printer a summary of all entries
concerning
your network.
The /BRIEF switch creates a listing
containing the sequence number, the time of the occurrence, and a
maximum of three lines of the most usable information for each entry.
Output may be directed to your terminal by typing TTY:= in place of
LPT:=.
Enter:
@SYSERR~

*LPT:=/BRIEF/NETALL~

Examine the output. If you need further help
entries, the following sources will be helpful:
•

Appendix C of this manual

•

TOPS-IO and TOPS-20 SYSERR Manual

•

HELP file for SYSERR

interpreting

To obtain a detailed listing of the entries summarized
listing,

the

first

PS:<UETP.DECNET).

The

Enter:
@SYSERR~
*T~M"1_~

1T""'I~rn1\TT

/~'TT"'rn1\TT

. LJr.i.. - / L-L.l.Cl.... .LJ/ l"L-.l.C-U.H-'~

Examples of SYSERR output may be printed from
example files are BRIEF.TXT and DETAIL. TXT.

The HELP file for SYSERR contains information on switches for use with
SYSERR.
For example, you can request listings for specific sequence
numbers or specific dates.

10-55

PART VI

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 via the network functions of the
MTOPR monitor call.
Table A-I
Disconnect or Reject Codes

~umh("\1Iu::llI10
_ _--

.... .1 ... ~~~

...

......

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

0
1
2
3
4
5
6
7
8
9
11
21

.DCX24
.DCX32
· DCX33
· DCX34
• DCX35
· DCX36
.DCX37
· DCX38
· DCX39
.DCX40
· DCX41
.DCX42
.DCX43

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

No special error
Resource allocation failure
Destination node does not exist
Node shutting down
Destination process does not exist
Invalid name field
Destination process queue overflow
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
Confirmation of disconnect initiate (DI)
Image data field too long

A-I

I
I

APPENDIX B
OECnet OBJECT TYPES

The object types listed in Table B-1 are
taken
from
the
Network
Services Protocol,
Version 3.1 documentation.
Object type codes are
expressed in decimal.
DECnt2t.-20 will, ill audi.t.i.on, recoglilze a nUirtDE.::L
of object names
in place of object types.
Object names that are
currently supported are shown ln 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
12R thrnunh 2~~ ar p availahl~ ~n ~11 ~n~~nr~
tasks.
Table B-1
OECnet Object Types
Object
Type
Code

Object
Name

Function

0
1
2
3-4
5
6
7
8-14
15
16
17
18
19
20-62
63
64-127
128-255

TASK

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

NRM

FAL
NCU

-.--.----

-..

B-1

I
I

APPENDIX C

NETWORK EVENT AND ERROR LOGGING

C.l

OVERVIEW

Error and event logging as described in
this appendix
is available
only for
DECSYSTEMs-2040/S0/60 with a minimum of 128K words in the
DN20 DECnet communications front end.
(Significant events on a
DECSYSTEM-2020 DECnet system are displayed as BUGCHKs or BUGINFs on
the operator's console and are logged in the SYSERR file.)
One of the functions performed by the network control task (NETCON) is
to record pertinent network events as SYSERR entries to the system's
ERROR.SYS file.
The following events are recorded each time
they
occur:
•

Load and start NETCON

•

Load a node

•

Dump a node

SYSERR entries are also created for:
•

hardware detected failures

•

CHKll diagnostic messages

In addition, you can optionally request NETCON to periodically log
line-counter values and error statistics for any communications line
terminating on any node in the network.
See the Operator Commands
in
Section 6.3 for a description of the following commands:
INITIATE LOGGING LINE-COUNTERS lineid node name
TERMINATE LOGGING LINE-COUNTERS lineid nodename
SET LOGGING-INTERVAL LINE-COUNTERS n

(MINUTES)

Note that this feature is a DECnet-20 function;
all SYSERR entries,
regardless of which line or node they are recorded for, are entered
into the ERROR.SYS file residing at the DECnet-20 node that processes
the INITIATE LOGGING command.
To obtain a formatted printout of all or
selected portions of the
ERROR.SYS file,
use
the SYSERR program described in the TOPS-IO and
TOPS-20 SYSERR Manual.

C-l

NETWORK EVENT AND ERROR LOGGING
C.2

SYSERR ENTRIES

Each of the SYSERR entries described below consists of two parts:
1.

A 4-word header section

A variable-length body section

The format of the header section is the same for
all entries;
the
format of the body section varies by the type of event being logged.
The header section is comprised of four
words
that provide general
information about
the system,
the
time and type of event, and the
length of the entry.
The format and contents are shown in Figure C-l.

Symbol

Offset

HDRCOD

(0)

HDRDAT

(1)

HDRUPT

(2)

HDRPSN

(3)

89
Event type

Reserved

1617 18

2324

Header
format

2627
Header
length

Body
length

Date and time in Universal Format**
System uptime (whole days)

System uptime (frac. days)

Processor serial number where the entry was recorded
*This entry recorded by TOPS-20
"'* A 36-hit quantity with a binary point between the left and right halves.

The left half is the number of days since 17 November 1858; the right
half is the fraction of a day in Greenwich Meridian Time.

Figure C-l

C.2.1

MR-S-603-80

Common Header Section for SYSERR Entry

NETCON Load Entry (event 201)

Whenever NETCON is loaded and started,
a SYSERR entry
is made
to
record
the version number
and the node on which NETCON is running.
The format and contents are shown in Figure C-2.

C-2

NETWORK EVENT AND ERROR LOGGING
Symbol

Offset

HDRCOD

(0)

201

I
(Header section)

NS%VER

(4)

NETCON version number

NS%NAM

(5)

Offset to the ASCIZ node name of host

NS%PGM

(6)

Offset to the ASCIZ program name
~L"

'"'

ASCIZ node name of host

ASCIZ program name

I
T
MR-S-604-80

Figure C-2

SYSERR Entry for a NETCON Load

C-3

NETWORK EVENT AND ERROR LOGGING
C.2.2

Node Load Entry (event 202)

Whenever NETCON loads a node,
a SYSERR entry is made to record
information such as the nodes involved, the line used, the load file
specification, and any return code.
The format and contents are shown
in Figure C-3.
Symbol
HDRCOD

Offset

202

(0)

I
(Header section)

NL%TAR

(4)

Offset to the ASCIZ name of the node being loaded

NL%SER

(5)

Offset to the ASCIZ name of the node doing the loading

NLo/oSLD

(6)

Offset to the ASCIZ line identification

NL%FIL

(7)

Offset to the ASCI Z load file specification

NL%RTN

(10)

Return code

I..-

ASCIZ name of the node being loaded

ASCIZ name of the node doing the loading

ASCIZ line identification

.... '--

L~----------------~I

ASCIZ load file specification
-I
I~--------------------------------------------------~

"T""

MR-S-605-80

Figure C-3

SYSERR Entry for a Node Load

C-4

NETWORK EVENT AND ERROR LOGGING
C.2.3

Node Dump Entry (event 203)

Whenever NETCON dumps a node,
a SYSERR entry is made to record
information such as the nodes involved, the line used, the dump file
specification, and any return code.
The format and contents are shown
in Figure C-4.
Symbol
HDRCOD

Offset

o
203

(0)

I
(Header section)

ND% TAR

(4)

ND%SER

(5)

Offset to the ASCI Z name of the node being dumped
Offset to the ASCIZ name of the node receiving the dump
I

ND% SLD

(6)

Offset to the ASCIZ line identification

ND%FIL

(7)

Offset to the ASCIZ dump file specification

ND% RTN

(10)

Return code

ASCIZ name of the node being dumped
ASCIZ name of the node receiving the dump

ASCIZ line identification

ASCIZ dump file specification

MR-S-606-80

Figure C-4

SYSERR Entry for a Node Dump

C-5

NETWORK EVENT AND ERROR LOGGING

C.2.4

Hardware Error Entry (event 210)

Whenever a hardware option detects a failure, a SYSERR entry is made
to assist in the network maintenance function.
The information
recorded includes the environment of the entry,
the hardware option
that detected the error, the software running in the node where the
error is detected, and a detailed log data description of the hardware
option reporting the failure.
The format and contents of the hardware
error entry are shown in Figure C-5.

8
210

Symbol Offse t
HDRCOD

(0 )

(Header section)

Transmitting node number

Destination node number

NH%MID

(4 )

NH%MID

(5 )

NH%RID

(6 )

Offset to ASCIZ receiving node name

NH%ADN

(7 )

Offset to ASCIZ adjacent node name (-1)

Offset to ASCIZ transmitting node name

NH%FUN (10 ) eserved

Number of 8-bit bytes in log data section
Hardware entry sequence number

NH%SEQ (12 )
NH%LlD (13 )

Controller number

NH%Lll (14 )

reserved

I
I

Line or unit number
Station number

Node uptime when error detected

NH%DAT (15 )
NH%TRY (16 )

Hdw option*

Oper. sys.

Hdw sys.

NH%NUM (11 )

Flags

reserved

Retry count

Threshold value

NH%RSM (17 )

Code (reason)

Offset to start of log data

NH%PTR (20 )

'''''''

AS C IZ t r a nsmi t tin g node name

...... v

ASCIZ receiving node name
ASCIZ adjacent node name

r,-

ro..,

Delay counter &.UN6r~S address

Deposit/examine word # 3

Deposit/examine word # 2

Deposit/examine word # 1

KL 10 memory additional word # 1

KL 10 memory additional word # 2

To -10 byte count

To -11 byte count

To -10 address

Toll address

To -10 data word

To -11 data word

DiaQonal/control register # 1

Diagonal/control register # 2

Control/status register

Diagonal/control register # 3

Log
data

*The hardware option field determines the content of the log data. Log data above is
according to hardware option = DTE20 (015).

Figure C-5 SYSERR Entry for Hardware Detected Failures

C-6

MR-S-607-80

NETWORK EVENT AND ERROR LOGGING
Log data for hardware option KMCll/DUPll
for this hardware option type follows.

The initial 21

(003).

bytes

Offset to first word of sub-device table

Input transfer & maintenance
can t ro 1/,s t a t us regis t er

Output transfer
. t er
can t ro 1/I s t a t us regiS

2nd half of data port

1st half of data port

Microcode
type

Microcode
version

MR-S-608-80

Figure C-S.l

Log Data for KMCll/DUPll

Receiver status register

Receiver data buffer register

Transmitter status register

Transmitter data buffer register
MR-S-609-80

Figure C-S.2

Sub-device Table for Hardware Option DUPll

C-7

(003)

NETWORK EVENT AND ERROR LOGGING
C.2.5

CHKII Diagnostic Entry (event 220)

CHKII, a hardware test module, is started when the DN20 or DN200 is
loaded.
All messages from CHKll, messages concerning available
memory, and number and status of devices as well as detected errors,
become part of the CHKll diagnostic entry.
The format of the environment and reporting device section that
follows
the header and precedes the log data section is the same as
that for event 210 (hardware error entry.)
Symbols NH%MID through
NH%PTR become NO%MID through NO%PTR.
The log data is an ASCIZ CHKll
message of arbitrary length.
The format and contents are shown in
Figure C-6.

220

(Header section)
Symbol Offset
NO%MID

(4)

NO%PTR (20)

Words NO%M I 0 throuqh NO%PTR are
the same as words NH%MID through
NH%PTR (event 210, Hardware entry)

ASCIZ transmitting node name
ASCIZ receiving node name
ASCIZ adjacent node name
~--------------------------ASCIZ--------------------------4

~--------------------------CHK11--------------------------~

~-----------------------

message - - - - - - - - - - - - - - - - - - - - - - - - - i

(length depends on specific message)

MR-S-61 0-80

Figure C-6 SYSERR Entry for CHKll Diagnostic Entry

C-8

NETWORK EVENT AND ERROR LOGGING
C.2.6

Line Status Entry (event 230)

Periodically, NETCON records the status of each communications line
via a SYSERR entry.
The information that is logged includes the node
name, line identification, and a variable number of line counters.
The format and contents are shown in Figure C-7.
Symbol
HDRCOD

Offset

230

(0)

(Header section)

Destination node number

LC%MID

(4)

LC%XID

(5)

Offset to ASCIZ transmitting node name

LC%RID

(6)

Offset to ASCIZ receiving node name

LC%ADN

(7)

Offset to ASCIZ adjacent node name (-1)

LC%FUN

(10)

LC%NUM

(11 )

Number of 8-bit bytes in log data section

LC%SEQ

(12)

Hardware entry sequence number

LC%LlD

(13)

Controller number

Line or unit number

LC%Lll

(14)

reserved

Station number

LC%DAT

(15)

LC%TRY

(16)

LC%RSM

(17)

Reason for entry

LC%PTR

(20)

Offset to start of log data

Transmitting node number

reserved

I Oper. system

Hdwe system

Hdwe option

Node uptime when error detected
Flags

Retry count

reserved

ASCIZ transmitting node name
ASCIZ receiving node name

..-,-,

Type of counter

Counter value

Type of counter

Counter value

•
•

""""""-'

~~I____________

__________T_y_p_e_o_f_:_o_u_n_te_r____________

•
•

'""-----

C_o_un_t_:_r_va_l_u_e___________

MR-S-611-80

Figure C-7

SYSERR Entry for Line Statistics

C-9

NETWORK EVENT AND ERROR LOGGING

The line counter entries are in half-word format, with the line
counter type
(0-10 octal) in the left half and the item count in the
right half. The current line counter types are described in Table
C-l.
The number of line counter values that are actually recorded
depends on the type of controller on the line.
Table C-l
Line Counter Types
Type
(Octal)

Count of

Meaning

seconds since last zeroed

This count is incremented
once
second.
It is
a
cleared
when
the
other
counters
are cleared and
thus provides a time frame
for their values.

blocks received

This is the number of blocks
successfully received over
the line.

blocks sent

This is the number of blocks
successfully sent over the
line.

retransmissions, line errors

This is the number of blocks
retransmitted because of CRC
or parity errors.

received line errors

This is the number of blocks
received with CRC or parity
errors.

retransmissions, other than
errors or parity

This is the number of blocks
retransmitted for
reasons
other than CRC or parity
errors.

receive timeouts

This is the number of times
the
timer
has
receive
expired.

receive selection errors

This is the number of times
blocks have been received
with invalid selection data.

resource errors

This is the number of times
such things as buffers have
not been available.

C-I0

APPENDIX D

BIBLIOGRAPHY

The following DIGITAL documents contain detailed
protocols used in DECnet.

information

the

DECnet DIGITAL Network Architecture:
Digital Data Communications Message Protocol
Network Services Protocol
(DAP)

Maintenanc~

Proto("ol

AA-D599A-TC
AA-D600A-TC

(NSP)

Data Access Protocol
Op~ration

(DDCMP)

(MOP)

AJ'l.-D602l\-TC

The
following published books
are
a
source of general
network
information.
The list
is both arbitrary and abbreviated and is
intended to be a catalyst to stimulate the reader's interest.
Title

Author

Publisher

Introduction to Data
CommunIcatIons

Murphy and
Kalis

DIGITAL
DIGITAL

Introduction to MiniComputer Networks
Technical Aspects of
Data Communications

McNamara

DIGITAL

Introduction to TeleProcessIng (and others)

Martin

Prentice-Hall

Basics of Data
Communications

Karp, ed.

McGraw-Hill

Communications Networks
for Computers

Davies and
Barker

Wiley and Sons

Handbook of Data
Communlcatlons

Editors

National Computing
Centre Publications
(United Kingdom)

Data Communications

Doll

Wiley Interscience

D-l

APPENDIX E

GLOSSARY

acceptance tests

Acceptance
tests
refer
to
the
verification
and
certification
procedures.

asynchronous transmission

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

certification procedure

The
DECnet
certification
procedure
ensures that the various components of
the DECnet-20 system function at
a
basic,
minimal
level.
The DECnet
certification procedure
is
performed
after
the
DECnet
configuration,
installation,
and
verification
procedures are performed.

computer network

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

configuration

The
process
of
customizing
the
DECSYSTEM-2040/S0/60.
Using
the
configuration tools,
the DECnet user
establishes
the
network
parameters
specific to the DECnet communications
front end (and RJE station, if included)
being configured.

configuration tools

The programs NETGEN, TKB20,
VNP20,
and
DNMAC.
These are the programs needed
for on-site configuration of DECnet-20
on a DECSYSTEM-2040/50/60.

connect

The process of creating a logical link.

connect password

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

E-l

GLOSSARY

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,
sequential transmission of data over
physical links.

disconnect

The process of closing a logical link.

DMCII

A
single
line
microprocessor-based
interface to the network.
The DMCII is
a synchronous DMA device.

DN20

A DECnet-20 communications front end.
As used in this manual,
DN20 is a
generic term and includes both the DN20
and the DN21.

DNMAC

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

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.

DTE

The hardware interface between the main
processor
in a DECSYSTEM-2040, 2050, or
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.

FAL (File Access Listener)

The FAL program resides on a DECnet host
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.
E-2

GLOSSARY
installation procedure

DECnet installation is
the process of
setting
up the DECnet
software and
modifying several
system
files
to
include
DECnet-related
jobs.
DECnet
installation
occurs
after
DECnet
configuration.

interrupt message

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

local node

A relative term indicating the

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.

logical node

The logical node is the
node
to which
the system sends a user's queued output.
At login time, the logical node
is
the
~ame as the physical node.
The user may
specify a logical node by using the
SET
LOCATION command
from TOPS-20 command
level.

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
compatible
communications facilities.

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 DECnet-20 network
control commands.
NCP refers to one of
the three major programs of NETCON.

NCU

network
NCU is the name of the
utility that executes network
the
NCU
implements
commands.
Exchange
Information
and
protocol.
NCU refers
to one
three major programs of NETCON.

node
at
which your task is executing or at which
your terminal is logged in.

E-3

makes
with

control
control
Network
(NICE)
of
the

GLOSSARY
NETCON

NETCON is a specialized network control
task
that accepts requests via operator
commands and command files.
NETCON
processes network control requests such
as
the
loading
or
dumping
of
communications front end software, the
loading or dumping of synchronous line
controllers,
the displaying of line
statistics for
any line,
etc.
See
Sections 1.4 and 1.6 in Chapter 1 for
details.

NETGEN

NETGEN is the interactive program used
to describe the hardware and software
during the configuration procedure for a
DECnet node.

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
residing on DECnet hosts
delete files
that
provide
network
file
access
NFT initiates the service
capabilities.
requests that will be carried out by the
FAL program.

NICE protocol

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

node

An endpoint of any branch of a network,
or
a
junction common to two or more
branches of 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.

node number

A number
uniquely identifying a node
within a network.
Although NSP allows
node numbers of 2 through 240, DECnet-20
nodes may only be assigned numbers 2
through 127.

E-4

between

two

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 program that
implements
the NSP protocol.
(In the text, NSP
refers to the program;
NSP protocol
is
used to refer to the protocol.)

aPR

aPR is the Operator Command Language
program that provides the operator with
one command language to communicate with
several
TOPS-20
components.
aPR
processes commands for syntax and passes
syntactically correct commands to ORION.
(See the ORION definition.)

ORION

ORION is the operator control program
that
accepts commands from aPR and
forwards
the commands to the proper
program for
execution.
ORION forwards
NCP commands to NETCON.

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.
(The
basic transmission unit of DDCMP).

physical link

path
between
two
A communications
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.

physical node

A physical node consists of the hardware
compr ising
a
node.
See also 'the
definition of a node.

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

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.
E-5

that

not

your

GLOSSARY
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

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.

TKB20

TKB20 is the program that constructs
PDP-II formatted task images from object
files during the configuration procedure
for a DECnet node.

UETP

UETP is the acronym for User Environment
Test Package.
UETP is a collection of
programs, data files, and batch control
files designed to allow the user to
verify the integrity of the operating
system.
UETP acts as an interface
between the user and the batch system by
allowing the user to selectively access,
enable, and run tests
in the form of
batch control files.
In this manual,
UETP is used during the
installation,
verification,
and
certification
procedures.

up-line dumping

Transmitting a copy of a computer's
memory over a logical link and storing
it in a file on another node.

verification procedure

The
DECnet
verification
procedure
ensures that the appropriate DECnet-20
software modules bave been installed.
The verification process checks for the
existence of each required module and
for the correct version of each required
module.

VNP20

VNP20 is the program that creates the
communication front end system image
during the configuration procedure for a
DECnet node.

E-6

APPENDIX F
SAMPLE PROGRAMS FOR REMOTE LOGIN

F.l

INTRODUCTION

This appendix describes a set of three programs that use DECnet-20
task-to-task communications capabilities to allow a terminal at a
local host to log in to a remote host.
The two environmental
requirements for
running these programs are that a DECnet connection
must exist between the two hosts and that both hosts must be running
the TOPS-20 operating system at or above Release 3A level.
The three programs that implement the remote login function are NRT20,
STNRT,
and NRTSRV.
The function of each program is defined briefly
below:

F.2

NRT20

provides a network source task at the source
terminal's local node,
accepts data from the
terminal, sends the data to the remote host via a
network connection,
and passes output from the
remote host to the source terminal.

NRTSRV

provides a server
task at the remote host to
accept the network connection from NRT20, passes
the received data to a pseudo-TTY, and returns
output
from the remote host to the network
connection.
The output is read by NRT20 and sent
to the source terminal.

STNRT

creates a job that runs NRTSRV on the remote host.

NRT20 PROGRAM

NRT20 allows a user at a terminal on a TOPS-20 system to log in to a
remote host in a DECnet network.
Note that the type of operating
system on the remote host is immaterial to the NRT20 program.
However,
this appendix describes the use of NRT20 in conjunction with
the NRTSRV program which sets up a server task on a TOPS-20 host.
NRT20 defines a network source task and establishes a
task-to-task
network connection between the source task and a previously defined
target task at the remote host.
NRT20 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 NRT20 and return to
TOPS-20 (EXEC) command level at the local node.
Finally,
NRT20
monitors the network connection and handles any unexpected break in
the connection.

F-l

SAMPLE PROGRAMS FOR REMOTE LOGIN
The NRT20 source listing provided in this appendix contains code that
implements the functions described immediately below.
The order in
which the functions are coded in the listing parallels the order
in
which the functions are presented in this description.

F.2.1

NRT20 Initialization Routines

NRT20 performs the following actions to create the proper
for executing its major functions:

environment

•

Creates an inferior process to read
input from the source
terminal and to send the source terminal's input to the remote
host.

•

Enables the
job to trap AC
characters to the remote host.

•

Initializes, activates, and enables the software interrupt
system to handle input of a special escape character from the
terminal.
This permits the user to exit from the remote host
and return to EXEC level at the local node.

•

Permits the user to define the special escape character either
by default or by explicit specification.
This action occurs
as part of the initial NRT20-user dialogue,
as shown in
Section F.6 "Using the Remote Login Capability".

•

Disables echoing and sets binary data mode for
the terminal.
This is done so that the monitor at the remote host can assume
responsibility for echoing and
character
handling
and
translation for the terminal.

•

Opens a network connection to the server task
host.
NRT20 uses the file specification:

interrupts

and

send

the

remote

DCN:node-200
where node is the remote host's node name as specified by the
user in the NRT20-user dialogue and 200 is the object type for
the server task NRTSRV.
If the object type 200 is already in
use,
another object type should be selected instead.
(Refer
to Appendix B for
a list of available object types.)
If
another object type is selected, the user must modify both the
DCN:
specification in the NRT20 program and the
SRV:
specification in the NRTSRV program.

F.2.2

NRT20 Operations

NRT20 handles data transmission between the terminal
host by performing the following actions:
•

and

the

remote

Starts an inferior process that reads terminal input and sends
the input to the remote host.
The inferior process sends all
characters (except the special escape sequence) to the remote
host and passes all data received from the remote host to the
terminal.

F-2

SAMPLE PROGRAMS FOR REMOTE LOGIN
•

If the network connection is broken unexpectedly, NRT20 prints
the following message:
?Connection broken.

Reason:

nn:

reasontext

where nn is the DECnet disconnect reason code and
reasontext
is the explanation for the disconnect.
Following the printing
of the message, NRT20 returns to EXEC command level.
If
the
user enters CONTINUE at this point, NRT20 restarts processing
from the beginning, as though the user had entered NRT20
in
response to the @ monitor prompt.
•

When the user enters the special escape
freezes the inferior process and prints

sequence,

NRT20

[Connection broken, back at node node-name,
Type CONTINUE to resume connection]
where node-name is the node name of the local node
to which
the
terminal
is attached.
NRT20 returns to EXEC level where
the user may resume NRT20 processing at
the point of
the
interrupt by entering CONTINUE.
If the user enters CONTINUE,
NRT20 prints:
%Reconnecting to remote node ...
and unfreezes the inferiur prucess.
At that point,
the
user
is connected to the remote system and processing is resumed.
(Section F.6.3 contains an example of this situation.)

F.3

STNRT PROGRAM

The server task NRTSRV permits remote users to log in to the host on
which NRTSRV is running.
For security reasons, NRTSRV must not be run
from a logged in job.
If NRTSRV were run from a logged
in
job,
any
user could log in to NRTSRV with the same user name and privileges as
specified for the job under which NRTSRV is running without supplying
a
password.
The use of the program STNRT prevents such a potential
breach of system security.
STNRT creates a job with the following characteristics:
•

The job is not logged in.

•

The job has the file SYS:NRTSRV.EXE as its top-level process.

•

The job is not owned by the user running STNRT.

STNRT must be included in the PTYCON.ATO file to initialize the NRTSRV
program at system startup time.
(Inclusion of the STNRT job in the
PTYCON file is described in Section F.S
"Installation",
below.)
At
system
initialization
time,
STNRT
creates
a
job with
the
characteristics described above and also:
•

Starts the job.

•

Detaches the job.

•

Halts execution and returns to EXEC.

F-3

SAMPLE PROGRAMS FOR REMOTE LOGIN
F.4

NRTSRV PROGRAM

NRTSRV is a server task that allows users at remote terminals to log
in to the system on which NRTSRV is running.
The number of users that
may run concurrently under NRTSRV is set by using the MAXFRK parameter
in the NRTSRV.MAC source file.
NRTSRV implements remote logins by connecting to pseudo-terminals on
its local host. Therefore, the maximum number of users cannot exceed
the number of pseudo-terminals on the host on which NRTSRV is running.
Before setting the value of MAXFRK,
the user should take into
consideration other processes that require the use of PTYs,
such as
BATCH and PTYCON.
Other factors that affect the maximum number of
users of the remote login capability are the maximum number of forks
permitted by the remote system and the system manager's evaluation of
the demand for the remote login capability. The value of MAXFRK is
set to 7 on the distribution tape.
When NRTSRV receives a network connection, it opens a pseudo-terminal
(PTY). As NRT20 sends messages over the network connection to NRTSRV,
NRTSRV passes the messages to the PTY. Conversely, as NRTSRV's host
system sends messages to the PTY, NRTSRV passes the messages over the
network connection to NRT20.
The NRTSRV source listing provided in this appendix contains code that
implements the functions described immediately below.
The order in
which the functions are coded in the listing parallels the order
in
which the functions are presented in this description.

F.4.1

NRTSRV Initialization Routines

NRTSRV performs the following actions to create the proper environment
for executing its major functions:
•

Sets the private name of the program being run by the job
up by STNRT to NRTSRV.

•

Verifies that the DECnet server device SRV:
exists on the
system.
If SRV:
does not exist on the system, the job is
logged out.

•

Enables the system-permitted capabilities for the job.

•

Creates and starts n inferior processes, each of
copy of NRTSRV.

•

Disables the system-permitted capabilities for
process.

•

Sets up a routine to handle the abnormal
inferior process.

which
the

termination

set

top-level
of

any

The job capabilities are originally enabled for the top-level process
so that they may be passed on to the inferior processes. The NRTSRV
program ensures that no logins occur between the time that the
capabilites are enabled for the top-level process and the time that
they are disabled after having been passed on to the inferior
processes.
A login during that time could constitute a breach of
system security.

F-4

SAMPLE PROGRAMS FOR REMOTE LOGIN
There are two situations in which NRTSRV must guard against undesired
logins:
(1) during the time that the job capabilities are originally
passed on to the inferior processes and (2) during the time that a new
inferior process is created to replace an inferior process that
terminated abnormally.
In both cases, NRTSRV prohibits logins by
freezing the inferior processes until the job capabilties have been
passed on.
If you intend to modify the NRTSRV source for your system,
recommended that you preserve this "no login" feature.

F.4.2

outputs

NRTSRV Operations

NRTSRV accepts input from the terminals and transmits PTY
the manner described below:
•

Each inferior process performs the following actions:
Clears,
then sets up and
initializes the
software
interrupt system.
Removes any PTY or server JFN assignments.
Opens a DECnet server connection with the filespec
SRV:200 which specifies a DECnet generic server with
object type 200.
Assigns and enables software interrupt channels tor
connect event notification and data available events for
the server JFN.
Awaits a software interrupt signalling an
incoming
connection.
When the inferior process receives a connect request,
it
requests a PTY to be used to log in the remote terminal.
If a
PTY is not available, the inferior process sends the following
message to NRT20 to be printed at the user's terminal:
?No more PTYs on remote host
Processing is then restarted as described above for
inferior
processes.
If a PTY connection is available, the NRTSRV
inferior process does the following:
Issues a ~C to the PTY.
The system then issues its
standard banner message.
Accepts the connection from the network and sets up a
routine run at background level to read data from the PTY
and pass it down the network logical link to the NRT20
program.
When a network connection data available is signalled,
the inferior process reads the data and passes it to the
PTY

F-5

SAMPLE PROGRAMS FOR REMOTE LOGIN
Data processing continues until the link is broken. When the
link is broken, processing is restarted as described above for
inferior processes.
•

In the event of
process, NRTSRV

abnor~al

termination

inferior

Freezes all inferior processes.
Scans to identify the inferior process that terminated.
Kills the inferior process.
Creates and starts another inferior process.
Resumes all inferior processes.

F.S

INSTALLATION PROCEDURES

The programs required to implement the remote login capability are
included on the distribution tape as part of the release of TOPS-20
Version 4.
The following files are relevant:
STNRT.REL
STNRT.EXE
STNRT.LST
NRTSRV.MAC
NRTSRV.REL
NRTSRV.EXE
NRTSRV.LST

CMD.UNV
CMD.REL
NRT20.MAC
NRT20.REL
NRT20.EXE
NRT20.LST
NRT20.MAC

CMD.UNV and CMD.REL are associated with the NRT20
relevant only if modifications to the NRT20.MAC
contemplated.

files and are
source code are

Installation of the remote login capability involves two steps:
restoring the necessary executable files from the distribution tape
and modifying the PTYCON.ATO file on each host on which NRTSRV is to
run to automatically start NRTSRV at system initialization time.

F.S.l

Restoring Files from the Distribution Tape

Follow the steps below
distribution tape:

restore

the

required

files

wheel

from

the

operator

Connect to the directory in which your
installation's
unsupported software is maintained.
(The directory should be
in the system search list SYS:.) For example:
$connect ps:<unsupported>~
connects to the directory PS:<UNSUPPORTED> which contains the
system's
unsupported
software.
You
should
replace
PS:<UNSUPPORTED> with the name of the
directory
that
maintains your installation's unsupported software.

Mount the distribution tape and run DUMPER to restore the
following
executable files:
NRT20.EXE, NRTSRV.EXE,
and
STNRT.EXE.
Also,
you may optionally restore any other
supporting files that you want for your installation.

F-6

SAMPLE PROGRAMS FOR REMOTE LOGIN
Editing the PTYCON.ATO File

F.S.2

Prior to using the remote login capability, you must edit your
installation's PYTCON.ATO file which is processed at system start-up
time. Add a line to run the STNRT program at a convenient place in
one of the operator jobs running under PTYCON.
For example, the
following sequence shows the editing of a PTYCON.ATO file.
The
operator edits the file to insert the STNRT command immediately above
the PUSH command.
$type ptycon.ato~
SILENCE
LOG
DEFINE "'$OPR
CONN OPR
LOG OPERATOR FOO OPERATOR
ENA
!NEW OPERATOR INTERFACE PARSER
OPR
TAKE SYSTEM:NCP.CMD
TAKE SYSTEM:DN200.CMD
PUSH
ENA
"'ESET LOGIN ANY
"'ESEND * SYSTEM IN OPERATION
APPEND PS:<SPOOL)ORION-SYSTEM-LOG.002.* PS:<SPOOL)ORION-OLD.LOG
DELETE PS:<SPOOL)ORION-SYSTEM-LOG.002.*
POP
"'X

NO SILENCE
WALL
CONN OPR
$edit pytcon.ato~
Edit: PTYCON.ATO.l
*fPUSH$": *~
01100
PUSH
*i.-l~
01050
STNRT~
*eu~

[PTYCON.ATO.2]
$

F.6

USING THE REMOTE LOGIN CAPABILITY

Each time the system is brought up, the edited PTYCON.ATO file
runs
the STNRT program.
STNRT loads, starts, and then detaches the server
task NRTSRV which automatically sets up the
inferior processes that
wait for a connection request from a remote terminal.
Users at remote
terminals may then run NRT20 to access the host on which NRTSRV is
running.

F-7

SAMPLE PROGRAMS FOR REMOTE LOGIN
F.6.l

Logging in to a Remote Host Using NRT20

You invoke NRT20 by entering some form of the NRT20 command
in
response to the TOPS-20 prompt at your terminal.
NRT20 expects you to
specify the remote host's node-name and a special escape character to
be used to exit from NRT20.
If you do not specify a special escape
character, NRT20 uses ~y by default.
To specify the remote host's node-name and use ~y as
escape character, use the following NRT20 command format:

the

special

@NRT20 node-name~
NRT20 sets
message:

as the special escape character and prints the following

[Type

to return to node node-name]

where node-name is the name of the
terminal's local host.
If you
enter an invalid node name
(or if no physical connection exists),
NRT20 prints:
Connection broken.
remote node.

Reason:

and terminates processing.

39:

Network failure.

path

You are returned to EXEC command level.

To specify a different special escape
following NRT20 command formats:

character,

use

one

the

@R NRT20[RET)
or

@NRT20~

NRT20 then prompts for the special escape character:
Escape character

(~Y):

Press the control key and enter any ASCII character between A and Z
except for
the following system-recognized control characters:
~C,
~F, ~G, ~I, ~J, ~M, ~O, ~Q, ~R, ~S, ~T, ~U, and ~W.
In addition,
if
you have enabled any other control characters, they are also invalid
as the special escape character for NRT20.
If you enter a carriage
return, NRT20 uses ~Y as the special escape sequence.
If you did not enter a node name, as shown in the
lines above, NRT20 prompts you for one as follows:

two

NRT20

command

Host name:
Enter the remote host's node name.
If you enter a carriage return,
NRT20 reissues the prompt until you enter a valid node name or a ~C.
If you enter an invalid node name,
NRT20 responds
in the manner
previously described by printing an error message and terminating
processing.

F-8

SAMPLE PROGRAMS FOR REMOTE LOGIN
After a successful connection to the remote host,
NRT20 prints the
remote host's standard banner message on your terminal.
After the
banner message is printed, you may perform any function permitted by
the remote host.

F.6.2

Exiting from a Remote Host Using NRT20

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

the

interrupt

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

terminal

again

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.
If you do
not log
off
before
breaking
the
connection,
the
job will exist on the
remote system in a DETACHED state and
may require operator
intervention to
kill it.

F.6.3

Sample Terminal Sessions Using NRT20

Note that, when used within the context of the remote
login
capability,
~S,
and ~Q do not stop the scrolling of pages on the
user's terminal.
This occurs because NRT20 does not trap these
control characters and also because one cannot use the TERMINAL PAGE
command to set the printing mode of a PTY.

F-9

SAMPLE PROGRAMS FOR REMOTE LOGIN
Example 1.
The following example shows user KAMANITZ at a terminal on system
2102.
He first logs in to 2102, then uses NRT20 to connect to the
remote system 4097. By entering the remote system's node name on the
NRT20 command line,
KAMANITZ allows NRT20 to use Ay as the special
escape character.
He then logs in to system 4097 as user CRUGNOLA,
performs functions on system 4097, and logs off 4097. After logging
off of system 4097, he presses Ay to return to system 2102.
From
2102, he issues a LOGOUT command to log off system 2102.
2102 Development System, TOPS-20 Monitor 4(3117)
@LOGIN KAMANITZ password 341~
Job 16 on TTYI06 19-5ep-79 14:41:15
@NRT20 4097~
[Type Ay to return to node 2102]
4097 Load-Test System, TOPS-20 Monitor 4(3100)
@LOGIN CRUGNOLA password 341~
Job 12 on TTY50 19-5ep-79 14:41:27
.

(User performs functions on system 4097.)

@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 Ay here which is not echoed.)
[Connection broken, back at node 2102,
Type CONTINUE to resume connection]
@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

F-I0

SAMPLE PROGRAMS FOR REMOTE LOGIN
Example 2.
In the following example, user KAMANITZ logs in to system 2102. Then,
he uses NRT20 to connect to system 4097 and specifies ~B as the
special escape character. Once he is connected to 4097, he logs on as
user CRUGNOLA and begins listing his directory. While system 4097 is
printing information about his directory, he presses ~B to gain the
attention of NRT20 on system 2102. From 2102, he enters CONTINUE in
response to the EXEC prompt and NRT20 reconnects to system 4097.
System 4097 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
4097.) User KAMANITZ then logs off system 4097, returns to system
2102, and logs off system 2102.
2102 Development System, TOPS-20 Monitor 4(3117}
@LOGIN KAMANITZ password 341~
Job 62 on TTY106 19-5ep-79 14:50:59
@I'a, T 2 0 (KlI)

Escape character (~Y) :~TRL~)
Host name:4097~
4097 Load-Test System, TOPS-20 Monitor 4(3100}
@LOGIN CRUGNOLA password 341~
JOB 13 ON TTY50 19-5ep-79 14:53:09
@vnT R (R"fT)

PS:<CRUGNOLA>
CALEND.EXE.1iP777700
5 (User enters CTRL/B. It does not
echo. }
[Connection broken, back at node 2102,
Type CONTINUE to resume connection]
@CONTINUE~

Reconnecting to node •••
10-6-AUG-79 15:51:41
LA36.CMD.1iP777700
LOGIN.CMD.2iP777700
MAIL.TXT.1iP770404
SWITCH.INIi 2 i P7 7 7700

VT50.CMDi1iP777700
VT52.CMD.1iP777700
ZIP.Q;1;P777700

1 74 (7)
1 21(7)
1 175(7}
1 39(7}
1 28(7}
160(7}
1 45(7}

13-MAR-78
13-MAR-78
26-JUL-79
18-MAY-78
13-MAR-78
13-MAR-78
14-JUN-78

15:39:48
15:36:23
13:01:46
15:33:10
15:37:44
15:38:49
17:06:25

TOTAL OF 13 PAGES IN 9 FILES
@LOGO~

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 CTRL/B.

It does not echo.)

[Connection broken, back at node 2102,
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

F-11

SAMPLE PROGRAMS FOR REMOTE LOGIN
Example 3.
This example shows the use of NRT20 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
2102

HOST
4097

HOST
2137

User CRUGNOLA on host 4097 wants to log in to host 2137. To do so, he
first logs in to host 4097.
Then, he uses NRT20 to establish a
network connection to host 2102 using the default special escape
character.
Once the connection to host 2102 is established, user
CRUGNOLA logs in to host 2102 as user KAMANITZ.
From host 2102,
KAMANITZ uses NRT20 to establish a network connection to host 2137,
specifying AB as the special escape character.
Note that a different special escape character must be used for
the
connection between hosts 2102 and 2137.
If the same special escape
character were used for both network connections, NRT20 on 4097 would
trap the special escape character and return control of the user's
terminal to host 4097. This would interrupt the connection between
hosts 4097 and 2102. Once this occurred, no means would exist to gain
access to host 2102 on the existing connection.

F-12

SAMPLE PROGRAMS FOR REMOTE LOGIN
After the network connection is established between hosts 2102 and
2137, user KAMANITZ logs in to host 2137 as user OSMAN. OSMAN
performs some functions on host 2137, then logs off and enters AB to
return to host 2102. Once at host 2102, user KAMANITZ logs off and
enters Ay to return to host 4097. Once there, user CRUGNOLA logs off.
4097 Load-Test System, TOPS-20 Monitor 4(3100)
@LOG CRUGNOLA password 341~
Job 7 on TTY33 25-Sep-79 10:18:05
@NRT20 2102~
[TYPE Ay TO RETURN TO NODE 4097]
2102 Development System, TOPS-20 Monitor 4(3117)
LOG KAMANITZ password 341~
Job 42 on TTY217 25-Sep-79 10:19:17
@NRT20~

Escape character (Ay) :«TRl/0
Host name:2137~
Gus - The Languages System (2137), TOPS-20 Monitor 4(3046)
@LOG OSMAN password~
Job 20 on TTY214 25-Sep-79 10:20:58
(User performs functions on host 2137)
@LOGO(~tiJ

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 CTRL/B.

It does not echo.)

[Connection broken, back at node 2102,
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 CTRL/Y. It does not echo.)
[Connection broken, back at node 4097,
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

F-13

SAMPLE PROGRAMS FOR REMOTE LOGIN

TITLE

NRT20 - Program to permit logins to remote network host

iCOPYRIGHT (C) 1979 BY
iDIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS.

,
iTHIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED
iONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE
iINCLUSION OF THE ABOVE COPYRIGHT NOTICE.
THIS SOFTWARE OR ANY OTHER
iCOPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY
iOTHER PERSON.
NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY
iTRANSFERRED.

,
iTHE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE
iAND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIP~ENT
iCORPORATION.
iDIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY
iSOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.

ITS

SALL
i Keep listing uncluttered, no macro expansion
SEARCH MONSYM,MACSYM,CMD i Universals to search
.REQUIRE SYS:MACREL,SYS:CMD i Make LINK load these automatically
SUBTTL

DECLARED SYMBOLS

Tl==l
T2==2
T3==3
T4==4
CX==16
P==17

AC definitions

NPDL==20
INSIZ==50
MAXINP==INSIZ*5
DBUFFR==lOOOOO

Size of pushdown list
Terminal input buffer size, in words
Maximum number of terminal input characters
Data buffer on page 100

F-14

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

IMPURE STORAGE

BLOCK 1
BLOCK 2
BLOCK 1
BLOCK INSIZ
BLOCK 4
BLOCK 10
BLOCK 1
EXP -1
BLOCK 3
PC
PC+l
PC+2
CHNTAB: 0
1"ESC
0
BLOCK NPDL
PDL:

Terminal interrupt word mask for STIW
Local node name
JFN of logical link to NRTSRV server
Terminal input stream buffer
Register save area for AC's 1 - 4
File spec name of logical link to NRTSRV
Handle of inferior process to read from TTY
Flag to indicate fresh start, initially -1.
Storage for PC on interrupts
Software interrupt level table

CMDSTG

Command parser storage

STIMSK:
LOCAL:
DCNJFN:
INSTR:
SAVACE:
NAI1E:
FORK:
VIRGIN:
PC:
LEVTAB:

Software interrupt channel table
Panic character (default ~Y)
Pushdown list (STACK)

F-15

(from CMDS)

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL
START:

START

Start of NRT20 program

RESET
Intialize ourself
MOVE P, [IOWD NPDL,PDL]
and set up pushdown list
AOS VIRGIN
Bump count of times we corne through here
CALL CMDINI
Initialize command parser
MOVX TI,CR%MAP
Create process to read from TTY
SETZM T2
CFORK
Make the process, same address map
JRST [ JSHLT
; on error .•• halt and allow continue
JRST START]
MOVEM TI,FORK
Save the process handle obtained
MOVEI TI,.FHSLF
Our process handle
RPCAP
Get our capabilities
TXO T3,SC%CTC
allow -C trapping for job
EPCAP
; Enable new set of capabilities
MOVE T2, [LEVTAB"CHNTAB] ; Address of software interrupt system tables
SIR
Give them to monitor
MOVX T2,lBI
Channel number
AIC
Activate software interrupt channels
EIR
Enable software interrupt system
CALL ALLaN
Turn on all TTY interrupts
CALL PRESCN
Prescan EXEC line for host name ...
JRST PREHST
Got it - skip the prompting
JRST ESCHAR
Otherwise get it now

F-16

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

ESCHAR - Obtain the escape character user wants to use

ESCHAR: PROMPT <Escape character (-Y) : > ; Put out prompt to users terminal
:-lOVEI TI, [FLDDB. (.CMTXT,CM%SDH,,<Character for interrupting connection>,<-Y»]
CALL CFIELD
; Read the escape character
LDB TI, [POINT 7,AT1-1BUF,6] ; Get character itself
CAlLE TI,.TICCZ
; Is it a valid character? (-A to -Z)
JRST [ HRROI TI, [ASCIZ /Invalid character/] ; No, tell user
ESOUT
JRST ESCHAR]
and try again
MOVNI T2,O(TIJ
Save the character
HRLS Tl
Character value is terminal code
HRRI TI,1
Channel number
Assign terminal code to software interrupt channel
ATI
MOVX TI,IBO
Get a bit
Make terminal interrupt word mask for character
LSH TI, 0 (T2)
TXO TI,IB<.TICTI>
Allow typein
Save for use later
MOVEM TI,STIMSK
JRST HSTNAM
Get the host name

F-17

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

HSTNAM - Get the host name user wants to login on

HSTNAM: PROMPT <Host name: >
; Put out prompt to users terminal
PREHST: MOVEI TI, [FLDDB. (.CMTXT,CM%SDH,,<Name of system to connect to»]
CALL CFIELD
Read host name
HRROI TI,INSTR
Pointer to destination buffer
HRROI T2,ATMBUF
Pointer to source buffer
MOVEI T3,O
An ASCIZ string
SOUT
Copy the host name
MOVX TI,177B6
See if real host name given
TDNN TI,INSTR
, Was one?
JRST [ HRROI TI, [ASCIZ /
[CONNECTING TO LOCAL HOST- /]
No, tell user what's happening
PSOUT
MOVEI TI,.NDGLN
Function code to get local node name
MOVEI T2,T3
HRROI T3,INSTR
NODE
Obtain local node name
HRROI TI,INSTR
PSOUT
Output to user's TTY
HRROI TI, [ASCIZ /]

/]
PSOUT
JRST .+1]
JRST SETTMD

;

Finish the message nicely

Have name. Now set TTY modes

F-18

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

SETTMD - Set TTY modes

SETTMD: MOVEI TI,.PRIIN
Primary input
RFMOD
Get current JFN mode word
TXO T2,TT%WAK
Wake on all
TXZ T2,TT%ECO!TT%DAM
Echoes off and binary data mode
SFMOD
Set new JFN mode word
MOVX TI,.FHJOB
Set terminal interrupt word for entire job
MOVE T2,STIMSK
Get terminal interrupt word saved earlier
STIW
Set it to allow only panic interrupts
HRROI TI,NAME
Build network file spec to NRTSRV
The DECnet device for making connection
HRROI T2, [ASCIZ /DCN:/]
SETZM T3
SOUT
The node name to connect to
HRROI T2,INSTR
SOUT
NRTSRV's object type
HRROI T2, [ASCIZ /-200/]
SOUT
MOVX TI,GJ%SHT
Do a short form GTJFN
HRROI T2,NAME
Using the spec just built
GTJFN
Get DCN connection
JRST
JSERR
If error, tell user
CALL ALLON
Reset TTY to normal mode
JRST HSTNAM]
And go back to get host name
MOVEM Tl,DCNJFN
Save JFN for the connection
MOVEI TI,.PRIOU
Check if parity OK on this TTY
GDSTS
Get device status
ERJMP [SETZM T2
If error, set all status off
JRST .+1)
; And continue along
MOVE TI,DCNJFN
Restore the JFN for network connection
TXNE T2,GD%PAR
; Does terminal allow parity?
SKIPA T2, [FLD(-D8,Of%BS2) !Ot~HD!Of%WRJ ; Yes, 8 bit bytes and read/write access
MOVE T2, [FLD(-D7,OF%BSZ) !OF%RD!OF%WR] ; No, then 7 bit bytes and read/write access
OPENF
Oppn the network connection
JRST [ JSERR
If failed, tell user
MOVE Tl,DCNJFN
; And release the JFN
RLJFN
JFCL
CALL ALLON
Reset TTY to normal mode
JRST HSTNAM]
And go back to get host name
MOVE Tl,FORK
Restore the process handle obtained
MOVEI T2,DOINPO
The start address
SFORK
Start the process to read input from TTY
ERJMP [RESET
If failed, reset ourself
JSHLT
; Tell user and halt
JRST START]
; Go back to beginning if continued
JRST GOTDAI
Connection now opened. Wait for input

F-19

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

GOTDAI - Read data from network connection

GOTDAl: MOVE Tl,DCNJFN
; Get the network connection JFN
MOVE T2, [POINT D8 ,DBUFFR] ; Pointer to buffer
MOVNI T3,1
One byte only
SIN
Read from logical link
ERJMP BADCON
; If error, connection broken
MOVE T3,T2
Save byte pointer
SIBE
Any more data to read now ?
SKIPA
; Yes, read the rest
JRST [ SETZM T4
No, then go type what there is to user
JRST GOTDAX]
EXCH T2,T3
Restore byte pointer
MOVE T4,T3
Save count
MOVNS T3
Read the exact number available
SIN
Read remaining bytes
ERJMP BADCON
; If error, connection broken
A

GOTDAX: MOVEI TI,.PRIOU
; Output to users terminal
MOVE T2, [POINT D8 ,DBUFFR] ; Pointer to data from remote host
MOVNI T3,I(T4)
Output count
SOUT
Type data on users terminal
JRST GOTDAI
And continue
A

F-20

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL
ALLON:

ALLON - Restore echoing and interrupts on terminal

MOVX TI,.FHJOB
SETml T2
STIW
MOVEI TI,.PRIIN
RFMOD
TXO T2,TT%ECO!TT%DAM
SFMOD
RET

Set terminal interrupt word for entire job
Terminal interrupt word mask for all codes
Set terminal interrupt word
Primary input
Read JFN mode word
Echo on, ASCII data mode, output translation disabled
Set new JFN mode word
Done, return to caller

F-21

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

PRESCN -

Prescan EXEC command for host name

PRESCN: SKIPE
VIRGIN
Starting out fresh?
RETSKP
No ... , so return +2 to force prompt
Tl,.RSINI
MOVEI
Make rescan buffer available
RSCAN
as command line to process reading from CTTY
ERJMP PRESCl
MOVX
Tl,.RSCNT
Get count of characters
RSCAN
in rescan buffer
ERJMP PRESCl
JUMPE
Tl, [RETSKP]
None there, so must prompt
MOVEI
Tl,.PRIIN
Primary input
BIN
Read a character
CAIE
T2,"R"
RUN or R (program name can't start with "R")
CAIN
T2,"r"
Check lowercase also
JRST PRESCO
Yes, no prescanning, go eat rest of line
CAIE
PRES 1:
T2," "
Have we hit a space yet?
CAIN
T2, "
Also accept a tab
PRES2
JRST
Yes, read the node name
CAIN
T2, .CHLFD
Have we hit EOL yet?
RETSKP
Yes, no node name, skip return to prompt
BIN
Read the next character
JRST
PRESl
And loop to test
Default to Ay for interrupt character
PRES 2:
MOVSI
Tl, .TICCY
HRRI
Tl,l
And use channel one
ATI
Assign terminal code to interrupt channel
MOVX
Tl,lBO
Get a hi order bit
Tl,-.TICCY
Shift bit by value of Ay code
LSH
TXO
Tl,lB<.TICTI>
Allow typein
MOVEM
Tl,STIMSK
: Save for use later
<[Type Ay to return to node> : Tell user how to get back
TMSG
MOVX Tl, . NDGLN
MOVX T2,T3
MOVE T3, [POINT 7,LOCAL]
NODE
And name of local node
JFCL
HRROI Tl,LOCAL
PSOUT
TMSG
<]
Finish off nicely
>
PROMPT <>
Null prompt
RET
Done, return no skip to not prompt
:HERE TO FLUSH REST OF EXEC COMMAND LINE
PRESCO: Blt:J
CAIE T2,.CHLFD
JRST PRESCO
RETSKP

Get next byte
The end of line?
No, Try again
Yes, return +2 to prompt for node

: Here if rescan attempt does not succeed
PRESC1: HRROI Tl, [ASCIZ/Unexpected error in scanning command line/]; If error,
ESOUT
tell user
HALTF
and halt
JRST START
Start over if continued •••

F-22

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL BADCON - Handle a broken network connection
BADCON: CIS
CALL ALLON
MOVE TI,FORK
KFORK
HRROI TI, [ASCIZ /
?Connection broken. Reason: /]
PSOUT
MOVE TI,DCNJFN
MOVEI T2,. MORLS
MTOPR
HRRZ T2,T3
MOVEI TI,.PRIOU
MOVEI T3,12
NOUT
JFCL
CAIG T2,MAXMSG
SKIPN TI,MSGTBL(T2)
SKIPA
PSOUT
HRROI TI, [ASCIZ /

Prevent further interruption
Restore TTY modes
Restore the process handle
Kill the terminal input process
Tell user bad news
Restore network connection JFN
Get current link status
Get DECnet error reason code
Output to users terminal
In decimal
Type it
Know about this error?
Yes, have one to type?
No
Yes, type it then

/]
PSOUT
MOVE TI,DCNJFN
TXO TI,CZ%ABT
CLOSF
HALTF
JRST START

Pretty it
Get the JFN for the link
Abort any operations
Close it
Halt here
And start at beginning if continued

F-23

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

ESC - Handle input of panic escape character from terminal

DMOVEM Tl,SAVACE
Save AC's we're going to use
DMOVEM T3,SAVACE+2
MOVE Tl,FORK
Restore process handle
FFORK
Freeze the terminal input process
MOVEI Tl,.PRIOU
Users terminal
RFMOD
Get current TTY modes
PUSH P,T2
Save them
TXO T2,TT%DAM
ASCII data mode, output translation disabled
SFMOD
Set new JFN mode word
CFOBF
Flush any pending terminal output
HRROI Tl, [ASCIZ I
[Connection broken, back at node I] ~ Tell user he's now talking to us
PSOUT
r-lOVX Tl, .NDGLN
MOVX T2,T3
MOVE T3, [POINT 7,LOCAL]
NODE
Get our node name
JFCL
HRROI Tl, LOCAL
PSOUT
~ Type node name to user
HRROI T 1, [ASC I ZI ,
Type CONTINUE to resume connection}
Let him know how to restart
I]
PSOUT
HALTF
Halt here until continued
HRROI Tl, [ASCIZ/%Reconnecting to remote node ...
I]
Let user know we are restarting
PSOUT
MOVEI Tl,.PRIOU
Users terminal
POP P,T2
Desired TTY modes
SFMOD
Set new JFN mode word
MOVE Tl, FORK
Restore process handle
RFORK
Resume the terminal input process
DMOVE Tl,SAVACE
Restore the AC's
DMOVE T3,SAVACE+2
DEBRK
And finish interrupt processing

ESC:

F-24

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

DOINPO - Read terminal input and send to remote host

DOINPO: MOVEI T4,MAXINP
MOVE T3, [POINT 7,INSTR]
MOVEI TI,.PRIIN
BIN
JRST DOINO

Maximum input characters
Where they are going
Primary input
Wait for a byte
Got one, go handle it .••

DOINP:

Any bytes?
Yes
No
Get another byte
Stash it in input stream buffer
Do it all
Maximum characters
Compute number to send
If none, go wait
The network JFN
Pointer to input stream buffer
Send this buffer to remote NRTSRV
And continue

DOINO:
EMPTY:

SIBE
SKIPA
JRST EMPTY
BIN
IDPB T2,T3
SOJG T4,DOINP
MOVNI T3,MAXINP
ADD T3,T4
JUMPE T3,DOINPO
MOVE TI,DCNJFN
HRROI T2,INSTR
SOUTR
JRST DOINPO

F-25

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL MSGTBL - Table of DECnet disconnect/abort reason text
MSGTBL:

o
-1"

[ASCIZ /: Destination node does not exist/]

-1"

[ASCIZ /: Destination process does not exist/]

o
o
o

-1" [ASCIZ
BLOCK ~D22
-1" [ASCIZ
-1" [ASCIZ
BLOCK 4
-1" [ASCIZ
-1" [ASCIZ
MAXMSG==.-MSGTBL-l

/: Connection aborted by remote node/]
/: No more NRTs at remote node/]
/: No more NRTs at remote node/]
/: Remote process aborted link/]
/: Network failure. No path to remote node/]

END START

F-26

SAMPLE PROGRAMS FOR REMOTE LOGIN

TITLE

NRTSRV - Program to provide remote network login service

;COPYRIGHT (C) 1979 BY
;DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS.
;THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED
;ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE
;INCLUSION OF THE ABOVE COPYRIGHT NOTICE.
THIS SOFTWARE OR ANY OTHER
;COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY
;OTHER PERSON.
NO TITLE TO AND OWNERSHIP OF THE SOFTWARE
IS HEREBY
;TRANSFERRED.
;THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE
;AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT
;CORPORATION.
;DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY
;SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.
SALL
SEARCH
• RRQrTTRR

SUBTTL

MONSYM,MACSYM
SVS! MACRRT.

ITS

Keep listing uncluttered, no macro expansion
Universals to search
Make LINK load these automatically

DECLARED SYMBOLS

Tl==l
T2==2
T3==3
T4==4
CX==16
P==17

AC definitions

MAXFRK==7
SRVOSZ==50
MAXOUT==SRVOSZ*4
SRVSIZ==lO
NPDL==40

Maximum number of server sub processes
Output buffer size in words
Maximum number of output characters
Size of server buffer in words
Size of pushdown list

F-27

SAMPLE PROGRAMS FOR REMOTE LOGIN

IMPURE STORAGE

SUBTTL
SAVAC:
OEVNAM:
PTYJFN:
TTYJFN:
SRVJFN:
SRVINP:
OUTPUT:
OUCNT:
PC:
SRVOUP:
FORKS:
HSTNAM:
POL:

BLOCK
BLOCK
BLOCK
BLOCK
BLOCK
BLOCK
BLOCK
BLOCK
BLOCK
BLOCK
BLOCK
BLOCK
BLOCK

4
2
1
1
1

SRVSIZ
1
1
1
SRVOSZ
MAXFRK
2
NPOL

RELOC 1000-140
LEVTAB: PC
CHNTAB: 1"GOTCI
1, ,GOTDAT

AC save area
For building PTY names
The JFN of the PTY
TTY designator
The JFN of the network connection
Holds input characters
Output buffer pointer
The software interrupt PC save area
Holds output data
Save process IO's here
Host name string
Pushdown list (stack)
Start on page boundary
Where to stash the PC
Network connect received interrupt routine
Network data available interrupt routine

F-28

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

BEGIN - Start of NRTSRV program

RESET
Initialize ourselves
MOVE TI, [SIXBIT /NRTSRV/] ; Our name in SIXBIT
SETNM
Set jobs private name
See if network exists
HRROI TI, [ASCIZ /SRV/]
By checking for SRV device
STDEV
JRST
SETOM TI
Doesn't exist, so go away
LGOUT
By logging out this job
JFCL
Should always work, but ...
HALTF]
Either way, go away
MOVEI TI,.FHSLF
This process
RPCAP
Get our capabilities
MOVE T3,T2
Copy them
EPCAP
Enable all capabilities we have
MOVSI T4,-NAXFRK
Maximum processes to create
MOVX TI,CR%CAP
Give them the same capabilities we have
FRKDO:
SETZM T2
No AC's
CFORK
Create a process
ERJMP WTFRK
; If no more, done
MOVEM TI,FORKS(T4)
Save process handle
HRLZ T2,TI
Process handle of destination
Start at page I in destination process
HRRI T2,1
Map this process to it
MOVE TI, [ . FHSLF, , I]
MOVEI T3,ENDPRG-l
Last address in use
LSH T3,-11
Make a repetition count
TXO T3,PM%CNT!PM%RD!PM%WR ; Make PMAP argument
Map the process' address space
PMAP
HLRZ TI,T2
Get process handle
MOVEI T2, START
Start address
Start the process up
SFORK
Do all of them
FRKLOP: AOBJN T4,FRKDO
MOVEI TI,.FHSLF
Our process
WTFRK:
SETZM T3
No capabilities
EPCAP
Disable all capabilities
MOVEI TI,.FHINF
All the inferior processes
RFORK
Resume them
WFORK
Wait for any inferior to halt

BEGIN:

F-29

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

RSPROC - Restart inferior process after it halted

RSPROC: MOVEI Tl,.FHINF
FFORK
MOVSI T4,-MAXFRK
DEDLOP: SKIPN Tl,FORKS(T4)
JRST DEDLOI
RFSTS
LOAD Tl,RF%STS,Tl
CAIE Tl,.RFHLT
CAIN Tl~.RFFPT
;
JRST [ MOVE Tl,FORKS(T4)
SETZM FORKS (T4)
KFORK
HRRZS T4
MOVEI Tl,.FHSLF
RPCAP
MOVE T3,T2
EPCAP
JRST FRKDO]
DEDLOl: AOBJN T4,DEDLOP
JRST WTFRK

All the inferior processes
Freeze them
Scan process table
This one exist?
No, go on
Yes, get its status
Get its status
Halted?
Or error?
Yes, get process handle again
Clear entry
Kill the process
Create one more process
Our process
Get our capabilities
Copy them
Enable all capabilities we have
Go back and create another process
Look at them all
Wait some more

F-30

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

START - Start of code for inferior process'

START:

CIS
Clear interrupt system
SKIPN TI,SRVJFN
Have a server JFN yet?
JRST START I
No ..•
TXO TI,CZ%ABT
Yes, abort it
CLOSF
Close and abort the network connection
JFCL
; Ignore errors
SETZM SRVJFN
Clear the server JFN
STARTI: SKIPN TI,PTYJFN
Have a PTY yet?
JRST START2
No •••
TXO TI,CZ%ABT
Yes, abort it
CLOSF
Close the PTY
JFCL
; Ignore errors
START2: MOVE P,[IOWD NPDL,PDL]
Initialize the stack pointer
MOVEl TI,.FHSLF
; Our process
MOVE T2, [LEVTAB"CHNTAB] ; Address of level and channel table
SIR
; Set software interrupt table addresses
MOVX T2~3BI
; Channel 0 and 1
AIC
; Activate software interrupt channels
EIR
; Enable software interrupt system
MOVE TI, [POINT ADS, SRVOUP] ; Initial output pointer
MOVEM Tl,OUTPUT
Initialize the pointer
MOVEI Tl,MAXOUT
Maximum output characters
MOVEM TI,OUCNT
Initialize the output count
MOVEl TI,.FHSLF
Our process
RPCAP
Get our capabilities
MOVE T3,T2
Copy them
EPCAP
Enable all capabilities we have
MOVX Tl,GJ%SHT
; Short form GTJFN
HRROI T2,{ASCIZ /SRV:200/] ; The NRT server file spec
GTJFN
Get a JFN for it
JRST TRYAGN
; Failed, go try to recover
MOVEM TI,SRVJFN
; Save the server JFN
MOVX T2,<FLD(A D8 ,OF%BSZ)!OF%RD!OF%WR> ; 8 bit bytes, read/write access
OPENF
; Open the server JFN
JRST [ MOVE Tl,SRVJFN
Failed, get server JFN
Release the JFN
RLJFN
JFCL
Ignore errors
SETZM SRVJFN
Clear the server JFN
And go try to recover
JRST TRYAGN]
MOVEI TI,.FHSLF
Our process
SETZB T2,T3
No capabilities
EPCAP
Disable all capabilities
MOVE TI,SRVJFN
Get the server JFN
MOVEI T2,.MOACN
; Assign interrupt system channel numbers
MOVX T3,<FLD{O,MO%CDN) !FLD(l,MO%DAV) !FLD(~MOCIA,MO%INA»
Connect event on 0,
Data available on I
MTOPR
Perform the device operation
WAIT
Wait for something to happen

F-31

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

TRYAGN - Wait before trying to become a server again

TRYAGN: MOVX Tl,~D<lOOO*60*2>
DISMS
JRST START

Two minutes in milliseconds
Dismiss the process until time expires
And go back to try again

F-32

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

GOTCI - Got a connect from the network

Get a PTY to use
CALL GETPTY
Failed, clear the software interrupt system
JRST [ CIS
HRROI Tl, [ASCIZ I
?No more PTYs on remote host
Point to message to tell what happened
IJ
Get the server JFN
MOVE T2,SRVJFN
All of the string
SETZM T3
Send message on network link
SOUTR
Ignore errors
ERJMP . +1
Get the server JFN
MOVE Tl,SRVJFN
Close the network connection
CLOSF
; Failed, go back to recover
JRST START
Clear the server JFN
SETZM SRVJFN
Go back to recover
JRST STARTJ
Save the PTY JFN
MOVEM Tl,PTYJFN
MOVEM T2,TTYJFN
Save the TTY designator
Get a Control-C (AC)
MOVEI T2,"C"-lOO
Output it to PTY to start up job
BOUT
Get the server JFN
MOVE Tl,SRVJFN
Confirm the network connection
MOVEI T2,. MOCC
SETZB T3,T4
No optional data
Do the device operation
MTOPR
; If error, link broken, start again
ERJMP START
Address of PTY input routine
MOVEI Tl,PTYIN
Change the interrupt PC value to start
MOVEM Tl,PC
GJINF
Get current job information
JUMPL 'l'4,lJUNCI
If terminal attached to job, done
HRROI Tl, [ASCIZ I
Point to message to say who's connecting
NRTSRV- CONNECTION FROM I]
Output to TTY
PSOUT
Clear host name buffer
SETZM HSTNAM
MOVE Tl,SRVJFN
Get the server JFN
MOVEI T2,.MORHN
Read network host name
HRROI T3,HSTNAM
Pointer to buffer
MTOPR
Do the device operation
; Ignore errors
ERJMP .+1
HRROI Tl,HSTNAM
Pointer to host name buffer
Output the host name to TTY
PSOUT
Pointer to continuation of message text
HRROI Tl, [ASCIZ I ON IJ
PSOUT
Output to TTY
TTY designator
MOVEI Tl,.PRIOU
MOVE T2,PTYJFN
Get the PTY JFN
Full file specification format
SETZM T3
Output file spec associated with PTY JFN
JFNS
HRROI Tl, [ASCIZ I
GOTCI:

IJ
DONCI:

PSOUT
DEBRK

End the message nicely
Dismiss interrupt and resume processing PTY input

F-33

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

GOTDAT - Got data available from network connection

GOTDAT: DMOVEM Tl,SAVAC
DMOVEM T3,SAVAC+2
GOTDAl: MOVE Tl,SRVJFN
MOVEI T2,. MORLS
MTOPR
TXNN T3,MO%CON
JRST START
SIBE
SKIPA
JRST [ DMOVE Tl,SAVAC
DMOVE T3,SAVAC+2
DEBRK]
CAlLE T2,SRVSIZ*S
MOVEI T2,SRVSIZ*S
MOVN T3,T2
MOVE T4,T3
HRROI T2, SRVINP
SIN
ERJMP START
SUB T4,T3
MOVE T3,T4
MOVE Tl,PTYJFN
HRROI T2, SRVINP
SOUT
JRST GOTDAl

Save AC's
Get the server JFN
Read link's status
Do the device operation
Connected?
No, go start over
Skip if input buffer empty
Not empty, have some data
Empty, no data, restore AC's
, Dismiss interrupt and resume processing
Buffer larger than number of bytes available?
No, get maximum buffer full
Get byte count
Save it
Pointer to server input buffer
Read from network link
; Failed, link broken, start again
Calculate number of bytes read
Get byte count
Get PTY JFN
Pointer to server input buffer
Output data to PTY
And go back to do more

F-34

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUSTTL

PTYIN - Pseudo TTY input routine

PTYIN:

MOVE TI,PTYJFN
Get PTY JFN
SIN
Input a byte from PTY
IDPS T2,OUTPUT
Store byte in output buffer and save pointer
SOSG OUCNT
Output buffer full?
JRST PTYINI
Yes, write it then
MOVE TI,TTYJFN
Get TTY desionator
SOSE
Skip if TTY output buffer empty
JRST PTYIN
: Not empty, go get more characters from PTY
PTYINI: MOVNI T3,MAXOUT
Get negative maximum output count
ADD T3,OOCNT
Compute number of bytes in buffer
MOVE TI,SRVJFN
: Get the server JFN
MOVE T2, [POINT ~D8,SRVOUP] : Get pointer to output buffer
SOUTR
: Output data to network link
ERJMP START
; Failed, link died, start over
MOVE TI, [POINT ~D8,SRVOUP] : Get pointer to output buffer
MOVEM TI,OUTPUT
Reinitialize output buffer pointer
MOVEI T2,MAXOUT
Get maximum output count
MOVEM T2,OUCNT
Reinitialize output count
JRST PTYIN
Go back and get more characters from PTY

F-35

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL

GETPTY - Get a pseudo TTY designator and return opened PTY JFN

GETPTY: STKVAR <SAVCHR>
Get stack variable storage
MOVE TI, [SIXBIT /PTYPAR/] ; Pseudo TTY parameter table name
SYSGT
Get system table information for PTY
HRRZM TI,SAVCHR
Save TTY number of first pseudo TTY
HLRZ T4,TI
Get number of PTY's
l"10VNS T4
Get negative of count
HRLZS T4
Make an index loop pointer
GETPTI: MOVSI TI,.DVDES+.DVPTY
Get device designator for PTY
HRR TI,T4
Get PTY number
DVCHR
Get device characteristics of PTY
TXNN T2,IB5
Available?
JRST GETPT2
No, try next PTY then
MOVE T2,TI
Get device designator
HRROI TI,DEVNAM
Pointer to device name string buffer
DEVST
Translate device designator to string
JRST GETPT2
; Failed, try next PTY
MOVEI T2,":"
Get device string terminator character
IDPB T2,TI
Store it after device name string
SETZM T2
Get a null byte
IDPB T2,TI
Make device name string ASCIZ
MOVX TI,GJ%SHT
Short form GTJFN
HRROI T2,DEVNAM
Get pointer to PTY name string
GTJFN
Get a JFN for PTY
JRST GETPT2
; Failed, try next PTY
MOVE T3,TI
; Save the PTY JFN
MOVX T2,<FLD(~D8,OF%BSZ) !OF%RD!OF%WR> ; 8 bit bytes, read/write access
OPENF
; Open the PTY
JRST [ MOVE TI,T3
Failed, get PTY JFN
RLJFN
Release the PTY JFN
JFCL
Ignore errors
JRST GETPT2]
And try next PTY
MOVEI T2,.TTDES(T4)
Get PTY index
ADD T2,SAVCHR
Get PTY designator
RETSKP
Done, return skip for success
; Step through all PTY's
GETPT2: AOBJN T4,GETPTI
RET

Increment PTY number and go back if more to do
No, give up, return no skip for failure

ENDPRG:

End of code
END BEGIN

F-36

SAMPLE PROGRAMS FOR REMOTE LOGIN

TITLE

STNRT -

Program to create NRTSRV as a not logged in job

iCOPYRIGHT (C) 1979 BY
iDIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS.

,
;THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED
IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE
iINCLUSION OF THE ABOVE COPYRIGHT NOTICE.
THIS SOFTWARE OR ANY OTHER
iCOPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY
iOTHER PERSON.
NO TITLE TO AND OWNERSHIP OF THE SOFTWARE
IS HEREBY
iTRANSFERRED.

iONLY

,
iTHE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE
SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT
;CORPORATION.

iAND

,
iDIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY
iSOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.
SALL
SEARCH MONSYM,MACSYM
.REQUIRE SYS:MACREL
SUBTTL

ITS

Keep listing uncluttered, no macro expansion
Universals to search
Make LINK load these automatically

DECLARED SYMBOLb

Tl==l
T2==2
P==17

AC definitions

NPDL==lO

Size of pushdown list

F-37

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL
PDL:
CRJBLK:

IMPURE STORAGE

BLOCK NPDL

Pushdown list (stack)

Argument block for CRJOB JSYS
No user name strinq
No password stringo
; No account string
o
-1, , [ASCIZ /SYS:NRTSRV.EXE/] ; Pointer to file name to be placed in job
Entry vector offset
o
377777
Controlling terminal designator is null device
o
(Reserved)
o
Address of AC block
o
Command language processor flags
o
Primary I/O designators for inferior processes
CPU runtime limit (0 = no limit)
o
o
Capability mask for job
IPCF PID for logout message
o

F-38

SAMPLE PROGRAMS FOR REMOTE LOGIN

SUBTTL
START:

START - Start of program

RESET
; Initialize ourself
MOVE P, [IOWD NPDL,PDL]
; Initialize PDL pointer
MOVX Tl,CJ%FIL!CJ%NPW!CJ%CAP ; CRJOB flags
MOVEI T2,CRJBLK
Address of argument block
CRJOB
Create the job
JSHLT
; Failed
HALTF
Made it
END START

F-39

APPENDIX G
TKB20 AND VNP20 WARNING AND ERROR MESSAGES

This appendix contains a list of messages that may be directed to the
user's I/O device by TKB20 and/or VNP20. The messages are separated
into two groups: warning messages and fatal error messages.
Within
each group, the messages are listed in alphabetical order.
Each warning message is preceded by a percent sign
(%).
TKB20 or
VNP20 issues a warning message to indicate a possible problem.
Processing continues; however, subsequent processing mayor may not
be successful.
If processing terminates some time after a warning
message is issuen r the []f;pr f;houln
he aware of any prior warning
messages. The problem highlighted in the prior warning message may be
related to the termination of processing.
Fatal error messages are characterized in two ways:
a fatal error
message may be preceded by a question mark (?) or it may have no
leading punctuation mark at all. After a fatal error message has been
issued by TKB20 or VNP20, processing is always terminated. The user
should then call his local Software Support Specialist, unless the
corrective action is apparent from the message text.
Replaceable arguments in both warning and fatal error messages are
shown as abbreviations.
The following abbreviations are found in
several messages:
Abbreviation
addr
cmdline
cntname
ddmname
dlcname
fn
ft
llcname
modname
objfile
psect
rtnname
symname

Meaning
octal address
command line
controller name
device driver module name
data link controller name
file name
file type
logical link controller name
module name
object file name
p-section name
routine name (usually follows the
message text and two dashes)
symbol name

Certain messages contain replaceable arguments that are relevant only
to the message containing the replaceable argument.
In these cases,
the replaceable arguments are defined immediately following the
message text.

G-I

TKB20 AND VNP20 WARNING AND ERROR MESSAGES
G.I

TKB20 AND VNP20 WARNING MESSAGES

% Badly formatted OBJ file objfile -- rtnname
% Checksum error
nnn -- rtnname

mmm
nnn

OBJ

file

objfile;

should

mmm,

was

is the octal value of the computed checksum.
is the octal value of the checksum that was read.

% Divide
by
zero
psect -- rtnname

when

resolving

relocation

P-section

% Global symbol symname defined in module modI with value xxx
mod2 with value yyy

modI
xxx
mod2
yyy

is
is
is
is

the
the
the
the

and

name of the first module.
value of the first symbol.
name of the second module.
value of the second symbol.

% Global symbol symname is not defined in fn -- rtnname
% Global symbol symname is undefined
% Module modname multiply defines P-section psect;
yyy - rtnname

xxx
yyy

flags

xxx,

were

is the octal value of the new flags.
is the octal value of the old flags.

% Object file feature is unsupported -- rtnname
% Only one module allowed in symbol table file fn -- rtnname
% Partition length of mmm less than task length of nnn -- rtnname
mmm
nnn

is the partition length in octal.
is the task length in octal.

% Relocation value
psect
rtnname
xxx

xxx

bits

P-section

is the octal value that was truncated.

% Unspecified output file:

G.2

truncated

"fn", ignored - rtnname

TKB20 AND VNP20 FATAL ERROR MESSAGES

Some fatal error messages may be issued by more than one routine or
module.
These messages are identified in this appendix by the
"rtnname" replaceable argument following
the message text.
Other
fatal error messages are issued by only one routine from a specific
module.
In this latter type of fatal error message,
the actual
routine name is shown at the end of the message text.

G-2

TKB20 AND VNP20 WARNING AND ERROR MESSAGES
Each fatal error message beginning with?

is followed by the message:

?Terminating - No recovery Available for Previous Error.
ADDRESS OUT OF RANGE - GETII
ADDRESS OUT OF RANGE - STOll
Attempting to OPEN an already OPEN channel - OPEN
BACKSLASH MISSING - VRBL_SYM
BAD PSECT POINTER - PRC_RELOC
BAD PSECT POINTER - STO_TEXT
CALL TO GETSTG BEFORE INISTG
? Cannot find nnn bytes in system pool in fn -- rtnname
nnn

is the number of decimal bytes requested.

Channel is not OPEN - CLOSE
Channel is not OPEN - INPUT
Channel number out of range -

INPUT

Channel number out of range - OUTPUT
? Complex relocation exceeded stack limit of nnn, file fn -- rtnname
nnn

is the stack limit in decimal.

? DCP dlcname is unknown

rtnname

? DDM ddmname is unknown

rtnname

EOF IGNORED IN SCAN
? Error in text file fn -- rtnname

? Failure freeing nnn bytes
errcode
rtnname
nnn
errcode

addr

is the number of octal
question.
is the decimal error code.

system

pool

fn,

bytes

the

block

code
in

? File fn size of xxx bytes is larger than max of yyy - rtnname
xxx
yyy

is the file's size in decimal.
is the maximum permissible file size in decimal.

? Illegal error
This message indicates that the error number is out of the range of
the defined error numbers.
The "Terminating ..... " message does not
follow this message,
as it does for
all other error messages
preceded by a question mark.
? Indirect files nested too deep:

"cmdline" -- rtnname

? Input error or unexpected EOF -- rtnname

G-3

TKB20 AND VNP20 WARNING AND ERROR MESSAGES

? Invalid address addr in file fn -- rtnname
? Invalid Address Match for KDPLN For CNT$DF xxx -- D_KDP
is a controller number.

xxx

? Invalid Address Match Starting KDZLN For CNT$DF xxx -- D_KDZ
xxx

is a controller number.

? Invalid CNT$DF for DDM ddmname -- LD-DDM
Invalid Channel Number - CLOSE
Invalid Channel Number - OPEN

? Invalid con type - xxx found -- rtnname
is the type of construct that was found
to
invalid.
is the decimal value of the invalid construct.

con type
xxx

? Invalid error
This message indicates that the error message has no text.
? Invalid file name:

"fn" -- rtnname

? Invalid Interrupt Setup for driver

in file fn -- LOADD

? Invalid UNT$DF for DDM ddmname and CNT$DF cntname -- LD_DDM
? I/O DATA ERROR on fn,

stat

status

= stat -- rtnname

is the octal status of the I/O data error.

? LLC llcname is unknown -- rtnname
LLC NOT FOUND - LD_LLC
? Loading

bytes
nnn

library
rtnname

file

libname

overflowed

is the decimal number of bytes
pool.

? LOOKUP/ENTER UUO failed for fn, code

errcode

MISSING CONTROLLER - LD-DLC
MISSING SLT - D_DCP
NO DEVICE COO: - MOUACP
NO DEVICE LB - INSTALL
NO GEN PARTITION - INSTALL
? No input files -- rtnname

G-4

that

nnn

overflowed

the

pool

= errcode -- rtnname

is the octal error code.

May not OPEN channel 0 - OPEN

network

TKB20 AND VNP20 WARNING AND ERROR MESSAGES
? OPEN UUO failed for

filename -- rtnname

? Program logical address space

(PLAS)

NOT ENOUGH STORAGE FOR INITIALIZATION -

is not supported -- rtnname
INISTG

? Second ft file in command string: "fn" -- rtnname
? Storage exhausted -- rtnname
? Switches must be associated with a file -- rtnname

? Symbol
symtab2

symname
has
rtnname

symtabl
symtab2

conflicting

symtabl

and

loaded

into

"cmdline" -- rtnname

INSTALL

? The

Communications
kernfile
rtnname

kernfile

is the first symbol table file.
is the second symbol table file.

? Syntax error in command line:
TCB LINKS BAD -

values

Executive

has

already

been

is the name of the kernel file

? The top of the COMM EXEC is

too

high:

ceaddr

.GT.

maxaddr

fn -- rtnname
ceaddr
maxaddr

is the address of the top of the communications
executive.
is the maximum permitted address of the RSXIIS
executive.

UNIT MISSING - LD-DLC
You May Not Close Channel 0 - CLOSE

? 22-bit memory management not supported in fn - rtnname

G-5

INDEX

Bootstrapping (Cont.)
specifying tertiary load
file, 6-13
BOUT monitor call, 2-5, 4-2
BRIEF.TXT file, 10-20,
10-55
.BTBEL function of BOOT,
2-6
.BTCHN function of BOOT,
2-6
.BTCLI function of BOOT,
2-6
.BTCPN function of BOOT,
2-6
.BTDMP function of BOOT,
2-6
.BTIPR function of BOOT,
2-6
.BTKMD function of BOOT,
2-6
.BTKML function of BOOT,
2-6
.BTLDS function of BOOT,
2-6
.BTRDD function of BOOT,
2-6
.BTRLC function of BOOT,
2-6
.BTRMP function of BOOT,
2-6
.BTROM function of BOOT,
2-6
.BTSDD function of BOOT,
2-6
.BTSLS function of BOOT,
2-6
.BTSMP function of BOOT,
2-6
.BTSSP function of BOOT,
2-6
.BTSTA function of BOOT,
2-6
.BTSTP function of BOOT,
2-6
.BTSTS function of BOOT,
2-6
.BTTPR function of BOOT,
2-6
BUGCHK,
in SYSERR file, C-l
BUGINF,
in SYSERR file, C-l
BUILD-ALL.CTL file,
defined, 9-4

32KBLD.CMD file,
use of defined, 9-4

4-CONFIG.CMD file, 10-1,
10-6, 10-12, 10-26,
10-30, 10-33, 10-45,
10-46

Aborting a network
connection, 5-2
notification of, 5-2
reason code, 5-2
Acceptance tests, 10-20
defined, E-l
Accepting a connection,
3-23
Access information switches,
8-7
/ACCOUNT, 8-7
/PASSWORD, 8-7
/USER, 8-7
Accessible nodes,
listing, 7-2
Accessing a remote node,
conditions for, 6-2
Accessing files,
on remote hosts, 8-1
Account string,
reading the, 3-18
/ACCOUNT switch, 8-7
/ASCII switch, 8-7
Asynchronous transmission,
defined, E-l
Automatic reload of DN20,
6-17
Automatic startup,
DECSYSTEM-2020, 6-4
DECSYSTEM-2040/50/60, 6-7

Batch file,
for remote node, 8-15
BATCH log file, 10-18
Bibliography, D-l
BIN monitor call, 2-5, 4-3
BOOT monitor call, 2-5, 2-6
functions, 2-6
Bootstrapping,
-2040/50/60, 6-13
specifying secondary load
file, 6-13
Index-l

INDEX (CONT.)

Card reader,
certifying, 10-52
in configuration, 9-7
CCB,
in configuration, 9-8
Certification procedure,
defined, E-l
Certifying DECnet-20, 10-20
DN200, 10-51
error/event logging test,
10-54
flowchart, 10-23
line loopback test, 10-35
list of directories for,
10-20
list of files for, 10-20
loopback, 10-21
NFT test, 10-48
Remote-NCP test, 10-40
CETAB,
defined, 9-5
Changing output destination,
7-3, 7-4
Changing the network,
procedure, 9-3
Changing the node name,
9-16
Changing the node number,
9-16
CHARS.TXT file, 10-20
CHKll,
SYSERR entry for, C-8
Clearing interrupts, 3-11
CLOSF,
with CZ%ABT, 5-3
CLOSF monitor call, 2-5,
5-2, 5-7
example, 5-2, 5-5
with CZ%ABT, 5-7
Closing a logical link, 5-2
Closing a network
connection, 5-1
NSP control, 5-1
Closing a network JFN, 5-3
Coding examples,
source task, 5-5
target task, 5-6, 5-7
COMIOP.KMC file, 6-10
COMIOP.KMC program, 6-20
Command file,
executing, 8-15
passwords omitted, 8-15
Command files,
for NCP commands, 6-24
Communications front end,
1-2
auomatic dump of, 6-18
displaying line
statistics, 6-20

Communications front end
(Cont. )
dumping the, 6-19
error/event logging, 6-24
loading, 6-13
logging activity, 6-15
reload, 6-16
Communications line
controller,
dumping a, 6-21
loading a, 6-20
Computer network,
defined, E-l
Configuration,
defined, E-l
Configuration tools, 9-1
defined, 9-4, E-l
Configuring DECnet-20,
adjusting hardware
parameters, 9-18
building DN20, 9-15
building RJE, 9-23
changing software
parameters, 9-19
creating system image,
9-22
directories, 9-10
identifying dn20, 9-16
overview, 9-2
restoring files, 9-12
saving configuration,
9-21
terms defined, 9-6
work space for, 9-1
Connect,
defined, E-l
Connect confirm message,
3-23
explicit, 3-23
implicit, 3-23
Connect event interrupt,
3-11
Connect initiate message,
3-1
Connect password,
defined, E-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
Controlling error/event
logging, 6-24
COpy (NFT command), 8-6
examples, 8-8
switches, 8-7

Index-2

INDEX (CaNT.)

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

.DCX8 disconnect code, A-I
.DCX9 disconnect code, A-I
DDCMP, 1-3, 4-1
data transfer functions,
4-1, 4-2
defined, E-2
error/event logging, 6-24
initializing, 6-21, 6-22
terminating, 6-22
DDCMP protocol,
reference document, D-l
DEBRK monitor call, 5-6
example, 5-6
DECnet,
object types, B-1
DECnet commands,
generic, 1-6
TOPS-20-specific, 1-6
DECnet-20,
and terminal users, 7-1
capabilities, 1-4
certification procedure,
10-20
configuration
prerequisites, ~-~u
configuration tools, 9-1
control, 1-5
hardware, 9-7
installing, 10-1
monitor calls, 2-4
operator interface, 1-5
options, 1-1
programmer interface, 1-5
protocols, 1-1
software, 1-1
structure, 1-2
user interface, 1-6
verification procedure,
10-12
DECnet-20 concepts, 2-1
network an I/O device,
2-1
network JFNs, 2-3
task a file, 2-1
DECnet-20 restrictions,
displaying line
statistics, 6-20
displaying line status,
6-23
loading a node, 6-18
protocol type, 6-15
DECNET.DAT file, 10-20
DECSYSTEM-2020,
automatic startup, 6-4
dumping a line controller,
6-21
lines supported, 1-1
loading a line controller,
6-20

DAP protocol, 1-6, 8-1
defined, E-2
reference document, D-l
Data,
segmentation of, 4-1
sending, 4-1
Data available interrupt,
3-11
Data transfer in general,
1-3
Data transfers,
continuous stream, 4-1
general, 4-1
loyicdl mes~dge~, 4-1
Data transmission,
defined, E-2
Date/time,
displaying, 6-23
DCN: ,
network device, 2-1, 3-1
DCN: device,
attributes, 3-6
descriptor, 3-5
file specification, 3-5
hostname field, 3-5
objected, 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
.DCX21 disconnect code, A-I
.DCX22 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
.DCX41 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

Index-3

INDEX (CONT.)

DECSYSTEM-2020 (Cont.)
manual startup, 6-10
NETCON functions, 6-3
starting cable loopback,
6-22
starting controller
loopback, 6-21
structure, 1-2
DECSYSTEM-2040/50/60,
automatic dump of DN20,
6-18
automatic reload of DN20,
6-17
automatic startup, 6-7
defining protocol, 6-15
displaying line
statistics, 6-20
dumping a node, 6-19
line logging restrictions,
6-15
lines supported, 1-1
loading a node, 6-18
loopback testing, 6-22
manual startup, 6-10
NETCON functions, 6-4
specifying default dump
file, 6-14
specifying default load
file, 6-14
starting event/error
logging, 6-24
stopping event/error
logging, 6-24
structure, 1-2
Default host node,
displaying, 6-23
Defaults,
automatic dump of DN20,
6-18
dump file for -2040/50/60,
6-14
executor node, 6-23
file processing modes,
8-10
load file for -2040/50/60,
6-14
logging interval, 6-16
logical node, 7-2
task name, 3-15
DELETE (NFT command), 8-11
Deleting files,
on remote hosts, 8-1,
8-11
Demultiplexing, 2-3
DESTINATION-NODE switch,
7-4
example, 7-4
10-55

Digital Data Communications
Message Protocol, See
DDCMP
Digital Network
Architecture, See DNA
DIRECTORY (NFT command),
8-11
DISABLE EVENT-LOGGING (NCP
command), 6-24
Disabling line loopback
mode, 6-17
Disconnect,
defined, E-2
Disconnect codes,
table of, A-I
with MTOPR, 5-3
Displaying date/time, 6-23
Displaying default host
node, 6-23
Displaying executor node,
6-23
Displaying filesj
from remote node, 8-15
Displaying line statistics,
6-20
Displaying line status,
6-23
Displaying NETCON request
queue, 6-19
Displaying node name, 6-23
Displaying node number,
6-23
Displaying node status,
6-23
Displaying operating system,
6-23
Displaying software
versions, 6-23
Distribution tapes, 9-4
DMCll,
defined, E-2
in configuration, 9-7
DMCll device,
error/event logging, 6-24
DN20,
automatic dump of, 6-18
defined, E-2
displaying line
statistics, 6-20
dumping the, 6-19
error/event logging, 6-24
in configuration, 9-6
loading, 6-18
DN200,
certification, 10-51
configuration procedure,
9-23
configuring hardware,
9-26

Index-4

INDEX (CONT.)

DN200 (Cont.)
loading, 6-13
DN200.CMD file, 10-1, 10-7
DN200BLD.CMD file,
use of defined, 9-4
DN20BLD.CMD file,
use of defined, 9-4
DNA, 1-1
DNMAC,
defined, E-2
DNMAC program,
defined, 9-4
DNV2FT.APP file, 10-20
DNV2FT.LOG file, 10-51
DNV2LL.CMP file, 10-21
DNV2LN.CMP file, 10-20
DNV2LN.LIN file, 10-36
DNV2LN.LOG file, 10-38
DNV2LN.NOD file, 10-35
DNWAIT.EXE file, 10-21
Down-line loading,
defined, E-2

Enabling line loopback mode,
6-16
Error and event logging
test, 10-54
Error messaqes,
from OPR and ORION, 6-30
list of NETCON, 6-29
NFT, 8-16
TKB20, G-l
VNP20, G-l
ERROR.SYS file, C-l
line statistics in, 6-15
Error/event logging,
Controlling, 6-24
controlling, 6-24
controlling at line level,
6-24
controlling at NICE level,
6-24
described, C-l
entries, C-l
NICE task, 6-24
Starting, 6-24
Stopping, 6-24
Error/event logging reports,
print using SYSERR, 10-55
Establishing a network
connection, 3-1
checking status, 3-13
Estimated-pool-size,
in configuration, 9-9
Examples,
aborting a logical link,
5-3, 5-4
automatic startup, 6-4,
6-5, 6-6
DECSYSTEM-2040/50/60,
6-8, 6-9
CLOSF monitor call, 5-5
connect confirm, 3-24
COPY, 8-8
CZ%ABT flag bit, 5-3
DeN: specification, 3-8
DEBRK monitor call, 5-6
deleting remote files,
8-1, 8-11
DESTINATION-NODE switch,
7-4
DTEMPS.BIN file, 6-13
DTEMPT.BIN file, 6-13
enabling interrupts, 3-12
EXIT (NFT command), 8-14
GTJFN monitor call, 5-5
5-6
HELP (NFT command), 8-14
INFORMATION (NFT command),
8-6
INFORMATION (TOPS-20
command), 7-2

T'\I'T'lt:"

LJ..LL,

defined, E-2
error/event logging, 6-24
in configuration, 9-7
interface, 2-2
DTEMPS.BIN file, 10-1, 10-4,
10-7
DTEMPS.BIN file,
example, 6-13
DTEMPT.BIN file, 10-1, 10-4,
10-7
DTEMPT.BIN file,
example, 6-13
DUMP CONTROLLER, 6-21
Dump file,
specifying default, 6-14
DUMP NODE, 6-19
Dumping a line controller,
6-21
Dumping a node, 6-19
Dumping nodes,
specifying default dump
file, 6-14
Dumping the DN20, 6-19
DUPll,
in configuration, 9-7
Duplex,
defined, E-2
DYNETS.EXE file, 10-20

ENABLE EVENT-LOGGING (NCP
command), 6-24
Enabling for interrupts,
3-10, 3-12

Index-5

INDEX (CONT.)

Examples (Cont.)
listing remote directory,
8-12
LOCAL-NCP test, 10-31
LOCAL-NCP.CMD file, 10-29
manual startup -2020,
6-10
manual startup
-2040/50/60, 6-10
.MOACN function, 3-12,
5-6
.MOCC function, 3-24,
5-6
.MOCLZ, 3-25
.MOCLZ function, 5-2
.MORAC function, 3-18
.MORCN function, 3-20
.MORDA function, 3-19
.MORHN function, 3-14
.MORIM function, 4-5
.MORLS function, 3-13,
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-4
MTOPR monitor call, 3-12,
3-13, 3-14, 3-19, 3-20,
3-21, 3-22, 3-24, 4-5,
5-5, 5-6
NCP commands, 6-1, 6-3
NETCON responses, 6-27
network file
specification, 3-8
OPENF monitor call, 5-5,
5-6
OPR initialization
failure, 6-32
PLEASE, 7-3
processing interrupts,
5-7
programming, 5-5, 5-6,
5-7, F-l
reading host name, 3-14
reading logical link
status, 3-13
remote logins, F-lO
REMOTE-NCP.CMD, 10-44,
10-46
restarting NETCON, 6-25
restarting ORION, 6-25
SECDMC.SYS file, 6-13
sending user data, 3-24,
3-25

Examples (Cont.)
SHOW COUNTS, 6-3
SHOW COUNTS response,
6-20
SHOW QUEUE response, 6-19
SHOW STATUS, 6-1
SIBE monitor call, 5-7
SINR monitor call, 5-7
source task, F-l
source task coding, 5-4,
5-5
SOUTR monitor call, 5-5
SRV: specification, 3-8
target task, F-l
target task coding, 5-6,
5-7
TERDMC.SYS file, 6-13
using CZ%ABT, 5-7
using MO%CDN, 3-12
using MO%DAV, 3-12
using MO%INA, 3-12
using .MOACN, 3-12
WA IT, 3 -1 2, 5 - 6
EXCEPT. LOG file, 10-18
Executing command file,
8-15
Executor node,
default, 6-23
displaying, 6-23
setting, 6-23
EXIT (NFT command), 8-14
Exiting,
from NFT, 8-14
Exiting from NCP, 6-20

FAL object name, B-1
FAL program, 8-1
and DAP, 8-1
defined, 8-1, E-2
responsibilities of, 8-1
File processing mode,
for local source files,
8-9
for remote source files,
8-9
File processing modes (NFT),
default destination modes,
8-10
restrictions on, 8-10
File specification,
examples, 3-7
field lengths, 3-4, 3-7
general, 3-3
network, 3-3
Filespec format,

for remote operating

SET DEFAULTS, 8-4, 8-5
SET LOCATION, 7-3

systems, 8-2

Index-6

INDEX

/FIXED switch, 8-7
Flowchart,
certification, 10-23
installation, 10-3
verifying DECnet-20,
10-14
Full-duplex,
defined, E-2

(CONT.)

Installation certification
(Cont.)
flowchart, 10-23
Installation procedure,
defined, E-3
Installing DECnet-20, 10-1
4-CONFIG.CMD, 10-1, 10-6,
10-12
DN200.CMD, 10-1, 10-7
DTEMPS.BIN, 10-1, 10-4,
10-7
DTEMPT.BIN, 10-1, 10-4,
10-7
flowchart, 10-3
NCP.CMD file, 10-1, 10-6,
10-7
nodename.SYS, 10-4
nodename.SYS file, 10-1
overview, 10-1
PS:<DN20-1), 10-1, 10-4
PS:<DN200), 10-1, 10-4
PS:<DNGEN), 10-1

Generic task identification,
2-3
Glossary, E-l
GROUPS directory attribute,
USER, 10-35
GTJFN,
file specification, 3-3
GTJFN monitor call, 2-3,
2-5, 3-1, 5-5
example, 5-5, 5-6
filespec, 3-3
for source task,
for target task, 5-6

nl"" ..

/l\.,r.tr.'";
(""'T'TT'"H'''1.7(''"1,
ro~,~~n-0UD0~0/,

,n'

~u-~

PS:<NEW-SYSTEM), 10-1
PS:<SUBSYS>, 10-1, 10-4
PS:<SYSTEM), 10-1, 10-4
PTYCON.ATO, 10-1, 10-8
RJE, 10-6
SECDMC.SYS, 10-4
SYSJOB.RUN, 10-1, 10-4,
10-6, 10-10
SYSTEM.CMD, 10-9
TERDMC.SYS, 10-4
Interface,
operator, 1-5, 1-6
programmer, 1-5, 2-4
terminal user's, 1-6
Interrupt,
connect pending, 3-11
data available, 3-11
message available, 3-11
Interrupt messages,
defined, E-3
limit, 4-5
receiving, 4-5
sending, 4-3
Interrupts,
clear ing, 3-11
enabling for, 3-10, 3-12
example of coding, 5-6
processing, 5-6, 5-7
setup for, 5-6
IPCF directory attribute,
10-35
IPCF directory subcommand,
10-13

Half-duplex,
defined, E-2
Hardware error,
DUPll header, C-7
SYSERR entry for, C-6
Hardware errors,
reporting, 6-24
HELP (NFT command), 8-14
Host computer,
defined, E-2
Host name,
reading, 3-14
Host node,
displaying default, 6-23

/IMAGE switch, 8-7
INFORMATION command, 7-2
INFORMATION (NFT command),
8-5
examples, 8-6
Information switches,
/ACCOUNT access, 8-7
INFORMATION (TOPS-20
command), 7-2
Initializing DDCMP, 6-21,
6-22
INITIATE LOGGING
LINE-COUNTERS, 6-15
Installation certification,
10-20

Index-7

INDEX (CaNT.)

JFN,
closing a network, 5-3
Job status,
information about, 7-2

KDP device,
dumping, 6-21
error/event logging, 6-24
in configuration, 9-6
loading, 6-20
KMCll,
in configuration, 9-7

Line,
starting a, 6-21
stopping a, 6-22
synchronizing a, 6-22
testing a, 6-21, 6-22
Line activity,
logging, 6-15
Line controller,
dumping a, 6-21
loading a, 6-20
starting a, 6-20
Line counter types, C-IO
table of, C-IO
Line counters,
initiate, 6-15
logging interval for,
6-16
Line drivers,
error/event logging, 6-24
Line loopback,
starting, 6-21, 6-22
Line loopback mode,
disabling, 6-17
effect, 6-16
enabling, 6-16
Line loopback testing, 6-22,
10-35
Line statistics,
displaying, 6-20
SYSERR entry for, C-9
Line status,
displaying, 6-23
Line-printer,
in configuration, 9-7
Link data base, 3-9
Link status, 3-10
Link, See also Logical link
or Physical link
Links,
in configuration, 9-7
logical, 2-2
physical, 2-2

Listing accessible nodes,
7-2
Listing directory,
examples, 8-12
on remote node, 8-11
Listing logical node, 7-2
Listing nodes,
for file transfer, 8-6
LOAD CONTROLLER, 6-20
Load file,
specifying a, 6-18
specifying default, 6-14
specifying secondary,
6-13
specifying tertiary, 6-13
LOAD NODE, 6-18
Loading a line controller,
6-20
Loading a node, 6-18
Loading communications
front end, 6-13
Loading nodes,
specifying default load
file, 6-14
specifying load files,
6-13
Loading RJE station, 6-13
Loading the DN20, 6-13,
6-18
Local loopback, 6-16
Local node,
defined, E-3
Local NSP,
defined, E-3
Local task,
defined, E-3
LOCAL-NCP test, 10-26
LOCAL-NCP-KL-EXAMPLE.CMD
file, 10-20, 10-26
LOCAL-NCP-KL-EXAMPLE.TXT
file, 10-20, 10-26
LOCAL-NCP-KS-EXAMPLE.CMD
file, 10-21, 10-30
LOCAL-NCP-KS-EXAMPLE.TXT
file, 10-21, 10-34
LOCAL-NCP.CMD file, 10-20,
10-28, 10-33
LOCAL-NCP.CMD file,
example, 10-29
Logging interval,
default, 6-16
setting, 6-16
Logging line activity, 6-15
Logical link, 2-2
assigned, 3-1
closing a, 5-3
creating a, 5-5

defined, E-3
JFN of, 3-23

Index-8

INDEX (CONT.)

Logical link data,
reading, 3-12
Logical link data base,
3-12
contents of, 3-12
created, 3-12
maintained, 3-12
Logical link protocols, 1-4
Logical link status, 3-13
flag bits, 3-13, 5-2
reading, 3-13
Logical links,
quotas, 3-10
segment size, 4-1
Logical node,
default, 7-2
defined, E-3
1 isting, 7-2
specifying, 7-2
vs. physical node, 7-2
Logical-links,
in configuration, 9-8
Login,
sample programs for
remote, F-l
LOOP LINE, 6-22
Loop-back,
defined, E-3
Loopback connector, 6-22,
10-21
Loopback mode, 6-21

MO%DAV link status bit
(Cont.)
using, 3-12
MO%EOM link status bit,
3-13
MO%INA field for .MOACN
function, 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
MO%CDN field, 3-12
MO%DAV field, 3-12
MO%INA field, 3-12
.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, E-3
.MONCI interrupt control
value, 3-11
Monitor call,
MTOPR, 3-24
Monitor calls,
BIN, 2-5, 4-3
BOOT, 2-5
BOUT, 2-5, 4-2
CLOSF, 2-5
facilities, 2-4
for receiving data, 4-3
for sending data, 4-2
functions, 2-5
GTJFN, 2-3, 2-5, 3-1
MTOPR, 2-5, 3-13, 3-14,
3-15, 3-16, 3-17, 3-18,
3-19, 3-20, 3-21, 3-22,
3-23

/MACYll switch, 8-7
Manual startup,
DECSYSTEM-2020, 6-10
DECSYSTEM-2040/50/60,
6-10
Messages,
list of NETCON, 6-27
list of NETCON warning,
6-28
NETCON at CTY, 6-26
NETCON fatal error, 6-29
NFT, 8-16
Tkb20, G-l
Vnp20, G-l
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-12
MO%DAV link status bit,
3-11

Index-9

INDEX (CONT.)

Monitor calls (Cont.)
network related, 2-5
NODE, 2-5
OPENF, 2-5, 3-1, 3-10
SIBE, 2-5, 4-3
SIN, 2-5, 3-10, 4-3
SINR, 2-5, 3-10, 4-3
SOUT, 2-5, 4-2
SOUTR, 2-5, 4-2
Monitor calls used, 1-5
MOP,
defined, E-3
MOP protocol,
reference document, D-l
.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-5
.MORIM function of MTOPR,
example, 4-4
.MORLS function of MTOPR,
2-6, 3-13, 5-2, 5-3,
5-7
.MORLS function of MTOPR,
example, 3-13, 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
.MOSIM function of MTOPR,
example, 4-4
MTOPR monitor call, 2-5,
2-6, 3-11, 3-13, 3-14,
3-23, 3-24, 5-5
MTOPR monitor call,
calling sequence, 3-11,
3-15, 3-16, 3-17, 3-18,
3-19, 3-20, 3-21, 3-22,
3-24, 4-4, 4-5, 5-1,
5-3
example, 5-5, 5-6
functions, 2-6
Multiplexing, 2-3

NCP,
commands to OPR, 6-1
defined, E-3
exiting from, 6-20
NCP command files, 6-24
NCP command summary, 6-12
NCP commands,
accessing, 6-11
action commands, 6-18
data base commands, 6-13
DISABLE EVENT-LOGGING,
6-24
DUMP CONTROLLER, 6-21
DUMP NODE, 6-19
ENABLE EVENT-LOGGING,
6-24
examples, 6-1, 6-3
EXIT, 6-20
general categories, 6-11
INITIATE LOGGING
LINE-COUNTERS, 6-15
LOAD CONTROLLER, 6-20
LOAD NODE, 6-18
LOOP LINE, 6-22
miscellaneous, 6-23
OPR processing, 6-2
OPR subset, 6-1
PUSH, 6-24
REMOTE keyword, 6-11
responses to, 6-27
restrictions, 6-3
RETURN, 6-20
SET EXECUTOR, 6-23
SET LOCAL LOOPBACK
DISABLED, 6-17
SET LOCAL LOOPBACK
ENABLED, 6-16
SET LOGGING-INTERVAL,
6-16
SET NODE AUTO-DUMP, 6-18
SET NODE AUTO-LOAD, 6-17
SET NODE DUMP-FILE, 6-14
SET NODE LOAD-FILE, 6-14
SET NODE PROTOCOL-TYPE,
6-15
SET NODE SERVER, 6-13
SET SECONDARY-LOAD-FILE,
6-13
SET STATE LINE
CABLE-LOOPBACK, 6-22
SET STATE LINE
CONTROLLER-LOOPBACK,
6-21
SET STATE LINE OFF, 6-22
SET STATE LINE ON, 6-21
SET TERTIARY-LOAD-FILE,
6-13

Index-IO

INDEX

NCP commands (Cont.)
SHOW COUNTS, 6-3, 6-20
SHOW EXECUTOR, 6-23
SHOW QUEUE, 6-19
SHOW STATUS, 6-1
SHOW STATUS KNOw~ LINES,
6-23
SHOW STATUS LINE, 6-23
SHOW STATUS LOCAL, 6-23
syntax error messages,
6-30
table of, 6-12
TAKE, 6-24
TERMINATE logging, 6-16
NCP module of NETCON, 6-2
NCP.CMD file, 10-1, 10-6,
10-7
NCU, 6-2
defined, E-3
aPR/ORION interface, 6-2
NCU object name, B-1
.NDCIC function of NODE,
2-7
.NDCLP function of NODE~
2-7
.NDFLP function of NODE,
2-7
.NDGLI function of NODE,
2-7
.NDGLN function of NODE,
2-7
.NDGNM function of NODE,
2-7
.NDGNT function of NODE,
2-7
.NDGVR function of NODE,
2-7
.NDSIC function of NODE,
2-7
.NDSLN function of NODE,
2-7
.NDSLP function of NODE,
2-7
.NDSNM function of NODE,
2-7
.NDSNT function of NODE,
2-7
.NDVFY function of NODE,
2-7
NETCON, 1-4
defined, E-4
examples of responses,
6-27
fatal error messages,
6-29
SYSERR entry for loading,
C-2
types of responses, 6-27
warning messages, 6-29

(CaNT.)

NETCON commands, 1-5
NETCON messages,
at operators console,
6-26
1 ist of, 6-27
list of fatal, 6-29, 6-30
list of warning, 6-28
NETCON program,
functions, 6-3, 6-4
NCP module, 6-2
NICE module, 6-2
operator interface, 6-1
restarting, 6-25, 6-29
system dependencies, 6-3,
6-4
NETCON request queue,
displaying, 6-19
NETCON warning messages,
reporting, 6-29
NETCON, See also NCP
NETGEN program,
commanos r q-5
defined, 9-5, E-4
NF.TGFN, See also
Configuring DECnet-20
NETVFY.VER file, 10-20
Network,
defined, E-4
Network access, 2-1
Network connection,
aborting a, 5-1, 5-2
accepting, 3-23
closing a, 5-1
normal close, 5-1, 5-2
rejecting, 3-23
specifying, 3-5, 3-6
Network control task, 1-5
Network dialoque,
defined, E-4
Network event and error
logging, C-l
Network facilities, 2-4
Network file access, 8-1
Network file transfer test,
10-48
Network File Transfer, See
NFT
Network JFN, 2-3, 3-1
Network JFN,
closing a, 5-3
obtaining a, 3-2
Network Job File Number,
See Network JFN
Network request queue,
displaying, 6-19
Network task,
defined, E-4
NETWORK-SERVICES-PROTOCOL,
6-15

Index-II

INDEX (CONT.)

NFT, 1-1, 1-6
NFT,
certifying, 10-48
defined, E-4
protocol for, 1-6
NFT access information
switches, 8-7
NFT commands,
list of, 8-2
NFT processing mode
switches, 8-7
NFT program, 8-1
and DAP, 8-1
and NFT.INIT, 8-1, 8-3
changing access
information, 8-3
COpy command, 8-6
default access
information, 8-2
defined, 8-1
DELETE command, 8-11
DIRECTORY command, 8-11
EXIT command, 8-14
fatal error messages,
8-16
file processing modes,
8-10
HELP command, 8-14
INFORMATION command, 8-4,
8-5
internal NFT errors, 8-18
listing accessible nodes,
8-6
listing remote directory,
8-11
NFT.INIT file example,
8-3
responsibilities of, 8-1
running, 8-2
SET DEFAULTS command, 8-2
SUBMIT command, 8-15
TAKE command, 8-15
transferring files, 8-6
TYPE command, 8-15
warning messages, 8-16
NFT record length switches,
8-7
NFT.INIT file, 8-1, 10-48
example of, 8-3
procedure when none, 8-13
NICE module of NETCON, 6-2
NICE protocol, 6-2
defined, E-4
NICE task,
and event/error logging,
6-24
Node,
defined, E-4
in configuration, 9-7

Node (Cont.)
SYSERR entry for dumping,
C-5
SYSERR entry for loading,
C-4
Node identification, 2-4
name, 2-4
number, 2-4
NODE monitor call, 2-5, 2-7
functions, 2-7
Node name, 2-4
changing, 9-16
defined, E-4
displaying, 6-23
in configuration, 9-8
Node number, 2-4
changing, 9-16
defined, E-4
displaying, 6-23
in configuration, 9-8
Node type,
in configuration, 9-8
nodename.SYS, 10-4
nodename.SYS file, 10-1,
10-7
use of defined, 9-3
NRM object name, B-1
NRT20 program,
defined, F-l
initialization routines,
F-2
operations, F-2
source code, F-14
NRTSRV program,
defined, F-l
initialization routines,
F-4
operations, F-4
source code, F-27
using pseudo-terminals,
F-4
NSP, 3-1, 3-23
code, 2-1
control of link closing,
5-1
data transfer functions,
4-1, 4-2
disconnect function, 5-2
functions, 3-9, 3-10
interface to monitor, 2-1
multiplexing, 2-3
sending node init message,
6-21
NSP protocol, 1-4
defined, E-5
reference document, D-l
NULL. TXT file, 10-20
Number-of-nodes,
in configuration, 9-9

Index-12

INDEX (CONT.)

Object descriptor,
reading the, 3-21
Object descriptors, 2-4
OBJECT names,
FAL, B-1
NCU, B-1
NRM, B-1
TASK, B-1
Object type,
reading the, 3-20
Object types, 2-4, B-1
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
Operating system,
displaying, 6-23
Operator Command Language
Program, See OPR
Operator interface, 1-5,
1-6
Operator messages,
NETCON responses, 6-26
while DECnet is running,
6-26
OPR,
command parser, 1-5
handling DECnet errors,
6-30
interface to NETCON, 6-1
NCP command parser, 6~2
NCP command subset, 6-11
when ORION not running,
6-32
OPR command level,
returning to, 6-20
OPR initialization failure,
example of, 6-32
OPR program,
defined, E-5
Optional data,
reading the, 3-19
ORION,
restarting, 6-25
ORION program, 1-5
defined, E-5
handling DECnet errors,
6-30
NCP function, 6-2
not running, 6-32
restarting, 6-25
Output destination,
changing, 7-3, 7-4

Output destination (Cont.)
specifying, 7-2, 7-4

Packet,
defined, E-5
formation of, 4-1
PASSWORD,
reading the, 3-17
Password receive,
in configuration, 9-8
IPASSWORD switch, 8-7
Password transmit,
in configuration, 9-8
Physical link, 2-2
defined, E-5
Physical link protocol, 1-3
Physical links,
segment size, 4-1
Physical node,
defined, E-5
vs. logical node, 7-2
PICTUR.TXT file, 10-20
PLEASE,
example, 7-3
prgnam.ERL file, 10-18
PRINT (TOPS-20 command),
DESTINATION-NODE switch,
7-4
Printer,
certifying, 10-52
Printing files,
specifying output
destination, 7-4
Processing mode switches,
8-7
IASCII, 8-7
IIMAGE, 8-7
IMACYll, 8-7
Processing module of NETCON,
6-2
Programmer interface, 1-5,
2-4
MACRO, 2-4
monitor calls, 2-4
Protocol,
logical link, 1-4
Protocol error thresholds,
reporting, 6-24
Protocols,
collectively, 1-1
DAP, 1-6
defined, E-5
hardware level, 1-3
levels, 1-2, 1-3
NETWORK-SERVICES-PROTOCOL,
6-15
NSP, 1-4

Index-13

INDEX (CONT.)

Protocols (Cont.)
physical link, 1-3
reference documents for,
D-1
RSX20F-QUEUED-PROTOCOL,
6-15
user level, 1-4
PS:(DECNET> directory,
use of defined, 9-2
PS:(DN20-1> directory, 10-1,
10-4
use of defined, 9-2
PS:(DN200> directory, 10-1,
10-4
use of defined, 9-2
PS:(DNGEN.CMDS> directory,
use of defined, 9-2
PS:(DNGEN> directory, 10-1,
10-4
use of defined, 9-2
PS:(NEW-SUBSYS>,
use when configuring,
9-10
PS:(NEW-SUBSYS> directory,
10-1
PS:(NEW-SYSTEM>,
use when configuring,
9-10
PS:(NEW-SYSTEM> directory,
10-1
PS:(SUBSYS> directory, 10-1,
10-4, 10-8
PS:(SYSTEM> directory, 10-1,
10-4, 10-7, 10-45
PS:(UETP.DECNET> directory,
10-20, 10-33
PS:(UETP.LIB> directory,
10-20, 10-35, 10-46
PS:(UETP.RUN> directory,
10-36
Pseudo-terminals,
in NRTSRV program, F-4
PTYCON.ATO file, 10-1, 10-8
functions of, 6-7
PUSH (NCP command), 6-24

Queue,
network request, 6-19
Quota of open links, 3-10
configuration, 3-10
job, 3-10
system, 3-10

RDB,
in configuration, 9-9

RDB-size,
in configuration, 9-9
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 user name, 3-16
Reason code for aborting a
connection, 5-2
Receiving interrupt
messages, 4-5
Record length switches, 8-7
/FIXED, 8-7
/VARIABLE, 8-7
Recording line activity,
6-15, 6-16
setting logging interval,
6-16
Redefining DECnet data base,
6-25
References,
communications networks,
D-1
DAP, D-1
data communications, D-1
DDCMP, D-1
MOP, D-1
NSP, D-1
Reject code, 3-25
sending data with, 3-25
Reject codes, 3-24
table of, A-I
Rejecting a connection,
3-23, 3-24, 3-25
Remote file transfer, 8-6
REMOTE keyword NCP commands,
6-11
Remote login,
sample programs for, F-1
examples, F-10
installation, F-6
special escape characters,
F-8
Remote node,
conditions for accessing,
6-2
defined, E-5

Index-14

INDEX (CONT.)

Remote nodes,
deleting files from, 8-11
displaying files from,
8-lS
listing directory from,
8-12
submitting Batch file to,
8-lS
transferring files
to/from, 8-6
Remote NSP,
defined, E-S
Remote task,
defined, E-S
REMOTE-NCP test, 10-40
RUN.LOG file, 10-SO
REMOTE-NCP-20-EXAMPLE.CMD
file, 10-20
REMOTE-NCP-20-EXAMPLE.TXT
file, 10-20
REMOTE-NCP-DN20-EXAMPLE.CMD
file, 10-20, 10-40
HBMOTE-NCP-DN20-EXAMPLE.TXT
file, 10-20, 10-43
REMOTE-NCP.CMD file, 10-20,
10-44, 10-46
Reporting hardware errors,
6-24
Reporting NETCON warning
messages, 6-29
Reporting protocol error
thresholds, 6-24
Reporting unsuccessful
commands, 6-27
Restart procedures,
for NETCON, 6-2S
for ORION, 6-25
Restarting NETCON, 6-2S
example, 6-2S
Restarting ORION, 6-2S
example, 6-2S
Restrictions,
displaying line
statistics, 6-20
displaying line status,
6-23
dumping a node, 6-19
line logging for
2040/S0/60, 6-lS
loading a node, 6-18
protocol type, 6-lS
Retrieval of source task
attributes, 3-7
RETURN from NCP, 6-20
Returning to OPR command
level, 6-20
Returning to TOPS-20
command level, 6-20
RJE option, 1-1

RJE station,
certification, 10-Sl
certifying card reader,
10-S2
certifying printer, 10-S2
configuration procedure,
9-23
configuring hardware,
9-26
loading, 6-13
RJEVFY.VER file, 10-20
RSXllS.STB file,
defined, 9-4
RSXllS.TSK file,
defined, 9-4
RSX20F-QUEUED-PROTOCOL,
6-lS
RUN. LOG file, 10-38, 10-SO

Sample programs for remote
login, F-l
SDB,
in configuration, 9-9
SDB-size,
in configuration, 9-9
SECDMC.SYS file, 10-4, 10-8
example, 6-13
Secondary load file,
specifying, 6-13
Segment size,
of logical links, 4-1
of physical links, 4-1
reading the, 3-22
Segmentation of data, 4-1
SENDER program, 10-19
Sending data, 4-1, 4-2
effect of buffer size,
4-2
example, S-S
monitor calls, 4-2
segmenting, 4-1
Sending interrupt messages,
4-3
Server node,
specifying for load/dump,
6-13
Server task,
defined, E-S
example of, F-l
Serverlineid for load/dump,
specifying, 6-14
SET NODE DUMP-FILE, 6-14
SET DEFAULTS, 8-2
and NFT.INIT, 8-4
example, 8-4
SET EXECUTOR, 6-23

Index-IS

INDEX (CONT.)

SET LOCAL LOOPBACK DISABLED,
6-17
SET LOCAL LOOPBACK ENABLED,
6-16
SET LOCATION, 7-2
example, 7-3
SET LOGGING-INTERVAL, 6-16
SET NODE AUTO-DUMP (NCP
command), 6-18
SET NODE AUTO-LOAD (NCP
command), 6-17
SET NODE LOAD-FILE (NCP
command), 6-14
SET NODE PROTOCOL-TYPE,
6-15
SET NODE SERVER, 6-13
SET SECONDARY-LOAD-FILE,
6-13
SET STATE LINE
CABLE-LOOPBACK (NCP
command), 6-22
SET STATE LINE
CONTROLLER-LOOPBACK,
6-21
SET STATE LINE OFF, 6-16,
6-17
SET STATE LINE OFF (NCP
command), 6-22
SET STATE LINE ON, 6-21
SET TERTIARY-LOAD-FILE,
6-13
Setting executor node, 6-23
SHOW COUNTS, 6-20
example, 6-20
SHOW COUNTS command, 6-3
SHOW EXECUTOR, 6-23
SHOW QUEUE, 6-19
example, 6-19
SHOW STATUS command, 6-1
SHOW STATUS KNOWN LINES,
6-23
SHOW STATUS LINE, 6-23
SHOW STATUS LOCAL, 6-23
SIBE monitor call, 2-5, 4-3
SIBE monitor call,
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
example, 5-7
Software versions,
displaying, 6-23
Software-ID,
in configuration, 9-8
Source node,
defined, E-5

Source task, 2-1, 3-1
attributes, 3-6
defined, E-5
example of, F-l
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 dump file,
6-19
Specifying a load file,
6-18
Specifying a network
connection, 3-5
account, 3-6
descriptor, 3-5
host name, 3-5
object name, 3-5
object type, 3-5
password, 3-6
task name, 3-5
userdata, 3-6
user id, 3-6
Specifying a target task,
3-3
Specifying default dump
file, 6-14
Specifying default load
file, 6-14
Specifying logical node,
7-2
Specifying output
destination, 7-2, 7-4
Specifying secondary load
file, 6-13
Specifying tertiary load
file, 6-13
SPRs,
for NETCON warning
messages, 6-29
SRV: ,
descriptor, 3-4
file specification, 3-3
network device, 2-2, 3-1
objectid, 3-3
task name, 3-4
Starting a line, 6-21
Starting a line controller,
6-20
Starting error/event
logging, 6-24

Index-16

Starting line loopback,
6-21, 6-22

INDEX (CONT.)

Startup dialogue DECnet-20
(2040/50/60), 6-8, 6-9
Startup dialogue
DECnet-20 (2020), 6-5,
6-6
Startup procedures, 6-4
DECSYSTEM-2020, 6-4
DECSYSTEM-2040/S0/60, 6-4
STNRT program,
defined, F-l
source code, F-37
Stopping a line, 6-22
Stopping error/event
logging, 6-24
SUBMIT (NFT command), 8-15
Submitting Batch file,
to remote node, 8-15
Switch,
/ACCOUNT, 8-7
/ASCII, 8-7
/FIXED, 8-7
/IMAGE, 8-7
/M.l\CYll, 8-7
/PASSWORD, 8-7
/USER, 8-7
/VARIABLE, 8-7
Switches,
access information, 8-7
DESTINATION-NODE, 7-4
for file transfer, 8-7
in DELETE (NFT command),
8-11
in DIRECTORY (NFT
command), 8-12
in SUBMIT (NFT command),
8-15
in TYPE (NFT command),
8-15
NFT COpy command, 8-7
processing mode, 8-7
processing mode (NFT),
8-9
record length, 8-7
Synchronizing a line, 6-22
Synchronous transmission,
defined, E-6
Syntax errors from OPR,
6-30
SYSERR entries, C-l
CHKll diagnostic, C-8
common header, C-2
DUPll header, C-7
hardware error, C-6
line counter types, C-IO
line statistics, 6-15,
C-9
NETCON loading, C-2
node dump, C-S
node load, C-4

SYSERR program, 10-55
SYSJOB,
in startup procedure, 6-7
SYSJOB.RUN file, 10-1, 10-4,
10-6, 10-10
functions of, 6-7
System,
overview, 1-1
System dependencies,
BOOT monitor call, 2-6
cache memory, 6-8
certification, 10-21,
10-51
configuration, 9-1
configuring RJE, 9-22
DUPll, 6-14, 10-36
error logging, C-l
event logging, C-l
extended addressing, 6-8
file processing modes,
8-9
in line loopback test,
in Remote-NCP test, 10-40
in verification procedure,
10-17
installation, 10-1
installtion, 10-4
remote Batch submission,
8-15
REMOTE keyword, 6-11
startup procedures, 6-4
verification, 10-21
System security,
guarding against breach
of, F-4
SYSTEM.CMD file, 10-9

TAKE (NCP command), 6-24
TAKE (NFT command), 8-15
Target node,
defined, E-6
specifying for load/dump,
6-13
Target task, 2-2, 3-1
defined, E-6
example of, F-l
file specification, 3-3
retrieval source task
attributes, 3-7
unique task name, 3-4
Target task coding,
example of, 5-6, 5-7
Task,
remote, E-S
server, E-S
source, 3-1, E-S

Index-17

INDEX (CONT.)

Transferring information
over the network, See
also Sending data
Transmit-buffer,
in configuration, 9-9
TYPE (NFT command), 8-15

Task (Cont.)
target, 3-1, E-5
Task identification,
generic, 2-3
unique, 2-4
Task name,
reading the, 3-15
TASK object name, B-1
Task-to-task capabilities,
1-1, 1-4
example of, F-l
TERDMC.SYS file, 10-4
10-8
example, 6-13
Terminal,
in configuration, 9-7
Terminal user,
accessing DECnet
information, 7-1
Terminal user's interface,
1-6
Terminal users,
remote login for, 7-4
SYSERR program, 7-4
transferring files, 7-1
TERMINATE LOGGING
LINE-COUNTERS, 6-16
Terminating DDCMP, 6-22
Tertiary load file,
specifying, 6-13
TEST72.CMP file, 10-21
Testing a line, 6-21,
6-22
specifying test data,
6-22
Throughput,
increasing, 3-10
TKB20 program,
defined, 9-5, E-6
error messages, G-l
warning messages, G-l
TOPS-20 command level,
returning to, 6-20

UETP,
defined, E-6
required login directory
changes, 10-13
SENDER program, 10-19
using BATCH log file,
10-18
using EXCEPT. LOG file,
10-18
using prgnam.ERL file,
10-18
using RUN. LOG file, 10-18
<UETP.LIB> directory, 10-15,
10-28
<UETP.RUN>, 10-15
Unique task identification,
2-4, 3-15
monitor supplied, 3-15
Unsuccessful commands,
reporting, 6-27
Up-line dumping,
defined, E-6
User data,
with connect confirm
message, 3-24
USER GROUPS directory
attribute, 10-35
subcommand, 10-13
User name,
reading, 3-16
User notificataion of abort,
5-3
/USER switch, 8-7
USERID,
reading the, 3-16

TOPS-20 commands,
INFORMATION, 7-2
relating to DECnet-20,
7-1
Transferring files, 8-6
by terminal user, 7-1
default destination modes,
8-10
giving file processing
mode, 8-9
required specifications,
8-9
restrictions, 8-10
Transferring information
over the network, 4-1

Index-18

/VARIABLE switch, 8-7
Verification procedure,
10-12
defined, E-6
Verifying DECnet-20,
flowchart, 10-14
list of directories for,
10-20
list of file for, 10-20
<SUBSYS>, 10-15
<UETP.LIB>, 10-15
<UETP.RUN>, 10-15

INDEX (CONT.)

Verifying DECnet-20 (Cant.)
using UETP, 10-13
VF2020.VER file, 10-21
VNP20 program,
defined, 9-5, E-6
error messages, G-l
warning messages, G-l

WAIT,
example of, 5-6
for interrupts, 5-6
Waiting for connect,
example, 5-5
Warning messages,
list of NETCON, 6-28
NFT, 8-16
TKB20, G-l
VNP20, G-l

Index-19

READER'S COMMENTS

NOTE:

TOPS-20 DECnet-20
Programmer's Guide and
Operations Manual
AA-509lB-TM

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?
page number.

If so, specify the error and the

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

[J Assembly language programmer
[J Higher-level language programmer
[J Occasional programmer (experienced)
[J User with little programming experience
[J Student programmer
[J Other (please specify) _______________________________________

Name

Date _________________________

Organization __________________________________ Telephone ____________________
Street _______________________________________________________________________
City_____________________________ State ______________ Zip Code ______________
or
Country

- - - - Do Not Tear - Fold Here and Tape

III II I

No Postage
Necessary
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 MR1-2/E37
MARLBOROUGH, MASSACHUSETTS 01752

,
,
,
,

,
,

- - -

Do Not Tear - Fold Here and Tape

--------------------------------------------,,
,
,

,
,
,
I

,
,
I

,
,

,
,
,

, .5
,...J

,13

,0
,0
It::

,..2
I~

'=
,
IU

,
,