Digital PDFs

AD-J678A-T1

May 1983

260 pages

Original

9.2MB

Document:	AA-J678A-TM DECnet-20 System Manager and Operators Guide Jun83
Order Number:	AD-J678A-T1
Revision:	0
Pages:	260
Original Filename:	AA-J678A-TM_DECnet-20_System_Manager_and_Operators_Guide_Jun83.pdf

OCR Text

DECnet-20
System Manager's
and Operator's Guide
AA-J678A-TM, AO-J678A-T1

June 1983
This manual describes the operational, control, and monitoring
functions of DECnet-20 and the TOPS-20 PSI product. These
products together with TOPS-20, provide the
DECSYSTEM-2040S/2060 computers with a communications
interface to DIGITAL's corporate network, DECnet, and to
Public Packet Switching Networks, PPSNs.
OPERATING SYSTEM:
SOFTWARE:

TOPS-20 VS.1
DECnet-20 V3.0
TOPS-20 PSI V1.0
GALAXY V4.2

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

Northeast/Mid-Atlantic Region

Central Region

Western Region

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

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

First Printing, December 1982
Updated, June 1983
© Digital Equipment Corporation 1982, 1983. All Rights Reserved.

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

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

MASSBUS
PDP
P/OS
Professional
Rainbow
RSTS
RSX

UNIBUS
VAX
VMS

VT
Work Processor

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

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

AD-J678A-T1

June 1983

Insert this Update Notice in the DECnet-20 System Manager's
and Operator's Guide to maintain an up-to-date record of
changes to the manual.
Changed Information
The changed pages contained in this update package reflect
information on the TOPS-20 PSI product.
The instructions for inserting this update start on the next page.

~DmDDmD

wore

INSTRUCTIONS
AD-J678A-T1
The following list of page numbers specifies which pages are to be placed in the OECnet-20 System
Manager's and Operator's Guide as replacements for, or additions to, current pages.
[Title page
Copyright page

[3-27
3-32

[A-13
A-15

[ii~
XIV

[7-1
7-2

[8-1
B-4

7
C-1-12.1

[7-9
7-10

[C-3
C-4

[2-1
2-18

[7-13
7-14

[C-11
Blank

[3-1
3-4

[7-17
7-18

[E-1
E-4

[3-7
3-14.2

[7-49
7-50

[Entire
Appendix F

[3-17
3-22.1

[8-1
8-23

[G-1
G-12

[A-3
A-6

[Entire
Index

KEEP THIS UPDATE NOTICE IN YOUR MANUAL TO MAINTAIN AN UP-TO-DATE
RECORD OF CHANGES.
TYPE AND IDENTIFICATION OF DOCUMENTATION CHANGES.
Five types of changes are used to update documents contained in the software manuals. Change
symbols and notations are used to specify where, when, and why alterations were made to each update
page. The five types of update changes and the manner in which each is identified are described in the
following table.

The Following Symbols and/or Notations

Identify the Following Types of Update Changes

1. Change bar in outside margin; version number and change date printed at bottom of
page.

1. Changes were required by a new version of
the software being described.

2. Change bar in outside margin; change date
printed at bottom of page.

Changes were required to either clarify or
correct the existing material:

3. Change date printed at bottom of page.

Changes were made for editorial purposes
but use of the software is not affected.

Bullet (e) in outside margin; version number
and change date printed at bottom of page.

Data was deleted to comply with a new version of the software being described.

Bullet (e) in outside margin; change date
printed at bottom of page.

Data was deleted to either clarify or correct
the existing material.

CONTENTS

PREFACE
PART I

INTRODUCTION

CHAPTER 1
1.1
1.2
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
1.2.7
1.2.8
1.3
1.4
1.5
1.6
1.7
1.8
CHAPTER 2
2.1
2.2
2.3
2.4
2.4.1
2.4.2
2.4.3
2.5
2.5.1
2.5.2
2.6
2.7
2.8

SYSTEM OVERVIEW
DIGITAL NETWORK ARCHITECTURE AND DECnet
• • 1-1
THE LAYERED STRUCTURE OF DNA • • • • • • • •
• 1-3
The User Layer • • • • • • • • • • • • • • • • • 1-5
The Network Management Layer •
••••
• 1-5
The Network Application Layer
• • • . . • 1-7
The Session Control Layer
• • • • • • • • 1-7
The Network Services Layer • • • • • • • • • • • 1-7
The Transport Layer
• • • • ••
• • • 1-7
The Data Link Layer
• • • • • • ••
• 1-8
The Physical Link Layer
• • • ••
• • 1-8
THE DECnet-20 VERSION 3.0 IMPLEMENTATION.
1-8
DECnet-20 OPTIONS • • • • • • • • • • •
• 1-9
DECSYSTEM 2040S/2060 HARDWARE - DECnet-20 V3.0. 1-10
DECnet IMPLEMENTATIONS • • • • •
1-10
DECnet CAPABILITIES
• • • • • •
1-11
OVERVIEW OF NCP COMMAND KEYWORDS • • • • • •
1-12
NETWORK CONCEPTS
NODES AND DATA LINKS •
THE PSI GATEWAY
• • • • •
• • • •
ENTITIES • • • • • • •
•
ROUTING CONCEPTS • • •
• • • • • • •
Node Routing Types •
• • • • • •
The Adaptive Least-Cost Routing Algorithm
Congestion and Packet Delivery. • • • • •
SUMMARY OF PHASE II/PHASE III COMPATIBILITY
Topological Restrictions • • •
• • • ••
Implementation Restrictions
•••.•
EVENT LOGGING • • • • • • • • • • • • •
OPERATOR FUNCTIONS AND RESPONSIBILITIES • • • •
SYSTEM MANAGER FUNCTIONS AND RESPONSIBILITIES

iii

•
•
•
•

2-1
2-2
2-6
2-6
2-7
2-10
2-11
2-11
2-11
2-12
2-14
2-14
2-16

June 1983

CONTENTS (Co n t. )

PART II

DECnet OPERATION

CHAPTER 3
3.1
3.1.1
3.1.2
3.1.3
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
3.4
3.4.1
3.4.2
3.5
3.6
3.0.1
3.7
3.7.1
3.7.2
3.7.3
CHAPTER 4
4.1
4.2
4.3
4.4
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5
4.5
4.5.1
4.5.2
4.5.3
4.5.4
4.5.5
4.5.6
4.5.7
4.5.8
4.5.9
CHAPTER 5
5.1
5.2

RUNNING DECnet-20
DECnet STARTUP PROCEDURES
• • • • • • • • • . • • 3-1
Automatic Startup on a DECSYSTEM-2040S/20~0
3-1
Manual Startup of DECSYSTEM-2040S/20nO
Communication Front End
• • • .•
• • • • • 3-4
Manual Startup with Command Files
• • 3-4
DECnet-20 RESTART PROCEDURES . • • •
• • 3-7
Restart Procedure for the Orion Process
• 3-7
Restart Procedure for NMLT20 •
• • • • • • • 3-7
Restart Procedure for X29SRV • • • • • •
• • 3-9
Restart Procedure for DN200
• . • • •
• • 3-9
CONTROLLING NODE, CIRCUIT, DTE, AND LINE STATE.
3-10
MONITORING NETWORK ACTIVITY
. • • • • • • • • • 3-11
NCP Commands for Network Monitoring - Local and
Remote • • • • • • • • • • • • • • • • • • • • 3-12
Using the SPEAR Program for Network Monitoring 3-13
3-18
DOWNLINE LOAD • . • • • • • • • . . • • •
• • • . • • • • • • • • • • • • • • 3-19
UPLINE DUMP
3-19
Automatic Dump of the MCB DN20 • • • • •
3-20
RECOGNIZING PROBLEMS - POTENTIAL, ACTUAL •
Using Loopback Tests • • • • • • • • • • • • • 3-20
Manual Procedure for Observing CHKll Output
3-31
Procedure for Automatic Output of CHK11
3-32
THE NETWORK MANAGEMENT PROGRAM
OPERATOR INTERFACE •
PROCESSING OVERVIEW • • • • • • •
NCP FUNCTIONS
NCP FEATURES • • • •
Typing Commands at the Terminal
Editing Commands.
Using Comments • •
Multiple Line Commands.
Getting Help from NCP
NCP COMMAND OPERATION
• • • •
Accessing NCP Commands •
Access Control • • • • • • • • •
Terminating NCP
••••
Leaving NCP and Returning to NCP
Restricting NCP Commands •
Command Input
••• • •
Command Output Response
••••
Specifying the Executor
Specifying Files in NCP Commands

• •
.

•
•

• • • • •
•
• • • •
. . . . .
• • •
• • • • •
• •

•
•
•
•

• •
•

• • •
•
• • •
• • •
• • •
• • •
•
• • •

4-1
4-1
4-2
4-3
4-3
4-3
4-4
4-4
• 4-4
• 4-5
• 4-5
• 4-7
• 4-7
• 4-7
• 4-7
• 4-8
• 4-8
4-11
4-11

NCP COMMANDS PROCESSED BY OPR
OPR/NCP COMMANDS •
EXAMPLES OF USE OF OPR/NCP COMMANDS

5-1
• • • • • • • 5-1

June 1983

CONTENTS (Co n t. )

CHAPTER 6
6.1
6.2
6.3
6.4
6.5
6.6
P:J.7
P:J.8

CHAPTER 7
7.1
7.2
7.3
7.3.1
7.3.2
7.3.3
7.3.4
7.3.5
7.3.6
7.4
7.5
7.5.1
7.5.2
7.5.3
7.5.4
7.5.5
7.6
7.7
7.8
7.8.1
7.8.2
7.8.3
7.8.4
7.9
7.10
CHAPTER 8

NCP COMMANDS PROCESSED BY THE NETWORK CONTROL PROGRAM
SET EXECUTOR
DEFINE EXECUTOR
CLEAR EXECUTOR •
PURGE EXECUTOR •
SHOW QUEUE • • •
CANCEL QUEUE REQUEST •
TELL PREFIX • • • • •
USING THE HELP COMMAND •

· . • n-3

· n-4
()-5
· n-5
• P:J-6
P:J-8

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
PROCESSING OVERVIEW • • • • • • • • • • • • •
7-1
DECNET-20 IMPLEMENTATION AND EXTENSIONS
• 7-2
NML CONCEPTS AND ORGANIZATION OF PARAMETERS
• 7-2
Entities. • • • • • • •
• • • •
• 7-2
Entity Identification
• • • 7-3
The Node En ti ty
• • 7-4
The Circuit Entity. • •
• • • • • • • 7-6
The Line Entity • • • •
••••
7-6
The Logging Entity. • • • • • •
• 7-8
GENERIC FORMAT OF NML/NCP COMMANDS •
7-11
CHANGING NETWORK DATA BASES: SET AND DEFINE
7-11
COMMANDS • • • • • • • •
7-12
SET/DEFINE Entity ALL
7-13
SET/DEFINE CIRCUIT •
7-20
SET/DEFINE LINE
7-22
SET/DEFINE NODE
7-36
SET/DEFINE LOGGING •
CHANGING NETWORK DATA BASES: CLEAR AND PURGE
7-37
COMMANDS • • • • • • • • • •
MONITORING THE NETWORK: LIST AND SHOW COMMANDS • 7-39
CONTROLLING THE NETWORK: TRIGGER, LOAD, DUMP,
7-47
LOOP COMMANDS
7-47
TRIGGER
7-48
LOAD •
7-49
DUMP • • •
7-51
LOOP • •
• • ••
•• • •
7-52
MONITORING NODE ACTIVITY: ZERO COMMAND •
7-53
NUMERICALLY CODED FIELDS • • • • • • • •
NETWOBK MANAGEMENT PACKET SWITCHING INTERFACE

8.1
8.2

THE MODULE ENTITY
X.25-SPECIFIC COMMANDS.

APPENDIX A

DECnet PARAMETER SUMMARY

APPENDIX B

COUNTER SUMMARY

B.l
B.2

• • • P:J-l
• P:J-3

DECnet COUNTER SUMMARY •
X.25 SPECIFIC COUNTERS •

• • • 8-2
• • • 8-3

• • B-1
• B-3

June 1983

CONTENTS (Con t.)

APPENDIX C
C.l
C.2
C.3
C.3.l
C.3.2
C.4

NETWORK RELATED MESSAGES
OPR/NCP COMMAND SYNTAX MESSAGES
• • • •
OPR/ORION/QUASAR INFORMATIONAL MESSAGES
NCP COMMAND RESPONSE MESSAGES
• • • • •
Status Messages
• • • • • • • • • • •
Error Messages from Network Management
X29SRV MESSAGES
• • • • . • • • • • • •

APPENDIX D

DECnet LINE DEVICES

APPENDIX E

X.29 FILES

E.l
E.2
E.3

X.29 PAD-PARAMETER FILES •
X.29 CONFIGURATION FILE
X.29 HERALD TEXT FILE

APPENDIX F

BIBLIOGRAPHY

APPENDIX G

GLOSSARY

•

• C-l
• C-2
• • • • • C-3
•
• C-4
Software C-4
• • • • C-ll

• E-l
· E-3

• E-4

June 1983

CONTENTS (Co n t. )

FIGURES
FIGURE

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

Communication between Adjacent and Equivalent Layers
of the DIGITAL Network Architecture
1-2
Logical Communication and Physical Path of
Routed Data
•••••••••••••
• 1-4
OPR/NCP/NML Logical processing Flow in DECnet-20
V3.0 • • • • • • • • • • • • • • • • • • •
• 1-5
Types of Nodes by Network Function • • • • • • • • 2-2
TOPS-20 PSI Gateway Software Components
• • 2-3
X.29 Terminal Access to a TOPS-20 Host.
• 2-5
Routing for DECnet-20 V3.0 (Phase III nodes)
2-7
Startup Dialogue for TOPS-20 Version 5.1
DECnet-20 Version 3.0 on a DECSYSTEM-20nO
• 3-2

TABLES
TABLE

1-1

7-1
7-2
7-3
A-I
A-2
A-3
A-4

A-5
A-n
A-7
A-8
B-1
B-2
B-3
B-4
B-5

NCP Command Keywords
• • • • • • • • • • • • • • 1-12
Relationship of Clock and Controller Parameters
to Mode of Line
• • • •
• • 7-8
EVENT Classes • • • •
• • • • • • •
• 7-9
7-10
Events • • • • • •
Node Parameters
• A-2
Line Parameters
• A-4
Circuit Parameters.
• • • • • • A- n
Logging Parameters •
• ••••
• • • • A-8
Event Parameters • • • • • • • • • • •
• A-9
Module X25-ACCESS Parameters •
A-13
Module X25-PROTOCOL Parameters •
• • ••
A-14
Module X25-SERVER Parameters •
A-15
DECnet-20 Specific Counters
• B-1
Data Link Circuit Counters for Permanent X.25
Circuits • • • • • • • • • • • • • • • • • • • • • B-3
Data Link Line Counters for LAPB Lines •
• B-3
X.25 Protocol Module Counters
• • • B-4
X.25 Server Module Counters
• B-4

vi i

June 1983

PREFACE

This manual describes the operational,
functions of TOPS-20 DECnet-20 Version
reference information are included.

control, and
monitoring
3.0.
Both tutorial and

The audience addressed is:
•

The DECnet-20 System Manager

•

The user with OPERATOR privileges who is engaged
in network
management and operational tasks under the direction of the
system manager

Readers are assumed to be experienced
in TOPS-20 operations and
familiar with computer networks. Previous experience with DECnet is
not assumed.
However,
if you have not yet read the
manual,
Introduction to DECnet, do so before continuing with this manual.
This manual contains two parts as follows:
Part I, Introduction, contains two chapters.
Chapter I briefly describes the DIGITAL Network Architecture
(DNA)
that serves as a model for the design of networks of
DIGITAL computers. Emphasis is on the relationships between the
Network Management Layer and other functional
layers.
The
DECnet-20 implementation of DNA is described.
Chapter 2 defines the basic network concepts in relation
operation of the DECnet-20 network.

the

Part II, DECnet Operation, contains five chapters.
Chapter 3 includes the minimum information needed by operators
responsible for keeping the network up and running.
Procedures
are explained, and examples are given for such tasks as manual
loading
of
the DN20 front end, controlling line states,
monitoring the network, and recognizing potential problems.
Chapter 4 is a tutorial on NCP, the control language that is the
operator's
and manager's interface to the network control
program, NMLT20.
Chapters 5, 6, and 7 describe the syntax and
function of NCP
commands processed,
respectively, by OPR,
the local node's
NMLT20, and the remote node's Network Management Program.

Chapter 8 describes X.2S NCP commands for
using Public Packet
switching Networks
(PPSNs)
if the Packetnet System Interface
(PSI) Version 1.0 software option
is
included.
If the PSI
software option
is not included, you can use the "TELL" prefix
(or SET EXECUTOR command) to send these commands to nodes that
support the X.2S facility.
If the PSI software is not included
and your network does not include nodes that support X.25,
you
can ignore this chapter.
Six Appendixes complete the manual.
Appendix A summarizes all
parameters
included
in the Network
Management V3.0 NCP commands.
There is a separate table for each
of the four entities:
NODE, CIRCUIT, LINE and
LOGGING.
Event
parameters are listed
in a separate table.
Applicability and
restrictions are presented both as defined
uy Digital Network
Architecture and
thus
relevant to all DIGITAL systems, and as
implemented specifically for DECnet-20 V3.0.

Appendix B summarizes the entity counters,
including
X.25
counters,
that may be displayed and zeroed by appropriate NCP
commands.
Appendix C describes
in detail
all messages related
to
the
execution of NCP commands and the state of the network:
output
responses;
informational messages;
and error messages.
Appendix D
devices.

table

currently

recognized

DECnet

line

Appendix E describes X.29 files for
use with the PSI system,
including PAD-parameter files, the X.29 configuration file, and
the X.29 herald text file.
Appendix
F
is
an
extended
network-related readings.

bibliography

suggested

Appendix G is a glossary.
Depending on your experience and responsibilities,
you may need
to
refer
to one or more of the
following manuals that contain more
detailed information on procedures or programs related
to DECnet-20
V3.0.
DECnet-20 User's Guide, Order No.

AA-J579A-TM

This manual contains procedures and examples for:
•

The MACRO programmer who will write network
programs

•

The nonprivileged terminal user who will use the TOPS-20
Command Language and the utility program, Network File
Transfer (NFT) , in network-related tasks.
The SETHOST
program, which provides remote login capabilities, is
also described in detail.

TOPS-20 PSI Version 1.0

application

June 1983

DECnet-20 Network Generation and Installation
No.
AA-K905A-TM

Procedures,

Order

This manual describes the TOPS-20 network configuration
tools,
the procedures for creating a host node in a DECnet
network,
the
procedures
for
configuring
a
DN20
communications front end, and the optional DN200 Remote Job
Entry Station
(RJE) •
Complete
network
installation
procedures,
including customer verification of the DECnet
software follow the generation procedures.
TOPS-20 DN200 Remote Station Guide, Order No.

AA-H786B-TM

This manual provides information on the operation of the
DN200 remote station for the operator at the remote station.
TOPS-20 PSI User's Guide, Order No.

AA-J533A-TM

This manual contains information on the following:
•

Writing a TOPS-20 FORTRAN or MACRO program that uses the
TOPS-20 X.25 software to access a PPSN (Public Packet
switching Network) •

•

Using the TOPS-20 X.29 software to
through a PPSN to a TOPS-20 host.

TOPS-20 PSI Installation Guide, Order No.

connect

terminal

AA-N819A-TM

This manual describes the configuration of the TOPS-20 PSI
nodes
in a DECnet network and details all generation,
verification, and
installation
steps.
It
describes
configuration tools, procedures to generate DN20 subsystems,
X25GEN (X.25 GENeration) program commands and
parameters,
and illustrates a sample system configuration.
TOPS-IO/TOPS-20 SPEAR Manual, Order No.

AA-J833A-TK

This manual describes the SPEAR program, a
library of
functions that analyzes and reports on error and significant
event information recorded by the operating system
ln the
ERROR.SYS file.
DECnet-20 operating systems record entries
for loads, dumps, and startups as well as errors.
You use
the SPEAR program's functions RETRIEVE and SUMMARIZE to
produce reports of errors and events recorded for DECnet-20.
You should also refer to the following non-DIGITAL publications if you
have the PSI software option, or if your network includes nodes that
support X.25.
CCITT publications that
contain
complete
information
on
recommendation X.3 (PAD) parameters.
(See the TOPS-20 PSI User's
Guide for a list of CCITT publications.)
Documentation provided by the user's PPSN (TELENET, for example).

TOPS-20 PSI Version 1.0

June 1983

The following suggestions are offered for your effective use
manual:
1.

this

You are the best judge of what you need to read, and how much
hands-on practice you need. Consider the following factors
in choosing what to read and what to practice:
•

Your own responsibilities and assigned

•

The depth of your present knowledge of TOPS-20 and DECnet

•

The extent of your experience as an
manager in a network environment

operator

system

•

The operating systems and the capabilities of
in your network

the

nodes

t~sks

Read the Glossary before you read the main part of the
manual.
You must understand the "network language" to
properly interpret descriptions of concepts and commands.
Terms In the Glossary are defined as they are to be
interpreted in this manual. The term "monitor", for example,
when used in the NCP command SET/DEFINE LOGGING, refers to
one possible destination of an event message and not to the
program that controls the operating system of the host.
This preliminary examination of the Glossary is to help you
in recall only.
Later, when you read a defined word in
context
in
the
manual,
you
can
refer
to
its
network-management interpretation as defined in the Glossary
for understanding.

Beginning with Chapter 4, after you have read each chapter,
take th~ manual to your terminal and enter the commands given
in examples, adjusting parameters as needed to conform to
your site's implement~tion and conventions. Try the same
commands again without using the manual. Use the "?" feature
if you forget the next element to be typed. Use the "?" to
review lists of possible entities or arguments for each
command.
Such practice sessions will be far more helpful
than "studying" the examples.
(The "?" feature is described
in Chapter 4. Several examples are included.)
With the exception of the SHOW NCP commands, any command that
changes parameter values has the potential for interfering
with the network activities of another network user.
When
possible, practice under supervision and always work within
the guidelines set by the system manager.
You can avoid
conflicts by using the aPR command SEND to inform one or all
network users of your intentions.
Such messages as the
following will be helpful to others on the network:
15:47:40 From Operator Terminal 23:
=>Reloading DN20 in 5 minutes
16:30:25 From Operator Terminal 25:
=>Restarting Galaxy in 5 minutes
You could also use
following format:

AEsend

produce

messages

the

[From PECKHAM on line 16 to all: restarting NMLT20 ••• ]

xii

System managers and operators using NCP commands to monitor
and control all nodes should read the entire manual.
If your
network includes DIGITAL operating systems
other
than
TOPS-20,
you should also read the appropriate manuals for
these operating systems.
If you are a central operator
in
the operations room, you will require a working knowledge of
all procedures in Chapter 3. Reading the remainder of the
manual is optional.
If the system manager has restricted your use of NCP
commands, concentrate on Chapters 2 through 6 in your initial
reading. All operators should refer
to Appendix F for
additional
reading whenever there
is a need for further
information.

This suggestion concerns you only if you have been operating
in a Phase II DECnet-20 environment.
Phase III NCP commands
have two changes in format.
The major change
is the
positioning of the entity (the component to be acted upon)
immediately after the command. Another change is using
the
hyphen to replace the underline symbol.
The following
example shows both these changes:
Phase II:
NCP>SHOW STATE LINE KDP 0 I
NCP>SET STATE LINE KDP 0 I OFF
NCP>
Phase III:
NCP>SHOW LINE KDP-O-I STATUS
NCP>SET LINE KDP-O-I STATE OFF
NCP>

xiii

June 1983

CONVENTIONS USED IN THIS MANUAL
The following conventions are used in
descriptions and in examples of dialogue:

this

manual

command

UPPER CASE

Upper case letters indicate actual input
required in a command string. You must type
an upper ca~e element in full or with an
abbreviation acceptable to the system.

lower case

Lower case letters in a command
string
indicate an input variable type (seconds, for
example), not the actual variable determined
by the operator (2, for example, for number
of seconds) •

[

]

Brackets indicate optional input.
(Brackets
are not in.cluded when you type the command.)

{ }

Braces indicate that one of several enclosed
parameters is applicable.
(Braces are not
included when you type the command.)

spaces

Spaces separate elements of a command. A tab
or multiple spaces may also be used. Spaces
must be input where shown.

red

Red characters indicate information you, the
user
typing
the command, enter.
Black
characters
indicate
system-supplied
i n form a t ion.
Indicates the place where you press
labelled RETURN or CR.

the

key

Indicates the place where you press
labelled ESC, ALT, or SEL.

the

key

Indicates the place where you type
the
control character designated by "character".

numbers

All numeric values that appear in this manual
are decimal numbers, unless otherwise noted.

The following acronyms
wordiness:

are

DLL
DNA
NICE
NML
NSP
PSI
PPSN

used

freely

this

manual

avoid

Da ta Lin k La ye r
DECnet Network Architecture
Network Information and Control Exchange protocol
Network Management Layer
Network Services Protocol
Packetnet System Interface
Public Packet Switching Network

TOPS-20 PSI Version 1.0

xiv

June 1983

PART I
INTRODUCTION

CHAPTER 1
SYSTEM OVERVIEW

1.1

DIGITAL NETWORK ARCHITECTURE AND DECnet

DIGITAL Network Architecture (DNA)
is a model upon which DIGITAL
computer networks can be built.
DNA presents a layered structure,
each layer corresponding to a major network function. A well-defined
set of interfaces allows each layer to communicate with its adjacent
layers; protocols provide rules and conventions for exchange of
information between peer layers in communicating nodes.
Refer to
Figure 1-1.
DECnet-20 V3.0 for the TOPS-20 system, is the third generation
(Phase
III)
of implementations based on the DNA model.
A general knowledge
of DNA will be helpful to both system managers and operators with
network management responsibilities.
The DNA model specifies functions
to be carried out in software
modules that implement each layer.
How the functions are implemented,
and which functions are implemented depends on the operating system.
For example,
an operating system with a minimum amount of core may
choose to implement only the minimum subset of Network Management
functions;
an operating system with a communications front end (DN20)
may choose to implement all Network Management functions.
Thus,
if
you know the functions that are
implemented by each node in your
net~ork, you can save time and effort.
This information is available
in the manuals and SPDs for the various DIGITAL operating systems.
Personal contact with the system managers of all nodes in your network
is highly recommended.

1-1

SYSTEM OVERVIEW

Legend:

= Data Interface to Adjacent Layer

C =

Network Management Control Interface

---_ = Protocoi ior Peer-Layer Communication between Noaes

To REMOTE NODE
UserWritten
Program
USER

-t

r--

NETWORK
MAII!AGEMEII!T

NETWORK
APPLICATION

f--

USER-DEFINED
PROTOCOLS

NETWORK INFORMATION
and CONTROL EXCHANGE
(NICE) PROTOCOL

------------------.
DATA ACCESS
PROTOCOL (DAP)

SESSION CONTROL

SESSION CONTROL
PROTOCOL

NETWORK SERVICES

NETWORK SERVICES
PROTOCOL (NSP)

I
I

L-

TRANSPORT

TRANSPORT PROTOCOL

DATA LINK

DIGITAL DATA
COMMUNICATION MESSAGE
PROTOCOL (DDCMP)

PHYSICAL LINK

(Specifications for
signal carrier control
replace protocols)

L-

Signal"Carrier

Figure 1-1 Communication between Adjacent and Equivalent
Layers of the DIGITAL Network Architecture
The major concepts of DNA are:
•

Transparency. In the context of the network, the system
manager or operator is the "user" of the DECnet utility, the
Network Control Program (NCP).
Once NCP is invoked, the
"user" is the module or routine that uses the capabilities of
the layer beneath it in the functional hierarchy.
Once you
have typed a command, all processing and routing of your
request is a function of the system.
You will receive a
response informing you of success or failure.

1-2

SYSTEM OVERVIEW

1.2

•

Local autonomy.
The node that is to execute an NCP command
retains the right to refuse to do so.
Such a refusal is
accompanied by a reason in the DECnet-20 V3.0 implementation.
Other operating systems mayor may not give a reason.
The
nature of the reason determines whether or not you repeat the
command at a later time.

•

High flexibility.
The functional orientation of the layered
structure lends itself well to the inclusion of new modules
and the insertion of new layers.
(See Section 1.2.)

•

Upward compatibility.
A Phase II node can communicate with
an adjacent node only, either a Phase II node or a Phase III
node.
The Phase II node derives no benefits from the routing
network, however, until it upgrades to Phase III.

•

Adaptability to the needs of individual network sites.
Within the limits set by Phase III minimum requirements, each
operating system implements only those functions appropriate
to that operating system.

•

Distributed or central management capability.
The Network
Management Layer (NML) of each DECnet-20 V3.0 node has access
to all other NMLs through the Network Information and Control
Exchange
(NICE)
protocol.
Thus, operators at any node can
control network management functions at any node in the
network, given the required willingness and capability on the
part of the remote node. When desired, the management of the
network can be restricted to one node.

THE LAYERED STRUCTURE OF DNA

The layered structure of DNA has, among several other advantages,
the
advantage of flexibility.
Adding new functions, and consequently new
layers and modules, is easily accomplished during product development.
DECnet-20 V3.0 offers a network of considerably more capability than
that offered by V2.
The changes are reflected
in the architectur~
which has developed as follows:
DECnet-20 V3.0
(Phase III DECnet)

DECnet-20 V2
(Phase II DECnet)
User Layer

User Layer
Network Management Layer

Network Application Layer

Network Application Layer
Session Control Layer

Network Services Layer

Network Services Layer
Transport Layer

Data Link Layer

Physical Link Layer

1-3

SYSTEM OVERVIEW
As shown in the chart, the layered structure reflects
added capabilities of DECnet-20 V3.0:

the

two

major

•

increased network management facilities (related modules
in the top three l~yers)

•

route-through capability (modules in the Transport Layer)

are

Beginning with the highest level: the User Layer, Application Layer,
and Network Management Layer carry out user functions;
the Session
Control Layer, the Network Services Layer, and the Transport Layer
carry out network functions;
and the Data Link Layer and Physical
Link Layer carry out the physical aspects of communication.
A brief descriotion of each of the
DECnet-20 V3.0, follows.
Refer
continue reading.

DNA lavers. as imolpmpntp~ for
to Fig~res'l-iand- l:~--b~~~~e you

Legend:
Logical communication - node A to node B
- - - - -

Physical communication - node A through node
B (lower 3 layers) to node C

H or T ~ Control information added at sending node (each
layer adds header; DLL adds header and trailer)
....

Control information removed by equivalent layer
at receiving node

t:---------------~----------------:~
,
,
Node A
Node B
Node C
,
,
, (Sending Node)

(Receiving Node),

B"
H ....

""~
"

I Data

.... "f
....
"

Network Management Layer

""
H~::
""

...

Network Application Layer

H~::

Session Control Layer

Network Services Layer

H~"

----

ij==============:;:;

H~::l

.......

Transport Layer

H •

User Layer

r
"
""
"

: /V
" /

Data Link Layer

"
T . . . ."
""

...
........ J

"! .....

Physical Link layer

Communication Facilities

MR-S-2300-B2

Figure 1-2

Logical Communication and Physical Path
of Routed Data

1-4

SYSTEM OVERVIEW
1.2.1

The User Layer

The User Layer supports user services and programs. NCP, the command
set of the Network Control Program, is in this layer. User-written
programs (MACRO programs using file system monitor calls) also reside
in this layer.

1.2.2

The Network Management Layer

NML's interaction with people is through the NCP command interface.
NCP commands allow operators at any node in the network to control the
network management functions of any other available Phase III node in
the network, as well as the local node functions. The NML, unlike
other architectural layers which interface only with adjacent layers,
has interfaces defined to every other layer. Refer to Figure 1-3 as
you read the following description of NCP command processing. All of
the action described is transparent to you. If your duties as an
operator require only that you enter NCP commands, you will not need
to understand transparent processing, but the system manager and
operators who are also systems analysts will find such knowledge
helpful if they have responsibility for diagnosis and maintenance.
14---'--~

I--"I~PC,,--:F_--; ORION

OPR

message

OPR PROCESSING:
ENTER PUSH
EXIT RETURN
HELP TAKE

IPCF
message
.--_ _-'--_ _...., NCP LOCAL PROCESSING:

~~~INE} LOCAL NODE

NCP

~RE::-:C:-E_IV_ER_ _ _-i ~b~~~
'---T-'-';;;';;";~---.o----'

NICE
RECEIVER

IS EXECUTOR

CANCEL
TELL command prefix
NICE
messages

- - NICE messages - - -

LOCAL
REQUEST
QUEUE

REMOTE
REQUEST
QUEUE

NICE messages
for Local Node
(EXECUTOR)

NICE messages
for Remote Node
(EXECUTOR)

To Remote Node
NICE RECEIVER

Logical
Link

Logical from Remote Node
Link
NICE TRANSMITTER

NICE
TRANSMITTER

NICE
PROCESSOR

NICE PROCESSING:
LIST
SET·
DEFINE·
SHOW
CLEAR·
DUMP
PURGE·
LOAD

TRIGGER
LOOP
ZERO

·Except when command
is processed by NCP

Circuit
Event

DATA
LINK
WATCHER

System Dependent Calls
for Network Management
To
Loopback
Mirror

(SET
CLEAR
DEFINE PURGE

System Dependent Calls
for
Data Link Service Functions
(LOAD DUMP TRIGGER LOOP)

Figure 1-3

OPR/NCP/NML Logical Processing Flow in
DECnet-20 V3.0

1-5

LIST ZERO
SHOW)

MR-S-2167-82

SYSTEM OVERVIEW
OPR parses all NCP commands. Correctly formatted commands that can be
processed by OPR (no action by NML is necessary) are processed and
executed immediately. All other NCP commands, those to be executed by
the local node and those to be executed by a remote node, paSS to the
NCP Receiver in the NML. A few commands have access to required data
for processing at this point and these are processed and executed.
All other commands are translated from NCP to NICE message format and
placed in the Request Queue.
The Request Queue also receives input from a NICE Receiver. The NICE
Receiver has received these NICE messages from a remote node for
processing and execution at the local node. All NICE messages to be
processed and executed by the local node are passed from the Request
Queue to the local NML processor.
The local NML Processor, using
system-dependent calls, directs these messages to appropriate routines
where local functions are processed. NICE messages to be processed by
a remote node are passed to the NICE Transmitter and sent by logical
link from the transmitter to the remote node.
Command responses are output to the terminal of the command node. All
NCP commands translated into NICE messages receive a response.
Commands that are processed before reaching the Request Queue do not
require a response. There is little delay and the timely execution of
the command at the local node serves as adequate response. Note that
there are two paths for responses from the NML Processor. If the
local node (the node pictured in the diagram) was both the command
node and the EXECUTOR, the response is from the local node and to the
local node. If the command was typed at the local node but the
EXECUTOR was set to be a remote node, the response is from the remote
node to the local node. The response to a command typed at a remote
node for processing at the local node is displayed at the remote node
where the command is entered.
Other processes within the Network Management Layer are the following:
The Data Link Watcher monitors the Data Link Layer
(DLL).
This
module can sense when there is a service request on a line from
an adjacent node. The Data Link Watcher reads the request (a MOP
protocol message)
and either services the line itself or passes
an appropriate request to the Upline Dumper or Downline Loader
process.
There is a Data Link Watcher in both the KLlO-E
(In DECnet-20, the Data Link
(TOPS-20) and the DN20 (MCB).
Watcher in the MCB front end acts in the manner described. In
the TOPS-20 KLlO node, the Data Link Watcher periodically checks
to see if the MCB front end is reachable; if it is not, it
attempts a dump and load.)
The Event Receiver receives remotely generated event messages and
checks these messages for proper syntax. Syntactically correct
messages are sent to the Event Recorder.
The Event Recorder examines the mask bits in the event messages
and distributes the messages to the indicated event sinks.
The Event Processor reformats raw event messages into processed
event messages. Filtering is performed, a date and time stamp is
added, and the processed events not filtered out are sent, as
appropriate,
to the local Event Recorder or to an Event
Transmitter to be sent to the remote Event Receiver.
The Event Transmitter uses a logical
messages to the Event Receiver of
node) .

1-6

link to transmit event
the remote node (the sink

SYSTEM OVERVIEW
The Loop Message Generator is responsible for all loop functions,
both those associated with a CIRCUIT or LINE and those associated
with a NODE.
Node loopback data is dispatched
to the Loopback
Mirror.
The primary function of the Loopback Mirror is to
reflect back to the generator the test message or an appropriate
error message.
CIRCUIT or LINE loopback is accomplished with or
without hardware assistance.
In a DECSYSTEM 2040S/2000, there is
a
Loopback Mirror
in both the KLIO-E and the DN20.
DECnet-20
V3.0 supports LOOP NODE and LOOP CIRCUIT.
The Downline Loader, using MOP protocol, accomplishes the loading
of DN20s from the host and DN200s connected to a DN20.
The Upline Dumper acts as a receiver of a dump from an
node.
The dump is stored on a file in the host node.
The Permanent Data Base
requests and supplies
SET ALL command.

1.2.3

adjacent

Processor processes DEFINE and PURGE
information with proper ordering for the

The Network Application Layer

This layer supports I/O devices and file access.
Modules within this
layer include the Loopback Mirror, Network File Access, and the File
Access Listener.

1.2.4

The Session Control Layer

The functions of the Network Services Layer in DECnet-20 V2 have been
expanded
for DECnet-20 V3.0.
Three DNA layers now support the
capabilities associated with logical links.
In Phase II, all logical
link
functions
were supported by the Network Services layer.
System-dependent functions of communication by logical links are now
supported by the Session Control Layer.
For example, the Session
Control module uses access control information in an incoming connect
request to perform system-dependent validation functions.

1.2.5

The Network Services Layer

Modules within this layer,
using
the Network Services Protocol,
control
the creation, maintenance, and destruction of the logical
links that provide the network's primary user-to-user communication.
It is the NSP layer that guarantees delivery, in proper sequence, of
all transmitted data.

1.2.6

The Transport Layer

This layer provides routing related processing.
The Transport module
first determines reachability,
that is, it determines if there is a
path from the sending node to the specified receiving node.
If there
is not, you receive an appropriate message.
If there is, a table
lookup is performed to determine the least-cost path.
The message is
directed
to the first node along the least-cost path.
(Routing
concepts are explained in more detail in Section 2.4.)

1-7

June 1983

SYSTEM OVERVIEW
1.2.7

The Data Link Layer

Using the DIGITAL Data Communications Message Protocol, DDCMP,
this
layer controls message sequencing and data integrity.
It does not
guarantee delivery, but it does ensure error-free communication
between adjacent nodes once communication is established.
An important fact to remember is that within one network the Data Link
Block Size must be the same.
If this rule is not followed when a node
is added to the network, the node will not communicate properly with
adjacent nodes.

1.2.8

The Physical Link Layer

This layer is concerned with the physical transmission of bits over a
channel.
The Physical Link Layer includes the software for driving
the
communications
hardware-interface
devices,
modems,
and
communication lines.

1.3

THE DECnet-20 VERSION 3.0 IMPLEMENTATION

Although the KLIO-E and the DN20 are two separate nodes,
they work
together as a
system.
The KL utilizes the DN20 capabilities to
participate fully in a Phase III network.
The KL
is technically a
phase II node with a Phase III NSP module.
The communication front
end (DN20) is a full Phase III routing node.
Features implemented
in the KLIO-E main processor
include file
transfer,
remote batch station features,
and a subset of Network
Management V3.0.
Features implemented in the communications front end
include adaptive routing through an intermediate node and exclude X.25
and DMP multipoint functions.
RJE-20 Version 2.0 software running
in
the DN200 is available as a DECnet-20 option.
The two parameter values BUFFER SIZE in bytes (a decimal number in the
range 290-576), and MAXIMUM ADDRESS (a decimal number in the range
2-255) are determining factors in the performance of your network.
These values are set during network generation.
BUFFER SIZE can not
be changed by the NCP command SET.
MAXIMUM ADDRESS can be changed
to
a
lower address by the SET command with the result that all nodes
above MAXIMUM ADDRESS will not be recognized.
An attempt to
raise
MAXIMUM ADDRESS above the value given during network generation will
result in an error message.
It is likely that you will repeat the network generation procedure at
some time
in the
future (to add lines or devices, or to change the
value of MAXIMUM ADDRESS or BUFFER SIZE). Certain relationships must
be understood to ensure that the BUFFER SIZE you select during network
generation will meet the requirements of your network.
The Data Link Layer (DLL) block size must be the same throughout the
network for communication between all DIGITAL operating systems
running DECnet.
To accept incoming messages of all possible sizes, an
EXECUTOR's BUFFER SIZE should be as large as the BUFFER SIZE of the
remote (sending) node.
The DECnet-20 default value for BUFFER SIZE,
576 bytes,
is the BUFFER SIZE most commonly used by DIGITAL systems
that support DECnet Phase III.
A node will refuse to accept a message
that is larger
than
its BUFFER SIZE.
There
is also a minimum
requirement for BUFFER SIZE.
To accommodate Transport messages,
the
BUFFER SIZE must be at least (2 * the MAXIMUM ADDRESS) plus 5.
1-8

SYSTEM OVERVIEW
DECnet-20 does not have a modifiable permanent data base and therefore
does not support the NCP commands DEFINE, PURGE, and LIST.
Data base
values established during network generation are read
from command
files at system startup and become the initial parameter values in the
volatile data base.
Appendix A summarizes all possible parameters and
describes both DNA and DECnet-20 applicability ("applies to EXECUTOR
only", for example) and restrictions ("display only", for example).
Currently, the DECSYSTEM-2020 remains a phase II node.
Within
the
restrictions outlined
in the section on compatibility, the 2020 can
participate in a Phase III network.

1.4

DECnet-20 OPTIONS

Two options are available for TOPS-20 DECnet on the 2040S/2060.
The RJE-20 Version 2.0 option includes software for the DN200
remote
job entry station and provides facilities for the DN200 to be downline
loaded, upline dumped, diagnosed, and maintained remotely.
Files for
RJE-20
loading and dumping are located at the central processor that
functions as the host node.
The DECnet-20 commands to the RJE station
are executed by the adjacent front end (DN20).
The PSI Version 1.0 option includes software for the Packetnet System
Interface
(PSI)
Gateway, which provides access to Public Packet
switching Networks (PPSNs).
The PSI Gateway is the interface between
a PPSN and a DECnet-20 network.
The Gateway software resides with
DECnet-20 software in a DN20.
The Gateway:
1.

Provides for communication over a
PPSN path between two
not
using
DECnet protocols as
cooperating
processes
end-to-end protocols.

Permits terminal access to TOPS-20 by a
user who dials by
phone connection
into a PPSN Packet Assembler/Disassembler
(PAD) fac iIi ty (see Append ix E).
NOTE
With DECnet-20 V3.0, you cannot downline
load
or upline dump a
remote node
through the DN20
if the PSI software
option is running
in that DN20.
The
RJE-20 and PSI options cannot co-exist
in the same DN20.

TOPS-20 PSI Version 1.0

1-9

June 1983

SYSTEM OVERVIEW
1.5

DECSYSTEM 2040S/2060 HARDWARE - DECnet-20 V3.0

The basic hardware configuration remains much the same as it was for
DECnet-20 V2.
As
in DECnet-20 V2, the DECSYSTEM-2040S/2060 system
consists of:
•

The KLIO-E Central processing Unit, running TOPS-20 software.
The
CPU
directs the entire operation of the system.
Contained in the CPU is the microcode
instruction set,
the
general purpose registers, interrupt and trap facilities, and
a subset of DECnet-20 software.

•

The console front end,
running RSX20F.
This front end
assists the CPU by handling the operator's console, terminal
communications, unit record peripherals, and diagnostics.

•

The communication front end,
running
the
Multifunction
Communication
Base
(~CB)
software.
MCB software,
in
cooperation with the CPU,
implements the V3.0 DECnet-20
functions.

•

The DTE hardware interfaces between the
the two front ends.

•

The DN200 Remote Job Entry Station running RJE-20 Version 2.0
software is available as a DECnet-20 option.

•

Communication devices as required.

main

processor

The KLIOE CPU supports only one DN20-MA communication front end
DECnet-20.
It
will
support one
IBM communication front
concurrently with the DECnet front end.

and

for
end

The major hardware change is
in line configuration and supporting
devices.
A maximum of 8 point-to-point synchronous links, with
combinations of three communication devices KMC1I/DUPll,
DMCll or
DMRll
are supported.
The DUP
(alone, not with the KMC) is not
supported in Version 3.0.

The PSI Version 1.0 software option restricts the basic hardware
configuration.
See the Software Product Description (SPD) for more
information.

1.6

DECnet IMPLEMENTATIONS

A DECnet network may consist of various DIGITAL operating systems,
each with a distinctive implementation. The concepts underlying the
implementation will be the same, but the
functions
implemented may
differ.
Although the DECnet Phase (whether Phase II or III)
is the major
factor
that determines the set of network functions available on a
particular node, it is not the only factor.
Even if all nodes in your
network are Phase III full
routing nodes, it is very likely that
several nodes support different sets of network functions.
When any
two nodes communicate,
their
interaction will be limited to the
functions common to both.

TOPS-20 PSI Version 1.0

1-10

June 1983

SYSTEM OVERVIEW
A Phase III node need only implement the Phase III minimum subset of
NCP commands.
A node
is not required to include any of the many
commands outside the subSet if the node has no use for them.
DECnet-20 V3.0 implements a subset of the NCP commands
in
the
phase
III DNA Network Management V3.0 Specification.
Not all parameters
that can be formatted and interpreted are supported.
You will not
receive an "action response" if a command is not implemented at the
receiving end.
The response you receive will probably be:
Unsupported Function or Option
DECnet implementations provide the ability to send commands to a
remote node for execution at the remote node.
Because it is a Central
Management node, the DECnet-20 node can format commands supported
by
other Digital hosts, even though the commands are not supported
locally.

1.7

DECnet CAPABILITIES

DECnet-20 capabilities are available to
the nonprivileged
terminal
user,
the programmer, and the system manager or operator.
The User's
Guide (see Preface for complete title and order number) describes the
DECnet
functions available to nonprivileged
terminal
users and
programmers.
This manual is specific to the operational, control, and
monitoring
functions
that are normally the
responsibility of the
system manager or of an operator designated by the system manager.
The system manager and operator use
the commands of the Network
Control Program
(NCP) to control and monitor the network.
It is the
system manager's responsibility to
inform the staff of critical
commands that should be used by only designated operators, or used at
off-hours only.
Chapters 4 through 7 describe the NCP command set in
detail.
Chapter 4 summarizes the general functions and features of
NCP.
The specific function of each command and
the meaning and
significance of allowed arguments are described in Chapters 5, ~ and
7•
A more general and more inclusive summary
follows:
•

DECnet-20

capabilities

Adaptive path routing.
Phase III routing nodes can send and
receive messages by routing through intermediate phase III
nodes.
Line and system failures can be detected, and, where
an alternate path exists, this path is chosen.
Adaptive path
routing is transparent to the user.
The system manager,
or
delegated operator, can change a routing path indirectly with
an NCP command.

1-11

SYSTEM OVERVIEW

I
1.8

•

Homogeneous network command terminals.
A user at one node
can log
into
the
system at another node in the network if
both systems are using the same operating system and
both
have implemented DECnet Phase III.
A Phase II DECnet-20 node
can only log into its adjacent Phase
III node;
it can,
however,
use its Phase III host to log into another Phase II
node adjacent to the same host.

•

Support of nodes of varying capabilities and
configurations.
DECnet-20 allows both end nodes
(nodes that can send and
receive but not forward) and phase II nodes to coexist on the
network within the restrictions described in section 2.5.1.

•

Because DECnet-20 V3.0.0 nodes are Central Management Nodes,
the NM modules understand the complete command set for DECnet
Phase III.
Thus. usinq
the TELL nodeid
prefix. YOU can
direct NCP commands n~t supported locally t~ other Phase III
nodes on your network.
A DECnet-20 V3.0 node can format any
command
that a
remote DECnet Phase III node can execute.
This includes multipoint- and X.25-related commands.

•

Extensive network management capability.
Using NCP,
the
system manager and operator can control and monitor network
activity from one or multiple nodes in the network.
Entity
states and characteristics can be changed in the permanent or
temporary data base.
Both current and
recent
network
activity can be displayed.
Loopback tests, downline loading
and upline dumping are available through NCP commands.

•

Logging of significant events.
Activity counters that you
can reset and display are available.
(See Appendix B for
de ta i 1 s • )
Ce r ta in even t s a n d
err 0 r s
( s ta r t- ups,
d um p s ,
hardware detected
errors,
for example) are also entered in
the file, ERROR.SYS.
You can use the SPEAR program to create
reports according to the specifications you select.

•

File transfer operation.
You can copy, delete,
or
type a
file
from a remote node;
you can obtain a directory from a
remote node;
you can submit a batch control file at a remote
node.

•

Support of up to four remote
option.)

stations.

(RJE-20

•

The X.25 facility for using Public Packet Switching
(PPSNs).
(PSI option.)

Networks

job

entry

OVERVIEW OF NCP COMMAND KEYWORDS

There are just 20 NCP command keywords that specify the action you
request.
The command keyword is always the first part of the command
that you type.
Command keywords mayor may not be followed
by an
entity
(a controllable network element such as a node or circuit) and
one or more parameters (values indicating characteristics or status of
an entity).
Most commands to remote nodes include both entity and
parameter(s).
Commands addressed to the local node may have entity or
parameter or both implied.
The complete command is a function of the
command keyword, the entity, and the parameter.

TOPS-20 PSI Version 1.0

1-12

June 1983

SYSTEM OVERVIEW
Each of the following commands is complete.
Command keyword only:
NCP>EXIT
NCP)HELP
Command keyword and entity:
NCP)SHOW EXECUTOR (SUMMARY is implied)
Command keyword, entity, and parameter:
NCP)SET EXECUTOR NODE nodeid
NCP)ZERO CIRCUIT cktid COUNTERS
A complete list of NCP command
keywords follows.
The order
is
alphabetic for ease of reference.
Because the action requested by a
command keyword is related to both the entity and parameter
that
follow the command keyword, the functions are defined in non-specific
terms.
Refer to the section indicated for a more specific description
of function.
Table 1-1
NCP Command Keywords
Complete
Description

Command

Function

CANCEL

Removes a command from the
Request Queue before
processing begins.

Section

CLEAR

Removes a value previously
entered in the volatile
da ta base.

Section ~.3 (EXECUTOR)
Section 7.6 (All entities)

DEFINE

Enters a value in the
permanent data base.

Section 6.2 (EXECUTOR)
Section 7.5 (All enti ties)

DUMP

Stores a copy of a
target node's memory
image in a dump file
at the host node.

Section 7.8.3

ENTER

Typed to OPR to access
a subset of OPR commands.

Section 5.2

1-12.1

n.e;

June 1983

SYSTEM OVERVIEW
Table 1-1 (Cont.)
NCP Command Keywords

Command

Complete
Description

Function

EXIT

Terminates an NCP session
and returns control to
TOPS-20 Command level.

Section 5.2

HELP

Returns the function and
major keywords for all NCP
commands.

Section 6.8

LIST

Displays on the user's
terminal information from
the permanent data base.

Section 7.7

LOAD

Allows one node to load
the system image file to
a remote node adjacent
to the EXECUTOR

Section 7.8.2

LOOP

Requests a loopback test.

Section 7.8.4

PURGE

Removes a value or values
from the permanent data
base.

Section 6.4

PUSH

Changes control from NCP
to TOPS-20 Command level.

Section 5.2

RETURN

Changes control from NCP
to Operator Command level.

Section 5.2

SET

Enters a value or values in
the volatile data base.

Section 6.1 (EXECUTOR)
Section 7.5 (All entities)

SHOW

Displays on the user's
terminal information from
the volatile data base.

Section 6.5 (SHOW QUEUE)
Section 7.7 (SHOW entity)

TAKE

Retrieves and executes a
file of NCP commands.

Section 5.2

I TELL

Directs the command that
follows to a remote node
for execution.

Section 5.2

I TRIGGER

Requests the target node
to send a load request.

Section 7.8.1

WAIT

Used in Batch programs,
delays processing the next
command for the specified
number of seconds.

Section 5.2

ZERO

Logs counters and then
zeroes them.

Section 7.9

(prefix)

1-13

(EXECUTOR)

CHAPTER 2

NETWORK CONCEPTS

2.1

NODES AND DATA LINKS

Nodes and data links are the two fundamental elements in the network.
As used in this document, a network node is an implementation that can
pass data, using DECnet, to one or more remote nodes.
Network nodes
are classified
in several ways.
One basic classification divides
nodes into local and remote.
From your point of view as an operator
typing NCP commands, the local node is the node where your terminal is
located (the TOPS-20 node in DECnet-20). All other nodes,
including
the MCB front end, are remote.
From Network Management's point of
view, the local node is the node acting as EXECUTOR;
this is usually,
but not always,
the node at which the command is typed. Any active
node in the network is remote to any other active node in the network.
Thus, by definition, the central processor is remote to its connected
MCB front end.
An adjacent node is one that is physically connected
to the node that it is termed adjacent to. The MCB front end is
adjacent to the KL central processor.
Nodes are also classified according to their network function.
In
descriptions of network functions, you will frequently see the terms
command (or control) node, executor node (or executor),
target node,
and host node.
The command node is the node where the command is
typed. The executor is the node where the command you type will be
executed.
The target node is the node where the action requested by
the command will take place. The host node is the node where needed
facilities for effecting the command may exist (storage space for
files,
for example).
These functional
classifications are
not
mutually exclusive.
For example, a node may serve as executor,
command, host node, and target node. Refer to Figure 2-1.
Logical links are logical connections. A physical link connects node
A to node B,
for example;
a
logical link connects Mary at one
terminal to Bob at a remote terminal, or connects a
user process at
one node to a utility process at another node.
The logical link
encompasses the end-to-end transmission of data.
Lines are the
physical media for logical links.
In a logical link from node A to
node C by way of node B, there is one logical link but there are two
physical links.
The term ncircuit n is synonymous with a logical
point-to-point connection.
Circuits are described
in detail
in
Section 7.2.5.

2-1

NETWORK CONCEPTS

Command: TELL DxxxxA LOAD DN200A
KL1
TOPS-20
node

KL 1 = Command node
Host node

KL 1 = Command node
Executor node
Host node

DN20 = Executor node

DN20 = Target node

DN200 = Target node

Command: TELL DxxxxB LOAD NODE DN200B

~
~
L2

FILES

TOPS-20
node

DN20
MCB node
"
DxxxxB

node
KL 1 = Command node
KL2 = Host node
DN20(B) = Executor node
DN200B = Target node

Figure 2-1

2.2

Types of Nodes by Network Function

THE PSI GATEWAY

The PSI Gateway interfaces a DECnet network to an X.2S PPSN over a
leased data communications line.
The
internationally recommended
protocol
for such an
interface
has
been
defined
by
CCITT
Recommendation X.2S.
The Gateway's main responsibility is to generate
and interpret the protocol messages necessary to communicate with the
X.2S node at the opposite end of the data link to the PPSN.
The PSI option also includes software to permit access to the Gateway,
and
thus
the X.2S network, from a TOPS-20 DECnet Version 3.0 node.
These software units include the Gateway Access Routines and the X.29
Server.
Figure 2-2
illustrates the placement of the TOPS-20 PSI
Gateway Access Routines and
the TOPS-20 Gateway Software
in the
central (TOPS-20) processor and the communications processor (DTE).

TOPS-20 PSI Version 1.0

2-2

June 1983

NETWORK CONCEPTS

I
~~~;-2°1
I
Local

OECSYSTEM-20
User Program

~--------------~

Local
OTE

ON20
TOPS-20 PSI
Gateway
Software

Remote
OTE

Remote
Node
Remote
User
Program

MR-S-2247-82

Figure 2-2

TOPS-20 PSI Gateway Software Components

TOPS-20 PSI Version 1.0

2-3

June 1983

NETWORK CONCEPTS
The Gateway Access Routines are a collection of subroutines that the
user
invokes to perform X.25 functions (see the TOPS-20 PSI User's
Guide).
These routines are linked with the user's software ~form a
single-job image.
They maintain communication with the Gateway by
using the Gateway Access Protocol over a DECnet logical
link.
This
permits users
to directly manipulate
the X.2S protocol at the
Gateway's interface to the X.25 network, even though the user may be
on a DECnet node that is geographically distant from that interface.

The X.29 feature permits a user at an asynchronous terminal to log
in
to a
TOPS-20 system that has Gateway access to an X.25 network.
The
terminal is connected to a PAD, either through a direct asynchronous
connection or a modem.
The X.29 Server uses the X.29 protocol to
control the terminal session through communication with the PAD.
The
X.29 Server uses the Gateway Access protocol to communicate with the
Gateway.
It communicates with the NRT Server
in the TOPS-20 host
using
the Network Remote Terminal
Protocol
(NRTP).
Figure 2-3
illustrates the components needed for such a connection.

TOPS-20 PSI Version 1.0

2-4

June 1983

NETWORK CONCEPTS

TOPS-20
Host

DECSYSTEM-20

~i--------------~

User Job

DECnet
Logical
'-----------1 LINK

,...----------1 NRT
DECSYSTEM-20 Protocol

X29SRV
TOPS-20 PSI
Gateway
Access Routines

MR-S-2756-83

Figure 2-3

X.29 Terminal Access to a TOPS-20 Host

TOPS-20 PSI Version 1.0

2-5

June 1983

NETWORK CONCEPTS
2.3

ENTITIES

The term "entity" is used in reference to NCP commands. An entity is
the element on which the command is to act:
the node, for example, in
the command SET NODE nodeid HOST hostname;
or the active lines in the
command SHOW ACTIVE LINES COUNTERS.
An entity in the sinqular form is
one of:
CIRCUIT, LINE, LOGGING, NODE, and MODULE.
ACTIVE and KNOWN
preceding CIRCUITS,
LINES,
LOGGING,
NODES, and MODULES are allowed
plural forms.
NODE has a third plural form, LOOP NODES.
Entities are
described in detail in Chapter 7.
The MODULE entity is provided for users of the TOPS-20 X.25 software.
The MODULE entity takes one of three forms:
MODULE X25-ACCESS, MODULE
X25-PROTOCOL, and MODULE X25-SERVER.
The MODULE entity is described
in detail in Chapter 8.

2.4

ROUTING CONCEPTS

Routing,
the primary function of the Transport Layer,
is
the
determination of the physical path that packets will follow between
nodes.
This path is determined at each node.
At each intermediate
node, the transport module reads the header of the packet to determine
the destination,
then reads the
routing
table to determine the
least-cost path.
Within
the limits set by the configuration, the
routing table is automatically updated when a path is no longer an
acceptable choice.
Tte path may also be changed indirectly by the
system manager or operator using
the appropriate NCP command
(SET
CIRCUIT cktid COST cost).
Refer to Figure 2-4.

TOPS-20 PSI Version 1.0

2-6

June 1983

NETWORK CONCEPTS

Legend:

= node

O--s--O

= data link
arrow = direction associated with n
n = cost of circuit

= 1 hop

Node E is a non routing node; nodes A, S, C, and D are routing nodes;
all nodes are Phase III nodes.

E
MR·S·2301·82

From
Node

To
Node

I
All
links
up

)
D

Link
between
Sand D
down

Path
Cost

Least Cost
Path

I3--->D
I3--->A--.D
I3--->C-->D

3
6

I3--->D

D-->B
D-->A--.B
D-->C--.B

3
6

I3--->A--.D
I3--->C--.D

6
5

I3--->C--.D

D-->A--.B
D-->C-->B

D-->A--.B

Path

Path
Length
1
2
2

D-->B

1
2
2

2
2
2
2

NCP Commands for Control:
FOR CIRCUIT

FOR EXECUTOR

SET NODE D2136A MAXIMUM COST 30
SET CIRCUIT DMR-O COST 3
SET CIRCUIT KDP-0-2 COST 4 SET NODE D2136A MAXIMUM HOPS 4
SET NODE D2136A MAXIMUM VISITS 8

Figure 2-4

2.4.1

Routing for DECnet-20 V3.0

(Phase III nodes)

Node Routing Types

There are three types of nodes supported by DECnet-20 V3.0
routing:
routing
nodes,
nonrouting
nodes,
and
Phase I I nodes.
The
characteristics and capabilities of the three major types of nodes
follow.

2-7

June 1983

NETWORK CONCEPTS
Routing Nodes
Routing nodes allow communication between nodes that are not adjacent.
This capability is first realized in Version 3.0.
Diagrammatically:
Phase II nodes:
Phase II Nodes:

--8

L--!
Communicating path is A to B.
Phase III nodes:
Phase III Nodes:

MR-S-2040-82

Communicating path is A to C through B.
Under normal conditions, neither A nor C is aware of Bls participation
in the
routing above
the DNA Transport level.
This means that the
operator perceives the connection as a direct A to C connection.
If
all nodes
in the network are
routing nodes,
then each node can
communicate with each other node in the network.
Nonrouting Nodes
Nonrouting nodes are Phase III nodes that have implemented a subset of
Phase
III capabilities.
They must be located adjacent to a Phase III
routing node.
Although they can send messages to any Phase
III node
in the network, they can not perform "route-through" for an incoming
message not addressed to themselves.
A nonrouting node must be placed
as an end node in the network, connected to the network by only one
link.
The nonrouting node can then both send and receive messages.
Diagrammatically:
Diagrammatically:

~R
'1R-S-204' -82

2-8

NETWORK CONCEPTS
Assume nodes A, B, C, and D are routing nodes;
nodes E and Fare
nonrouting nodes;
all nodes are Phase III nodes.
E can send messages
to A, B, C, D, F, and self, and can receive messages from each of
them.
Similarly, F can communicate with A, B, C, D, E, and self. As
long as each node in the path from E or F to the destination node is a
routing node, messages can continue through the network for a maximum
of six hops.
Messages from any node to E or F can also continue
in
this manner.
The placement of the nodes diagrammed suggests that D does more
communicating with E and F than with A, B, and C.
Note that if B goes
off line, D (and E and F) can not send to or receive from A, B, or C.
The network shown also suggests that A, B, and C expect to communicate
with each other more than with D.
Note that each of these nodes has a
direct path to each of the others:
one direct one-line or "hop" path;
and one two-hop path:
for example, A to B and A to B through C.
You
considered
routing implications when you planned the topology of your
network.
Certain factors may, however,
suggest changes that will
increase efficiency.
Actual
traffic
in a functioning network, new
network nodes, and new or relocated hardware, may all
suggest
topological
changes.
NCP commands are available to accomplish this.
Such changes should be made by the system manager, or someone
delegated by the system manager.
(Sections 2.4.3 and 2.5.1 are also
related to routing.)
Now let us reverse the positioning of D and E as shown below:
R

With this topology, both D and F can exchange messages only with E.
E
loses nothing
in the repositioning:
there is a direct line to D and
F;
all other nodes are routing nodes. With this positioning, we have
three links
into a nonrouting
node.
As previously mentioned, a
nonrouting node must be connected to the network by only one link.
The topology shown is illegal.

2-9

June 1983

NETWORK CONCEPTS
Phase II Nodes
Phase II nodes can participate in a Phase III network, but a Phase
II
node gains none of the DECnet capabilities added for DEcnet Phase III.
The Phase II node does not support full routing:
it can send
packets
only to an adjacent node
to which it is physically connected;
it
cannot forward packets it receives to any other node in the network.
Therefore, a Phase II node is logically located as an end node within
a Phase III network.
Phase III NCP commands will not be understood by
the Network Management process
in a
Phase II node;
Phase II NCP
commands will not be understood by the NML in a phase III node.
An
appropriate error message will be output if such commands are sent or
received. With the exception of NCP, however, a
Phase II node can
communicate with an adjacent phase III node:
NFT, SETHOST, and
user-written programs in MACRO will be unoerstood by both Phase II and
Phase III nodes.
Refer to the first diagram of nodes A,
B,
C,
D,
E,
and
F.
NOw,
imagine a phase II node, G, positioned between C and D, as shown:

Node G needs a point-to-point link to communicate.
Both physically
and
logically, node G has only two links for communication, the two
lines from its two adjacent nodes. G perceives the "network" as made
up of three nodes:
C, D, and itself. D perceives itself as having a
link to G, but is (functionally) unaware of G's link to C.
Likewise,
C perceives its link to G, but does not perceive the D to G link.
Both C and D perceive all nodes, but for both the path to G is the end
of communication.
Although we have added a node and two lines of
communication, A, B, E, and F perceive the network exactly as shown in
the diagram without node G.

2.4.2

The Adaptive Least-Cost Routing Algorithm

Routing and related functions are accomplished in the Transport Layer
of
the
DN20
communications
front end.
Although routing
is
transparent, you, as the system manager or operator can,
through the
NML interface to Transport, obtain information about and control the
routing operation.
Therefore, you need to understand how routing
is
determined.
More
specifically,
you
need
to understand
the
significance of parameter changes in the NCP commands that you use.
The
"Transport
language"
includes
a
few common terms with
transport-specific meanings.
Figure 2-4 is designed to define these
terms and, at the same time, provide you with a basic understanding of
the DECnet-20 routing algorithm.
Be sure to read
the legend
first,
and
refer
to
the diagram as you mentally follow the examples at the
bottom of the figure.

2-10

June 1983

NETWORK CONCEPTS
2.4.3

Congestion and Packet Delivery

The Transport Layer attempts to keep network traffic through its node
at a manageable level.
It accomplishes this through a stringent
assignment of buffers. When buffer resources are exhausted, Transport
refuses packets from NSP and discards packets from other nodes.
If the data link remains open, NSP guarantees eventual delivery
(once
it accepts the message) between Phase III nodes in a network.
Timely
delivery occurs under normal traffic loads.

2.5

SUMMARY OF PHASE II/PHASE III COMPATIBILITY

There are three types of nodes permitted in a Phase III network:
Phase III Full - a Phase III Full
routing node has software
that
satisfies the route-through capability. This node has no restrictions
in connecting to other phase III nodes.
Phase III Nonrouting - A phase III Nonrouting node implements a subset
of Phase III capabilities.
It can always communicate with its
adjacent Phase III node.
In addition,
when located adjacent to a
phase III Full node,
the Full Routing node will accomplish the
"route-through" for the nonrouting node.
Phase II - this is a DECnet Phase II node with nothing
II nodes can route to self, or to an adjacent node.

2.5.1

added.

Phase

Topological Restrictions

To achieve maximum performance within the network, certain types of
nodes must be strategically placed within the network.
A Phase III
Full routing node is not restricted in placement within
the network.
Because a Phase II node has no
route-through capability, it can
communicate only to itself and adjacent nodes.
Therefore, the optimum
location for a Phase II node in a Phase III network is as an end node.
A Phase III nonrouting node must be adjacent to a Phase III full
routing node.
A nonrouting node is permitted only one link into the
network, and is positioned as an end node.

2-11

June 1983

NETWORK CONCEPTS

Implementation Restrictions

2.5.2

Although the DECnet phase (II or III) is certainly the major factor
that determines the set of network functions available at a particular
node, it is not the only factor. Even if all nodes in your network
are Phase III nodes, it is very likely that several nodes will support
different sets of network functions. When any two nodes communicate,
their interaction is limited to functions common to both.
A Phase III node need only implement the Phase III Minimum Subset of
NCP commands.
A node is not required to implement any of the many
commands outside the subset if the node has no use for them. You will
not receive a "completed successfully" response to a command that has
not been implemented by the executor of that command.
The response
will be "Failed" followed by the reason for the failure (error
message). The commands listed below are the Minimum Subset for Phase
III nodes. Commands in the minimum subset should be available for all
Phase III nodes. The required capability is described first. The NCP
commands that are required to implement the capability follow.
•

Network Services Layer counters on at least one node of
pair of nodes that will communicate using logical links:

any

SHOW NODE nodeid COUNTERS
ZERO NODE nodeid COUNTERS
•

Display
minimal
information
communications link and node:

point-to-point

about

level

logical

SHOW CIRCUIT cktid SUMMARY
SHOW NODE nodeid SUMMARY
•

Test communication using the node
test:

link

loop

SET NODE nodeid NAME nodename CIRCUIT cktid
CLEAR NODE nodeid NAME CIRCUIT
SHOW NODE nodeid SUMMARY
LOOP NODE nodeid (accessctlJ [WITH blocktype]
[COUNT count]
[LENGTH lengthJ
•

Disable a point-to-point communication link:
SET CIRCUIT cktid STATE OFF

•

Disable a hode:
SET NODE nodeid STATE OFF
This command is given for the local node or the executor node
only.

2-12

June 1983

NETWORK CONCEPTS
•

Display and zero Data Link Layer counters on all multipoint
control nodes and on at least one end of each point-to-point
link:
SHOW CIRCUIT cktid COUNTERS
SHOW LINE lineid COUNTERS
ZERO CIRCUIT cktid COUNTERS
ZERO LINE lineid COUNTERS

•

Display and zero Transport Layer counters and display
control of Transport Layer events for all routing nodes:

and

SHOW CIRCUIT cktid COUNTERS
SHOW NODE nodeid COUNTERS
ZERO CIRCUIT cktid COUNTERS
ZERO NODE nodeid COUNTERS
SET LOGGING sinktype EVENTS eventlist [sourcequal] [sinknode]
NAME sinkname
STATE sinkstate
CLEAR LOGGING sinktype EVENTS eventlist [sourcequal] [sinknode]
NAME
SHOW LOGGING sinktype SUMMARY [sinknode1
•

For central management nodes, send NCP commands
managed nodes:

remotely

TELL nodeid [accessctl] NCP command
SET EXECUTOR NODE nodeid [accessctl]
CLEAR EXECUTOR NODE
DECnet-20 V3.0 can parse
the complete phase
III NCP command
(except for the commands excluded in Section 1.6), and can format
possible responses.
This does not mean that all commands with
possible parameters can be executed.
(The complete set of
commands is described in detail in Chapters 5, ~, and 7.)

set
all
all
NCP

The following DIGITAL computer systems all support some set of DECnet
functions.
Because one or more of these systems may be in your
network now, or in the future, the basic
texts for each operating
system are listed.
Manuals that describe the capabilities of nodes in
your network should be available at your site.
(There
is additional
documentation for
these
systems.
The manuals listed represent the
minimum you should have on hand.)
RSX DECnet

RSX DECnet User's Guide
RSX DECnet System Manager's Guide

DECnet-IAS

RSX/IAS DECnet User's Guide
RSX/IAS DECnet System Manager's Guide

DECnet-VAX

DECnet-VAX User's Guide
DECnet-VAX System Manager's Guide

DECnet/E

RSTS/E DECnet/E

DECnet/RT

RT-ll DECnet/RT User's Guide

~ystem

Manager's Guide

Because network software is periodically updated, it is suggested that
the local system manager contact the system managers at the sites of
nodes in your network that are other than TOPS-20 systems.
They will
be able to give you the order numbers of the manuals appropriate for
the software that they are currently using.

2-13

NETWORK CONCEPTS
2.6

EVENT LOGGING

The Event Logger is one of the modules
in
the Network Management
Layer.
This module provides the capability for logging significant
events - such occurrences as a line shutting down,
errors
in packet
headers,
or
error
thresholds reached.
Logged events help in
maintaining the network, recovering from failures,
and
planning
for
the future.
See Tables 7-1 and 7-2 for a complete list of events that
can be logged from each of the DNA functional layers.
The operator or system manager can control event logging by using
the
NCP command SET LOGGING EVENT eventlist.
Once the events to be logged
have been selected and set and
the logging sinks determined,
the
operator
or
manager
can
examine
the event logger's output
periodically.
Several avenues that might be followed in utilizing the
logged data follow.
These are only suggestions~
Familiarity with the
network, gained in daily operations, will suggest many more ways to
capitalize on the event logging feature.

2.7

•

Network application programs can be tested by
setting
specific counters to
zero, running the application program
and then examining
the event output to observe how the
program affected node and/or network performance.

•

Counters specific to the Transport Layer
(circuit counters
that monitor terminating and
transit congestion loss and
circuit downs, for example) can be used to identify potential
problems.

•

An examination of the times and dates when potentially useful
information
is lost can be helpful.
There are many queues
and their lengths cannot be
infinite.
Circumstances will
occur when an event will no longer fit on the queue.
This
will be recorded as an "event-lost" event, not as an error.
All
processed events are time stamped and identified as to
source node and entity name, if any is
indicated.
On the
basis of these
factors certain changes can be made:
the
logging sink can be moved, peak loads can be adjusted by
schedule changes, or particular events can be dropped from
logging.
Any changes so made should be evaluated by a
reexamination of the same event counts that suggested the
adjustment.

OPERATOR FUNCTIONS AND RESPONSIBILITIES

An "operator", in the context of Lhis manual,
is any terminal
user
with OPERATOR or WHEEL privileges who is given the responsibility for
entering NCP commands or running system or network-related programs
(requiring OPERATOR privileges)
for
the purpose of monitoring or
controlling the network.
An operator's duties may consist of well
defined, simple, and repetitive tasks, or may consist of complex tasks
that can not be predefined.
Some operators will have responsibilities
that combine both types of duties.
Because of the many variations in
personnel and site management, your responsibilities as an operator
may be quite different from
those of another operator.
However,
whatever these responsibilities are, it is important that you:
•

Have a clear idea of what your responsibilities are

2-14

June 1983

NETWORK CONCEPTS
•

Have (or gain)
both the
software and
needed to perform your assigned tasks

hardware

knowledge

•

Consult with the system manager, or someone designated by the
system manager, whenever you are in doubt about a procedure.

A few NCP commands have
the
potential
for disrupting
the entire
network.
Several
commands will,
if formatted
with valid
but
ill-chosen parameters, at least disrupt your own node's performance.
No
operator
should
enter an NCP command without a complete
understanding of the probable effect of the command.
Do not make
changes in the permanent data base of a remote node without consulting
the system manager at the remote node.
All commands to change either
the volatile or permanent data base of a remote node must include any
required USER and PASSWORD parameters.
A list of functions commonly performed by operators follows.
As an
operator,
you may be responsible for one or several of the following
functions:
•

Automatic startup of the network

•

Manual startup of the network

•

Manually loading the DN20 (the DECnet-20 communication
end) if required

•

Starting up software or devices
(GALAXY, printer, for example)

•

Loading and starting adjacent nodes

•

Monitoring local and remote nodes

•

Securing a dump after a crash (local or remote node)

•

Changing parameters in the permanent or volatile
data base

•

Shutting down a node or all network operation

•

Changing the state of network entities

•

Changing the routing path indirectly
cost

•

Gathering
(and possibly
errors, performance)

•

Running SPEAR for network events and errors

•

Using network command files and
possibly creating
files to be executed at scheduled intervals

•

Testing network application programs

analyzing)

2-15

needed

the

front
network

(temporary)

changing
statistics

the

line

(events,

command

NETWORK CONCEPTS

•

Recognizing po tential problems
error rate, for example)

Examining the
• security

central

console

(high
log

response
file

for

time,

high

breaches

•

Using diagnostic tools

•

Keeping all network-related logs and forms up-to-date

Once you have a clear idea of your responsibilities, concentrate first
on the sections of this manual that describe the functions you need.
Get working at the terminal as soon as possible. Use the Index to be
sure you have read all pertinent information. The Index contains
pages that reference examples and Appendix material as well as the
pages of primary text in the main section of the manual~

2.8

SYSTEM MANAGER FUNCTIONS AND RESPONSIBILITIES

The DECnet-20 System Manager has final responsibility for the total
functioning of the node in the network. The tasks that the manager
performs depend on several factors. The principal factors are:
•

The degree to which the management of the network is
distributed.
(Will there be standards and procedures from a
central management node? Is the local node responsible for
some or all of the control of other nodes in the network?)

The complexity of the network of which the local node is a
• member.
(Are there non-DECnet-20 nodes in the network? What
and where are available resources?)
•

The knowledge and experience of the manager's staff.
(How
can responsibilities best be allocated? What training is
needed and how can it best be achieved?)

Ideally, a system m~nager concentrates on activities that call for
planning and requIre a high degree of knowledge and expertise.
Actually, however, you may frequently have to perform some of the
operator duties described in the previous section. Listed below are
the functions that are the peculiar responsibility of a system manager
in a "typical" DECnet-20 environment.
•

Generating and installing the DECnet-20 software. A DIGITAL
software specialist performs the original generation and
installation of the DECnet software.
You should, however,
follow the procedure and read the appropriate manual. The
network may grow in number of nodes and other physical
resources.
Some of the steps followed in the original
generation and installation may be repeated in the future by
you as system manager. Some of the parameters established
during system generation may require change due to changes in
resources.
You will become aware of these and be better
prepared to make intelligent changes if you
use
the
generation and installation procedures as a learning device.

June 1983

NETWORK CONCEPTS

•

Assigning personnel
to specific duties.
For reasons of
security, as well as efficiency, operators should be aware of
those functions they are not to perform, as well as those for
which they have responsibility.
For example, certain NCP
commands that have the potential
for disrupting services l
should be restricted in use.

•

providing appropriate documentation to all operators who will
use NM functions.

•

Scheduling network services. To the extent possible, network
startup and shutdown should be set up automatically at the
times dictated by the nature of the node's needs.
At least
until operators become proficient in their use of the
network,
the manager should
consider
a
schedule
of
stand-alone time for demonstrations and practice.
Initial
schedules should attempt to avoid extremes of traffic, but
the
ideal schedule can.not be built until traffic patterns
have been analyzed.

•

Handling of physical resources.
The manager should provide
both hard copy and on line sources of information on the node
"locations of processors,
terminals, peripherals, network
application
programs,
remote
stations, and any other
facilities to be used in the network.
The manager should
provide information to all operators on the use of all
facilities.
All
resources
should
be
analyzed
for
performance.
Error and performance data should be kept for
maintenance engineers and specialists, as well as for site
planning and scheduling.
Each operator should be able to take simple
recovery
procedures
(manual reloads, for example). Systems analysts,
network programmers or the manager should set up command
files
for procedures that will be repeated frequently.
Not
only will response be faster, but this procedure can be used
to increase the operator's effectiveness in network activity.

•

Checking the surveillance log periodically. Whenever OPR is
running
and
you
have typed "ENTER NCP",
the system
automatically records all OPR/NCP activity on the network.
This log
includes the terminal number where the NCP command
was entered and the command itself. The current log has the
file name PS:<SPOOL)OPERATOR-SYSTEM.LOG.n.
When ORION is
started
or
restarted,
this
file
is
copied
to
PS:<SPOOL)OPERATOR-SYSTEM-LOG.nnn.n where nnn is the next
highest generation. This is the file you can examine to
observe all network activity by date and time.
(Use the
VDIRECTORY command to find the date and
time you wish to
observe because there are frequently multiple files.)

•

As the system manager, you should at all times be aware of
the operational status of the network - both nodes and
devices used in your network activities.
Functions you may
have to perform include: adjustment to line costs to achieve
new routing paths, shutting down network components or
circuits,
sending messages to all network operators, and
analyzing errors and failures.

2-17

June 1983

NETWORK CONCEPTS

•

Bringing new devices, circuits, and users on line.

•

Gathering statistics on
errors, and failures.

network

use,

traffic

congestion,

You may delegate many of your responsibilities, but you are a key
person in the success or failure of your network. You can ensure
success by closely monitoring both the system and the manner in which
your staff performs. You may have to assume some training duties for
inexperienced operators.

2-18

PART II
DECnet OPERATION

CHAPTER 3
RUNNING DECnet-20

3.1

DECnet STARTUP PROCEDURES

To run DECnet on the DECSYSTEM-2040S/20nO, the communication front end
processor
(DN20) must be loaded with the appropriate DECnet software.
This normally occurs automatically when TOPS-20
is loaded.
It can
also be performed manually at any time after TOPS-20 is loaded.

3.1.1

Automatic Startup on a DECSYSTEM-2040S/2060

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 file PS:(SYSTEM>SYSJOB.RUN.
This file contains RUN commands for
major system programs (for example, ORION, QUASAR, INFO, MAILER, and
LPTSPL). SYSJOB also starts PTYCON which executes the PTYCON.ATO
command file.
PTYCON subjobs run the network management program NMLT20,
the MCBNRT
server, FAL, X29SRV
(PSI only)
and OPR.
The OPR subjob processes
command files that start all necessary batch streams, printers, and
readers.
In addition, the OPR subjob processes the file NCP.CMD.
This command file contains the NCP commands required
to setup the
network management volatile data base.

These commands specify the node names and addresses (node numbers) for
the network as well as the parameters required to load and dump the
DN20 front end. After OPR processes the NCP command that enables
autoservicing for the circuit to the front end, the network management
program will check the status of the front end and,
if necessary,
automatically initiate a down line load.
After you receive the topology message indicating that the node is
online, both the TOPS-20 KLIO node and the MCB DN20 node are ready for
network activity.
If you have an RJE station and wish to start it up
at this time, follow the procedures in Section 3.2.4. Two procedures
for observing eHKll output are described in Section 3.7.
Figure 3-1 shows a dialogue to bring up TOPS-20 VS.l with DECnet-20
V3.0. The CPU in the example is a DECSYSTEM-2060.
Startup procedures
for your system will be similar, but differences may exist because of
the hardware or software at your site.
(Because the first command in
the PTYCON.ATO file
is "SILENCE", not all steps in the startup
procedure are visible in the example dialogue.)

TOPS-20 PSI Version 1.0

3-1

June 1983

RUNNING DECnet-20
(Mount the PS: disk pack on drive o. Press the ENABLE rocker switch
while pressing the DISK rocker switch on the console front end.)
RSX-20F VB14-45 13:51 12-Nov-81
[SYO: REDIRECTED TO DBO:]
[DBO: MOUNTED]
KLI
VERSION VB12-27 RUNNING
KLI -- KLI0 SiN: 2476., MODEL B, 60 HERTZ
KLI -- HARDWARE ENVIRONMENT:
MOS MASTER OSCILLATOR
EXTENDED ADDRESSING
INTERNAL CHANNELS
CACHE
KLI
KLI

MICROCODE VERSION 275 LOADED
ALL CACHES ENABLED

LOGICAL MEMORY CONFIGURATION.
ADDRESS SIZE INT TYPE CONTROLLER
000000000 512
4
MF20 10
KLI
KLI

CONFIGURATION FILE WRITTEN
BOOTSTRAP LOADED AND STARTED

[PS MOUNTED]
System restarting, wait •••
ENTER CURRENT DATE AND TIME: 7-21-82 1755
YOU
IS
WHY
RUN

HAVE ENTERED WEDNESDAY, 21-JULY-1982 5:55PM
THIS CORRECT (Y,N) Y
RELOAD? SA
CHECKD? N

RUNNING DDMP
SYSJOB 5(14) STARTED AT 21-JUL-82 1775
RUN SYS:ORION
RUN SYS:QUASAR

****

21-JUL-82 17:55:12 - TGHA 2(6) RUNNING FIRST TIME.

****

RUN
RUN
RUN
RUN
RUN
RUN
RUN
RUN
RUN

SYS:MOUNTR
SYS:INFO
SYS:MAILER
SYS:MAPPER
SYS:LPTSPL
SYS:LPTSPL
SYS:LPTSPL
SYS:CDRIVE
SYS:SPRINT
Figure 3-1

Startup Dialogue for TOPS-20 Version 5.1 DECnet-20
Version 3.0 on a DECSYSTEM-2060

3-2

RUNNING DECnet-20
JOB 0 /LOG OPERATOR XX OPERATOR
ENA
AESET LOGIN PSEUDO
AESET LOGIN CONSOLE
AESET OPERATOR
PTYCON
GET SYSTEM:PTYCON.ATO

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

/
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ
SJ

o : @LOG OPERATOR OPERATOR
1:
0:
1:
0:
1:
1:
0:
0:
0:
1:

@LOG OPERATOR OPERATOR
JOB 1 ON TTY220 21-JUL-82 17:55:25
@ENA
$A ESET LOGIN PSEUDO
JOB 2 ON TTY221 21-JUL-82 17:55:25
@ENA
$A ESET LOGIN CONSOLE
$AES ET OPERATOR
$PTYCON
$RUN SYS:BATCON
o : PTYCON> GET SYSTEM:PTYCON.ATO
0: PTYCON> SILENCE

(From OPERATOR on line 220 to all: SYSTEM IN OPERATION]
SJ 0: PTYCON> WALL
SJ 0: NML(O)
3
OPERATOR
NMLT20
RN
0:0:1
SJ 0: NODES(l)
4
OPERATOR
NODES
RN
0:0:0
SJ 0: MCBNR(2)
5
OPERATOR
MCBNRT
RN
0:0:0
SJ 0: FAL(3)
6
OPERATOR
FAL
RN
0:0:1
SJ 0: OPR(4)
7
OPERATOR
OPR
TI
0:0:2
SJ 0: X29(5)
10
OPERATOR
X29SRV
RN
0:0:1
SJ 0: PTYCON>
SJ 0:**** NML(O) 17:56:10 ****
SJ 0:
SJ 0:
(LINK-WATCHER]:
AUTO-DUMP REQUEST *18 ENTERED FOR DTE-O-l
SJ 0: PTYCON> CONN OPR
SJ 0: (CONNECTED TO SUBJOB OPR(4)]
SJ 0: **** NML(O) 17:56:24 ****
SJ 0:
SJ 0:
[NML-PROCESSOR]:
AUTO-DUMP DONE ON DTE-O-l
SJ 0:
[NML-PROCESSOR]:
AUTO-LOAD REQUEST i19 ENTERED FOR DTE-O-l
SJ 0: **** OPR(4) 17:56:24 ****
SJ 0: **** NML(O) 17:57:41 ****
SJ 0:
(NML-PROCESSOR]:
AUTO-LOAD DONE ON DTE-O-l
SJ 0: **** OPR(4) 17:57:41 ****
SJ 0:
SJ 0: 17:57:41
-- NETWORK NODE D2476A IS ONLINE
AC
DSME 5.1 DECNET TEST SYSTEM, TOPS-20 Monitor 5.1(4766)
@

Figure 3-1

Startup Dialogue for TOPS-20 Version 5.1 DECnet-20
Version 3.0 on a DECSYSTEM-2060 (Cont.)

TOPS-20 PSI Version 1.0

3-3

June 1983

RUNNING DECnet-20
3.1.2

Manual Startup of DECSYSTEM-2040S/2060 Communication Front End

The TOPS-20 and the MCB Operating Systems may crash independently.
When TOPS-20 fails,
it attempts an automatic restart. If this is
successful, the Network Management Program running under TOPS-20
checks to see if the MCB system is running. If the MCB has also
failed, it is loaded;
if it has not failed, there is no action.
Therefore, a manual startup is only required when normal automatic
procedures fail.
The following sequence of commands may be used if
the
DN20
communications front end fails to come up when the TOPS-20 node comes
up or following a crash that is not followed by an autoload.
Normally, the first step will load the front end. If the load fails,
continue with next sequence of commands.
Step 1.

Type the following at your terminal:
@ena ~
$opr ~
OPR)enter ncp ~
NCP)set cir dte-O-l service enabled ~
NCP)load node d2l3na ~
The circuit identification, DTE-O-l, represents the circuit
used to load the DN20. Normally, this will be the DTE-O-l;
if it is not, use the identification of the circuit actually
used for the load.

Step 2.

If the load fails, enter NCP and type an NCP command for each
of the required parameters, inserting the values appropriate
for your MCB DN20 node. Include as the last command, SET
CIRCUIT DTE-O-l SERVICE ENABLED.
The value DTE-O-l must
identify the circuit over which the load will be effected.
The command file example in the next section can be used to
check format. "D213nA" in the example is the name of the
network front end.
The following parameter values are required for the load:
Secondary Loader
Tertiary Loader
Service Circuit
CPU = PDP1I
Load File
Dump File
Secondary Dumper
Host
You can now repeat:
NCP)load no d2136a ~

3.1.3

Manual Startup with Command Files

You will find it helpful to use command files for procedures that may
be repeated.
You will save unnecessary typing, avoid such errors as
misspelling and transposition, and ensure against errors of omission.
You will probably find
it helpful to keep a set of command files on

3-4

RUNNING DECnet-20

your own directory. Following is an example of
loading the front end named D2136A:

command

file

for

$type feload.cmd
clear executor node
set node d2l36a cpu pdp-II
set node d2l36a service circuit dte-O-l
set node d2l36a secondary loader sys:dtemps.sys
set node d2l36a tertiary loader sys:dtempt.sys
set node d2l36a load file sys:d2l36a.sys
set node d2l36a dump file sys:d2l36a.dmp
set node d2l36a secondary dumper sys:dtedmp.sys
set node d2l36a host k12l36
set cir dte-O-l service enabled
load node d2l36a
$

The above command set includes all information needed by the system
for a manual load. However, when the system is brought up, several of
the commands shown above are processed when the NCP.CMD file is
executed. Normally, only the last command is required.
Assume the TOPS-20 system is running. Before using the network, you
check the status of the communications front end and receive the
following:
NCP) show node d2l36a status ~
NCP)
9:24:09
NCP
Request # 253: Show Node Complete
Remote Node = 129 (D2l36A)
State = Reachable
Active Links = 3

(A few NCP commands are entered)
After a few minutes, the following topology message is output to
terminal:
NCP)
9:30:04

your

Network topology

Nodes off-line:
D2l36A
When you fail to receive output in a few minutes informing you that
D2l36A is online, you can assume that the DN20 has failed to autoload.
You TAKE the file FELOAD.CMD. Input and output follow:
$~Esend

* I am going to load the front end -

in 5 minutes~

[From CIRINO on line 25 to all: I am going to load
the front end - in 5 minutes
$opr
~

OPR)disaBLE outPUT-DISPLAY (of) all-MESSAGES~
OPR)
9:59:51
--Output display for OPR modified-OPR)ent ncp~
3-5

RUNNING DECnet-20
NCP)take
NCP)
10:00:34
NCP)
10:00:36
NCP)
10:00:42
NCP)
10:00:42

feload.cmd~

NCP
Clear Executor Complete

NCP
Request # 266 Accepted
NCP
Request # 256; Set Node Completed
NCP
Request # 257; Set Node Failed, Component in wrong

state
NOTE
This failure will
not
affect
the
results.
The DTE-O-l has already been
established as the service circuit when
the system came up.
10:00:42

NCP
Request # 258; Set Node Completed