Digital PDFs

AA-L413B-TB

May 1986

276 pages

Original

11MB

Document:	DECnet and PSI System Managers and Operators Guide Apr86
Order Number:	AA-L413B-TB
Revision:	0
Pages:	276
Original Filename:	AA-L413B-TB_DECnet_and_PSI_System_Managers_and_Operators_Guide_Apr86.pdf

OCR Text

TOPS-10
DECnet and PSI
System Manager's and
Operator's Guide
AA-L413B- TB

April 1986
This manual describes the operation, control, and monitoring
functions of DECnet-1 0 and the TOPS-1 0 PSI products.
These products, together with TOPS-10, provide the
DECsystem-1 090/1091/1095 computers running TOPS-10
with a communications interface to DIGITAL's corporate
network, DECnet, and to Public Packet Switching Networks,
PPSNs.
This manual supersedes the TOPS-10 DECnet-1 0
System Manager's and Operator's Guide, order number
AA-L413A-TB, and the TOPS-10 PSI System Manager's
and Operator's Guide, order number AA-CK83A-TB.

OPERATING SYSTEM:

TOPS-10 V7.03

SOFTWARE:

DECnet-10 V4.0
GALAXY V5.1
Network Management V4.0
PSI Gateway V1.0

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

digital equipment corporation. marlboro. massachusetts

(
\

First Printing, February 1984
Revised, April 1986
Copyright ©1984, 1986 by Digital Equipment Corporation. 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 be
used or copied only in accordance with the terms of such license.
No responsibility is assumed for the use or reliability of software on equipment that is
not supplied by Digital Equipment Corporation or its affiliated companies.
The following are trademarks of Digital Equipment Corporation:
DEC
DECmate
DECsystem -10
DECSYSTEM-20
DECUS
DECwriter
DIBOL

MASSBUS
PDP

P/OS
Professional
Q-BUS
Rainbow
RSTS

RSX
RT
UNIBUS
VAX
VMS
VT
Work Processor

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

CONTENTS

PREFACE
PART I

INTRODUCTION

CHAPTER 1

SYSTEM OVERVIEW

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

NETWORK CONCEPTS

2.1
2.2
2.3
2.4
2.4.1
2.4.2
2.4.3
2.4.4
2.4.4.1
2.4.4.2
2.4.5
2.4.6
2.5
2.5.1
2.6
2.7
PART II

DIGITAL NETWORK ARCHITECTURE AND DECnet
1-1
THE LAYERED STRUCTURE OF DNA • • • • • • • • • • • 1-3
The User Layer • • • • • • • • •
• • • • • 1-4
The Network Management Layer •
• 1-5
The Network Application Layer
• • 1-7
The Session Control Layer
••••
• 1-7
The End Communication Layer
1-7
The Routing Layer
•••••
• 1-7
The Data Link Layer • • • •
• • 1-8
The Physical Link Layer
• • • •
• 1-8
THE DECnet-1~ VERSION 4.~ IMPLEMENTATION. • • • • 1-8
DECnet-l~ V4.~ HARDWARE
••••
• • • 1-9
DECnet IMPLEMENTATIONS • • • • •
1-1~
DECnet-10 CAPABILITIES • • • • • •
1-1~
OVERVIEW OF NCP COMMAND KEYWORDS •
1-11

NODES AND DATA LINKS
• • • • • • • •
•
THE PSI GATEWAY
• • • • •
• •
ENTITIES • • • • • •
• • • •
•
ROUTING CONCEPTS • •
• • • •
Node Routing Types
Area Routing • • • • • • •
• • • • • •
Levelland Level 2 Routers •
Ethernet Routers and End Nodes •
• • ••
Ethernet Designated Routers • • • •
Ethernet End Node Caching
•••••••
The Adaptive Least-Cost Routing Algorithm
Congestion and Packet Delivery • • • • • • • •
SUMMARY OF PHASE III/PHASE IV COMPATIBILITY
Topological Restrictions • • • • • • • • • • •
OPERATOR FUNCTIONS AND RESPONSIBILITIES
SYSTEM MANAGER FUNCTIONS AND RESPONSIBILITIES

•
•
•
•
•
•

2-1
2-2
2-6
2-6
2-8
2-9
2-10
2-11
2-11
2-11
2-12
2-12
2-13
2-13
2-14
2-15

DECnet STARTUP PROCEDURES • • • • • • • • • •
Automatic DECnet-10 Startup • • • • • • • • • •
Manual Startup of DECsystem-109~/1091/1~95
Communication Front End
•••••••••
Manual Startup with Command Files • • • •
•
DECnet-10/PSI-10 RESTART PROCEDURES
• • • •
Restart Procedure for the ORION Process • • • •
Restart Procedure for NML • • • • • •
••
Restart Procedure for X29SRV • • • • •
• ••
Restart Procedure for PSITSB • • • • • • • • • •
CONTROLLING NODE, CIRCUIT, DTE, AND LINE STATE • •

3-1
3-1

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

RUNNING DECnet-10

iii

3-3
3-4
3-6
3-6
3-6
3-7
3-7
3-8

MONITORING NETWORK ACTIVITY • • • • • • • • • • • 3-9
NCP Commands for Network Monitoring - Local and
Remote • • • • • • • • • • • • • • • • • • • • • 3-9
using the SPEAR Program for Network Monitoring 3-10
3.4.2
DECNET-10 HOST SERVICES • • • • • • • • • •
3-12
3.5
DOWNLINE LOADING • • • • • • • • • • • •
3-13
3.5.1
Target-initiated Downline Loading
3-14
3.5.1.1
Operator-initiated Downline Loading
• • • • 3-14
3.5.1.2
LOAD Sequence • • • • • • • • • • • •
3-15
3.5.2
Downline Load Requirements • • • • • • •
3-15
3.5.3
Downline Load Bootstraps • • • • • •
3-16
3.5.3.1
Setting Up the Downline Load Devices •
3-16
3.5.3.2
Set Up the Host Circuit
• • • • • 3-16
3.5.3.3
Establish Default Information
• • ••
3-16
3.5.3.4
Trigger the Bootstrap Mechanism
3-16
3.5.3.5
Overriding Default Parameters
3-17
3.5.3.6
Load the Target Node. • • • •
••• ••
3-17
3.5.3.7
Procedure if the LOAD Fails
3-17
3.5.3.8
Host Identification • • • •
• • • ••
3-18
3.5.3.9
Load File Identification • •
3-19
3.5.3.10
Software Type • • • • • • • •
• • ••
3-19
3.5.3.11
CPU and Software Identification
3-20
3.5.3.12
Service Device Identification •
3-20
3.5.3.13
Service Circuit Identification •
• • • • 3-20
3.5.3.14
Service passwords • • • • • • • • • • • • • 3-20
3.5.3.15
Diagnostic File • • • • • • • • •
3-21
3.5.3.16
Downline Loading a Communications Server •
3-21
3.5.4
Downline Loading the DN20
3-21
3.5.5
3.5.6
UPLINE DUMPING • • • • • • • • •
3-22
Upline Dump Procedures • • • •
3-22
3.5.6.1
Upline Dump Requirements • • •
3-23
3.5.6.2
Manual Upline Dump of the DN20 Mca
3-23
3.5.6.3
Connecting to a Remote Console
• • ••
3-24
3.5.7
3.6
TESTING THE NETWOR~ • • • • • • •
•• • ••
3-24
Using Loopback Tests • • • • • •
3-24
3.6.1
Circuit Level Loopback Testing • •
•• ••
3-28
3.6.2
Looping to a Multicast Address •
•• ••
3-28
3.6.2.1
Looping to a Remote Node • • •
• • ••
3-28
3.6.2.2
Remote Loopback Tests Using a Loop Node Name.
3-29
3.6.3
Manual Procedure for Observing CHK11 Output
3-29
3.6.4
3.7
NODE IDENTIFICATION • • • • • • • • • • • • • •
3-29
Maximum Address Parameters • • • • • • • • • •
3-30
3.7.1
Local Node Identification Parameter • • • • • 3-30
3.7.2
Using and Removing Node Names and Addresses
3-31
3.7.3
3.8
ETHERNET ADDRESSES OF NODES • • • • • • • •
3-31
3.8.1
Format of Ethernet Addresses • • • • • • • • •
3-31
Ethernet Physical and Multicast Addresses
3-32
3.8.2
Values of DIGITAL Ethernet Physical and
3.8.3
Multicast Addresses • • • • • •
• • • • • 3-33
3.9
DATA LINK CONTROL • • • • • •
• • • •
3-34
Setting the Buffer Size
3.9.1
3-34
Maximum Number of Buffers • • • • •
3.9.1.1
3-35
Maximum Number of Circuits
3.9.1.2
3-35
3.10
REMOTE FILE ACCESS - F~L • • • • • • • •
3-35
FAL Mode Operation • • • •
• • • • • 3-36
3.10.1

3.4
3.4.1

CHAPTER 4
4.1
4.2
4.3
4.4
4.4.1

THE NETWORK CONTROL PROGRAM
OPERATOR INTERFACE •
PROCESSING OVERVIE~
NCP FUNCTIONS
NCP FEATURES • • • • • • • • • • • • • •
Typing Commands at the Terminal
iv

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

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

5.1
5.2
CHAPTER 6

6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
CHAPTER 7

Editing Commands •
Using Comments •
Multiple Line Commands •
Getting Help from NCP
NCP COMMAND OPERATION
Accessing NCP Comman';s ..
Access Control • • •
•
Restricting NCP Commands •
Queued Command s
Command Input
Command Output Response
Specifying the Executor
Specifying Files in NCP Commands •

• 4-3
• • • 4-4
• 4-4
4-4
• 4-5
4-5
• 4-5
• • 4-5
• 4-6
• 4-6
• 4-6
4-8

• 4-9

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

• 5-1
• • 5-1

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 •

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

6-1
6-3
6-3
6-4
6-5
6-5
6-6
6-8

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER

PROCESSING OVERVIEW
7.1
7.2
DECnet-10 IMPLEMENTATION AND EXTENSIONS
7.3
NML CONCEPTS AND ORGANIZATION OF PARAMETERS
Entities •
7.3.1
Entity Identification • •
•
7.3.2
Circuit and Line Identification
7.3.2.1
Node and Area Identification •
7.3.2.2
Logging Identification •
7.3.2.3
Module Identification
7.3.2.4
The Node Entity
7.3.3
The Circuit Entity.
7.3.4
The Line Entity
7.3.5
The Logging Entity •
7.3.6
Event Identification •
7.3.6.1
Selecting Events for Logging •
7.3.6.2
DN20 (MCB) Events
7.3.6.3
Logging Events at Remote Nodes •
7.3.6.4
The Maintenance Module Entity
7.3.7
The CONFIGURATOR Module
7.3.7.1
The CONSOLE Module •
7.3.7.2
The LOADER and LOOPER Modules
7.3.7.3
The Area Entity
7.3.8
GENERIC FORMAT OF NML/NCP COMMANDS •
7.4
CHANGING NETWORK DATA BASES: SET AND DEFINE
7.5
COMMANDS •
SET/DEFINE Entity ~~~
7.5.1
7.5.2
SET/DEFINE CIRCUIT •
SET/DEFINE LINE
7.5.3
SET/DEFINE MODULE
7.5.4
v

• 7-1
• 7-2
7-2
• • • 7-2
• 7-3
• • 7-3
• 7-4
• 7-4
• • 7-5
• • • 7-5
• 7-7
• • • 7-7
7-10
7-11
7-12
7-13
7-14
7-14
7-14
7-15
7-15
7-15
7-16

7-16
7-17
7-18
7-23
7-25

7.5.5
7.5.6
7.6
7.7
7.8
7.8.1
7.8.2
7.8.3

7.8.4
7.9
CHAPTER 8
8.1
8.2

SET/DEFINE NODE • • • • •
SET/DEFINE LOGGING • • • •
CHANGING NETWORK DATA BASES: CLEAR AND PURGE
COMMANDS • • • • • • • • • •
MONITORING THE NETWORK: LIST AND SHOW COMMANDS •
CONTROLLING THE NETWORK: DUMP, LOAD, LOOP, AND
TRIGGER COMMANDS •
• • •
• • • •
DU~P ••
LOAD • • • • • •
LOOP ••
TRIGGER
• • • • •
MONITORING NODE ACTIVITY: ZERO COMMAND •

THE MODULE ENTITY
X.25-SPECIFIC COMMANDS ••
DECnet PARAMETER SUMMARY

APPENDIX B

COUNTER SUMMARY

B.3.4

B.3.5
APPENDIX C
C.1
C.2
C.3
C.3.1

C.3.2
C.4
C.4.1
C.4.2
C.4.3
C.4.4
C.4.5
C.4.6

APPENDIX 0
0.1
0.1.1
0.2
D.2.1

D.2.2
0.3

0.3.1
0.3.2
0.3.3
0.3.4
0.3.5

7-39
7-40
7-43
7-47
7-47
7-48

7-51
7-53
7-54

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE

APPENDIX A

B.1
B.2
B.3
B.3.1
B.3.2
B.3.3

7-27

DECnet COUNTER SUMMARY • •
X.25 SPECIFIC COUNTERS
COUNTER DESCRIPTIONS •
Circuit Counters • • •
Line Counters
Node Counters
• • •
X.25 protocol Module Counters
X.25 Server Module Counter.q

· . • • •• 8-1
8-2

• • • • • 8-1
• 8-2

• • • • • 8-4
• 8-4

• • • • B-6
• ••
• 8-9

8-12

8-13

NETWORK RELATED MESSAGES
OPR/NCP COMMAND SYNTAX MESSAGES •• • • •
• C-1
OPR/ORION/QUASAR INFORMATIONAL MESSAGES
• • • C-2
NCP COMMAND RESPONSE MESSAGES •• • ••
• • • C-3
Status Messages • • • • • • • • • • • • • • • • C-4
Error Messages from Network Management Software C-4
EVENT MESSAGES • • • • • • • • • •
C-ll
Event Class and Type Summary • • •
C-l1
Network Management Layer Events • • • • •
C-12
Session Control Layer Events • • • • • •
C-14
C-14
End Communication Layer Events
Routing Layer Events •
• • •• C-15
Data Link Layer Events • • • • •
C-20
X.29 CONFIGURATION FILE
MANAGING X29SRV • • • • • •
Security Considerations
SAMPLE DIALOGUE
X29SRV.I~I • • • •
Dialogue • • • • • • • • •
MANAGEMENT COMMA~DS • • • •
Error Conditions • • • •
DEFINE DEFAULT HOST Comman~
DEFINE HERALD Command • • • • •
DEFINE MAXIMUM CIRCUITS Comman~
DEFINE MAXIMUM CONNECT ERRORS Command

. . .. .. . . . . .

• D-1
D-1
• • • D-1
D-2
•

• • 1)-2

• • • • D-3
• 0-3
• D-4
1)-5

•• D-5
•

•

• D-6

D.3.6
D.3.7
0.3.8
D.3.9
D.3.10
D.4
D.4.1
0.4.2
D.4.3
0.4.4
0.4.5
D.4.6
D.4.7
D.4.8
D.4.9
D.4.10
D.4.11
0.4.12
D.4.13
D.4.14
0.4.15
D.4.16
0.4.17
D.4.18

DEFINE NETWORK Command •
• D-6
DEFINE PROMPT Command • • • • • • • • • • • • • D-7
DEFINE RESPONSE Command
• • • • • • • • • D-8
DEFINE REVERSE CHARGING Command
• • • D-8
DEFINE SET Command • • • • • • • •
• D-9
VALUES OF THE PAD PARAMETERS • • • • • • •
D-11
Parameter 1 - PAD Recall using a Character
D-12
Parameter 2 - Echo • • • •
• • • • •
0-12
Parameter 3 - Selection of Data Forwarding
Signals • • • • • • • • • • • • • • • • • • • 0-12
Parameter 4 - Selection of Idle Timer Delay
0-13
parameter 5 - Ancillary Device Control • • •
0-13
Parameter 6 - Control of PAD Service Signals • D-14
Parameter 7 - Action of PAD on Receipt of Break
Signal • • • • • • • • • • • • • • • • • • • • D-14
Parameter 8 - Discard Output • • • • • • • • • 0-14
Parameter 9 - padding After Carriage Return
D-15
Parameter 10 - Line Folding
0-15
Parameter 11 - Speed of Start-stop Mode
Terminal • • • • • • • • • • • • •
0-15
Parameter 12 - Flow Control of the PAD •
D-16
Parameter 13 - Line Feed Insertion After
Carriage Return
D-16
Parameter 14 - padding After Line Feed • • • • 0-16
1)-16
parameter 15 - Editing • • • • • • • • • •
Parameter 16 - Character Delete
• • • • • D-17
D-17
Parameter 17 - Line Delete •
• •••
D-17
Parameter 18 - Line Display

APPENDIX E

BIBLIOGRAPHY

APPENDIX F

DECnet LINE DEVICES

APPENDIX G

GLOSSARY

INDEX
FIGURES
1-1
1-2
1-3
2-1
2-2
2-3
2-4
2-5
3-1
3-2

Communication Between Adjacent and Equivalent
Layers of the Digital Network Architecture • •
1-2
Logical Communication and Physical Path of Routed
• 1-4
Data • • • • • • • • • • • • •
OPR/NCP/NML Logical processing Flow in DECnet-10
V4.0 • • • • • • • • • • • • • • • • . • • • • • • • 1-5
TOPS-10 PSI Gateway Software Components
• • 2-3
X.29 Terminal Access to a TOPS-10 Host
• • 2-5
Routing for DECnet-10 V4.0
•••••
• 2-7
Routing Node • • • • • • • • • • • • •
• • • • 2-8
Nonrouting Nodes • • • • • • • • • • • •
~-9
Startup Dialogue for TOPS-10 Version 7.03
DECnet-10 Version 4.0 on a KLl~90 System • • • • • 3-2
Types of Nodes by Network Function • • • • •
3-13

vi i

TABLES
1-1
7-1

7-2
A-I
A-2
A-3
A-4
A-5
A-6
A-7
A-8
A-9
A-l~

B-1
B-2

B-3
B-4
B-5
C-l
D-l
F-1

NCP Command Keywords •
1-12
Relationship of Clock and Controller Parameters to
Mode of Line •
• 7-9
Logging Parameters and Their Function
7-13
Node Parameters
• A-2
DECnet-1~ Specific Node Parameters
• A-4
Line Parameters
• ~-5
DECnet-l~ Specific Line Parameters •
• • A-6
Circuit Parameters •
• A-6
Logging Parameters •
• • A-a
Event Parameters •
• A-9
Module X25-ACCESS Parameters •
A-II
Module X25-PROTOCOL Parameters
A-II
Module X25-SERVER Parameter~ •
A-12
DECnet-l~ Specific Counters
• B-1
Data Link Circuit Counters for Permanent X.25
Circuits •
• •
• B-2
Data Link Line Counters for LAPB Lines •
• B-3
X.25 Protocol Module Counters
• B-3
X.25 Server Module Counters
• B-4
EVENT Classes
C-ll
Summary of PAD Parameter Values
0-11
DECnet Line Devices
• F-l

viii

PREFACE

This manual describes the operation, control, and monitoring functions
of TOPS-10 DECnet-10 Version 4.0 and PSI version 1.0. It includes
both tutorial and reference information.
The audience addressed is:
o

The DECnet-10/PSI-10 System Manager

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

This manual assumes that
its readers are experienced in TOPS-10
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.
MANUAL ORGANIZATION
This manual contains two parts as follows:
PART I, INTRODUCTION, contains two chapters.
Chapter 1, SYSTEM OVERVIEW, briefly describes the DIGITAL Network
Architecture
(DNA)
that is the model used to design networks of
DIGITAL computers.
This chapter emphasizes the relationships
between the Network Management Layer (NML) and other functional
layers, and describes the DECnet-10 implementation of DNA.
Chapter 2, NETWORK CONCEPTS, defines the basic network
in relation to the operation of the DECnet-10 network.

concepts

PART II, DECnet OPERATION, contains six chapters.
Chapter 3, RUNNING DECnet-10, includes the minimum information
needed by operators responsible for keeping the network up and
running. This chapter explains procedures and gives examples for
such tasks as manual loading of the DN20 front end, controlling
line states, monitoring the network,
recognizing
potential
problems, and running the FAL program.
Chapter 4, THE NETWORK CONTROL PROGRAM, is a tutorial on NCP, the
control language that is the operator's and manager's interface
to the network control program, NML.
Chapter 5, NCP COMMANDS PROCESSED BY CPR, describes
and function of NCP commands processed by OPR.
ix

the

syntax

Chapter 6, NCP COMMANDS PROCESSED BY THE NETWORK CONTROL PROGRAM,
describes the syntax and function of NCP commands processed by
the local node's NML.
Chapter 7, NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT
LAYER,
describes the syntax and function of NCP commands
processed by the local node's NML and the remote node's Network
Management Program.
Chapter 8, NETWORK MANAGEMENT PACKET
SWITCHING
INTERFACE,
describes X.25 NCP commands for using Public Packet switching
Networks (PPSNS) as part of the Packetnet System Interface (PSI)
Version 1.0 software option.
Seven appendixes complete the manual.
Appendix A, DECnet PARAMETER SUMMARY, summarizes all parameters
included in the Network Management V4.0 NCP commands. There is a
separate table for each of the entities:
AREA, NODE, CIRCUIT,
LINE, MODULE, and LOGGING.
Event parameters are listed in a
separate table. Applicability and restrictions are presented
both as defined by Digital Network Architecture and thus relevant
to all DIGITAL systems, and as implemented specifically for
DECnet-10 V4.0.
Appendix B, DECnet
counters that can
commands.

COUNTER SUMMARY, summarizes
the
entity
be displayed and zeroed by appropriate NCP

Appendix C, NETWORK RELATED MESSAGES, describes all messages
related to the execution of NCP commands and the state of the
network: output responses, informational messages, and error
messages.
Appendix D, X.29 CONFIGURATION FILE, describes the information to
maintain access to the system through the Public Packet Switching
Network.
This appendix explains X29SRV commands and gives
examples for configuring X29SRV.
Appendix E, BIBLIOGRAPHY,
network-related readings.

Appendix F, DECnet LINE DEVICES,
recognized DECnet line devices.

bibliography
is

table

suggested

currently

Appendix G, GLOSSARY, is a glossary of network terms.

MANUALS REFERENCED
Depending on your experience and responsibilities, you may need to
refer to one or more of the following manuals, which contain more
detailed information on procedures or programs related to DECnet-l~
Version 4.~ and PSI Version 1.0.
TOPS-I~

DECnet and PSI Installation Guide

This manual describes the configuration of DECnet-l~ nodes
in
a
DECnet
network
and
details
all generation,
verification, and
installation steps.
It describes the
DECnet-l~
configuration tools,
the procedures to generate
the DN2~ subsystem,
the NETGEN
(NETwork GENeration)
and
NIPGEN
(Network Installation Procedure GENerator) programs.
This manual also provides a sample system configuration.
TOPS-I~/TOPS-20

SPEAR Manual

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 in the
ERROR.SYS file.
DECnet-l~ 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-I~.
TOPS-10 PSI User's Guide
This manual contains information on the following:
o

Writing FORTRAN-I~ andMACRO-I~ programs
TOPS-10 X.25 software to access a PPSN.

Using the TOPS-l~ X.29 software to connect a terminal
through a PPSN - to a TOPS-10 host.

The PSI Network-Specific
following:
PSI
PSI
PSI
PSI
PSI
PSI

NSI
NSI
NSI
NSI
NSI
NSI

Information

PSS Card
DATANET-I Card
TRANSPAC Card
TELENET Card
DATEXP Card
TYMNET Card

cards,

that

use

the

include

the

publications

for

which

AV-N804A-TE
AV-N805B-TK
AV-N8~6B-TK

AV-N807B-TK
AV-N808A-TE
AV-X573A-TK

You should also refer to the following
the PSI software option:

non-DIGITAL

CCITT publications that
contain
complete
information
on
(See Appendix E for a list
recommendation X.3 (PAD) parameters.
of CCITT publications.)
Documentation provided by the user's PPSN (TELENET, for example).

EFFECTIVE USE OF THIS MANUAL
The following suggestions are offered for your effective use
manual:
o

this

Beginning with Chapter 4, after you have read each chapter,
take the manual to your terminal and enter the commands given
in examples, adjusting parameters as needed to conform to
your site's implementation and conventions. The NCP command
language has many features that make it easy to use,
including the "?" feature, command recognition mode, and
command abbreviation mode (see Chapter 4).
With the exception of the NCP SHOW 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:4~ From Operator Terminal 23:
=>Reloading DN20 in 5 minutes

16:30:25 From Operator Terminal 25:
=>Restarting Galaxy in 5 minutes
You can also use the monitor SEND
messages in the following format:
iiTTY51 -

command

produce

Restarting NML •••

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-10, you should also read the appropriate manuals for
those 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.

xii

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

this

manual

command

UPPERCASE BOLD PRINT

indicates what you type in a command string.

lowercase letters

indicate an input variable type in a command
string.
For
example,
if
the command
description specifies "seconds," you might
type "2" to indicate "2 seconds."
indicate optional input.
(Do not
brackets when you type the command.)

include

{ }

indicate that one
of
several
enclosed
parameters is applicable.
(Do not include
braces when you type the command.)

<RET>

means press the key labelled RETURN or CR.

<ESC>

means press the key
SEL.

means hold the CTRL key and
key "x" at the same time.

numbers

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

labelled

ESC,
press

ALT,

character

The following abbreviations are used in this manual:
DLL
DNA
IPCF
LAT
MCB
NCP
NICE
NML
NSP
PSI
PPSN

Data Link Layer
DIGITAL Network Architecture
Inter Process Communications Facility
Local Area Transport
Multifunction Communication Base
Network Control Program
Network Information and Control Exchange protocol
Network Management Layer
Network Services Protocol
Packetnet System Interface
Public Packet switching Network

xiii

REVISION HISTORY
This reVISIon supercedes the TOPS-l0 DECnet-l0 System Manager's and
Operator's Guide, order number AA-L4l3A-TB, and the TOPS-l0 PSI System
Manager's and Operator's Guide, order number AA-CK83A-TB.
The TOPS-l~ PSI gateway software was released after TOPS-l0 Version
7.02 (DECnet V3.0), thus the TOPS-10 PSI System Manager's and
Operator's Guide was created. The TOPS-10 PSI gateway software is
available for TOPS-l0 7.03 (DECnet V4.0), thus the information in the
PSI manual was merged into this revision, the TOPS-l~ DECnet and PSI
System Managers's and Operator's Guide.
In addition to the PSI information, this revision
features of DECnet-10 Version 4.~, which include:

includes

the

The Ethernet device NIA20, which provides
multi-access
connections between nodes on the sarna Ethernet circuit

phase III compatibility

The AREA and MODULE entities

phase IV routing nodes and Ethernet non-routing nodes

Area routing

New upline dump/downline load procedures

Multiple FAL streams

xiv

PART I
INTRODUCTION

CHAPTER 1
SYSTEM OVERVIEW

1.1

DIGITAL NETWORK ARCHITECTURE AND DECnet

DIGITAL Network Architecture (DNA)
is a model by 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 corresponding layers in communicating nodes. See
Figure 1-1.
Version 4.~ is the fourth generation (Phase IV)
of
implementations based on the DNA model.
The following general
description of DNA will be helpful to both system managers and
operators with network management responsibilities.
DECnet-l~

NOTE
TOPS-l~ systems
can also contain ANF-l~ networks.
ANF-lm and DECnet-l~ are totally independent networks
that can coexist in a TOPS-l~ system.

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 small amount of memory may
choose to implement only the minimum subset of Network Management
functions; an operating system with a communications front end (DN2~)
may choose to implement all Network Management functions. If you know
the functions that each node in your network implements, you can save
time and effort. This informatiort is available in the manuals for the
various DIGITAL operating systems. Personal contact with the system
managers of all nodes in your network is highly recommended.

SYSTEM OVERVIEW

Legend:

= Data Interface to Adjacent Layer

= Network Management Control Interface
= Protocol for Peer-Layer Communication between Nodes

NFT
Utility

UserWritten
Program

,---

DNA LAYER

To REMOTE NODE

USER

USER-DEFINED
PROTOCOLS

.().

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

NCP
Utility

'V
NETWORK
MANAGEMENT

I--

.().

'U'
NETWORK
APPLICATION

r----

.().

'U'

r----

SESSION CONTROL

1'l'V

r-----

END COMMUNICATION

1'l-

NETWORK INFORMATION
and CONTROL EXCHANGE
(NICq:) PROTOCOL
------~-----------.

DATA ACCESS
PROTOCOL (DAP)
------------------~

SESSION CONTROL
PROTOCOL
-------------------~

NETWORK SERVICES
PROTOCOL (NSP)

-- - -------------------

'V
ROUTING

f-------

.().

'V
DATA LINK

r---

.().

'V'
Device
Drivers

'---

PHYSICAL LINK

ROUTING PROTOCOL
-------------------~

DIGITAL DATA
COMMUNICATION MESSAGE
PROTOCOL (DDCMP)
------------~-----~

(Specifications for
signal carrier control
replace protocols)

'I.

Signal Carrier

(
tv'A 5 4449 86

Figure 1-1:

Communication Between Adjacent and Equivalent
the Digital Network Architecture

1-2

Layers

SYSTEM OVERVIEW
The major features of DNA are:

1.2

Transparency.
In the context of the network, the system
manager or operator is the "user" of a 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. After you
type a command, all processing and routing of your request
depends on the system. You receive responses informing you
of success or failure.

Local autonomy. The node that is to execute an NCP command
retains the right to refuse to do so.
A refusal
is
accompanied by a reason in the DECnet-l~ V4.~ implementatione
The nature of the reason determines whether or not you should
repeat the command at a later time.

Flexibility.
The modular orientation
of
the
layered
structure lends itself well to the inclusion of new modules
and new layers.
(See Section 1.2.)

Upward compatibility. Each new DECnet phase is compatible
with the previous phase.
For example, a Phase IV node can
communicate with a Phase III node, but not with a Phase II
node.

Adaptability to the needs of individual operating systems.
Within the limits set by phase IV minimum requirements, each
operating system implements only those functions appropriate
to that operating system.

Distributed or central management capability.
The Network
Management Layer of each DECnet-l~ V4.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, a single node can
perform centralized management of the entire network.

THE LAYERED STRUCTURE OF DNA

The layered structure of DNA provides an easily upgraded product.
Adding new functions,
and consequently new layers and modules, is
easily accomplished during product development.
The User Layer, Application Layer, and Network Management Layer carry
out user functions; the Session Control Layer, the End Communication
Layer, and the Routing Layer carry out network functions; and the Data
Link Layer and Physical Link Layer carry out the physical aspects of
communication.
A brief description of each of the DNA layers, as
DECnet-10 V4.0, follows.
(See Figures 1-1 and 1-2.)

1-3

implemented

for

SYSTEM OVERVIEW

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 tralier)
____

Control Information removed by equivalent layer
at receiving node

f: --------------- ---------------~

Node B

Node C

Node A

I
I (Sending Node)

(Receiving Node) I

User Layer

II
II

lIl

lit

II
II
II

Network Management Layer

H . . . . II
II
II

H~::

Network Application Layer

H...-::

Session Control Layer

II
II

j'j------ ----'I
-------~-----

Routing Layer

H " " - II

II!
II
II

H •

T"'-

:
t
II

.....

H....

Data Link Layer

....

......
......
I
T"-::, ......

II~

II
II

Communication Facilities

II
II
II
II
II

Physical Link layer

II
II
II

End Communication Layer

H . . . . . II

II
II
II
II

MR·S·445086

Figure 1-2:
1.2.1

Logical Communication and Physical Path of Routed Data

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 DECnet monitor calls) also reside in
this layer.

1-4

SYSTEM OVERVIEW
The Network Management Layer

1.2.2

NCP commands allow operators at any node in the network to control the
network management functions of any other available node in the
network, as well as of the local node. The Network Management Layer
(NML),
unlike other architectural layers that interface only with
adjacent layers, has interfaces 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 do not need
to understand transparent processing, but the system managers and
operators who are also systems analysts will find such knowledge
helpful if they have responsibility for diagnosis and maintenance.

14-=-~

I---"-IPC=F_-l ORION
message

OPR

OPR PROCESSING:
ENTER
EXIT RETURN
HELP TAKE

IPCF
message

NCP LOCAL PROCESSING:
SET
\ LOCAL NODE
CLEAR ( IS EXECUTOR
CANCEL
TELL command prefix

NCP
RECEIVER

NML

NICE
RECEIVER

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:
SET'
DUMP
CLEAR'
LOAD
LIST
LOOP
SHOW
ZERO
'Except when command
is processed by NCP

Circuit
Event

System Dependent Calls
for Network Management
To
Loopback
Mirror

(SET
ZERO

CLEAR
SHOW)

LIST

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

fv1R-S-4456-86

Figure 1-3:

OPR/NCP/NML Logical Processing Flow in DECnet-10 V4.0

1-5

SYSTEM OVERVIEW
The Operator Command Language program, OPR, parses all NCP commands.
Correctly formatted commands that can be processed by OPR (when no
action by NML is necessary) are processed and executed
immediately.
All other NCP commands, whether to be executed by the local node or by
a remote node, are passed to the NCP Receiver in NML.
Commands that
already have access to required data are processed and executed
immediately. 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
receives these NICE messages from a remote node for
processing at the local node.
All NICE messages for processing by the
local node pass from the Request Queue to the local NML processor.
The local NML Processor directs these messages to appropriate routines
that process local functions. NICE messages in the Request Queue for
processing by a remote node pass to the NICE Transmitter, which sends
them to the remote node.
All NCP commands that are 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 is both the command node and
the EXECUTOR, the
response is from the local node and to the local node.
If you type
the command at your local node but set the EXECUTOR to 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 Data Link Watcher monitors the Data Link Layer
(OLL).
This
module detects 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 request itself or passes an appropriate
request to the Upline Dumper or Downline Loader process.
This
service request is generated by the monltor in response to a
protocol crash.
In DECnet-10 the Data Link Watcher
is in the
KL10 processor only (not in DN20 processor). In the TOPS-10 KLl~
node, the Data Link Watcher services load and dump requests from
both MCB and Ethernet nodes.
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 determines which sink to send messages to and
distributes
the
messages
to
the indicated event sinks.
(DECnet-10 only supports the FILE sink and CONSOLE sink to OPR
jobs, and messages are logged in the SYS:ERROR.SYS file.)
The Event Processor processes event messages, and sends the
processed event messages, along with ~ date and time stamp, to
either the local Event Recorder or to an Event Transmitter for
transmission to a 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
(used
for testing and maintenance), 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 Loopback Message
Generator either the test message or an appropriate error
message.
CIRCUIT or
LINE loopback
is accomplished with or
without hardware assistance.
In a DECsystem-I~9~/1~91/1095,
there is a
Loopback Mirror
in both the KLl~ and
the DN20
processors.
The Downline Loader, using the MOP protocol,
DN2~ or Ethernet node from the KLl~ host.

loads

adjacent

The Upline Dumper acts as a receiver of a dump from an adjacent
DN2~
or Ethernet node.
The dump is stored in a file in the host
node.

1.2.3

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

This layer defines a mechanism that allows a program in one node to
communicate with a
program in another node, regardless of either
program's location in the network.
This mechanism is called a logical
link, and modules in the User Layer, the Network Management Layer, and
the Network Application Layer can use it.

1.2.5

The End Communication Layer

The End Communication Layer was referred to as the Network Services
Layer
in previous DECnet-l~ versions.
Modules in this layer, using
the Network Services protocol (NSP), control the system-independent
aspects of communications that use the logical link.
These include
connection management, data flow control, end-to-end error control,
and
segmentation/reassembly of user messages.
Logical links provide
the network's primary user-to-user communication.
It
is the End
Communication Layer
that guarantees delivery of all transmitted data
in proper sequence.

1.2.6

The Routing Layer

The Routing Layer was referred to as the Transport Layer
in previous
DECnet-1~
versions.
This layer provides routing-related processing.
The Routing module first determines if the target node is "reachable,"
that
is,
whether
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.
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

SYSTEM OVERVIEW
1.2.7

The Data Link Layer

This layer controls message sequencing and data integrity
for
communications between adjacent nodes, whether they are connected by
an X.2S link, an Ethernet link, or a DDCMP link.
It does not
guarantee delivery, but it does ensure error-free communication
between adjacent nodes once communication is established.
NOTE
In all nodes in your network, the Data Link Block Size
must be the same. If you do not follow this rule when
a node is added to the network, the new node may lose
data when communicating with the other nodes in your
netwo rk.

1.2.8

The Physical Link Layer

This layer defines the way that
hardware (such as modems and
transmission line.

1.3

device
1 ines)

drivers and communications
are used to move data over a

THE DECnet-10 VERSION 4.1 IMPLEMENTATION

DECnet-10 phase IV runs on a KLl~-based or KS10-based system.
the KL10 and KS10 support a subset of Network Management V4.0~

Both

On KL10 systems, the DN20 communications front end with l28K words of
memory Is a DECnet Phase III node. Although the KL10 and the DN20 are
two separate nodes, they work together as a system.
The KL10 can
utilize the DN20 capabilities to communicate with phase III nodes, but
not with phase IV nodes. To communicate with phase IV nodes, the KL10
requires an Ethernet port.
KS10 systems support Phase IV directly over KDP lines.
DECnet-10 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-10 applicability ("applies to EXECUTOR only", for example)
and restrictions ("display only", for example).

1-8

SYSTEM OVERVIEW
1.4

DECnet-10 V4.0 HARDWARE

The KS10 (2020) processor running TOPS-10 allows direct Phase IV
connection by means of KDP (KMC/DUP-ll) lines. The system can have
one or two DECnet lines.
basic

hardware

The KL10 Central processing Unit running TOPS-l0
The KLl0 is a full DECnet-l0 phase IV node.

software.

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

The communication front end (DN20) running the Multifunction
Communication Base (MCB) software. MCB software includes the
V3.0 DECnet-l0 functions.
The DN20 is a full DECnet-l0 phase
III node.

The DTE hardware interfaces between the
the two front ends.

The NIA20 provides multi-access connections between nodes on
the same Ethernet circuit.
Ethernet messages are sent over
the Ethernet as datagrams, which means messages can be lost
because
of
errors.
DECnet-10 provides for automatic
retransmission of lost messages; therefore data integrity is
guaranteed. The Ethernet device allows multiple users of the
device at the same time.
Up to one NIA20 per CPU is
supported, but only one Ethernet.

Communication devices as required.

On KL10
(DECsystem-l090/l09l/l095)
configuration contains:

systems,

the

main

processor

and

A single KL10 can support up to three DN20 communications front ends
for DECnet-10. Multi-CpU systems can support up to three on each CPU.
The PSI Version 1.0 software option restricts the basic hardware
configuration.
See the Software Product Description (SPD) for more
information.
NOTE
Although a KL10 processor can support three
only one PSI Gateway is supported per system.

1-9

DN20s,

SYSTEM OVERVIEW
1.5

DECnet IMPLEMENTATIONS

A DECnet network can consist of nodes running various DIGITAL
operating systems, each with its own implementation of DECnet. The
concepts underlying the implementation are the same, but the functions
implemented may differ.
DECnet-10 V4.0 implements a subset of the NCP commands in the Phase IV
DNA Network Management V4.0 Specification. Not all the parameters
that can be formatted and interpreted are supported. You receive no
"action response" if you use a command not implemented at the
receiving end. The response you receive is usually:
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-10 host node can format and send commands
supported by other DIGITAL hosts, even though the commands are not
supported locally.

1.6

DECnet-10 CAPABILITIES

DECnet-10 capabilities are available to the nonprivileged terminal
user, the programmer, and the system manager or operator. The TOPS-10
Operating System Commands Manual describes the DECnet functions
available to nonprTvileged terminal users and programmers.
The
TOPS-10 DECnet and PSI System Manager's and Operator's Guide is
specific to the operational, control, and monitoring functions that
are normally the responsibility of the system manager or operator.
The system manager and operator use the NCP commands 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 during off-hours only. Chapters 4
through 7 describe the NCP command set in detail.
Chapter 4
summarizes the general functions and features of NCP. Chapters 5, 6
and 7 describe the specific function of each command and the meaning
of allowed arguments.
DECnet-10 capabilities include:
o

Adaptive path routing. Permits messages to be routed through
the network over the most cost-effective path; messages are
re-routed automatically if the circuit is disabled.
Routing
nodes can send and receive messages by routing through
intermediate nodes. When a line or system failure occurs,
and an alternate path exists, the alternate 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.

Heterogeneous network command terminals. A user at one node
can log into the system at another node in the network if
both systems are running DECnet phase IV and the CTERM
protocol.

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

1-10

SYSTEM OVERVIEW

1.7

Because DECnet-lg Version 4.g nodes are Central Management
Nodes, the Network Management modules understand the complete
command set for DECnet phase III and DECnet phase IV.
Thus,
using the TELL command prefix, you can direct NCP commands
not supported locally to other phase III or Phase IV nodes on
your network.
A DECnet-lg V4.g node can format any command
that a remote DECnet Phase III or DECnet phase IV node can
execute. This includes multipoint 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. You can
change entity states and characteristics in the volatile data
base (also in the permanent or temporary data base using the
TELL command prefix to nodes that support it). You can also
display both current and recent network activity.
Loopback
tests, downline loading and upline dumping are available
through NCP commands.

Logging of significant events. You can reset and display
activity counters (see Appendix B for details). Certain
events and errors (start-ups, dumps, 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 specJfications you select. You can also log events to
the CONSOLE sink.

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

OVERVIEW OF NCP COMMAND KEYWORDS

The command keyword specifies 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 can have entity or
parameter or both implied. Thus, a complete command can consist of
the command keyword, the entity, and the parameter.
Each of the commands illustrated below is complete.
Command keyword only:
NCP>EXIT
NCP>HELP
Command keyword and entity:
NCP>SHOW EXECUTOR
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. Refer to the section indicated for
a more specific description of function.
1-11

SYSTEM OVERVIEW
Table 1-1:

NCP Command Keywords

Command

Function

CANCEL

Removes a command
Request
Queue
processing begins.

CLEAR

Removes
entered
base.

DEFINE

Enters
a
value
in
permanent data base.

Complete
Description
from the
before

Section 6.6

a value previously
in the volatile data

Section 6.3
(EXECUTOR)
Section 7.6
(All entities)

the

Section 6.2
( EXECUTOR)
Section 7.5
(All entities)

DUMP

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

Section 7.8.1

ENTER

Accesses
a subset of OPR
commands when typed to the
OPR prompt.

Section 5.1

EXIT

Terminates an NCP session and
returns control to TOPS-l0
monitor level.

Section 5.1

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 the executor 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.3

PURGE

Removes a value or values
from the permanent data base.

Section 6.4
(EXECUTOR)

Changes

Section 5.1

PUSH

TOPS-1~

node-level

control from NCP to
command level.
1-12

SYSTEM OVERVIEW
Table 1-1:

NCP Command Keywords (Cont.)
Complete
Description

Command

Function

RETURN

Switches OPR from the NCP
command set to the standard
OPR command set.

Section 5.1

SET

Enters a value or values
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.1

TELL
(prefix)

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

Section 6.7

TRIGGER

Requests the target node to
send a load request.

Section 7.8.4

WAIT

Used
in
batch
delays processing
command for
the
number of seconds.

programs,
the next
specified

Section 5.1

ZERO

Logs counters and then zeroes
them.

Section 7.9

1-13

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 a computer processor 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. For typing NCP commands, the
local node is usually (could be SET HOSTed) the node where your
terminal is located (the TOPS-10 node in DECnet-10). All other nodes,
including the MCB front end, if any, are remote.
In the DECnet software, the local node is the node acting as EXECUTOR;
this is usually, but not always, the node at which you type the
command. 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."
For example, on KL10 based systems, the MCB front end is adjacent to
the KL10 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 you type a command.
The executor is the node where the command is executed.
The target
node is the node where the action requested by the command takes
place. The host node is the node where resources for processing the
command
exist
(storage space for files, for example).
These
functional classifications are not mutually exclusive. For example, a
node can serve as executor, command, host node, and target node. See
Figure 3-2.
Data links are actual physical connections between nodes; Logical
links are logical connections.
A physical link connects node A to
node B, for example; a logical link connects Marcia at one terminal to
George 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 "circuit" is synonymous with a logical point-to-point connection.
Section 7.3.4 describes circuits in more detail.

2-1

NETWORK CONCEPTS
2.2

THE PSI GATEWAY

The PSI Gateway interfaces a DECnet network to an X.2S Public Packet
Switching Network (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 which connects the DN20 to the PPSN.
The PSI option also includes software to permit access to the Gateway,
and thus the X.25 network, from a TOPS-10 DECnet Version 4.0 node.
These software units include the Gateway Access Library and the X.29
Server.
Figure 2-1 illustrates the placement of the TOPS-10 PSI
Gateway Access Library Routines and the TOPS-10 Gateway Software in
the central
(TOPS-10)
processor and the communications processor
(DN20) •

2-2

NETWORK CONCEPTS

Local
DECsystem-10
TOPS-10
Node - - - - - - - - . . . ,
User Program
TOPS-10 PSI
Gateway
Access Routines

DECnet
Logical
Link
X.25
Gateway
Access
Protocol

Local
DTE

DN20
TOPS-10PSI
Gateway
Software

'-----I X.25
Protocol

Remote
DTE

Remote
Node
Remote
User
Program

MR-S-3710-84

Figure 2-1:

TOPS-10 PSI Gateway Software Components

2-3

NETWORK CONCEPTS
The Gateway Access Library is a collection of subroutines that the
user can use to write programs and applications that perform X.25
functions (see the TOPS-10 PSI User's Guide).
These routines are
linked with the user's software to form a single-job image. The
routines allow communication with the Gateway by using the Gateway
Access Protocol over a DECnet logical link.
This permits user
programs to directly manipulate the X.25 protocol at the Gateway's
interface to the X.25 network, even thQugh 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-10 system that has access to an X.25 network. The terminal
is connected to a Packet Assembly/Dissembly (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-l~ host using the Network Remote Terminal Protocol (NRTP).
Figure 2-2 illustrates the components needed for such a connection.

2-4

NETWORK CONCEPTS

DECsystem-10

TOPS-10
Host

User Job

DECnet
Logical
-I LINK

L . . - - -_ _

------INRT
DECsystem-10 Protocol

X29SRV
TOPS-10 PSI
Gateway
Access Routines

DN20

X.25
Gateway
Node

MR-S-3729-84

Figure 2-2:

X.29 Terminal Access to a TOPS-10 Host

2-5

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:
for example, in the
command SET NODE nodeid HOST hostname, NODE nodeid is the entity; or
in the command SHOW ACTIVE LINES COUNTERS, ACTIVE LINES is the entity.
An entity in the singular form is one of:
AREA, CIRCUIT,
LINE,
LOGGING, MODULE and NODE.
ACTIVE and KNOWN preceding AREAS, CIRCUITS,
LINES, LOGGING, MODULES and NODES permit plural forms. NODE has two
other forms,
LOOP NODES and ADJACENT NODES. Chapter 7 describes
entities in detail.
The MODULE entity is provided for users of the TOPS-10 X.25 software
(discussed
in Chapter 8)
and for maintenance of the Ethernet. The
MODULE entity for X.25 takes one of three forms:
MODULE X25-ACCESS,
MODULE X25-PROTOCOL, and MODULE X25-SERVER.

2.4

ROUTING CONCEPTS

Routing,
the primary function of the Routing
Layer,
is
the
determination of the physical path that packets follow between nodes.
This path is determined at each node. At each intermediate node, the
Routing module reads the header of an incoming packet to determine its
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. The system manager or operator can also change the path using
the appropriate NCP command (SET CIRCUIT cktid COST cost). See Figure
2-3.

2-6

NETWORK CONCEPTS

Legend:

node

O-s-O =

1 hop

= data link

--n

arrow := direction associated with n
n
cost of circuit

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

1 - - - -7

,
I

All
links
up

Link
between
Band 0
down

From
Node

To
Node

Path

-8

Path
Cost

Least Cost
Path

3
6

B->D

B->A~D
B->C~D

3
6

2
2

D~B
~A~B
~C~B

Path
Length

2
2

B->A~D
B->C~D

6
5

B->C~D

~A~B
~C~B

~A~B

2
2
2
2

NCP Commands for Control:
FOR CIRCUIT
SET CIRCUIT OMR-O COST 3
SET CIRCUIT KOP-0-2 COST 4
SET CIRCUIT OTE -1-3

FOR EXECUTOR
SET EXECUTOR MAXIMUM COST 30
SET EXECUTOR MAXIMUM HOPS 4
SET EXECUTOR MAXIMUM VISITS 8
MR·S·3531·84

Fig ure 2-3:

Routing for DECnet-19 V4.9

2-7

NETWORK CONCEPTS
2.4.1

Node Routing Types

DECnet-l0 Version 4.0 routing supports two major types of nodes:
The
routing
nodes and Ethernet nonrouting nodes (end nodes).
characteristics and capabilities of the two major types of nodes
follow.
o

Routing Nodes
Routing nodes (routers)
that are not adjacent.

allow

communication

between

nodes

MR-S-3530-84

Figure 2-4:

Routing Node

Routers can have one or more circuits.
Routers regularly
receive and maintain information about other nodes. They
perform the routing operation by associating a circuit with
the destination node for the packet and transmitting that
packet over that circuit. Routers can use DDCMP, Ethernet,
or X.2S circuits as their data links.
In Figure 2-4, neither A nor C is aware of B's participation
in the routing above the DNA Routing level. Thus, 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 every other node in the
network.
o

Nonrouting Nodes
Nonrouting nodes (end nodes) contain a subset of network
software that permits them to send packets or receive packets
addressed to them, but not to route packets to other nodes.
In DECnet-l0, only Ethernet nodes can be end nodes. End
nodes have a single circuit, ETH-~, connecting them to the
rest of the network. They do not send or receive information
about network configurations. If two end nodes are connected
by a nonbroadcast circuit, these nodes constitute the entire
network.
On an Ethernet, if there are two or more routers, one router
is designated the router to provide message routing services
for end nodes on the Ethernet. If no routers are available,
Ethernet end nodes can communicate with each other directly,
by sending a packet out over the Ethernet and then waiting
until the timeout for a reply. However, routers are the only
Ethernet nodes that can route messages to nodes not on the
Ethernet.

2-8

NETWORK CONCEPTS

Figure 2-5:

Nonrouting Nodes

In Figure 2-5, nodes A, B, C, and D are routing nodes; nodes
E and Fare nonrouting nodes.
E can send messages to A, B,
C, D, F, and itself, and can receive messages from each of
them.
Similarly, F can communicate with A, B, C, D, E, and
itself. 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) cannot 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.
In planning your network, the number of routing nodes should be kept
down because of the overhead associated with routing. You should try
to minimize the use of routers and maximize the use of end nodes.
Although end nodes are less flexible than routers, they require less
memory and have less system overhead. Often, by using fewer routing
nodes, you can get better system performance.

2.4.2

Area Routing

phase IV DECnet supports the configuration of very large, as well as
small, networks by dividing the network into areas.
In a single-area
network, a maximum of 1023 nodes is possible, but the optimum number
of nodes is much less (approximately 200 to 300 nodes, depending on
the topology). Area routing techniques permit configuration of very
large networks, of up to 63 areas, each containing a maximum of 1023
nodes.
In a multiple-area network, nodes are grouped
into separate
areas,
each functioning as a sub-network.
DECnet supports routing
within each area and a second, higher level of routing that links the
areas.
Nodes that perform routing within a single area are called
level 1 routers; those that perform routing between areas as well as
within areas are called level 2 routers (or area routers).

2-9

NETWORK CONCEPTS
does not perform level 2 routing.
However, a DECnet-l~
system can use the services of systems that support level 2 routing to
participate in area-organized networks.
For more information on
configuring area networks, refer to the DECnet manuals for operating
systems that support this function.
DECnet-l~

Area routing offers the following advantages:
o

Permits configuration of very large
1~23 nodes.

networks

Requires less routing traffic, restricting routing overhead
Level I routers
between areas to the level 2 routers.
exchange routing information about nodes in their own area
only.

Allows different organizations to
separately within a large network.

Makes the merging of existing networks easier.

manage

than

nodes

their

A DECnet-l~ system connected to the network by the Ethernet can
communicate with all nodes in an area network (with a level 2 router),
whereas a system connected by a DN2~ can only communicate with at most
255 nodes in that system's area. In particular, the DN2~ can only
communicate with nodes whose node address is less than 256 (such as,
nodes 1-255) in the same area as the DN2~.

Level 1 and Level 2 Routers

2.4.3

nodes cannot perform area routing, however they
can
participate in area configurations that use non-DECnet-l~ nodes as
area routers.

DECnet-l~

An area can contain many level 1 routers and end nodes, and must
contain at least one level 2 router to provide the connection to other
areas. A level 1 router acts as a standard routing node.
It keeps
information on the state of nodes within its own area. Levell
routing nodes and end nodes obtain access to nodes in other areas
through a level 2 router residing in their own area.
A level 2 router keeps information on the state of nodes in its own
area and also information on the cost and hops involved in reaching
other areas. (The logical distance between adjacent level 2 nodes is
one hop.) The level 2 router always routes packets over the least cost
path to a destination area.
Level 2 routers have the following
characteristics:
o

Level 2 routers connect areas together.

Level 2 routers also act as level 1 routers within their
area.

Each level 2 router in a network must be physically connected
to at least one other level 2 router.

A level 2 router serves as a level 1 router when
phyaically connected to another level 2 router.

All level 2 routers must be connected in such a way that they
create a network of their own.

2-l~

own

not

NETWORK CONCEPTS

2.4.4

Level 2 routers
themselves.

exchange

level

routing

messages

among

In any given area, there can be more than one level 2 router.

Ethernet Routers and End Nodes

Two special concepts are involved in routing over an Ethernet circuit:
the designated router and end node caching.

2.4.4.1 Ethernet Designated Routers - The function of the designated
router is to route messages over the Ethernet on behalf of end nodes.
A designated router is elected even if there are no end nodes
currently on the Ethernet.
If there are two or more routers on the same Ethernet, one of them is
elected as the designated router. By convention the router with the
highest numerical priority (set with the command SET CIRCUIT ROUTER
PRIORITY)
is elected router for the circuit. In case of a tie, the
node with the highest address is elected as the designated router.
The designated router broadcasts messages telling end nodes that it is
available for routing. End nodes transmit multicast hello messages,
so that routers know of their presence on the Ethernet.
End nodes keep no information about the network configuration, except
that they are permitted to keep a cache of nodes within their area
that they may address directly on the Ethernet, rather than going
through a router (see the description of Ethernet end node caching
below). Thus an end node may send a packet directly to another
Ethernet end node, if the address has been cached, or it may send a
packet to the designated router for forwarding.
Note that end nodes can exist on an Ethernet without a router.
When
an end node on the Ethernet wishes to communicate with another end
node, and notes that no designated router exists, it will always send
the packet directly to the addressed node. If the addressed node is
active, the sender will receive a reply; if the addressed node is not
available, a timeout will occur.

2.4.4.2 Ethernet End Node Caching - End nodes normally send packets
by means of a router.
To minimize the space and time overhead
involved in the routing function on Ethernet circuits, a caching
mechanism is available that takes advantage of the fact that nodes on
an Ethernet are logically one hop away from each other (one hop is the
distance between two adjacent nodes).
When a designated router is present and an end node is ready to send a
packet to a node for the first time, the end node sends the packet to
the designated router. When there is no designated router on the
circuit, the end node sends the packet directly, in expectation that
the other node is there. If a response is received, the end node
examines the received packet to see if the "on-Ethernet" bit is set
(the bit is checked even if the first packet went to the designated
router) •
If the bit is not set, no action is taken; if the bit is
set, the next packet can be sent directly, rather than by means of the
designated router.

2-11

NETWORK CONCEPTS
An end node's cache contains the addresses of end nodes that the node
has communicated with within the last minute. When a minute has
passed without receiving a message from the node, the node's address
is removed from cache.
The buffer size to be used in a connection is negotiated during the
connect process.
This process can occur directly between two end
nodes or with the assistance of a designated router. Once the buffer
size is negotiated, it cannot be changed.
The cache time limit can cause links to be aborted when different
buffer sizes are assigned to end nodes and routers. For example, a
designated router with a buffer size of 576 bytes initiates a direct
connection between two end nodes using a buffer size of 1467 bytes.
(This succeeds because the first packet sent to the router is small,
always under 576 bytes.) A pause in communications between the two end
nodes occurs that causes the destination node's address to be removed
from the sender's cache. The sender attempts to resume communications
by sending a 1467 byte packet through the designated router's 576 byte
buffer, forcing the link to be aborted. Therefore, the designated
router should have the largest buffer size used in the network.

2.4.5

The Adaptive Least-Cost Routing Algorithm

Routing and related functions are accomplished in the Routing Layer of
the KL10 or KS10 node and of the DN20 communications front end.
Although routing is transparent, you, as the system manager or
operator can, through the NML interface to Routing, 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 "Routing language" includes a few common terms with
routing-specific meanings. Figure 2-3 is designed to define these
terms and, at the same time, provide you with a basic understanding of
the DECnet-10 routing algorithm.

2.4.6

Congestion and packet Delivery

The Routing Layer attempts to keep network traffic through its node at
a manageable level. It accomplishes this through stringent assignment
of buffers. When buffer resources are exhausted, the Routing Layer
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 from the user) between nodes in a network.
Timely delivery occurs under normal traffic loads.

2-12

NETWORK CONCEPTS
2.5

SUMMARY OF PHASE III/PHASE IV COMPATIBILITY

The following types of nodes can exist in a Fhase IV network:
phase IV Router - This node sends messages to and receives messages
from other nodes, and routes messages from other source nodes to other
destination nodes. A phase IV Router can use one of the following
circuits:
Ethernet,
DDCMP,
or
X.2S.
In
an area network
configuration, Phase IV routers exist at two routing levels:
o

The level 1 router, which performs routing
area. The node type is ROUTING-IV.

within

single

The level 2 router, which performs routing within its own
area and to and from other areas.
The node type is
AREA-ROUTER. DECnet-10 does not perform level 2 routing.
However, a DECnet-10 system can use the services of systems
that support level 2 routing.

Phase IV Nonrouting Node (end node)
This node sends messages to, and receives messages from, other
nodes, but does not route messages. A Ph~se IV nonrouting node
can be connected through Ethernet or through DDCMP circuits. For
DECnet-10, it can be connected only through Ethernet. The node
type is NONROUTING-IV.
phase III Router
This node sends messages to and receives messages from other
nodes, and routes messages from other source nodes to other
destination nodes. It uses DDCMP, and X.25 circuits, but does
not support Ethernet circuits. The node type is ROUTING-III.
Phase III Nonrouting Node (end node)
This node sends messages to and receives messages from other
nodes, but does not route messages. This node cannot support the
Ethernet. The node type is NONROUTING-III.
phase II Node
This node can send messages to an adjacent phase III router or to
an adjacent phase II node. However, a phase II node can send
messages only in point-to-point configurations. In addition, a
Phase III node cannot communicate with a phase II node through
another Phase III node. A Phase II node cannot communicate with
a phase IV node. This node can never be on the Ethernet.

2.5.1

Topological Restrictions

The following types of nodes can be configured adjacent to each other:
o

phase II/Phase II

phase II/Phase III

phase III/phase III

phase III/Phase IV

phase IV/Phase IV
2-13

NETWORK CONCEPTS
phase IV nodes can communicate with Phase III nodes.
Certain
restrictions apply, however, in a mixed Phase III/Phase IV network:
o

A phase III node should not be included
phase IV nodes.

path

between

A Phase III node in a phase IV multiple-area network
not be linked with nodes outside its own area.

should

Routing initialization passwords are required when
III node is initialized in a phase IV network.

Phase

The following restriction applies to the placement of end nodes:
o

2.6

An end node must be adjacent to a routing node.

OPERATOR FUNCTIONS AND RESPONSIBILITIES

An "operator," in the context of this manual, is any terminal user
with the privileges to run the OPR program, and who is responsible for
entering NCP commands or running system or network-related programs
(requiring
these privileges)
for monitoring or controlling the
network.
An operator's duties can consist of well-defined, simple,
and
repetitive tasks, or can consist of complex tasks that cannot be
predefined. Some operators 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:
o

Have a clear idea of what your responsibilities are.

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

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

hardware

knowledge

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.
Never 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 the required USER
and PASSWORD parameters.
A list of functions commonly performed by operators follows.
As an
operator, you may be responsible for any of the following functions:
o

Starting the network automatically

Starting the network manually

Loading the DN20 manually (the DECnet-10 communication
end on KL10-based systems) if required

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

needed

the

front
network

NETWORK CONCEPTS
o

Loading and starting adjacent nodes

Monitoring local and remote nodes

Securing a dump after a crash

Changing parameters in the volatile data base

Shutting down a node or all network operation

Changing the state of network entities

Changing the routing path indirectly by changing the
cost

circuit

Gathering (and possibly
errors, performance)

(events,

Running SPEAR for reports on network events and errors

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

Testing network application programs

Recognizing potential problems
error rate, for example)

Using diagnostic tools

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

analyzing)

(long

statistics

response

command

time,

high

Once you have a clear idea of your responsibilities, concentrate first
on the sections of this manual that describe the functions you need.

2.7

SYSTEM MANAGER FUNCTIONS AND RESPONSIBILITIES

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

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-10 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?)

2-15

NETWORK CONCEPTS
Ideally, a system manager 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-10 environment.
o

Generating and installing the DECnet-10 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 (see the
TOPS-l~ DECnet and PSI Installation Guide).
The network may
grow in number ~nodes and other physical resources. As the
system manager, you may need to repeat some of the steps
followed in the original generation and installation in the
future. Some of the parameters established during system
generation may require change due to changes in resources.

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

providing appropriate documentation to all operators who will
use Network Management 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 cannot be built until you have analyzed
traffic patterns.

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

Checking the surveillance log periodically. Whenever OPR is
running
and
you
have typed "ENTER NCP," the system
automatically records all network activity.
This
log
includes the terminal number where the NCP command was
entered and contains the command itself. The current log has
the file name SSL:OPERAT.LOG[3,3]. When ORION is started or
restarted, this file is copied to SSL:OPERAT.nnn[3,3]
(for
example, OPERAT.001[3,3], OPERAT.~~2[3,3]), where nnn is the
next highest generation number. This is the file you can
examine to observe all NCP activity by date and time. (Use
the DIRECT monitor command to find the date and time you wish
to observe because 'frequently there are multiple files.)

2-16

NETWORK CONCEPTS

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:
adjust line cost to achieve new
routing paths, shut down network components or circuits, send
messages to all network operators, and analyze errors and
failures.

Bringing new devices, circuits, and users on line.

Gathering statistics on
errors, and failures.

network

use,

traffic

congestion,

You can 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.

2-17

PART II
DEenet OPERATION

CHAPTER 3
RUNNING DECnet-19

3.1

DECnet STARTUP PROCEDURES

To run DECnet on a DECSYSTEM-2~29 running TOPS-19, you need only bring
up the TOPS-19 monitor generated with DECnet.
On the DECsystem-1090/199l/l095 with a DN20 DECnet front end, you must
also load the communications front end with the MCB software. This
normally occurs automatically when TOPS-10 is loaded. It can also be
done manually any time after TOPS-10 is loaded.

3.1.1

Automatic DECnet-10 startup

When TOPS-10 is loaded, the INITIAprogram automatically uses the
FRCLIN functionality of the TOPS-10 monitor to process the commands in
the file SYS:SYSJOB.INI.
Following these commands, INITIA starts up
major system programs, such as ORION, QUASAR and LPTSPL.
The ORION program does an automatic TAKE of SYSTEM.CMD, which can then
schedule a TAKE of NCP.CMD.
(See the TOPS-19 Operator's Guide for
information on GALAXY and OPR.)

3-1

RUNNING DECnet-10
Mount the SYSTEM disk pack on drive 0.
Press the ENABLE rocker switch
while pressing the DISK rocker switch on the console front end.
RSX-20F VE15-31 10:30 24-May-85
[SY0: redirected to DB0:]
[DB0: mounted]
KLI -- VERSION VA15-50 RUNNING
KLI -- ENTER DIALOG [NO,YES,EXIT,BOOT]
KLI>
KLI
KL10 SIN: 2476., MODEL B, 60 HERTZ
KLI -- KL10 HARDWARE ENVIRONMENT:
MCA25 CACHE PAGER
EXTENDED ADDRESSING
INTERNAL CHANNELS
CACHE
KLI -- MICROCODE VERSION 2.0[411] LOADED
KLI -- ALL CACHES ENABLED
LOGICAL MEMORY CONFIGURATION.
ADDRESS SIZE
INT
TYPE CONTROLLER
00000000
1536K
4
DMA20
4
KLI -- CONFIGURATION FILE WRITTEN
KLI -- BOOTSTRAP LOADED AND STARTED
BOOT V3(47)
BOOT>DSKA:RL171B.EXE[1,4]
[Loading from DSKA:RLl7IB.EXE[I,4]]
RLI7IB DECI0 Development 05-15-85
Date: I5-JUN-85
Time: 10:34
startup option: Q
[Initializing CI network]
%% Node NOVA(31) up at 10:34:57
%% Node JUBLEE(2) up at 10:34:58
[CCPWFD Waiting for file daemon to start]
.LOGIN 1,2
Figure 3-1:

Startup Dialogue for
TOPS-10
Version 4.8 on a KL1090 System

3-2

Version

7.03

DECnet-10

RUNNING DECnet-10
RL171B DEC10 Development 10:34:59 CTY system 1026/1042
Connected to Node KL1026(26) Line # 361
.R OPSER
[OPRPAF processing auto command file]
[KNLRLD Reloading NI-0 with microcode version 1(167)]
%% Node SPIRIT(30) up at 10:34:58
%% Node NEXT(27) up at 10:34:58
%% Node COMET(70) up at 10:34:59
%% Node CTCH22(22) up at 10:35:00
[KNLRLD Reloading NI-1 with microcode version 1(167)]
%%TTY STOMPER - Starting
OPR
8
FAL
7
10:37:11(6)

1,2
1,2

1 [RP20 microcode %3(1)

SL
RN

00:00:02
00:00:00

o
o

loaded on CPU0, RH20 550, DX20 0 on 14-Jun-85

10:40:42]
Figure 3-1:

3.1.2

Startup Dialogue for TOPS-10 Version 7.03 DECnet-10
Version 4.1 on a KL1090 System (Cont~)

Manual startup of DECsystem-1090/l09l/1095 Communication
End

Front

The TOPS-10 and the MCB Operating Systems may crash independently.
When TOPS-10 fails, it attempts an automatic restart. If this restart
is successful, the Network Management Program running under TOPS-l0
checks to see if the MCB system is running.
If the MeB 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.
You can use the following sequence of commands if
the
DN20
communications froryt end fails to come up when the TOPS-10 KL10 node
comes up, or following a crash that is not followed by an autoload.
Normally, the first step loads the front end. If the load fails,
continue with the next sequence of commands.
You must have system
operator privileges to use these commands.
Step 1:

Type the following at your terminal:
.R OPR
OPR>ENTER NCP
NCP>SET CIR DTE-0-l STATE ON
NCP>SET CIR DTE-0-1 SERVICE ENABLED
NCP>LOAD NODE BOSTON
The circuit identification, DTE-0-l (DTE number 1 on CPU 0),
represents the DTE number connecting the MCB, node BOSTON, to
the KLl0.

3-3

DECnet-l~

RUNNING
Step 2:

If the load fails, enter NCP and type an NCP SET NODE command
for
each of the required parameters, inserting the values
appropriate for your MCB DN2~ node.
Include as the last
command, SET CIRCUIT DTE-0-1 SERVICE ENABLED.
The value
DTE-0-1 identifies the circuit over which the load occurs.
Use the command
file example in the next section to check
format.
"BOSTON" in the example is the name of the network
front end.
When loading the communications front end, you
values for the following parameters:

must

provide

Secondary Loader
Tertiary Loader
Service Circuit
CPU = PDPII
Load File
Dump File
Secondary Dumper
Host
Service Node version
You can now repeat:
NCP)LOAD NODE BOSTON

3.1.3

Manual Startup with Command Files

It is helpful to use command files for procedures that are often
repeated.
You
save unnecessary typing,
avoid such errors as
misspelling, and ensure against errors of omission. You will probably
find
it helpful to keep a set of command files in your own directory.
The following is an example of a command file, BOSTON.CMD, for loading
the front end named BOSTON:
CLEAR EXECUTOR NODE
SET NODE BOSTON CPU PDP-II
SET NODE BOSTON SERVICE CIRCUIT DTE-0-l
SET NODE BOSTON SERVICE NODE VERSION 0
SET NODE BOSTON SECONDARY LOADER SYS:DTEMPS.SYS
SET NODE BOSTON TERTIARY LOADER SYS:DTEMPT.SYS
SET NODE BOSTON LOAD FILE SYS:BOSTON.SYS
SET NODE BOSTON SECONDARY DUMPER SYS:DTEDMP.SYS
SET NODE BOSTON DUMP FILE XPN:BOSTON.DMP
SET NODE BOSTON HOST KLl036
SET CIR DTE-0-1 STATE ON
SET CIR DTE-0-I SERVICE ENABLED
LOAD NODE BOSTON
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 OPR.ATO file
is
executed. Normally, only the last two commands are required.

3-4

RUNNING DECnet-lg
Assume the TOPS-10 system is running.
Before using the network, you
check the status of the communications front end and receive the
following:
NCP>SHOW NODE BOSTON STATUS<RET>
NCP>
NCP
9:24:09
Request # 253; Show Node Status Completed
Node
State
Active Delay Type
Cost Hops Circuit
Links
Routing IV
7.129 (Boston) Reachable
1
Next node = 7.94(PYTHON)
If you do not receive output in a few minutes informing you that the
load was successful, you can TAKE the file Boston.CMD after returning
to monitor level. Input and output follow:
.send all Will use a .CMD file to load front end in 5 minutes
iiTTY5l: - Will use a .CMD file to load front end in 5 minutes
.R OPR
OPR>DISABLE OUTPUT-DISPLAY (OF) ALL-MESSAGES<RET>
OPR>
9:59:51
--Output display for OPR modified-OPR>ENTER NCP<RET>
NCP>TAKE BOSTON.CMD<RET>

NCP>SHOW NODE BOSTON<RET>
NCP>
10:02:26
NCP
Request # 271i Show Node Summary Completed
Node
7.129 (Boston)
NCP>

State

Active
Links

Delay

Circuit

Next Node

Reachable

The first command to the OPR program disables the display of all
messages.
This allows you to use the network facilities without
interruption by numerous messages about such things as batch programs,
tape mount requests and reports printed.
You will receive all NCP
responses and messages.

3-5

RUNNING DECnet-10
3.2

DECnet-10/PSI-10 RESTART PROCEDURES

Section 3.2.1 describes the restart procedure for the ORION
and Section 3.2.2 describes the restart procedure for NML.

3.2.1

process,

Restart Procedure for the ORION Process

If the ORION process fails while you are entering
following message appears on your terminal:

NCP

commands,

the

ORION not running
You can restart the ORION process with the following command
from a [1,2] job terminal:

sequence

.SYSTAT
(get job number for ORION)
.ATTACH JOB-NUMBER [1,2]
.HALT
.GET SYS:ORION
.CSTART
.DETACH or attach to old job-number
The ATTACH command re-attaches to the detached ORION program.
The
HALT command stops its execution. GET obtains a new copy of ORION.
CSTART restarts execution, and DETACH detaches the job.
If the restart is successful, the next step is to restart NML, the
Network Management program containing the NCP module among other
control modules (see Section 3.2.2). This is necessary because the
new copy of ORION has no knowledge of NML's location. When NML is
loaded, the initialization routine identifies itself to ORION. If the
communication front end has also crashed, you will also need to follow
the procedures in Section 3.1.2.

3.2.2

Restart Procedure for NML

If the aPR program cannot communicate with NML,
following message when you type an NCP command:

you

receive

the

--- NCP is not running --This message can occur when ORION cannot communicate with NML (as when
ORION is restarted without restarting NML). NML must be restarted.
If you receive no response from an NCP command within a few minutes,
enter the NCP command SHOW QUEUE. If NML refuses to respond to an NCP
command, it may simply be busy loading a node.
If there is no
response
to
SHOW
QUEUE,
assume
NML
has
stopped running.
(Alternatively, you can use your normal procedure for determining the
state of a program.) If NML is hung, then you should take a dump of
NML and, if possible, note a description of the environment.

3-6

RUNNING DECnet-le
You can restart the NML program with the
from a [1,2] job terminal:

following

command

sequence

.SYSTAT
(get job number for NML)
.ATTACH JOB-NUMBER [1,2]
.HALT
.GET SYS:NML
.CSTART
.DETACH or attach to old job-number
NML should be successfully restarted.
When NML is restarted, the volatile data base is lost. Therefore, the
procedure to restart NML includes TAKing the NCP.CMD file.
The
NCP.CMD file sets the node names and addresses (numbers)
for the
network and sets the values for the TOPS-Ie Network Management
volatile data base. Use the following commands:
.R OPR
OPR>TAKE SYS:NCP.CMD
OPR>EXIT
Once you restart NML, you are ready to continue network activity.

3.2.3

Restart Procedure for X29SRV

Use the following command sequence to restart the X29SRV program
a [1,2] job terminal:

from

.SYSTAT
(get job number for X29SRV)
.ATTACH JOB-NUMBER [1,2]
.HALT
.GET SYS:X29SRV
.CSTART
.DETACH or attach to old job-number
X29SRV should be successfully restarted.

3.2.4

Restart Procedure for PSITSB

If the background process PSITSB is not running when you run the
PSITST program, it displays a message similar to the following before
halting:
Encountered IPCF Error
PSITST Partner Process Does Not' Exist
This message occurs when PSITST cannot communicate with PSITSB.

3-7

RUNNING

DECnet-l~

PSITSB must be restarted, and you can restart the program
following command sequence from a [1,2] job terminal:

with

the

NCP

.SYSTAT
(get job number for PSITSB)
.ATTACH JOB-NUMBER [1,2]
.HALT
.GET SYS:PSITSB
.CSTART
.DETACH or attach old job-number
PSITSB should be successfully restarted.

3.3

CONTROLLING NODE, CIRCUIT, DTE, AND LINE STATE

DECnet-10 does not support the setting of node
command:
SET NODE nodeid STATE

OFF
ON
SHUT
RESTRICTED

state

using

You can, however, control the state of the circuits connected to your
node.
using the OFF parameter in the following NCP command, if there
is no alternate path, causes the adjacent node to become UNREACHABLE.
The circuit is nonoperational for network traffic. Therefore, when
you use this command you must consider the position of the node to be
set.
If the node is a full-routing node, you can disrupt network
traffic between several nodes.
OFF}
SET CIRCUIT cktid STATE { ON
You may wish to set a circuit OFF if errors over the circuit become
excessive, or if performance over the circuit becomes unacceptable.
For the PSI option, you can control X.2S
command:
SET MODULE X25-PROTOCOL STATE

~ OFF
) ON
( SHUT

access

with

the

following

l{ DTE
dte-address}
KNOWN DTES

You may wish to turn the DTE off to terminate access to the PPSN.
You can also control lines with the following command:
SET LINE lineid STATE
Certain NCP commands require that a line
execution of the command.

With DECnet-10, you cannot set circuit or line
CLEARED.

3-8

the

OFF

state

for

state

SERVICE

RUNNING DECnet-10
3.4

MONITORING NETWORK ACTIVITY

DECnet-10 software continually monitors both static and dynamic
characteristics and accumulates statistics for nodes, circuits, and
lines. These statistics are available to you in two major ways:
o

with selected NCP commands

with the SPEAR program

Considerable data is collected automatically. As a system manager,
you are responsible for planning the "how" and "when" of collecting,
organizing, and analyzing network data. If you take full advantage of
the system's automatic monitoring facilities, the network will run
more smoothly. Traffic patterns, hardware, and your site's needs can
change in time. Parameters can be changed more efficiently when based
on observations of actual statistics and characteristics.
Periodic analysis also helps you prevent problems before they disrupt
the network.
For example, you can make desirable routing changes by
adjusting the COST parameter before performance becomes unacceptable.
Before and after comparisons can aid in evaluating the effect of new
applications or additions to hardware. Observing traffic peaks may
suggest helpful changes in scheduling.
It is suggested that you run the SPEAR program daily (see Section
3.4.2 for details).
The interval between the monitoring of other
display types depends upon local activity and can only be decided
after some experience with your network. Because counters are zeroed
when the node where they are located goes down, some data may be lost
at that time.
How much is lost depends upon when data was last
captured. Using command or control files saves time and effort.
As a user with system operator privileges, you are responsible for
providing the input according to plan and schedule. This requires a
knowledge of the following:

3.4.1

the format of the appropriate NCP commands

an understanding of display types

familiarity with the specific items displayed according
entity, display type, and arguments and keywords used

an understanding of the SPEAR program

NCP Commands for Network Monitoring - Local and Remote

You can use NCP commands that display current attributes
and
statistics to monitor both the local node and remote nodes that have
implemented the commands. To obtain output from a remote node, use
either of the following procedures:
Procedure 1
NCP>SET EXECUTOR NODE MRVAX
(Wait for Set Node Complete message)
NCP>SHOW EXECUTOR CHARACTERISTICS
(Output follows)
3-9

RUNNING DECnet-lg
procedure 2
NCP)TELL MRVAX SH EX CHAR
The NCP commands for monitoring the local node and its
front end are described in Section 7.7.

communications

NOTE
Using the NCP commands in this manual to communicate
between DECnet-l~ V4.~ nodes and other nodes on the
network requires that the other nodes have implemented
Network Management Version 3.~ or later.

using the SPEAR Program for Network Monitoring

3.4.2

All network errors and significant events are written by the system
into the file SYS:ERROR.SYS. The SPEAR program can be used to read
these entries. You do not need privileges to run SPEAR.
However,
check any files that SPEAR uses for input or output. If accessing a
file requires certain conditions, these should be met before you run
the SPEAR program.
When the prompt SPEAR) appears on the terminal, you type the mode of
the SPEAR program you wish to run. You will probably find "RETRIEVE"
and "SUMMARIZE" modes most useful f~r monitoring the network.
SPEAR
next asks for specific information. Each request is followed by a
default answer in parentheses. To take the default, you press the
RETURN key.
SPEAR allows you to select only network-related events by specifying
the "Selection type" as ERROR.
You can then select one of the
following network-related event types:
NETWORK
NI
COMM

all network errors
all NI related entries
all communication device entries

The output of NETWORK can be restricted to
for example:
3

1,4

specified

event

classes,

all class 3 events
all class I and 4 events

The output of NI can be restricted with these options:
EBUS
MBUS
CRAM-PARITY
CHANNEL-ERROR
When SPEAR finishes selecting data as you have directed, SPEAR informs
you that retrieval is complete.
If you select the output default
(DSK:RETRIE.RPT for the RETRIEVE mode and DSK:SUMMAR.RPT for SUMMARY
mode), you can now type the report on your terminal, or print it.
The SPEAR program creates the appropriate output file (RETRIE.RPT or
SUMMAR.RPT) •
The next time you run SPEAR you overwrite any existing
file. Rename the previous file if you wish to save it.

3-l~

RUNNING DECnet-19
The runtime for the same SPEAR report can vary from a few minutes to
over an hour depending on filesize or system load.
Runtime is greatly
increased when you allow records to accumulate in the ERROR.SYS file.
Runtime is somewhat longer when the system is busy~
Use CTRL/T to
check both the runtime and the fact that SPEAR is still running during
the retrieval interval.
When you have many thousands of records to search, runtime may become
excessively long. Copying the ERROR.SYS file to tape every 39, 6~, or
99 days may not ensure a satisfactory runtime:
fairly minor problems
with
network or system hardware or software can result in a
proliferation of records sent to ERROR.SYS. As system manager, you or
a delegated operator should monitor the file to prevent time-consuming
SPEAR reports. Both the disk block count of the ERROR.SYS file
(use
the TOPS-l~ DIRECT command)
and the record sequence of retrieved
entries will help you determine when you should copy the ERROR.SYS
file to tape.
or tape
You should keep all ERROR.SYS records on disk (current)
(historical) •
(This complete copy is in addition to the regular
system backup copy.)
Example:
The following example shows the SPEAR program, which selects a full
report of network events in classes 3 and 4 occurring in the past two
days:
.R SPEAR<RET>
Welcome to SPEAR for TOPS-19, Version 2(1137)
Type "?" for help.
SPEAR> RETRIEVE<RET>
RETRIEVE mode
Event or packet file (SYS:ERROR.SYS):<RET>
Selection to be (INCLUDED):<RET>
Selection type (ALL): ERROR<RET>
categroy (ALL): NETWORK<RET>
Event class and type (ALL):3,4<RET>
Next category (FINISHED):<RET>
Time from (EARLIEST): -2<RET>
Time to (LATEST): <RET>
Output mode (ASCII):<RET>
Report format (SHORT): FULL<RET>
Output to (DSK:RETRIE.RPT):<RET>
Type <cr> to confirm (/GO):<RET>
INFO - Retrieving selected entries from SYS:ERROR.SYS
INFO -

Total Entries =

Retrieval Complete

SPEAR> EXIT<RET>

3-11

1~~.

RUNNING DECnet-10
SPEAR allows you to select between two output formats SHORT and FULL.
Because runtime depends primarily on search time for user-selected
records, the short form saves little
time
and
has
certain
disadvantages.
If you need any of the following information, select
the long form:
o

Detail on reason for error, if event was an error
Example:

Identification of the data link associated with an error
Example:

"Line synchronization lost"
for "circuit down, circuit fault"

"Circuit = KDP-0-1" for "circuit
down" and "circuit up"

For a "circuit up" event, the node at the remote end
circuit
Example:

the

"Circuit = KDP-0-0
NODE = Area.number

The short form is useful because of its simpler format for locating
specific events.
Once found, you can then limit your "selected
window" for the full report.
For definitions of DECnet events, see Appendix C.
For help in interpreting the SPEAR
SPEAR Reference Manual.

output,

see

the

DECnet-10 can act as host node in performing
for unattended systems.

the

following

3.5

TOPS-10/TOPS-20

DECNET-10 HOST SERVICES
services

Down1ine loading of an unattended system: transferring a copy
of an operating system file image from a TOPS-10 node to a
target node.

Upline dump of memory from an unattended system: transferring
a copy of a memory image from an unattended target node to
your TOPS-10 host.

Connect to a remote console permitting a TOPS-10 terminal to
act as the console for certain unattended systems, such as
the DECserver-100.

These operations are described in the following sections.

3-12

RUNNING DECnet-lg
3.5.1

DOWNLINE LOADING

DECnet-lg allows you to downline load an operating system image.
Downline loading
is the transferring of a copy of the system image
file of a remote node's operating system from a TOPS-lg node to an
unattended target node.
For example, DECnet-1g lets you load an MCB
image file from you DECnet-1g host node down1ine to a ,DN2A remote
node.
Down1irie loading can be initiated by a DECnet-10 opeiator or by
the remote node.
Following is a description of the nodes involved in the loading
sequence.
In the node descriptions, the command node and the executor
node can be the same or different nodes, but cannot be the targ~t
node.
See Figure 3-2.
o

Command Node. Anoperator-initi~ted down1ine load request
originates at the command node.
You can use either the NCP
LOAD or TRIGGER command to initiate this request.

Executor Node.
The executor node actually performs
a
down1ine load or trigger operation. It must be adjacent to
the target node because the down1ine load uses circuit-level
access.

Target Node. The target node is the node that
bootstap loaders and the system image file.
NCP>LOAD NODE TS1::
KL 1

KL1::
TOP8-1 0
Node

= Command Node
Executor Node
Host Node

TS1 = Target Node

NCP>TELL KL2:: LOAD NODE FE2::
KL1::
TOP8-1 0
Node

KL2::
TOP8-1 0
Node

KL 1 = Command Node
KL2 = Executor Node
Host Node
FE2 = Target Node

MR-S-4451-86

Figure 3-2:

Types of Nodes by Network Function

3-13

receives

the

RUNNING DECnet-10
Down1ine loading is initiated in one of two ways:
o

Target-initiated. The target node initiates the operation by
triggering its bootstrap ROM and sending a program load
request to the executor node.

Operator-initiated.
An operator on the
executor
node
initiates the operation with the NCP LOAD or TRIGGER command.

3.5.1.1 Target-initiated
Downline
Loading - If
the
load
is
target-initiated and the circuit is a non-Ethernet circuit, the
Routing layer process detects Low Level Maintenance Operation protocol
(LLMOP) messages coming over the circuit and calls the Data Link
Watcher (DLW).
If the target on an Ethernet circuit does not have a specific host
node from which to request a program load (for example, if the
target's host node crashes, or if the load is initiated by means of
the BOOT button on the target), the target proceeds as follows:
1.

The target node sends a program load request message to the
Ethernet load assistance multicast address AB-00-~0-0l-00-00.
This message is a request for any node on that Ethernet to
perform the load.

The nodes on the Ethernet whose Ethernet circuits are enabled
for service operations check their own node databases for a
remote node entry whose Ethernet hardware address matches
that of the target node.
This determines if they can
downline load the target. If so, they send to the target the
secondary loader (if the target is requesting the secondary
loader) , or a message volunteering to do the load (if the
target
is requesting the tertiary loader or operating
system) •

The target chooses the node responding first to continue the
loading sequence.
It does not send a message to any other
node. The loading sequence continues normally from there.

3.5.1.2 Operator-initiated Downline Loading - An operator-initiated
load uses NCP directly to perform the load operation. The target
node's primary bootstrap mayor may not have to be triggered depending
on the state of the target. The target node is triggered primarily to
put it into a known state and to force it to supply program request
information.
Use the NCP LOAD or TRIGGER command to perform an operator-initiated
down1ine load. The TRIGGER command allows you to directly trigger the
remote node's bootstrap ROM (if the device supports this), which
causes the target node to load itself in whatever manner the primary
loader is programmed to operate. The programs to be loaded may come
from a disk file local to the target node, another adjacent node, or
the executor node.
Note that the TRIGGER command mayor may not initiate a downline load.
One of the functions of this command is to simulate the operation that
occurs when the BOOT button on the target node is pushed. A bootstrap
operation from a local disk may result.

3-14

RUNNING DECnet-lg
When you use the LOAD command, the executor node proceeds with the
load operation according to the options specified in the initial load
request. Any required information that has been defaulted is obtained
from the host node's volatile database. with this information, the
executor is thereby able to control the load sequence.
Chapter 7 describes the TRIGGER and LOAD commands.

3.5.2

LOAD Sequence

The first program to run at the target node is the primary loader.
Typically, this program is either executed directly from the target
node's bootstrap ROM, or it is in the microcode of the load device
(DMC, DMR, DMP, DMV, NI). Once the target node's primary loader is
triggered, the target node sends a REQUEST PROGRAM LOAD message to the
executor node requesting a program load. Usually, the primary loader
requests a secondary loader program, which, in turn, may request a
tertiary loader.
The final program to be loaded is the operating
software. In this sequence, each program requests the next one until
the operating software is loaded.
The secondary loader is small (4~~-6~~ bytes) and is always sent as a
single MEMORY LOAD WITH TRANSFER message. The secondary loader is
always loaded into the lower 36K words of memory and operates without
memory management. The secondary loader requests the tertiary loader,
which is sent in multiple MEMORY LOAD messages followed by a MEMORY
LOAD WITH TRANSFER ADDRESS message.
The tertiary loader is much larger (1-3K bytes) and uses memory
management to relocate itself to the top of memory before requesting
the operating system. For this reason any operating system to be
loaded must not use the top 3K bytes of memory or the tertiary loader
would be forced to overwrite itself and the load would not be
successful.
The operating system is sent in multiple MEMORY LOAD
messages followed by a PARAMETER LOAD WITH TRANSFER ADDRESS message,
which supplies the start address of the image just loaded and contains
extra values for the node identification and the host identification.

3.5.3

Downllne Load Requirements

Before attempting a downline load operation, you must ensure that the
nodes, lines, and circuits involved in the downline load meet the
following requirements:
o

The target node must be connected directly to the executor
node.
This is necessary because the executor node uses
circuit-level access to load the target system; no routing
information is used.

The proper bootstrap must be present at the target node.
This
bootstrap must be capable of recognizing TRIGGER
messages if the node is to be operator-initiated downline
loaded or, be able to send program requests if the load is
target-initiated.

The physical hardware devices must be
support the load.

The executor node must have access to the load files.
The
location of the files can either be specified in the load
request or defaulted by the remote node database.
3-15

set

correctly

RUNNING DECnet-19
3.5.3.1 Downline Load Bootstraps - The downline load sequence is
started by a primary loader. This primary loader is contained in the
target node's bootstrap ROM or in the microcode of the target node's
load device. In either case, you must ensure that you have the proper
ROM support for the downline load to be initiated.
Following is a
list of the types of bootstrap supported by each device:
o

Power-on boot. This device can be used when
will be invoked by a power-on condition.

the

bootstrap

Remote trigger detect boot. This device can be used for
operator-initiated downline loads because it responds to the
TRIGGER message.

Console boot. When a power-on boot cannot be used, the
target's console can be used to start the downline load
sequence. If this is the only type of boot supported, the
target system cannot operate entirely unattended.

3.5.3.2 Setting Up the Downline Load Devices - If the sequence is to
function
correctly, the devices involved in the downline load
operation must be configured properly. In all cases the host node
device is set up in a normal manner (see the Operations Manual for the
device being used).
Whenever possible you should conduct a loopback test to verify the
operation of the Ethernet target's (and the host's) downline load
device before trying the downline load.

3.5.3.3 Set Up the Host Circuit - The host circuit must be in the ON
or SERVICE state; an Ethernet circuit must be in the ON state. For
example, the following command readies circuit DMC-9 for downline
loading an adjacent node:
NCP>SET CIRCUIT DMC-9 SERVICE ENABLED
NCP>SET CIRCUIT DMC-~ STATE ON

3.5.3.4 Establish Default Information - The most convenient method of
downline loading is to set up default information in the volatile
database. You can use the SET NODE command to establish default
information for the target node in the volatile database. For
example,
NCP>SET NODE 1.124 NAME KL2991

3.5.3.5 Trigger the Bootstrap Mechanism - Use the NCP TRIGGER NODE or
TRIGGER VIA command to trigger the bootstrap mechanism of a target
node, which causes the node to request a downline load.
Because the
system that is being booted is not necessarily a fully functional
network node, the operation must be performed over a specified
circuit. For example,
NCP>TRIGGER NODE JUPITE VIA DMC-9

3-16

RUNNING DECnet-l0
NOTE
If you use the TRIGGER NODE command and do not specify
a loading circuit, the executor node obtains the
circuit identification associated with the target node
from its volatile database.
If you use the TRIGGER VIA command, which indicates
the loading circuit but not the node identification,
the executor node uses the default target
node
identification in its remote database.

3.5.3.6 Overriding D~fault parameters - If you choose to override the
default parameters that were set up in the remote node's database
using NCP SET NODE command, you can change the following aspects of·
the TRIGGER sequence.
(See Chapter 7 for a detailed description of
the following parameters.)
o

The physical address of the target node:
PHYSICAL ADDRESS ethernet-address

The service password needed
device:

trigger

the

target's

load

used

the

SERVICE PASSWORD password
o

(For TRIGGER NODE only) The
downline load:

service

circuit

for

VIA circuit-id
Once the target node is triggered, it will then load itself in
whatever manner its primary loader is programmed to operate. The
target node could request a downline load from either the executor
node that just triggered it or another adjacent node, or the target
node could load itself from its own mass storage device.

3.5.3.7 Load the Target Node - Use the NCP LOAD NODE or LOAD VIA
commands to load the software downline to a target node. The LOAD
NODE command requires the identification of the service circuit over
which to perform the load operation. If you do not explicitly specify
a service circuit in this command, the executor node uses the SERVICE
CIRCUIT from the remote node database entry for the target node. Use
the SET NODE command to enter the SERVICE CIRCUIT in the database.
Alternatively, you can use the LOAD VIA command to specify the circuit
over which to perfor~ the downline load. For example, to load using
circuit DMC-0 connected to the executor node, issue the command:
NCP>LOAD VIA DMC-0

3.5.3.8 Procedure if the LOAD Fails - If the load fails, enter NCP
and define default parameters for downline loading. Each target
system to be loaded has a separate set of defaults. Use the SET NODE
command to set up the database. To remove node parameters from the
database, use the CLEAR NODE command.

3-17

RUNNING DECnet-10
NOTE
Some parameters have a different keyword associated
with them depending on whether the parameter is being
specified in the SET NODE command or in one of the
LOAD or TRIGGER commands.
The downline load parameters that you can define for
the database include:
o

each

target

A service circuit parameter for the executor node:
SERVICE CIRCUIT circuit-id

Parameters that pertain to the target node:
NODE node-id
NAME node-name
SERVICE NODE VERSION phase
SERVICE DEVICE device-type
SERVICE PASSWORD password
HARDWARE ADDRESS eth-address (Ethernet nodes only)
HOST node-id

Parameters that specify load files:
CONSOLE LOAD FILE file
CONSOLE SECONDARY LOADER file
LOAD FILE file
SECONDARY LOADER file
TERTIARY LOADER file
DIAGNOSTIC FILE file (Ethernet Communications Server
Only)

All these parameters are described in Chapter 7.
NOTE
For a downline load request to be successful, you must
specify at least the SERVICE CIRCUIT, NODE, NAME, and
LOAD FILE parameters either in the LOAD command or by
previously defined defaults. For Ethernet nodes, the
HARDWARE or PHYSICAL ADDRESS must also be specified.
When the appropriate values have been defined for the parameters
listed above, you can re-enter the LOAD command, for example:
NCP)LOAD NODE LAT180

Host Identification - At the end of the load sequence, the
target receives a message with the name of the host and places that
name in its volatile database. The target can then use the HOST
node-1d for downline task loading applications. The host may be the
executor node or any other reachable node except for the target
itself. Use the SET NODE command to specify a default host node where
the target will find the files used to load tasks downline.
For
example, the command below sets node BANGOR'S host to node NYC:
3.5.3.9

NCP)SET NODE BANGOR HOST NYC
You can override any default information by using the
for the LOAD command.
3-18

HOST

parameter

RUNNING DECnet-10
3.5.3.18 Load File Identification - The load files are those files to
be loaded downline to the target node. These files may consist of a
secondary loader, a tertiary loader, and an operating system image.
If the node is a communications server with an operator console, the
files may also consist of a console loader and a console secondary
loader.
You can specify default load file names in the volatile
database with the SET NODE command.
Load
files
default
to
SYS:nodename.SYS.
DECnet-10 does not support remote files for
downline loading or dumping.
The following sequence of NCP commands loads the
over a DTE circuit:

target

node

AURORA

NCP)SET EXECUTOR NODE BOSTON
NCP)SET CIRCUIT DTE-0-l STATE ON
NCP)LOAD NODE AURORA FROM SYS:AURORA.SYS
If the secondary and tertiary file names are not included in the LOAD
command or as entries in the volatile database for the target node,
the load will not occur.
The default secondary and tertiary loader files for DECnet-10 are
following:
Device
Type

Secondary
Loader

Tertiary
Loader

DTE
QNA
UNA

DTEMPS.SYS
SECQNA.SYS
SECUNA.SYS

DTEMPT.SYS
TERQNA.SYS
TERUNA.SYS

the

If you include the secondary and tertiary file names as entries in the
volatile database for the target node, they can override the default
loader files described above.
By using the SET NODE command, you can
select your own special load files for a particular target node.
If
you do not specify the load files, you can change the service device
type at the target node without changing the target node's database
entry at the executor node.
The system image file entry in the host node's volatile database
serves as the default file name for
the operating system to be
downline loaded. This file name is required when the target node is
to be loaded, but it can be supplied by the LOAD command.

3.5.3.11 Software Type - Along with identifying load files, you can
specify the file types to be used for the initial load.
For example,
if the target node is already running a secondary loader program, you
may only want to load the tertiary loader and operating system
downline. To do this, you use the SOFTWARE TYPE parameter with the
LOAD command.
For example, to load the tertiary loader file, which in
turn would load the operating system image, use the following command:
NCP)LOAD NODE BANGOR SOFTWARE TYPE TERTIARY-LOADER
Use the SET NODE command to specify default software type information
for
the target node entry in the volatile database.
If no software
type information is specified in the volatile database,
the default
type is the secondary loader.

3-19

RUNNING DECnet-10
3.5.3.12 CPU
and
Software
Identification - The
software
identification is the default program name of the operating system to
be loaded down1ine. Use the SOFTWARE IDENTIFICATION parameter to
specify a software-id of up to 16 alphanumeric characters. For
example, the following command specifies the default operating system
to be loaded downline:
NCP>SET NODE BANGOR SOFTWARE IDENTIFICATION SYS:RSX11S.SYS

3.5.3.13 Service Device Identification - The service device is, the
controller on the target node end of a service circuit. The service
device handles down1ine loading in a variety of ways, depending on the
device used. In particular, this device influences the type of files
suitable for down1ine loading. Default load file names are selected
according to the service device for the target node.
The SERVICE DEVICE parameter identifies the default secondary and
tertiary loaders for' the load operation. This parameter is required
for any down1ine load if the secondary and tertiary load files are not
specified in the volatile database of the target node. SERVICE DEVICE
is also required if the program load requests from the target node do
not specify the secondary and tertiary load file names. Use the SET
NODE command to specify the service device type in the volatile
database.
For example, the command below identifies the service
device as an NI device controller.
NCP>SET NODE BANGOR SERVICE DEVICE UNA-0
By using the SERVICE DEVICE parameter for the LOAD
override the default service information.

command,

you

can

3.5.3.14 Service Circuit Identification - In terms of the executor,
the service circuit is a circuit connecting the executor node with an
adjacent target node. When you issue the LOAD and TRIGGER commands,
you must specify or default to a circuit over which the load operation
is to take place. Use the VIA parameter to explicitly identify the
circuit when issuing those commands.
If specifying an Ethernet
circuit in the LOAD VIA command, you must include the PHYSICAL ADDRESS
parameter in the command.
If you do not specify a circuit, this information defaults to the
circuit specified in the target node's volatile database. To set a
service circuit in the volatile database, use the SET NODE command.

3.5.3.15 Service Passwords - When defining nodes for down1ine loading
in the local volatile database, the system manager can specify a
default service password. This password may be required to trigger
the primary bootstrap mechanism on the target node. If a user issues
a LOAD or TRIGGER command without a service password, then this
default parameter will be used if the target node requires one. To
set a service password in the volatile database, use the SET NODE
command. This password must be a hexadecimal number in the range 0 to
FFFFFFFFFFFFFFFF.
For example, to load node BANGOR use the following commands:
NCP>SET NODE BANGOR SERVICE PASSWORD FEFEFEFE
NCP>LOAD NODE BANGOR
3-20

RUNNING DECnet-10
3.5.3.16 Diagnostic File - Once the target node is loaded downline,
it can request diagnostics.
Use the DIAGNOSTIC FILE parameter in the
SET NODE command to identify (in the volatile
database)
the
diagnostics file that the target node can read.

3.5.4

Downline Loading a Communications Server

The following example show the procedure for
terminal server called LAT4 over the Ethernet.

downline

NCP)CLEAR NODE 13.204 NAME
NCP)CLEAR NODE 13.204 ALL
NCP)SET NODE 13.204 NAME LAT4
NCP)SET NODE LAT4 SERVICE CIRCUIT ETH-0
NCP)SET NODE LAT4 SECONDARY LOADER SYS:PLUT02.SYS
NCP)SET NODE LAT4 TERTIARY LOADER SYS:PLUT03.SYS
NCP)SET NODE LAT4 LOAD FILE SYS:PLATOT.SYS
NCP)SET NODE LAT4 DUMP FILE XPN:LAT4.DMP
NCP)SET NODE LAT4 SERVICE PASSWORD 0
NCP)SET NODE LAT4 HARDWARE ADDRESS AA0093912F99
NCP)SET NODE LAT4 HOST ETHER
NCP)SET CIRCUIT ETH-9 SERVICE ENABLED
NCP)LOAD NODE LAT4

3.5.5

Downline Loading the DN29

A manual load
circumstances:

the

DN20

may

indicated

the

following

The DN20 was not powered up when the KL10 was loaded

The DN20 became "UNREACHABLE" after being loaded and must
reloaded

If one of the above conditions exists, TOPS-10 should execute an
automatic reload of the system.
If the automatic reload does not
occur, try to load by using the appropriate command file (see section
3.1.3)
or by typing the necessary NCP commands on your terminal (see
section 3.1.2).
The following example shows the procedure for downline loading a
communications front end:

DN20

NCP)SET NODE D2102A CPU PDP-II
NCP)SET NODE D2192A SERVICE CIRCUIT DTE-9-l
NCP)SET NODE D2192A SERVICE NODE VERSION 9
NCP)SET NODE D2l02A SECONDARY LOADER SYS:DTEMPS.SYS
NCP)SET NODE D2102A TERTIARY LOADER SYS:DTEMPT.SYS
NCP)SET NODE D2192A LOAD FILE SYS:D2192A.SYS
NCP)SET NODE D2l92A DUMP FILE XPN:D2192A.DMP
NCP)SET NODE D2l92A SECONDARY DUMPER SYS:DTEDMP.SYS
NCP)SET NODE D2l92A HOST KL2102
NCP)SET CIRCUIT DTE-0-l STATE ON
NCP)SET CIRCUIT DTE-0-l SERVICE ENABLED
Note that since the DN20 is a phase III node, this procedure
the command:
SET NODE 2102A SERVICE NODE VERSION 0
which identifies the target as a Phase III node.
3-21

includes

RUNNING DECnet-10
3.5.6

UPLINE DUMPING

You can include certain SET NODE parameters in the volatile database
that allow an adjacent unattended node to dump its memory into a file
on your TOPS-10 system. This procedure is called upline dumping, and
it is a valuable tool for crash analysis. Programmers can analyze the
dump file and determine why the unattended system failed.
When an
unattended system detects an impending system failure, that system
requests an upline dump; for example, the DN20 may request an upline
memory dump to the KL10 system.
For upline dump operations, the local KLl~ node is referred to as the
executor and the adjacent unattended node as the subordinate. A
subordinate can be a DN20 or an Ethernet Communications Server.

3.5.6.1 Upllne
Dump
Procedures - This
section
describes
the
procedures for an upline dump initiated by a subordinate node. DECnet
uses the maintenance operation protocol (MOP)
to perform an upline
dump operation.
MOP is a subset of the DIGITAL Data Communications
Message Protocol (DDCMP), which sends messages used for circuit
testing, triggering, downline loading, and upline dumping. See the
Maintenance Operation Protocol Functional Specification for a more
complete discussion.
There are four steps involved in the upline dump process.
dump takes place by repeating step 3.

The

actual

When a subordinate node senses a system failure, it sends a
memory dump request to the KL10 host node. On the Ethernet,
it sends requests to a dump assistance multicast address if
an Ethernet host is not available. The request is a MOP
request dump service message.
This message might contain
information about the subordinate's memory size (DUMP COUNT)
and the upline dump device type at the subordinate.

If the message from the subordinate includes a DUMP COUNT
value, the host node uses it.
Otherwise, the host node
checks the subordinate node's entry in its volatile database
for the DUMP COUNT, the target address from which to start
dumping (DUMP ADDRESS) and the file where the memory will be
stored for the subordinate.
(If no entry exists for DUMP
ADDRESS, the value defaults to 0. If no entry exists for
DUMP FILE, the file defaults to XPN:node-name.DMP.) The host
node, which can now be considered the executor, sends a MOP
request memory dump message to the subordinate with the
starting address and the buffer size values.

Using the values it received from the
executor,
the
subordinate returns the requested block of memory in a MOP
memory dump data message. The executor receives the block of
dump data, places it in the DUMP FILE, increments the DUMP
ADDRESS by the number of locations sent, and sends another
request
memory dump message to the subordinate.
This
sequence is repeated until the amount of memory dumped
matches the DUMP COUNT value. The executor then sends a MOP
Dump Complete message to the target.

Once the upline dump is completed, the executor
node
automatically attempts to downline load the subordinate
system. It initiates the downline load by sending a TRIGGER
message to the subordinate.
3-22

RUNNING DECnet-l~
If the target node is on an Ethernet circuit, the target will attempt
to perform an upline dump to the node that originally loaded it
downline. If that node is not available, the target node proceeds as
follows:
1.

The target node sends a memory dump request to the Ethernet
dump assistance multicast address AB-~~-~~-0l-~~-0~. This
message is a request for any node on the Ethernet to receive
an upline memory dump.

The nodes on the Ethernet whose circuits are enabled to
perform service functions check their own databases to
determine if they can accept an upline dump.
If so, they
respond to the target node.
The target chooses the node
responding first to continue the dumping sequence.
The
target does not send a message to any other node. The
loading sequence continues normally from there.
Note,
however, that you may have to look for event 0.3 in the event
logs for all nodes on the Ethernet to determine which node
received the dump.

3.5.6.2 Upline Dump Requirements - Prior to attempting an upline dump
operation, you must ensure that the nodes, lines, and circuits meet
the following requirements:
1.

The subordinate node must be directly connected to the
executor node by a physical line. The executor node provides
the line- and circuit-level access.

The subordinate node must be capable of requesting the upline
dump when it detects a system failure.
If the dumping
prog.ram does not exist on the subordinate, upline dumping
cannot occur.

The circuit involved in the dump operation must be enabled to
perform service functions. It must also be in the ON state.
For example, the following command readies circuit ETH-~ for
upl ine dumping:
NCP>SET CIRCUIT ETH-~ SERVICE ENABLED
CIRCUIT ETH-~ STATE ON

NCP>SE~

If the subordinate does not supply the DUMP FILE name;
executor must have this entry in its volatile database.

the

3.5.6.3 Manual Upline Dump of the DN2~ MCB - This section applies
only to a MCB node adjacent to the KL10 host node. If the DN2~
crashes, Network Management software in the KL10 node senses that
communication has been lost. Using dump-related parameter values for
the DN20, the KLl~ initiates a dump of the entire contents of the
DN20's memory.
This is automatic and normally occurs whenever
communication between the TOPS-10 and the DN20 is lost.
A reload
normally follows the dump.

3-.23

RUNNING DECnet-10
If it appears that the automatic dump/reload is not going to occur
(you do not get a load node complete message), type an NCP SHOW QUEUE
command. If there is no response to SHOW QUEUE, wait 30 seconds.
(NCP cannot respond if it is in the process of dumping or loading.)
Because the system load has a significant effect on execution time,
you must judge wait-time by experience.
If the DN20 is still not online, use the following
TOPS-10 KL as executor:

command

with

the

where DTE-x-y identifies the SERVICE CIRCUIT over which the
load is to occur.

dump

and

NCP>SET CIRCUIT DTE-x-y SERVICE ENABLED

You should eventually receive the load node complete message. If you
don't receive the message, follow the procedures in Section 3.2.2
(Restart Procedure for NML).

3.5.7

Connecting to a Remote Console

DECnet-10 allows you to set up a logical connection between your
TOPS-10 node and the console interface on certain unattended nodes, in
effect permitting your terminal to act as the console for the remote
system.
For example, your terminal can act as the console for the
DIGITAL Ethernet Communications Server (DECSA)
hardware and its
resident software, such as the DECnet Router software and the
DECserver-100 Terminal Server.
You can set up the logical connection to the console using the RMTCON
facility.
Both your host node and the target node (that is, the
server node) must be on the same Ethernet.
For more information on using RMTCON, type HELP at the RMTCON> prompt.

3.6

TESTING THE NETWORK

In addition to using the SPEAR program, you can use loopback testing
and CHKII output as diagnostic tools to help determine whether the
network is operating properly. These tests let you exercise network
software
and hardware by sending data through various network
components and then returning that data to its source. After you have
started DECnet-10, you may want to run some of these tests. CHKII
output goes to SYS:ERROR.SYS.

3.6.1

Using Loopback Tests

DECnet-10 supports the NCP commands LOOP NODE and LOOP CIRCUIT.
The
LOOP LINE command is supported in the MCB for DECnet-10 PSI (LAPB
lines onl y) •
LOOP NODE exercises all DECnet layers in the DN20 and in the remote
node when the loop is executed from a local node to remote node.
Normal network activity continues with the appropriate protocols and
with the normal updating of counters at each level. The LOOP CIRCUIT
command, however, does not exercise all levels.
It uses the MOP
protocol, and does not result in the incrementing of counters.

3-24

RUNNING DECnet-10
You can use the LOOP NODE command to loop messages at a running remote
node, at the device controller, or at a turnaround connector (loopback
connector) on a physical line.
The following
examples demonstrate
these three uses.
The first example is best executed first:
if it
succeeds there is no need to test further.
The LOOP NODE procedure that loops at a remote node requires that
remote node is running Network Management V3.0 or later.

the

Example 1:
LOOP NODE - Local to Remote
.R OPR<RET>
OPR)ENTER NCP<RET)
NCP)SHOW NODE D1037A<RET)
NCP)
10:27:04
NCP
Request # 263; Show Node Summary Completed
Node

State

Active Delay Circuit
Links
123 (D1037A)
Reachable
0
1
DTE-0-l
NCP)LOOP NODE D1037A COUNT 10 LENGTH 20<RET)
NCP)
10:27:46
NCP
Request # 264 Accepted
10:27:53
NCP
Request # 264; Loop Node Completed
NCP)EXIT<RET>

Next Node

Example 2:
LOOP NODE - Using Device Controllers DMR and KDP (MCa only)
In this example, a circuit is established over which the messages will
travel, a
loop name is established,
and the controller is set to
loopback mode.
This example is for the Mca only.
For DMR:

(system output not shown)

NCP)SET EXECUTOR NODE D1036A USER OPERATOR PASSWORD SECRET
NCP)SET CIRCUIT DMR-0 STATE OFF
NCP)SET LINE DMR-0 STATE OFF
NCP)SET NODE FOO:: CIRCUIT DMR-0
NCP)SET LINE DMR-0 CONTROLLER LOOPBACK
NCP)SHOW LINE DMR-0 CHARACTERISTICS
NCP)SHOW CIRCUIT DMR-0 STATUS
NCP)SET LINE DMR-0 STATe ON
NCP)SET CIRCUIT DMR-0 STATE ON
NCP)LOOP NODE FOO:: COUNT 10 LENGTH 20
NCP)

***
***
***

This controller-loopback test is completed.
Procedure for restoring normal network
conditions follow.

NCP)SET CIRCUIT DMR-0 STATE OFF
NCP)SET LINE DMR-0 STATE OFF
NCP)SET LINE DMR-0 CONTROLLER NORMAL
NCP)CLEAR NODE FOO:: CIRCUIT
NCP)SET LINE DMR-0 STATE ON
NCP)SET CIRCUIT DMR-0 STATE ON
NCP)SHOW LINE DMR-0 CHARACTERISTICS
3-25

***
***
***

RUNNING DECnet-19
NCP)SHOW LINE DMR-9 STATUS
NCP)SHOW CIRCUIT DMR-9 STATUS
NCP)CLEAR EXECUTOR NODE
For KDP (MCB only):
This test differs from the test using the DMR in just one respect.
For the KDP controller loopback, you must set the CLOCK to INTERNAL.
This test is for the MCB only.
(System output not shown)
NCP)SET EXECUTOR NODE D1036A USER OPERATOR PASS SECRET
NCP)SET CIRCUIT KDP-9-9 STATE OFF
NCP)SET LINE KDP-9-9 STATE OFF
NCP)SET LINE KDP-9-9 CONTROLLER LOOPBACK
NCP)SET LINE KDP-9-9 CLOCK INTERNAL
NCP)SET NODE FOO:: CIRCUIT KDP-9-9
NCP)SHOW LINE KDP-9-9 CHARAC
NCP)SET LINE KDP-0-9 STATE ON
NCP)SET CIRCUIT KDP-0-0 STATE ON
NCP)LOOP NODE FOO:: COUNT 10 LENGTH 20

***
***
***

This controller-Ioopback test is completed.
Procedure for restoring normal network
conditions follow.

***
***
***

NCP)SET LINE KDP-0-1 STATE OFF
NCP)SET CIRCUIT KDP-0-9 STATE OFF
NCP)CLEAR NODE FOO:: CIRCUIT
NCP)SET LIN KDP-0-9 CONTROLLER NORMAL
NCP)SET LINE KDP-9-0 CLOCK EXTERNAL
NCP)SET LINE KDP-I-9 STATE ON
NCP)SHO LIN KDP-9-9 CHARAC
NCP)SET CIRCUIT KDP-0-9 STATE ON
NCP)CLEAR EXECUTOR NODE
Example 3:
LOOP NODE - Loopback Connector on Cable
This procedure is similar, but not identical, to controller loopback.
The LOOP NODE command is used again to do the testing. Messages are
looped back at a manually installed
(and later removed)
loopback
connector. Thus, the controller is not placed in loopback mode.
For DMR:

(system output not shown)

NCP)SET EXECUTOR NODE Dl036A PASS SECRET USER OPERATOR
NCP)SET CIRCUIT DMR-0 STATE OFF

***

Install loopback connector

NCP)SET NODE FOO:: CIRCUIT DMR-I
NCP)SET CIRCUIT DMR-I STATE ON
NCP)LOOP NODE FOO:: COUNT 19 LENGTH 29
NCP)CLEAR NODE FOO:: CIRCUIT
NCP)SET CIRCUIT DMR-0 STATE OFF

***
***

Remove loopback connector
Restore network connection

NCP)SET CIRCUIT DMR-I STATE OFF
NCP)CLEAR EXECUTOR NODE

3-26

***
***

RUNNING

DECnet-l~

For KDP (MCB only):
Thi s proced ure is similar to
that for
the DMR with a loopback
connector.
the KDP test requires that you set the line
However,
parameter CLOCK to INTERNAL. Hence, yo u turn both line and circuit
OFF before and ON after making parameter changes SET LINE and SET
(System output not shown)
NODE. Thi s proced ure is for the MCB only.
NCP)SET EXECUTOR NODE Dl~36A PASS SECRET USER OPERATOR
NCP)SET CIRCUIT KDP-~-~ STATE OFF
NCP)SET LINE KDP-0-0 STATE OFF
NCP)SET LIN KDP-0-0 CLOCK INTERNAL

***

Install loopback connector

NCP)SET NODE FOO:: CIRCUIT KDP-~-0
NCP)SET LIN KDP-~-0 STATE ON
NCP)SET CIRCUIT KDP-~-0 STATE ON
NCP)LOOP NODE Faa:: COUNT 10 LENGTH 20
NCP)SET LIN KDP-0-0 STATE OFF
NCP)SET CIRCUIT KDP-~-0 STATE OFF

***
***

Remove loopback connector
Restore network connection

***
***

NCP)CLEAR NODE FOO:: CIRCUIT
NCP)SET LIN KDP-0-0 CLOCK EXTERNAL
NCP)SET LIN KDP-~-0 STATE ON
NCP)SET CIRCUIT KDP-~-0 STATE ON
NCP)CLEAR EXECUTOR NODE
You can also use the LOOP CIRCUIT command from your local node to an
adjacent remote node, using controller loopback, and with a loopback
connector. The procedure would follow the appropriate node loopback
procedure except that the loopback node, FOO, would not be set.
(The
node loopback procedure is recommended.)
Example 4:
LOOP LINE - Loopback Connector on Cable (PSI option only)
This procedure is for the KDP only.

(System output not shown)

NCP)SET EXECUTOR NODE MRX25
NCP)SET LINE KDP-~-0 STATE OFF

***

Install loopback connector

***

NCP)SET LINE KDP-0-~ CLOCK INTERNAL
NCP)SET LINE KDP-0-0 SERVICE ENABLED
NCP)SET LINE KDP-0-0 STATE ON
NCP)LOOP LINE KDP-~-~ COUNT l2~ WITH MIXED LENGTH 10

***
***
***

This controller-loopback test is completed.
procedure for restoring normal network
conditions follow.

NCP)SET LINE KDP-0-0 STATE OFF

***
***

Remove the loopback connector.
Restore connection to PPSN modem

NCP)SET LINE KDP-0-~ CLOCK EXTERNAL
NCP)SET LINE KDP-0-0 SERVICE DISABLED
NCP)SET LINE KDP-0-0 STATE ON
3-27

***
***

***
***
***

RUNNING DECnet-10
3.6.2

Circuit Level Loopback Testing

In DECnet-10, circuit-level loopback testing is supported only for
Ethernet circuits.
The Network Management layer accesses the Data
Link layer directly, thus bypassing intermediate DECnet layers.
One
advantage of the Ethernet loopback test is that it can be performed
concurrently with other DECnet operations on the circuit.
DECnet-10 supports two types of looping on the Ethernet.
to the multicast address, or to a specific remote node.

You can loop

3.6.2.1 Looping to a Multicast Address - To test the NIA20 hardware
use the LOOP CIRCUIT command. All DECnet nodes on the Ethernet should
respond to the loop request. The loop test is successful if at least
one other system responds, indicating that the executor node's NIA20
is capable of communicating with other Ethernet nodes.
To be tested, an Ethernet circuit must be in the ON state and the
SERVICE parameter must be set to ENABLED. Note that, by default, the
SERVICE parameter is set to DISABLED for Ethernet circuits.
For
example:
NCP)SET CIRCUIT ETH-0 STATE ON
NCP)SET CIRCUIT ETH-0 SERVICE ENABLED
To initiate a looping test to
CIRCUIT command. For example:

multicast

address,

use

the

LOOP

NCP)LOOP CIRCUIT ETH-0
Use parameters with the LOOP CIRCUIT command to control the type of
test information and the number and size of blocks sent during
testing. Use the COUNT and LENGTH parameters to specify the number of
blocks and the length of each block (in bytes).
NCP)LOOP CIRCUIT ETH-0 COUNT 10 LENGTH 300
Use the WITH parameter to specify the type of binary information sent
during loopback testing~
You can specify three types of binary
informat ion:
ONES
ZEROES
MIXED

All binary ones
All binary zeros
A random combination of ones and zeros

For example, the following command sends 10 blocks
each containing all binary ones, over the circuit:

300

bytes

long,

NCP)LOOP CIRCUIT ETH-0 COUNT 10 LENGTH 300 WITH ONES

3.6.2.2 Looping to a Remote Node - Use the LOOP CIRCUIT NODE command
to test a logical link path over a circuit between the local node and
a remote node. You can specify the node's physical address or node
name in the LOOP CIRCUIT command. For example:
NCP)LOOP CIRCUIT ETH-0 PHYSICAL ADDRESS AA-80-BB-II-CC-22
or
NCP)LOOP CIRCUIT ETH-0 NODE TOSCA
You can also specify the COUNT, LENGTH, and WITH parameters.
3-28

RUNNING DECnet-10
3.6.3

Remote Loopback Tests Using a Loop Node Name

In DECnet-10, these tests can be used for DTE and Ethernet circuits.
Use the LOOP NODE command with a loop node name to test both local and
remote Routing layer software operation.
For example:
NCP>SET NODE TESTER CIRCUIT ETH-0
NCP>LOOP NODE TESTER
Note that you cannot assign two loop node names to the same circuit.
For example, once you establish TESTER as the loop node name for
circuit ETH-0, you must issue a CLEAR NODE TESTER CIRCUIT command
before assigning another loop node name to ETH-0.
When a logical link connection request is made to the loop node name,
all subsequent logical link traffic is directed over the associated
circuit. The destination of the traffic is whatever node address is
associated with the loop node name. The loop node name is necessary
because, under normal operation, DECnet Routing software selects which
path to use when routing information.
The loop node name overrides
the routing function so that information can be routed over a specific
circuit.
To remove the association of the loop node name with a
circuit, use the CLEAR NODE CIRCUIT or CLEAR NODE ALL command, as in
the following command:
NCP>CLEAR NODE TESTER CIRCUIT
A loop node name specified with the .SET NODE CIRCUIT command may be
used
for
any network traffic (for example, COpy requests or
application program traffic). The loopback node name appears as a
valid node name in the network for all purposes.

3.6.4

Manual procedure for Observing CHKll Output

You can use the following commands to observe CHKll output:
.R DTELDR
*/TALK:nn
where:
nn

is the two digits associated with DTE identification.
For example, for DTE-0-l, type "01" for "nn".

You must run CHKll before NML does a dump or load of the MCB,
this procedure the CHRll output is not output to SYS:ERROR.SYS.

with

You can also use SPEAR to examine SYS:ERROR.SYS after CHRll
recorded by Network Management.

been

3.7

has

NODE IDENTIFICATION

in the executor
When configuring the network, you must identify,
configuration database,
the local node and all network nodes with
which the local node expects to communicate.
Identifying all nodes by
name as well as address permits you to reach any node by its name.
This section describes node identification and NCP parameters relevant
to identifying nodes.

3-29

RUNNING DECnet-l~
Either the node address or the node name can serve as a node
identifier
(node-id)
in
NCP
commands; in all other network
applications only the node name may be used. The node address is a
decimal number assigned to the node in the configuration database.
The address must be unique within the network. The node address may
include, as a prefix, the area number, an integer indicating the area
in which the node is grouped. In the node address, the area number
and node number are separated by a period, in the following format:
area-number.node-number
For example, if node 3 is in area 7, its node address is 7.3.
The
area number must be unique within the network and the node number must
be unique within the area. If you do not specify an area number, the
area number of the executor node is used. The default area number for
the executor is the number of your local area.
In multiple-area
networks, it is recommended that you always specify the area number.
A node name is a unique alphanumeric string that contains up to six
characters including at least one alphabetic character. It must start
with an alphabetic character.
Before a remote node can be accessed by name, you must specify the
node name to be associated with a node address. Use the SET NODE
command to specify node names and node addresses. The command below
associates the node name TOSCA with the node whose address is 1.5.
NCP>SET NODE 1.5 NAME TOSCA
Once you set the executor node's address, you cannot change it unless
you restart the system. For DECnet-l~, the executor's node address is
specified during the system build (MONGEN), and cannot be changed
without rebuilding and reloading the system.

3.7.1

Maximum Address Parameters

The MAXIMUM ADDRESS parameter sets the highest node address, and
consequently, the greatest number of nodes that can be recognized by
the local node. Both the DN2~ and the KLl~ have maximum address
parameters.
The maximum address for the DN2~ is set with the NETGEN
command DEFINE EXECUTOR MAXIMUM ADDRESS, and the maximum address for
the KL1~ is set with the MONGEN dialog (see the TOPS-l~ DECnet and PSI
Installation Guide). The range for the DN2~ is 2-255, and the default
is 255. The range for the KL1~ is 1-1~23, and the default is 1~23.
It is recommended that you set the DN20 and KLl~ maximum addresses to
the same number, if possible. This will insure that the same nodes
can be recognized by the DN20 and the KLl~. If for example, the KLl0
maximum address is set to 1023 and the NIA2~ goes down, communication
with nodes above address 255 can not be resumed through the DN2~.
It
is also recommended that you set these parameters to the smallest
number possible to minimize overhead and memory usage.

3.7.2

Local Node Identification parameter

In addition to defining a node name and address for the local node,
you can also specify a descriptive quoted string of alphanumeric
characters. Use the IDENTIFICATION parameter with the SET EXECUTOR
command to specify this optional information:
NCP>SET EXECUTOR IDENTIFICATION "TOPS-l~ END NODE"
3-3~

RUNNING DECnet-10
NCP displays this identification in the SHOW EXECUTOR command display:
NCP>SHOW EXECUTOR

Identification =

TOPS-1~

END NODE

NCP>

3.7.3

Using and Removing Node Names and Addresses

Once you have specified a node name and address, you can use them
interchangeably whenever you need to specify a node-id in an NCP
command. The local DECnet-10 software translates the node names into
node addresses.
For example, where node TOSCA is set to address 7.5,
these NCP commands perform identical functions:
'
NCP>SHOW NODE 7.5 CHARACTERISTICS
NCP>SHOW NODE TOSCA CHARACTERISTICS
To remove a remote node address from the volatile database,
remove all parameters for the node as in the command:

you

must

NCP>CLEAR NODE TOSCA ALL
On a DECnet-10 node, the CLEAR NODE ALL command removes all parameters
except for
the node name.
To remove a remote node name from the
volatile database, use the CLEAR NODE command. The following command
removes the association between TOSCA and node 7.5:
NCP)CLEAR NODE 7.5 NAME
Once all parameters for a component are removed from the volatile
database, the component is no longer recognized by the executor.

3.8

ETHERNET ADDRESSES OF NODES

Nodes on Ethernet lines are identified by unique Ethernet addresses.
A message can be sent to one, several, or all nodes on an Ethernet
line simultaneously, depending on the Ethernet address used.
The
Ethernet address of a TOPS-10 node must be changed to a format that is
recognized by DECnet.

3.8.1

Format of Ethernet Addresses

An Ethernet address is 48 bits in length.
Ethernet addresses are
represented by six pairs of hexadecimal digits (6 bytes), separated by
hyphens (for example, AA-01-23-45-67-FF).
The bytes are displayed
from left to right in the order in which they are transmitted; bits
within each byte are transmitted from right to left. In the example
AA-01-23-45-67-FF,
byte
AA
is transmitted first;
byte FF is
transmitted last.

3-31

RUNNING DECnet-10
Xerox Corporation assigns a block of addresses to a producer of
Ethernet interfaces upon application. Thus, every manufacturer has a
unique set of addresses to use. Normally, one address out of the
assigned block of physical addresses is permanently associated with
each interface (usually in read-only memory). This address is known
as the Ethernet hardware address of the interface.
DECnet-10's interface to the Ethernet is the NIA20. To be compatible
with DECnet, the NIA20 must be set to a different address known as the
Ethernet physical address.
DECnet-10 sets the system's Ethernet
address to the correct value for the operation of DECnet-10.
The Ethernet physical address is constructed by appending the 16-bit
executor node address to a constant 32-bit number (AA-00-04-00) within
the block of Ethernet addresses assigned to DIGITAL.

+---------------------------------------+
1
32 bits
1 16 bits
1

1---------------------------------------1
1
Construct within
1 DECnet node 1
1

Ethernet block assigned I
to DIGITAL
I

address

+---------------------------------------+
An example is a phase IV routing node with DECnet address 1.182
(decimal), which would be set to an Ethernet physical address of
AA-00-04-00-B6-~4.

Once the Ethernet physical address has been set to its new value, it
is reset to its original hardware address value only when a reset is
issued to the NIA20 (for example, when the machine power is shut off) •
The Ethernet physical address of a node includes the number of the
area in which the node resides. The area number is represented by the
most significant 6 bits of the l6-bit DECnet node address, while the
number of the node within the area is indicated by the least
significant 10 bits of the node address.
If an existing network is not divided into areas, the default area
number 1 is stored in the DECnet node address of each node.
Conversion of an existing network to a multiple-area network may
require modification of the area number in the executor node address.

3.8.2

Ethernet Physical and Multicast Addresses

An Ethernet address can be a physical address of a single node or a
multicast address, depending on the value of the low-order bit of the
first byte of the address (this bit is transmitted first).
The two
types of node address are physical and multicast addresses.
The Ethernet physical address is the unique address of a single node
on any Ethernet (as described previously). The least significant bit
of the first byte of an Ethernet physical address is 0.
(For example,
in physical address AA-00-04-00-FC-00, byte AA in binary is 1010 l01~
and the value of the low-order bit is 0.)

3-32

RUNNING DECnet-lg
The Ethernet multicast address is a multidestination address of one or
more nodes on a given Ethernet. The least significant bit of the
fi rst byte of a mul ticast address is 1.
(For example, in the
multicast address AB-22-22-22-22-22, byte AB in binary is 19l9 l~ll
and the value of the low-order bit is 1.) A multicast address can be
either of the following:

3.8.3

Multicast group address. An address assigned to any number
of nodes;
this address can be used to send a message to all
nodes in the group in a single transmission. The number of
different groups that can be formed equals the maximum number
of multicast group addresses that can be assigned.

Broadcast address. A single multicast address (specifically,
FF-FF-FF-FF-FF-FF)
that can be used to transmit a message to
all nodes on a given Ethernet.
(Note that the broadcast
address should be used only for messages to be acted upon by
all nodes on the Ethernet, since all nodes must process
them. )

Values of DIGITAL Ethernet Physical and Multicast Addresses

DIGITAL physical addresses are in the range
AA-0g-04-FF-FF-FF.
Multicast
addresses
cross-company communications are:

AA-~~-g0-g0-~0-00

assigned

Value

Meaning

FF-FF-FF-FF-FF-FF

Broadcast

CF-gg-00-g0-00-00

Loopback assistance

DIGITAL multicast addresses assigned to be received by
nodes on the same Ethernet are:

for

through
use in

other

DIGITAL

Value

Meaning

AB-00-00-01-00-00

Dump/load assistance

AB-00-00-g2-00-00

Remote console

AB-00-g0-03-00-00

All phase IV routers

AB-00-00-04-00-00

All Phase IV end nodes

AA-00-00-05-g0-0g
through
AA-00-03-FF-FF-FF

Reserved for future use

AB-g0-04-00-00-00
through
AB-00-04-FF-FF-FF

For use by DIGITAL customers for
their own applications

DECnet always sets up the Ethernet controller at each node to receive
messages sent to any address in the above list of DIGITAL multicast
addresses. Only appropriate address are set up.

3-33

RUNNING DECnet-19
3.9

DATA LINK CONTROL

Several local node parameters regulate various aspects of physical
line operation.
These are the size of NSP receive buffers and
transmit buffers (segment buffers), the number of buffers used to
transmit on all circuits, and the number of circuits that the local
node can use as DECnet-l~ communication lines.
Four parameters are
provided for this purpose: RECEIVE BUFFER SIZE, SEGMENT BUFFER SIZE,
MAXIMUM BUFFERS, and MAXIMUM CIRCUITS. You should be careful to set
the values for these parameters to a reasonable level, or system
performance might suffer. The parameters all have reasonable default
values.
The RECEIVE BUFFER SIZE and MAXIMUM BUFFERS parameters can only be set
at system build time. The MAXIMUM CIRCUITS parameter can be set using
the NCP command SET MAXIMUM CIRCUITS. The SEGMENT BUFFER SIZE cannot
be changed.

3.9.1

Setting the Buffer Size

The buffer 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-l~ default value for BUFFER SIZE, 576
bytes, is the BUFFER SIZE most commonly used by DIGITAL systems that
support DECnet phase IV. To accommodate Routing messages, the BUFFER
SIZE must be at least 29~ bytes.
This value is set by the monitor symbol %DLBSZ, which is set with
MONGEN dialog when the system is built.

the

NOTE
It is strongly recommended that you use the same
buffer size for all nodes in your network. Otherwise,
nodes with smaller buffer sizes will drop packets when
you attempt to route through them.
The maximum buffer size for the DN2~ is 576 bytes. The maximum buffer
size for the Ethernet is 1476 bytes. Thus, data can be transmitted
faster with less processor load on the Ethernet.
(The smaller the
segments, the more messages have to be processed for a given data
stream. )
A buffer size that is greater than 576 bytes is used only for Ethernet
links;
the DN2~ defaults to 576.
Should the Ethernet become
unavailable when using a maximum buffer size that is greater than 576
bytes, the interrupted Ethernet links cannot be resumed through the
DN20. Instead, the user must restart the network operation.
For example, assume two systems are connected by the Ethernet and by
that both systems are allowing large buffers (greater than 576)
on the Ethernet. If the Ethernet becomes unavailable, the existing
logical links are broken and not switched to the DN2~. Thus, a file
transfer being transmitted between the two systems over the Ethernet
is aborted when the Ethernet becomes unavailable. However, the user
can start the file transfer again without any intervention required.
DN2~s,

3-34

RUNNING DECnet-10
The buffer size value can be less than 576 bytes; however, the smaller
value will be the maximum buffer size used on any link, including the
Ethernet.
The maximum buffer is actually 17 bytes less than the one set or
displayed.
The 17 bytes are used for DECnet headers. An application
can use the NSP. UUO to find the maximum buffer size, so that it can
use messages that are a multiple of the buffer size for maximum
efficiency.
The maximum size of the transmit buffer is specified in the SEGMENT
BUFFER SIZE parameter. This parameter cannot be changed in DECnet-10.
The segment buffer size is in the range of 256 to 576 bytes and is
automatically set to the same value as the buffer size. However, if
the buffer size is set to a value greater that 576, the segment buffer
will remain at 576 bytes.
You should consider the
val ue.

following

when

selecting

the

buffer

size

Faster lines perform better with large buffers and large user
messages that reduce the processor load. (The smaller the
segments, the more messages are processed.)

Lines that are error prone (for example, telephone lines)
should use small buffers (256 bytes) to reduce both the
probability and the cost of retransmissions.

3.9.1.1 Maximum Number of Buffers - The value that you
assign
determines
the size of internal data structures for DECnet-10
software. For most operations, DECnet-10 will allocate only as many
buffers as it needs (even if you specify a greater number than the
amount needed), and will not allocate more than the number of buffers
that you specify.

3.9.1.2 Maximum Number of Circuits - To specify the maximum number of
routing circuits that can be used, use the MAXIMUM CIRCUITS parameter.
This value determines the size of internal data structures' for
DECnet-10 software. For example, the following command establishes an
upper limit of 3 circuits that th~ local node can use:
NCP)SET EXECUTOR MAXIMUM CIRCUITS 3
The default value 1s 16.

3.10

REMOTE FILE ACCESS - FAL

The TOPS-10 File Access Listener (FAL) provides network-level remote
file access capabilities as specified in the Data Access Protocol
(DAP). FAL enables remote network processes to gain access to the
local TOPS-10 file system. FAL runs as a GALAXY-controlled request
queue called a FAL-stream.
You can have multiple FAL streams
operating at the same time.

3-35

RUNNING DECnet-l~
3.11.1

FAL Mode Operation

FAL is controlled by the OPR program. All commands are issued in OPR
and all status information is output by OPR. The OPR program has the
following commands for FAL:
o

SET Command

The SET command specifies which network each
will talk to. The SET command format is:

individual

FAL

stream

SET FAL-STREAM stream-list NETWORK network
where:
stream-list is a stream number or range of stream numbsrs to
affected.
network

is either ANF or DECnet. Specify DECnet to have the
FAL stream perform Input/Output (I/O) with a DECnet
network.

START Command

The START command is used to start up FAL's I/O
remote file access. The START command format is:

streams

allow

START FAL-STREAM stream-list
where:
stream-list is the list of FAL I/O streams to be started.
The START command directs FAL to initiate an inactive I/O stream so
that remote file accessors can gain entry into the local file system.
The START command does not actually start any I/O, it merely enables
the FAL process to receive and process remote file access requests.
o

DEFINE Command

The DEFINE command sets parameters that apply to all FAL streams.
DEFINE command format is:

The

DEFINE FILE-ACCESS REJECTION-LIST NODE::[P,PN] , •••
All connections for NODE::[P,PN]
wildcarded, for example:

will

rej~cted.

PPNs

can

OPR)DEFINE FILE-ACCESS REJECTION-LIST [1,2], MRVAX::[*,*]
DEFINE FILE-ACCESS DEFAULT-PPN [P,PN] sets the account under which all
FAt accesses, without access control information, will be executed.
The default is [377777,377777]. For example:
OPR)DEFINE FILE-ACCESS DEFAULT-PPN [2,5]

3-36

RUNNING DECnet-ll
o

ABORT Command

The ABORT command terminates an active I/O stream request.
command format is:

The

ABORT

ABORT FAL-STREAM stream-list
where:
stream-list is the I/O streams to be aborted.
The ABORT command imm~diately terminates the I/O streams specified~
No warning is given to the remote 'active' accessing process. The
effect on the I/O stream is the s~me as if the job had executed a
'RESET';
any file OPEN for input is closed, and any file OPEN for
output is aborted.
o

SHOW Command

The SHOW command displays the status of the current FAL
The SHOW command format is:

I/O

SHOW STATUS FAL-STREAM
or
SHOW PARAMETERS FAL-STREAM
Examples:
OPR>SHOW STATUS FAL-STREAM
OPR>
Fal-Stream Status:
Strm
Status Node

Connect Time Bytes

Idle
Active KL5872
~:~~::5~
631
Reading file DSKA:FAL.MEM for user [1~,5535]
Connect MRVAX
Idle
Idle
Active BOSTON
~:1~:41
65l~2
Writing file LPT7~0:QPRV2.MEM for user [6~,5635]
Idle
Idle
Idle
Idle

1
2
3
4
5
6
7
8
9
OPR>

OPR>SHOW PARAMETERS FAL-STREAM
OPR>
11:36:~6
--System Device Parameters-Fal-stream Parameters:
Strm

Network

DECnet
DECnet
DECnet
DECnet

1
2
3
4
5

..-------

ANF-l~
ANF-l~

OPR>

3-37

streams.

RUNNING DECnet-lg
o

SHUTDOWN Command

The SHUTDOWN command terminates FAL-based I/O operations in an orderly
manner for a specified stream. The SHUTDOWN command format is:
SHUTDOWN FAL-STREAM stream-list
where:
stream-list is the I/O streams to be shutdown.
The SHUTDOWN commmand immediately aborts and terminates all dormant
I/O streams selected. All currently active I/O streams selected are
marked for termination when the remote active process releases control
of the DAP link.
o

STOP Command

The STOP command temporarily
command format is:

freezes

FAL

I/O

streams.

STOP FAL-STREAM stream-list
where:
stream-list is the list of I/O streams to be frozen.

3-38

The

STOP

CHAPTER 4
THE NETWORK CONTROL PROGRAM

4.1

OPERATOR INTERFACE

The Network Control Program
(NCP)
commands provide the only user
interface to operational controls and measurements of DECnet-10
Version 4.0.
This manual uses the term NCP to refer to the
application-specific subset of commands that are part of NML. NML
refers to the entire program (commands, local processing routines, and
dispatching of IPCF and NICE messages) •
NCP commands are executed on the TOPS-10 operating system as one set
of application commands available through the operator interface
program OPR.
In this case, the application is DECnet-10 running under
TOPS-10 V7. '" 3.
The
DECnet-10
DN20
communications
front
end
on
DECsystem-1090/1091/1095 systems has no direct command interface. NCP
commands to control the network or obtain network information are
executed through the NCP on the DN20's host or the NCP on another
network node.

4.2

PROCESSING OVERVIEW

During GALAXY generation, with the GALGEN program, NCP tables are
supplied to aPR. These tables provide the information needed by aPR
to parse the NCP commands. A command that is syntactically correct is
accepted by OPR,
formatted as an IPCF packet, and sent to ORION.
ORION dispatches the packet to the Network Control program.
The
program acknowledges all commands received by returning an IPCF packet
for output to the user's terminal. Therefore, NCP commands cannot be
executed if ORION is not running.
How and where the NCP commands are processed and executed is
determined by the NCP's analysis of the command. OPR/NCP generic
commands, commands that can be processed locally without access to
other architectural layers, commands to be processed locally that do
require interlayer communication, and commands to be processed by
remote nodes, all
follow different paths.
You can save time in
recovering from abnormal situations if you know the path taken by
commands.
If,
for example, ORION stops running when you are in the
process of entering a command to be processed locally by the NCP/NML
process,
there is no point in looking further for the cause of the
problem. The NCP request cannot be forwarded to NCP/NML until you, or
another operator with that responsibility, restores ORION.
Chapters 5
and 6 describe the processing path for the generic commands and the
locally processed commands requiring a minimum of processing.
In
general, these commands are simple in format and easy to understand.

4-1

THE NETWORK CONTROL PROGRAM
Commands requiring communication with other architectural layers in
the local system and commands to remote nodes require additional
parameters because of the more complex nature of interlayer and
node-to-node communication. These commands are processed by routines
in the NML of the local or remote node. Commands processed by NML are
described in Chapter 7.
Both IPCF and NICE messages (used to communicate with NML) are
internal and transparent to you as an operator entering NCP commands.
As an operator, your responsibility is to type the NCP commands
accurately and completely.
Sections 4.4 and 4.5 will help you in
typing and checking the NCP commands.
Refer to Figure 1-3 to review the processing flow described above
preview the flow to follow.

4.3

and

NCP FUNCTIONS

NCP commands perform two major functions:
o

Controlling network activity

Monitoring network activity

Control functions you can perform with NCP include:
o

Downline loading of a DN2~ or Ethernet
( DECSA)

Setting and
parameters

Changing the network configuration

Modifying message-traffic patterns

Initiating and terminating network functions

changing

line,

node,

Communication
circuit,

Server

and

logging

Upline dumping of a DN2~

Displaying information
about
network
entities
characteristics and/or states) and counters

(their

Displaying the status of operations on the network, including
operations in progress and operations that have failed

Measuring network performance by displaying the contents of
counters and the output of the Event Logger through the SPEAR
prog ram.

performing loopback tests

Monitoring functions you can perform with NCP include:

The planning function is served by collecting information from the
day-to-day
control and monitoring functions.
This information,
however, must be organized and saved in usable form.

4-2

THE NETWORK CONTROL PROGRAM
4.4

NCP FEATURES

The NCP command language has many features that make it easy to use.

4.4.1

Typing Commands at the Terminal

There are three ways to type commands:
o

Full input mode

Recognition mode

Abbreviated mode

Each of the following commands is acceptable:
Example using full input:
NCP>SHOW KNOWN CIRCUITS SUMMARY
Example using recognition:
NCP>SH<ESC>OW K<ESC>NOWN C<ESC>IRCUITS SU<ESC>MMARY
Example using abbreviation:
NCP>sh k c su

4.4.2

Editing Commands

You can use the following character commands to edit your input to
NCP.
Because of the more complex nature of the NCP commands, you may
wish to add to your current use of these commands.
o

DELETE
Moving backwards from the last character typed, deletes
one character each time you press the DELETE key.

CTRL/U
Deletes all characters typed since the beginning
line.

the

CTRL/W
Deletes back to the last punctuation character (including
space) •

CTRL/H
Used after receiving a format-error message, retypes
command up to the point of error.

the

CTRL/R
Used to display the current
characters you have deleted.

4-3

command

line,

omitting

THE NETWORK CONTROL PROGRAM
4.4.3

Using Comments

You can include comments on the command line or on a separate line by
prefixing the comment with a semicolon or exclamation point. The
semicolon causes the remainder of the line to be considered as a
comment;
the exclamation point causes only the text up to the next
exclamation point or the end of the line to be considered as a
comment.

4.4.4

Multiple Line Commands

A long command can be continued to the next line by simply typing the
The system
command past the end of the line onto the next line.
If you want
allows fields of a command to be split between two lines.
to avoid splitting a command field,
type a hyphen as the last
character in the line. For example:
NCP>SET EXECUTOR HARDWARE ADDRESS 11 INCOMING TIMER 30 STATE ON

4.4.5

Getting Help from NCP

Helpful text is output to your terminal if you type a question mark at
the beginning of any field.
Note, in the example that follows, how using the question mark guides
you through the correct format of a command.
Assume you wish to check
current network activity. You know that the command keyword for
display is SHOW, but you are uncertain about the rest of the command.
You proceed as shown below, checking for both possible choices and
command completion.
Command completion is implied when the response
is "confirm with carriage return".
NCP>SH<ESC>OW ? one of the ~ollowing:
ACTIVE
ADJACENT
AREA
CIRCUIT
LINE
LOGGING
LOOP
MODULE
SIGNIFICANT

EXECUTOR KNOWN
NODE
QUEUE

NCP>SHOW K<ESC>NOWN ? one of the following:
AREAS
CIRCUITS
LINES
LOGGING
MODULES

NODES

NCP>SHOW KNOWN N<ESC>ODES ? one of the following:
CHARACTERISTICS
COUNTERS
STATUS
SUMMARY
NCP>SHOW KNOWN NODES ST<ESC>ATUS ? confirm with carriage return
NCP> shOW kNOWN nODES stATUS
NCP>
14:52:50
NCP
Request # 116; Show Known Node Status Completed
Cost Hops Circuit
Active Delay Type
Links
Unreachable
1 (TOPS20)
0
5
Unreachable
7.2(RALPH)
Routing IV 14
7.3 (PIONER) Reachable
5
DTE-fJ-l
7.4{TOPS10) Reachable
1 Routing IV 19
ETH-0
0
8
Node'

State

(Output continues.)
4-4

THE. NETWORK CONTROL PROGRAM
4.5

NCP COMMAND OPERATION

The following sections describe how to use NCP commands.

4.5.1

Accessing NCP Commands

The Operator Command Language program, OPR, provides the operator with
one command language to communicate with TOPS-l0 application programs,
including the Network Control Program. To invoke NCP,
run OPR and
then give .the command ENTER NCP:
.R OPR
OPR>ENTER NCP
NCP>
Alternatively, you can execute a single NCP command from
level by typing NCP followed by the NCP command:

OPR

command

The

system

OPR>NCP SHOW KNOWN NODES
To return to the TOPS-10 monitor from
prints the TOPS-10 prompt, ".".

4.5.2

NCP,

type

EXIT.

Access Control

If a node-id in a command represents a node to be connected to, you
may
need
to enter access control
information.
Access control
information can consist of one or any combination of the keywords
USER,
PASSWORD, and ACCOUNT, each keyword followed by a valid value.
Access control parameters follow the node-id in the command string.
with the USER parameter, specify a project-programmer number or
user-name
(up to 39 characters)
(for the MCB, the information
specified at NETGEN).
The PASSWORD parameter can contain up to 39
printable characters, and the ACCOUNT parameter can be up to 39
characters long.
Systems other than TOPS-10 may require a format that
differs from the TOPS-10 format.
Each node in the network may limit
the amount of access control data it will accept.
(See section 6.7
for more information on the access control parameters.)

4.5.3

Restricting NCP Commands

As implemented on TOPS-10, using NCP requires only that you have
system (.OBSOP) operator privileges. The appropriate values for these
privileges are entered in ACTDAE.SYS. Your privileges are enabled by
default when you log in.
To set NCP prameters from a remote node, you
must specify an account that has these privileges or POKE privileges.
Refer to
the TOPS-10 Software Installation Guide if you require
additional informatIon on accessIng and settIng values for privileges.

4-5

THE NETWORK CONTROL PROGRAM
4.5.4

Queued Commands

When NCP cannot immediately process a command, the command is placed
in the NCP request queue. Once a request is queued, you can resume
giving NCP commands. The SHOW QUEUE command lists the queued requests
that are processing or waiting to be processed.

4.5.5

Command Input

NCP input takes the form of arguments delimited by one or more
or tabs.

blanks

If you type a carriage return following the NCP prompt (without typing
a command), the NCP prompt is repeated.
Multiple outstanding commands are permitt~d.
the order entered.

4.5.6

NML

processes

them

Command Output Response

The most general output content and format in response to NCP commands
includes the following:
time

NCP
Request inn; Command input status
Entity type = Entity Identification
Requested Information or "No Information"

where:
time

is in hours, minutes, seconds (hh:mm:ss)

Command input is a brief identification of the request you typed
status

is one of:
Complete - information follows
Accepted - information follows after a brief
delay
Failed - reason for failure follows and,
optionally, further detail is given

Entity-type

is either AREA, NODE, CIRCUIT, MODULE, LINE, or
LOGGING
(singular
or plural form).
If the
entity-type Is NODE, NODE will be preceded by
EXECUTOR, REMOTE, or LOOP. All commands to change
either the volatile or permanent data base of a
remote node should include the required USER and
PASSWORD parameters.

4-6

'THE NETWORK CONTROL PROGRAM
Requested Information differs according to the action
entity specified, and the arguments given.

requested,

the

The output "No Information" means that no paiameters
No failure of the command is implied.

have

~een

set.

Example 1:

Request for characteristics o~ the TOPS-10 node:

.R OPR<RET>
OPR>DISABLE OUTPUT-DISPLAY (of) ALL-MESSAGES<RET>
OPR>
9:27:41
--OUTPUT DISPLAY for OPR Modified-OPR>ENTER NCP<RET>
NCP>SHOW NODE BOSTON CHARACTERISTICS<RET>
NCP>
9:28:25
. NCP
Request # 255; Show Node Characteristics Completed
Executor Node = 7.124 (BOSTON)
Identification = DECnet-10 Version 4.~
Management Version = 4.0.0
Loop Count = 1
Loop Length = 127
Loop With = Mixed
Identification = RC177B DEC10 Development
Incoming Timer = 30
Outgoing Timer = 60
NSP Version = 4.0.0
Delay Factor = 48
Delay Weight = 10
Inactivity Timer = 120
Retransmit Factor = 10
Routing Version = 2.0.0
Type = Routing IV
Routing Timer = 120
Broadcast Routing Timer
40
Maximum Address = 255
Maximum Cost = 1012J
Maximum Hops =28
Maximum Visits = 30
Maximum Broadcast Nonrouters = 64
Maximum Broadcast Routers = 32
Maximum Buffers = 80
Buffer Size = 576
Segment Buffer Size = 576
NCP>
Example 2:

Request for status of known circuits
(Executor is SATURN):

NCP>SHOW KNOWN CIRCUIT STATUS<RET>
NCP>
9:29:16
NCP
Request # 256; Show Known Circuits Status Completed
Circuit

State

DTE-0-3
DTE-1-3
ETH-12J
ETH-0

On
On
On
On

Loopback
Name

Adjacent
Block
Node
Size
7.111(CHRYON)
576
7.252 (GNOME)
576
7.58 (MARTEN)
1498
7.62(DEEP)
1498

NCP>

4-7

THE NETWORK CONTROL PROGRAM
Example 3:

Request for status of known circuits
(Executor is SATURN)

NCP>SET EXECUTOR NODE SATURN<RET>
NCP>
NCP
9:30:07
Set Executor Complete
NCP>SHOW KNOWN CIRCUIT STATUS<RET>
NCP>
NCP
9:30:51
Request # 257 Accepted
NCP>
9:30:53
NCP
Request # 257; Show Known Circuits Status Completed
Circuit

State

Loopback
Name

DTE-0-1
On
User = Node / 7.129 /

SATURN

KDP-0-0
On
User = Node / 7.129 /

SATURN

Adjacent
Node
7.124

Block
Size
576

7.123

576

KDP-0-1
On
Substate = Synchronizing
User = Node / 7.129 / SATURN

576

KDP-0-2
On
Substate = Synchronizing
User = Node / 7.129 / SATURN

576

KDP-0-3
On
Substate = Synchronizing
User = Node / 7.129 / SATURN

576

NCP>EXIT
Appendix C lists and explains, in text or by
output to the user's terminal,
including
console.

example,
the CTY

all messages
or operator's

The general output format given in Appendix C does not apply to
commands processed by OPR or processed by the local NCP program.
commands translated into NICE messages follow the content of
format example for DECnet-10 V4.0.
The actual order of items
their physical placement may differ for other operating systems.

4.5.7

NCP
All
the
and

Specifying the Executor

DECnet-10 V4.0 is designed to make central, fully distributed, or
partially distributed control and management possible. An NCP command
does not have to be executed at the node where it is typed.
Therefore, the operator must determine and designate the node that is
to process and execute each command. You can specify the executor by
implication (allowing the default to be effective), by a SET EXECUTOR
command, or by using the TELL prefix. For a detailed description of
how to specify the executor, see the commands in Chapters 6 and 7.
The operator must be aware of the characteristics (and status) of all
nodes in the network to effectively determine the ability of a node to
act as executor for the command node.

4-8

THE NETWORK CONTROL PROGRAM
4.5.8

Specifying Files in NCP Commands

File specifications used as arguments in NCP commands for execution by
nodes follow TOPS-l~ file specification conventions.

DECnet-l~

The full file specification for DECnet-10 is:
dev:filename.ext[p,pn]
The TOPS-10 Operating System
specifications in detail.

Commands

Manual

describes

file

Example:
DSK:SECDMC.SYS[1,2]
Note that the file operations are actually performed by another job,
so you cannot use job-wide logical names, or depend on search lists or
paths being set up by your job. You can, however, use ersatz device
names such as SYS: and SSL:, which are system wide. In the case of a
load file residing on SYS:, you could use either the specification
SYS:DTEMPS.SYS or SSL:DTEMPS.SYS[1,4].
However, you should avoid
using DSK:DTEMPS.SYS[1,4], which depends on the search list for your
job.

4-9

CHAPTER 5
NCP COMMANDS PROCESSED BY OPR

5.1

OPR/RCP COMMANDS

Some of the OPR commands available in the NCP application subset are
for general use by operators;
that is, for activities other than
network activities. These commands require no action by NCP.
They
are processed directly by OPR. These commands are:
ENTER (command subset) application-name
EXIT (to monitor level)
PUSH (to monitor level)
RETURN (to operator command level)
TAKE (commands from)
WAIT (for)

5.2

fileid

/DISPLAY
/NODISPLAY

seconds

EXAMPLES OF USE OF OPR/RCP COMMANDS

Because these commands are among those used frequently by operators,
the description of the input/output examples is specific to network
functions.
Only the OPR/NCP commands appear in red so that you may
identify them readily.
Assume that you are the user [29,7199] with operator privileges and
that you are logged in on a DECsystem-109l host node.
First, you run
OPR and disable all messages output periodically by the OPR program.
These commands are never necessary, but they are helpful if you are
using your terminal under timesharing and wish to avoid interruptions.

5-1

NCP COMMANDS PROCESSED BY OPR
Next, you enter NCP and check the status of the local node.
The
system reports that "State is On". So far, you have the following
input/output:
.R OPR<RET>
OPR>DISABLE OUTPUT-DISPLAY (0£) ALL-MESSAGES<RET>
9:37:39
--Output display for OPR modified-OPR>ENTER NCP<RET>
NCP>SHOW EXECUTOR STATUS<RET>
NCP>
5:29:14
NCP
Request # 27 Show Executor Node Status Completed
Executor Node = 8.11~ (ALPHA)
State = On
Physical Address = AA 00 ~4 0~ 8E 1C
Active Links =1
NCP>
You next type EXIT to return to the TOPS-1~ monitor, and then you type
the NETWORK/DECNET command to check for currently accessible nodes.
(The NETWORK command without the /DECNET switch displays nodes from
all networks in the system;
it displays ANF-1~ nodes as well as
DECnet-1~ nodes.) You type:
NCP>EXIT<RET>
.NETWORK/DECNET<RET>
[DECnet network: local node ALPHA, 134 reachable nodes in area 7]
ABACUS ABLE
ADAM
AJAX
ALGOL
ALIEN
ALPHA
ALPINE
ARSON
ARUBA
ARWEN
ASIMOV AURORA BABEL
BANZAI BAXTER
CACHE
CAR
CASTOR CDR
CHAOS
CHARLY CHIPS
CHUCKL

WAFER
ZEKE

WILBUR
ZEPHYR

WINNIE
ZEUS

WIZARD
ZIP

5-2

WOMBAT
ZONKER

WOOKIE
ZOO

XENON

VODA

NCP COMMANDS PROCESSED BY OPR
You then run OPR again and ENTER NCP, as shown above.
The following
order of commands assumes you wish to check the number of operators
with jobs on the host node.
Satisfied that the system is not
overloaded, you reenter NCP. Assume that you now wish to check the
DTE counters. Using the SHOW EXECUTOR command, you find that the host
node is the executor. You set the EXECUTOR to be the Dl~26A. You are
called away from the terminal and repeat the SHOW EXECUTOR command
when you return. Whenever you interrupt a network session, checking
the EXECUTOR is desirable. Do not assume that there has been no
user-activity at your terminal during your absence.
Also, the
EXECUTOR you previously set may have gone off-line. You have added:
NCP>RETURN<RET>
OPR>SHOW OPERATORS<RET>
OPR>
l5:l9:~7
-- Operators
Node
Type
Terminal
ALPHA
system
ALPHA
system
ALPHA
system
OPR>ENTER NCP<RET>
NCP>SHOW EXECUTOR<RET>
NCP>
15:19:49
NCP

Job

User

7 OPERATOR [1,2]
46 OPERATOR [1,2]
65 ANDERSON [2~,7l~~]

24~

2
56

Executor Node = 9.ll~ (ALPHA)
Identification = DECnet-l~ Version 4.0
State = On
Active Links = ~
NCP>SET EXECUTOR NODE D1~26A<RET>
NCP
15:41:33
NCP
Set Executor Complete
NCP>SHOW EXECUTOR<RET>
NCP
15:41:38
NCP
Request # 39 Accepted
NCP>
15:41:39
NCP
Executor Node = 9.121 (D1~26A)
Identification = DECnet-10 Version 4.0 Release
State = On
Active Links = 1

5-3

NCP COMMANDS PROCESSED BY OPR
In the following example, you have the SHOW COUNTERS command in a file
named CNTDTE.CMD and use the TAKE command for indirect input. The
/DISPLAY switch displays the command entered.
At this point, you
continue with whatever network activities you had planned.
Finally,
you use the EXIT command to return to the TOPS-l~ monitor.
NCP)TAKE CNTDTE.CMD /DISPLAY<RET)
NCP)CLEAR EXECUTOR NODE<RET)
NCP)
15:42:10
NCP
Clear Executor Complete
NCP)TELL D1026A SHOW CIRCUIT DTE-0-1 COUNTERS<RET)
15:42:15

NCP
Request i

43 Accepted

15:42:16
NCP
Request i 43; Show Circuit Counters Completed
Circuit = DTE-0-1
Seconds Since Last Zeroed
17443
Terminating Packets Received
4059
Originating Packets Sent
4669
Terminating Congestion Loss
63
Transit Packets Received
39842
Transit Packets Sent
47361
Transit Congestion Loss
3
Circuit Downs
~
Initialization Failures
~
Bytes Received
1532485
Bytes Sent
2522599
Data Blocks Received
43993
Data Blocks Sent
52~32
NCP)EXIT
You can now log off or continue with other activities using the
monitor. You have in this short terminal session used each of
the OPR/NCP commands except WAIT.
You have also moved efficiently
among three command sets.

TOPS-1~

The format of the WAIT command is:
WAIT (for)

seconds

where seconds is a number from 1 to

6~.

You use the WAIT command in command files and batch control files;
it
attempts to ensure that the response to one command is output before
the next command is processed.
If you did not insert the WAIT command
following an NCP command that might take a few seconds to process, it
is possible for the command sequence to continue or complete before
the response is output. With experience you will learn to approximate
the time required for responses in your particular environment.
The
argument cannot exceed 6~ seconds, but you can increase the wait time
by repeating the WAIT command.

5-4

CHAPTER 6
NCP COMMANDS PROCESSED BY THE NETWORK CONTROL PROGRAM

NCP processes certain commands directly by means of an internal data
path between NCP and the volatile network data base in the host node
(the DECsystem-1090/1091/1095 KL10 node or the DECSYSTEM-2020 KS10
node) •
See Figure 1-3 if you wish to review the flow of these
commands. Commands processed internally by NCP/NML include:
SET EXECUTOR NODE nodeid

(Section 6.1 )

DEFINE EXECUTOR NODE nodeid

(Section 6.2)

CLEAR EXECUTOR NODE

(section 6.3)

PURGE EXECUTOR NODE

(Section 6.4)

SHOW QUEUE

(Section 6.5)

CANCEL QUEUE REQUEST requestid

(Section 6.6)

[USER ppn]
TELL nodeid [PASSWORD password] NML-command-line
[ACCOUNT account]
HELP

(Section 6.7)

(Section 6.8)

(TELL and its arguments form a command prefix. A command to a remote
node follows.
The local node processes the prefix, whereas the remote
node processes the command.)
Format, function, arguments (keywords and variable data), examples,
and remarks if called for, follow for each of the NCP commands (and
prefix) that NCP processes locally.

6.1

SET EXECUTOR

SET EXECUTOR NODE nodeid [USER userid][PASSWORD password] [ACCOUNT account]
Function:
The SET EXECUTOR command acts immediately to establish the node
specified as the processing node for subsequent commands. The
value of nodeid becomes part of the temporary data base.
The
node specified in the command continues to be sent commands to
process until you change the executor with another SET EXECUTOR
command or clear the executor with the CLEAR EXECUTOR command.
If the system goes down, this value is lost. You cannot execute
this command remotely.
6-1

NCP COMMANDS PROCESSED BY THE NETWORK CONTROL PROGRAM
Arguments:
nodeid

This can be the decimal number representing
address of the node, or the node name.

userid
password
account

These arguments provide access control information and
mayor may not be required. The system you specify
with nodeid sets the required format for these values.
On TOPS-19 systems, the userid is a ppn or user-name
up to 39 characters long, the password and the account
are each up to 39 characters long.
For the MCB
processor, the password is up to eight characters
long, and the account and userid are each up to 16
characters long.
(See
Section
6.7
for
more
information on access control parameters.)

the

Examples:
Example 1:

To display characteristics for the

DN2~

node:

NCP)SET EXECUTOR NODE D1e36A
NCP)
14:17:17
NCP
Set Executor Complete
Example 2:

To change a parameter value, add access information:

NCP)SET EXECUTOR NODE Dle37A USER OPERATOR PASSWORD SECRET
NCP)
12:28:32
NCP
Set Executor Complete
NCP>
Remarks:
Note that commands processed locally receive an
immediate
response of Complete or Failed and are not assigned a request
number.
If you specify values for USER and PASSWORD during the generation
procedures for the DN29 Mca front end, you must specify these
values in the SET EXECUTOR command if you intend to execute a
command that alters the DN20's data base.
(ACCOUNT is an
optional parameter, but if present, it must match the value set.)
If you omit these values when setting the executor, subsequent
commands that set or change parameter values will fail.
WARNING
If you have not set USER and PASSWORD values, any user
at a remote node can manipulate the Mca operating
system by setting the executor to your DN2~ Mca node.
You do not need USER and PASSWORD values with the SET EXECUTOR command
if subsequent commands are to be SHOW commands.

6-2

NCP COMMANDS PROCESSED BY THE NETWORK CONTROL PROGRAM
6.2

DEFINE EXECUTOR

DEFINE EXECUTOR NODE nodeid [USER userid][PASSWORD password] [ACCOUNT account]
Function:
The DEFINE EXECUTOR command establishes the specified node as the
processing node in the permanent data base. This is the default
value for the executor.
When NCP is started, the default
executor is the node on which the control program is running,
unless the executor node was previously defined with the DEFINE
EXECUTOR command.
The values in the permanent data base remain
from one initialization to the next. The executor node in the
permanent data base can be changed only by the DEFINE EXECUTOR or
the PURGE EXECUTOR command.
Arguments:
The arguments are the same as those defined for the SET
command.

EXECUTOR

Remarks:
Not implemented .for DECnet-lC?J.

6.3

CLEAR EXECUTOR

CLEAR EXECUTOR NODE
Function:
The CLEAR EXECUTOR command accomplishes the reverse of the SET
EXECUTOR command.
It removes the value that was previously
entered in the volatile data base as the executor.
After this
command, the executor defaults to the node on which NCP is
running unless a DEFINE EXECUTOR command has previously been
given. For operating systems that support a permanent data base,
the value in the permanent data base is always the default taken
when no value is given. For DECnet-lC?J, the executor defaults to
the TOPS-lC?J KLlC?J or KSl~ node when this command is executed. The
CLEAR EXECUTOR NODE command cannot be executed remotely.
Arguments:
The keyword NODE acts as the only argument.

6-3

NCP COMMANDS PROCESSED BY THE NETWORK CONTROL PROGRAM
Example:
NCP>SET EXECUTOR NODE D1836A USER OPERATOR PASSWORD D1836<RET>
NCP>
9:30:41
NCP
Set Executor Complete
NCP>SHOW EXECUTOR<RET>
NCP>
9:30:53
NCP
Request
244 Accepted
NCP>
NCP
9:30:54

Executor Node = 7.129 (D1036A)
Identification = DECnet-10 4.0 Release
State = On
Ac t i veL ink s == 1
NCP>CLEAR EXECUTOR NODE<RET>
NCP)
9: 31: 27
NCP
Clear Executor Complete
NCP>SHOW EXECUTOR<RET>
NCP>
9: 31: 34
NCP
Executor Node = 7.110 (KL1826)
Identification = DECnet-10 Version 4.0
State = On
Active Links = 2
NCP>
Remarks:
This command is the simplest way to change the executor from
DN20 MCB front end to the TOPS-18 KL18 host.

6.4

the

PURGE EXECUTOR

PURGE EXECUTOR NODE
Function:
The PURGE EXECUTOR command accomplishes the reverse of the DEFINE
EXECUTOR command.
It removes the value that was previously in
the permanent data base as the executor. The default executor is
then the node where NCP is running.
Remarks:
Not implemented for DECnet-l8.

6-4

NCP COMMANDS PROCESSED BY THE NETWORK CONTROL PROGRAM
6.5

SHOW QUEUE

SHOW QUEUE
Function:
You use the SHOW QUEUE command to display the NCP-request queue.
This command causes the display of either a list of NCP-requests
waiting to be processed, or the message [The queue is empty].
Request numbers are assigned in order as commands are received.
Therefore, request numbers are in ascending order.
The numbers
are consecutive when you are the only operator using NCP. To
locate the command you entered, refer back to the command.
The
request number is printed
immediately before "Accepted" and
"Completed."
Arguments:
None.

(NCP-requests is implied.)

Examples:
NCP>SHOW QUEUE<RET>
NCP>
9:38:22
NCP
[The queue is empty]
NCP>

*****
NCP>SHOW QUEUE<RET>
NCP>
9:41:31
NCP
Request t 249 Active, Remote, Executor

7.129 (D2136A)

Remarks:
The SHOW QUEUE command is potentially helpful when you receive no
response from any command within a few seconds.
If there is no
response from SHOW QUEUE, one of two conditions is probable: the
NML program is busy loading an adjacent node, or the NML program
is hung. Wait a few minutes, and if there is still no response,
restart NML.
(See Section 3.2.2 for NML restart procedures.)

6.6

CANCEL QUEUE REQUEST

CANCEL QUEUE REQUEST requestid
Function:
Use the CANCEL command to remove a request from the queue before
processing begins.
You can check the status of the request with
the SHOW QUEUE command.
Argument:
requestid

requestid is the number assigned to a command
request
by
NMLi
this number is output
immediately following all commands that will
be translated into NICE messages (commands in
Chapter 7.)
6-5

NCP COMMANDS PROCESSED BY THE NETWORK CONTROL PROGRAM
Remarks:
You cannot cancel commands processed locally by NCP (commands in
this chapter).
They are executed immediately and do not appear
in the queue. Also, you cannot cancel requests that are noted as
Active.

6.7

TELL PREFIX

TELL nodeid

[USER userid]
[PASSWORD password]
[ACCOUNT account]

NCP command
prefix

Access control
keywords and parameters

command line

NCP command to
be executed by
node named in
nodeid

Function:
You use the TELL nodeid prefix to designate the node that is to
execute the command. The prefix is effective only for the single
command that immediately follows.
The receiving node can require any combination of the three
access keywords and parameters, or none of them. The receiving
access
node can refuse to execute the command even when
parameters meet requi rements. (See Remarks.)
Arguments:
[USER userid]
[PASSWORD password]
[ACCOUNT account]

You must format access control parameters
according to
the
conventions of the
operating system of the node specified
in node id.

TOPS-10 format:
USER [p,pn] or USER user-name
where:
p

is a field of up to six octal
digits
representing the user's project number.

is a field of up to six octal
digits
representing the user's programmer number.

user-name

is any combination of
exceeding 39.

ASCII

characters

not

is any combination of
exceeding 39.

ASCII

characters

not

PASSWORD password
where:
password

6-6

NCP COMMANDS PROCESSED BY THE NETWORK CONTROL PROGRAM
ACCOUNT account
where:
account

is any combination of
exceeding 39.

ASCII

characters

not

MCB format:
PASSWORD is any combination of 6-bit characters
8.

not

exceeding

ACCOUNT is any combination of ASCII
16.

not

exceeding

characters

USER is any combination of ASCII characters not exceeding 16.
TOPS-2~

format:

Each parameter can contain any combination of ASCII
not exceeding 39.

characters

Other DIGITAL operating systems:
See the documentation for that system.
Examples:
TOPS-1~:

TELL KL1836::
USER [18,5665] PASSWORD DEC18 ACCOUNT NETWRK -<RET>
ZERO KNOWN LINE COUNTERS
TOPS-2~:

TELL D21~2A::
USER NISI PASSWORD DECNET ACCOUNT 341 -<RET>
ZERO KNOWN LINE COUNTERS
Remarks:
using the TELL prefix is more efficient than a combination of SET
EXECUTOR and CLEAR EXECUTOR commands when you need to give only
one command to a node. Assume you have set the executor to node
CAR for
the purpose of monitoring network traffic there for an
hour or more. The system manager interrupts you with a request
to check the status of lines at node BAR. You can use the
command TELL NODE BAR SHOW KNOWN LINE STATUS.
The TELL prefix
command format overrides the previous setting of the executor to
node CAR, displays the status of lines at node BAR, and allows
you to continue with commands to be executed at node CAR.
Before using this or any other NCP command requiring that access
control parameters be sent to another node, you should have
established both the values and the format that is acceptable to
the remote node.

6-7

NCP COMMANDS PROCESSED BY THE NETWORK CONTROL PROGRAM
Assuming the access control parameters are correct, the receiving
node can still reject the connection for a number of reasons.
For example, all logical links at the receiving node are busy,
the state of a required obj~ct does not allow processing of the
command, or the receiving node cannot verify parameters given by
the sender.
The receiving node sends the source node a reject
message with a reason for the rejected connection. Depending on
the reason given, you must determine the likelihood of obtaining
a successful connection at a later time. A TELL command could
also fall if the specified node does not respond in 60 seconds.

6.8

USING THE HELP COMMAND

The HELP command provides a convenient display of the function of any
NCP commands.
Typing HELP lists the commands; typing HELP keyword,
where keyword is an NCP command keyword, lists
all
possible
combinations of command keyword and entity keyword.
Examples:
NCP>HELP RETURN(RET>
Use RETURN to return to OPR command level.
NCP>HELP CLEAR(RET)
Use CLEAR to clear parameters of an entity from the volatile data
base. Additional information available
CLEAR CIRCUIT
CLEAR EXECUTOR NODE
CLEAR LINE
CLEAR LOGGING
CLEAR MODULE
CLEAR NODE
NCP>HELP CLEAR LINE(RET>
CLEAR LINE is used to clear the volatile line parameters for
line(s) identified in the command.

6-8

the

CHAPTER 7
NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER

7.1

PROCESSING OVERVIEW

The NCP commands described in this chapter are processed by routines
in
the Network Management Layer (NML)
and involve transparent
conversion of NCP commands to Network Information and Control Exchange
(NICE)
protocol messages. Commands to be executed by the local node
are processed by the local node's NML; commands to be executed by a
remote node are processed by the remote node's NML.
The NML itself contains most of the logic and data bases needed to
process the NCP commands. When needed information resides in other
architectural layers, NML uses its interface to the ~ppropriate layer
to read or set parameters. Both system managers and operators will
find that a knowledge of the processing flow of NCP commands will
increase their efficiency in using and maintaining the network.
All communication with NML that involves an exchange of data between
local and remote nodes is by means of the NICE protocol.
(This
includes communication between the 1~90/1091/1~95 main processor and
the DN20.) As an operator, you are not required to know the details of
the NICE protocol. It may be necessary for a programmer to have a
working knowledge of NICE (refer to the DECnet Di ital Network
Architecture Network Management Functional Specificat on, Version
4.0). The Network Control Program understands NICE, and given a valid
NCP command, will reformat the command-content (now in an IPCF
message)
into a NICE message for the intended NML. There is one NICE
message for each NCP command.

When the intended receiver is a remote NML, all DECnet systems use the
same method of sending the NICE message. The message is sent over a
logical link provided by End Communication and session Control.
When NML receives a NICE message from a remote NML, it always sends an
acknowledgement to the sender. Following the receipt of a command,
the NML of the node that acted as executor sends a response to the NML
of the command node. Here NCP/NML formats this response into an IPCF
packet; the packet is forwarded to ORION; ORION dispatches the
response to OPR; the response is displayed on the operator's terminal.
You have now followed the paths taken by various NCP commands.
You
may wish to refer to Figure 1-3 for a visual review. Note that your
participation was restricted to entering the NCP command at the
terminal and receiving an acknowledgement. Later, normally within a
the
few seconds, you receive a response that informs you of
disposition of the command. When this response indicates no action
was taken, the system, to the extent possible, gives the reason a
The examples that follow, beginning in section 7.4, show both positive
and negative responses to individual commands. Appendix C contains
additional examples, including common sequences of commands.
7-1

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
7.2

DECnet-10 IMPLEMENTATION AND EXTENSIONS

DECnet-l~
Version 4.~ implements a subset of the NCP commands
described by DNA for Version 4.~ of Network Management. X.25-specific
commands are implemented for the PSI software (see Chapter 8).
DECnet-l~ does not implement commands specific to DMP multipoint.

In addition, DECnet-l~ contains two extensions made to accommodate the
distinctive hardware characteristics of DECsystem-l~. The extensions
to the DNA specification are:
o

Remote permanent parameters
The communications front end (DN2~) has
no
modifiable
permanent memory. Certain MeB (DN2~) data base items are set
during network generation and are stored in the front-end
system image. The NCP commands PURGE and DEFINE cannot affect
these values after network generation.

Boot DN2~ on failure
This facility detects that the DN2~ communications software is
not communicating with the KLl0 processor. The DN2~ is then
automatically reloaded.

7.3

NML CONCEPTS AND ORGANIZATION OF PARAMETERS

Some of the NCP commands that NML processes have up to twenty possible
parameters. Most of these parameters appear in several commands. The
most commonly repeated keywords that accept other keywords
as
arguments
(rather
than
specific variables like name or line
identification) appear in this section. You will save yourself time
if you make the required associations at this time. Until you become
familiar with the command/entity/keyword/variable combinations, the
following
descriptions
of
concepts, variables, and groups of
parameters common to specific entities should help you to choose the
correct parameter and interpret the output when you use the "?"
feature.

7.3.1

Entities

The major network management keywords are those that immediately
follow the command action word (such as SET or LOAD). These keywords
specify the element on which the command is to act.
All other
keywords act as "labels" for variables to be typed or as requests to
choose one of a set group of responses.

7-2

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Some entities are either singular or plural. You can include only one
entity in each command. The following list includes all entities in
commands processed by the NML for DECnet-lg Version 4.g:
Sing ul ar

7.3.2

pI ural

AREA

ACTIVE AREAS
KNOWN AREAS

CIRCUIT

ACTIVE CIRqUITS
KNOWN CIRCUITS

LINE

ACTIVE LINES
KNOWN LINES

LOGGING

ACTIVE LOGGING
KNOWN LOGGING

MODULE

ACTIVE MODULES
KNOWN MODULES

NODE

ACTIVE NODES
AJACENTNODES
KNOWN NODES
LOOP NODES

Entity Identification

The plural form of an entity defines and restricts itself.
(Active
lines,
for example, are known lines in the ON or SERVICE state.)
However, you must follow each singular form of an entity by an
identification in a system-specific format to indicate one specific
line, circuit, or node. The identification is also referred to as the
name of the entity.
NOTE
Devices that are similar in operations are referred to
by the same mnemonic. See Appendix F for a list of
mnemonic device names for devices used by DECnet-l~.

7.3.2.1 Circuit and Line Identification - This section describes the
identification of circuits and lines in NCP commands. Circuits and
lines are identified in the same wasy, with the exception of the
tributary number, which applies only to circuits.
DTE Identification
DTE-cpu-uni t
cpu

is the number of the CPU on which the DTE resides.

unit

is the number of the DTE unit.

Example:
NCP)SET LINE DTE-9-1 STATE OFF

7-3

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Ethernet Identification
ETH-channel
channel

identifies
the
specific
Ethernet
channel.
DECnet-l0 supports only a single channel (ETH-0).

Example:
NCP)SET CIRCUIT ETH-0 STATE ON
DDCMP Identification
For DECnet-10, DDCMP circuit and line identification takes one of
the following formats:
device-controller
device-controller-unit
device-controller.tributary
device-controller-unit.tributary
device

is the device name. (See Appendix F for a list of
mnemonic device names.)

controller

is the device's hardware controller.

unit

is the circuit or line number if the device is a
multiline controller.
For multipoint lines, the
unit number is optional and, if specified, is
always 0.

tributary

is the tributary node address (for circuits only) •

Example:
NCP)SET CIRCUIT DMC-0 STATE ON

7.3.2.2 Node and Area Identification - Either the node address or the
node name can serve as a node identifier (node-id). The node address
may include as a prefix the area number (area-id).
node-name
node-number
area-number.node-number
For example, if node 3 is in area 7, its node address is 7.3. If
do not specify an area the area number of the executor is used.

you

NCP)SHOW NODE AURORA SUMMARY
NCP)SHOW NODE 6.12 SUMMARY

7.3.2.3 Logging Identification - The LOGGING entity is followed by an
identification of the sink-type, rather than an identification of the
logging entity itself. However, sinktype must always follow LOGGING
in the command in the same manner that node-id follows NODE. Sinktype
identifies the place where a copy of the event is recorded.

7-4

NCP COMMANDS PROCESSED BY ,THE NETWORK MANAGEMENT LAYER
Sinktype must be one of the following:
a

CONSOLE

FILE

MONITOR (Not implemented for

DECnet-I~)

Example:
NCP>SHOW LOGGING'FILE EVENTS

7.3.2.4 Module Identification - The module
following modules:

entity

CONFIGURATOR (Not implemented for DECnet-10)

CONSOLE (Not implemented for DECnet-10)

LOADER (Not implemented for DECnet-10)

LOOPER (Not implemented for DECnet-10)

X25-ACCESS (see Chapter 8)

X25-PROTOCOL (see Chapter 8)

X25-SERVER (see Chapter 8)

consists

the

Example:
NCP>SHOW MODULE X25-ACCESS

7.3.3

The Node Entity

The node is the central entity of the network.
All network control
and monitoring is based on the concept of the node.
From the
standpoint of network management, nodes are either local or remote.
The local node is the node where you log in. The Netwo,rk Management
Layer, the Session Control Layer, the End Communication Layer, and the
Routing
Layer
of
DNA contain node functions and parameters.
Associated with nodes are several keywords that require you to choose
one of several other keywords to qualify or select specific parameters
for the first keyword.

7-5

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Keywords you can use with the node entity are:
TYPE

AREA-ROUTER

A node that can route packets
from
one
node to another
within its
own
area
and
between areas. Also known as
a level 2 router. A DECnet-l~
node cannot be an area router.

ROUTING-III

Full phase III routing node.

NONROUTING-III

phase III node wi thout routing
capability.

ROUTING-IV

Full phase IV routing node.

NONROUTING-IV

phase IV node wi thout
capability.

routing

STATE
For EXECUTOR node:
ON

Allows logical links.

OFF

Allows
no
new
links,
terminates existing links, and
stops routing (not implemented
for DECnet-I~).

SHUT

Allows no new links, does not
destroy existing links, and
goes to OFF when all logical
links
are
gone
(not
implemented for DECnet-10).

RESTRICTED

Allows no new incoming logical
links from remote nodes (not
implemented for DECnet-10).

For Remote nodes:

CPU

REACHABLE

A remote node is REACHABLE if
the
Routing module of the
executor node believes it has
a usable path to the remote
node.

UNREACHABLE

A remote node is UNREACHABLE
when the path length from the
executor to the remote node is
longer than the maximum hops
in the network.

PDP-8
PDP-II
DECSYSTEM-1020
VAX-ll

Identifies the adjacent target
node's CPU type for downline
loading.

SOFTWARE TYPE

SECONDARY-LOADER
TER'rIARY-LOADER
SYSTEM

Identifies initial target node
program
type
for downline
loading the adjacent node.

All other keyword responses are specific variables (one per
such as number, seconds, fileid and the like.
7-6

keyword),

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
7.3.4

The Circuit Entity

All circuits have the following choices for the keywords listed:
SERVICE

STATE

7.3.5

ENABLED

Indicates
that
the
SERVICE
functions
loading, dumping, and
1 ine
loopback
test ing ,
are
performed automatically.

DISABLED

Indicates that no functions will be
performed automatically.
In the
case of a DTE, indicates NML will
not detect when the DN20 goes down,
and thus will not attempt to reload
or dump the DN20.

CLEARED

The link cannot be used, but space
is reserved for it.
Link data
bases and
parameters
are
not
present.
(Not
implemented for
DECnet-10.)

OFF

The circuit cannot be used by any
network-related software.
It is
functionally
nonexistent.
Link
data
bases
and parameters are
present.

The circuit is available for normal
use
by
its
owner,
with the
exception of overrides for service.

SERVICE

Applies only to the volatile data
base (SET command). The circuit Is
available for service functions,
but is not available for use by the
owner (Routing). (Not implemented
for DECnet-10.)

The Line Entity

Lines provide physical point-to-point connections.
Functions and
parameters for the line entity come from the Network Management, Data
Link and Physical Link layers.
Lines have the following choices for the keywords listed:
CLOCK

INTERNAL

Clock is supplied by a device
instead of a modem. usually
used
for
external
cable
loopback.

EXTERNAL

For normal clock
(MCB onl y)
operating mode (clock signal
supplied
by
the
normally
modem) •

7-7

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
CONTROLLER

LOOPBACK

places the device to loo~back
internally, thus not requiring
a loopback connector to turn
data around.

NORMAL

(MCB only)
Can be used
modem or cable loopback.

for

NOTE
See Table 7-1 at the
end of this section
relationships
for
between
the
above
keywo rds
and
the
loopback mode of the
line.
DUPLEX

PROTOCOL

SERVICE

FULL

Full duplex mode of
device.

HALF

(MCB only) Half duplex mode of
the line device.

DDCMP POINT

(KS1~ only) This is
the line
protocol
for a point-to-point
ODCMP connection.

DOCMP CONTROL

This is the line protocol for
the control station (master)
end of a DOCMP
multipoint
group.
(Not implemented for
DECnet-1~. )

OOCMP TRIBUTARY

This is the line protocol for
the tributary (slave) end of a
ODCMP multipoint group.
(Not
implemented for DECnet-1~.)

ODCMP DMC

(MCB only) This line is in DMC
emulation mode.

LAPB

For X.25 lines.

ENABLED

Indicates that the
SERVICE
functions
loading, dumping,
and line loopback testing, are
performed automatically.

DISABLED

Indicates that no
functions
will
be
automatically
performed. In the case of a
indicates NML will not
OTE,
detect when the DN2~
goes
down,
and
thus
will not
attempt to reload or dump the
ON2~.

7-8

the

line

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
STATE

Table 7-1:

CLEARED

The line cannot be used, but
space
is reserved for it.
Line data bases and parameters
are not present.

OFF

The line cannot be used by any
network-related software. It
is functionally nonexistent.
Line data bases and parameters
are present.

The line is available
for
normal use by its owner, with
the exception of overrides for
service.

SERVICE

Applies only to the volatile
data base (SET command). The
line is available for service
functions but is not available
for use by the owner (the
executor
node
implying
Routing) •

Relationship of Clock and Controller Parameters to Mode of
Line

Mode of Line

Clock

Controller

Operation

Normal

External

Normal

Normal operation

Normal

Internal

Normal

Device supplies clock
to simulate synchronous
modem

Internal
loopback

Internal

Loopback

Device loops data
internally

External cable
loopback

Internal

Normal

Cable loopback with
loopback connector

External modem
loopback

External

Normal

Modem loops back data

7-9

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
7.3.6

The Logging Entity

The LOGGING entity is the network component that logs significant
events that occur during operation and/or maintenance of the network.
An event is defined as a network- or system-specific occurrence for
which the logging component maintains a record. A partial list of
significant events includes:
0

Circuit and node counter activity

Changes in circuit, line, and node states

Service requests (when a
automatic service state)

circuit

Passive loopback (when the
messages)

executor

back

test

Routing performance and error counters (circuit, line,
and data packet transmission)

node,

Data transmission performance and error counters (when errors
in data transmission occur)

Lost event reporting (when some
logged)

line
is

number

put

looping

events

are

not

Events are recorded continuously by the event logger and can provide
useful information for maintaining the network. In DECnet-1~~ you can
control the logging of events. In particular, you can control the
type of events to be logged, the source for these events, and the
location at which these events are logged. You can also control the
logging component at the local node and its operational state.
An example of an event is:
22:46:3~

-- Message from DECnet event logger --

DECNET Event type 4.15, Adjacency up
Event came from node 7.142 (AURORA), occurred 8-JAN-1985 22:46:28
Circuit DTE-~-l
Node = 7.143 (FEAURA)
automatically logs events to the system
error
file
SYS:ERROR.SYS.
All users have access to these recorded events by
running the SPEAR program.

DECnet-l~

The logging component is the device or process that records
events. You can select any of the following components.

logging

CONSOLE

A logging console, which is a OPR terminal
that
displays
event messages.
Set the
terminal to display event messages with the
OPR
command
ENABLE
OUTPUT-DISPLAY
NCP-MESSAGES.

FILE

A logging file, which records events in
binary format.
The logging file is always
the system error file SYS:ERROR.SYS.

MONITOR

A logging monitor, which is a program or file
supplied by the user that receives events.
(Not implemented by DECnet-19.)
7-1~

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
The sink name identifies the specific console, file, or monitor
program to which events are to be logged. At the local node, you can
control the operational state of the logging sink.
Use the SET
LOGGING STATE command to set the sink to one of the following states:
Events

destined

for

OFF

The sink is not available.
the sink are discarded.

The sink is available for receiving events.

HOLD

The sink is temporarily unavailable and events are
queued.

7.3.6.1 Event Identification - Events are defined by class and type.
You can specify the kinds of events to be logged by using the
following event-list format:
class.type
class

Identifies the DNA or system-specific
event pertains.

type

Identifies a particular form
event class.

layer

event,

which

the

unique

within

For example, to specify an event in the Routing layer, you would use
event class 4.
The event types for this class range from 9 to 14.
Event type 9 indicates aged packet loss, event type 1 indicates
unreachable node packet loss, and so forth.
Refer to the Appendix C
for a summary of events by class and type. Use the EVENTS parameter
for
the SET LOGGING command to specify those events to be logged.
If
you want to log all event classes and types, use the KNOWN EVENTS
parameter.
When defining the logging component, you must specify
events to be logged.
When providing an event list for the EVENTS parameter, you can specify
only one class for each instance of this parameter.
However, several
formats can define event types for a particular class.
You can
specify a single event type, a range of types, or a combination of the
two. The following table illustrates these formats.
Event-list

Meaning

4.4

Identifies event class 4, type 4

4.5-7

Identifies event class 4, types 5 through 7

4.5,7-9,11

Identifies event class 4, types 5, 7 through 9, and 11.
Note that types must be specified in ascending order.

The commands below ilustrate invalid event lists.
NCP>SET KNOWN LOGGING EVENTS 4.4,5.1
NCP>SET KNOWN LOGGING EVENTS 4.7,3-4,1
The first example specifies more than one event class.
The second
example specifies event types in numerically descending, rather than
ascend ing order.

7-11

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
You can use the asterisk (*) wildcard character in an event list.
This character can replace only an event type. The following example
illustrates the correct use of wildcards:
NCP>SET KNOWN LOGGING EVENTS 2.*
This command identifies all event types for class 2 events.
Two invalid uses of the wildcard character are shown below.
NCP>SET LOGGING FILE EVENTS *.2-5
NCP>SET LOGGING FILE EVENTS 4.2-*
The first command specifies specific event types for all classes.
Unless you use the KNOWN EVENTS parameter, you can only specify event
type information for a single class.
The second command uses a
wildcard to specify a partial range of event types. The wildcard
character denotes the entire range of event types for a given class.

7.3.6.2 Selecting Events for Logging - The operator or system manager
can control event logging by using the NCP command SET LOGGING EVENT
event-list. If you have a fairly small network, you may elect to log
all events.
However in a large network, it is advisable to log only
significant events. For instance, a level 1 router generates event
4.15 "adjacency up" each time an Ethernet node comes on-line. with a
large number of nodes on the Ethernet, numerous "adjacency up" events
can make it difficult to observe more significant events.
It is recommended that you enable the Data Link Layer events (class
5). These events typically indicate a problem with the Ethernet.
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 avenu&s 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.
o

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 Routing 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.
7-12

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
In order to log events, you must turn logg ing on.
(The DECnet-l~
default has all events enabled for the FILE sink.) To do so, use the
SET LOGGING command.
Use the same command to modify any of the
logging parameters. To remove any or all parameters from the volatile
database, use the CLEAR LOGGING command.
You must turn the logging
state to OFF before attempting to use the CLEAR LOGGING command.
Table 7-2 lists all logging parameters by function,
according to operational categories.
Table 7-2:

and

groups

them

Logging Parameters and Their Function

Parameter
Function

Source-Related
Parameters

Identifies events

EVENTS event-list
KNOWN EVENTS

Identifies source for
events

CIRCUIT circuit-id
LINE line-id
MODULE X25-ACCESS
MODULE X25-PROTOCOL
MODULE X25-SERVER
MODULE X29-SERVER
NODE node-id

Determines location for
logging events

SINK EXECUTOR
SINK NODE node-id

Sink-Related
Parameters

Assigns name to
logging component

NAME sink-name

Sets state of
logging component

STATE

HOLD
OFF
ON

Use the SET LOGGING EVENTS command to specify source-related events,
and
the SET LOGGING STATE command to specify sink-related events. To
display the status of the logging sinks and the events enabled for
logging, use the SHOW LOGGING command. The following command displays
the status of the CONSOLE sink:
NCP>SHOW LOGGING CONSOLE SUMMARY

(MCB)
Events - The DN20
(MCB)
and
KLl~
generate
events.
The DN2~, since it has no logging sinks, logs its
events with the KL10.
The KLl~-generated events selected for logging
are the same events that are accepted from the DN20.
The KLl~ filters
out all other DN20-generated events.
This filtering can produce
considerable overhead for the KL10.
For example, if the DN2~ is
connected to a VAX/VMS system, the VMS system may send routing
messages that are too large for the DN20 to process. This causes the
DN20 to generate "partial routing update loss"
(event 4.5)
events.
When this occurs frequently, it is recommended that you disable the
logging of class 4 events.
7.3.6. 3.

DN2~

DECnet-l~

7-13

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
DN20 events can also be controlled by disabling their generation at
the DN20.
For example, to disable the generation of class 4 events,
issue the following command to NETGEN, then rebuild the MCB:
NETGEN>PURGE LOGGING FILE EVENT 4.5
Since the DN20 does not have a clock, it cannot supply the time of an
event.
DN20 events do however, include the DN20's uptime. Add the
MCB uptime to the exact time that the DN20 was started to determine
the time of an event.

7.3.6.4 Logging Events at Remote Nodes - In addition to logging
events at the sinks on your node, events can be sent to remote DECnet
nodes. For instance, you might select a single node to collect all
the events that occur in the network. In the following example, all
network management events (class 0) are sent to the logging console on
node TEAL:
NCP>SET LOGGING CONSOLE EVENT 0.* SINK NODE TEAL::

7.3.7

The Maintenance Module Entity

The Link Management maintenance modules are responsible for handling
maintenance functions on circuits and lines.
These modules have
implied responsibility for handling maintenance for all DDCMP and X.25
data links, and they have specific responsibility for Ethernet
circuits assigned to them by the network manager.
The Link Maintenance modules provide entities that can own Ethernet
circuits for link service functions such as loop testing and down1ine
loading. The names of Link Maintenance modules are LOOPER, LOADER,
CONSOLE, and CONFIGURATOR.
The LOOPER, LOADER, and CONSOLE modules are the only link maintenance
modules that can be CIRCUIT owners. They each own one circuit on
every Ethernet line that is to have their related service functions.
The CONFIGURATOR module is a user of the services represented by the
console module. The configurator module can provide information from
a single console request for system identification or can listen
through the console and construct a list of systems on an Ethernet
line.

7.3.7.1 The CONFIGURATOR Module - The Ethernet CONFIGURATOR module is
not
supported
by DECnet-10.
The Ethernet CONFIGURATOR module
maintains a list of all nodes on the Ethernet.
Approximately once
every 10 minutes, each node on an Ethernet circuit that conforms to
the DNA specifications transmits a system identification message (a
hello message) to a multicast address that the configurator monitors.
The configurator module listens to these messages and builds a
user-accessible database of configuration information for all systems
on the Ethernet.
The configurator runs as a separate process, and, once it is
becomes available to all users on the system.

7-14

started,

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
The CONFIGURATOR module has the following states for
Ethernet circuits:

surveillance

SURVEILLANCE

7.3.7.2

ENABLED

The list of Ethernet nodes is kept.

DISABLED

The list of Ethernet nodes is not kept.

The CONSOLE Module - The CONSOLE module is not supported by
However, a similar function
is provided by the RMTCON

DECnet-l~.

program.
The CONSOLE module is a logical console terminal
(CTY)
that is
connected to a terminal server such as the DECserver l~~ Terminal
Server. This allows control of the terminal server from a remote
node.
When the console receives a message, it becomes reserved for
the exclusive use of the system that sent the message.
After a
predefined number of seconds, if the console has not received another
message for the node that reserved it, the console becomes available
for reservation by another node. The RESERVATION TIMER parameter sets
the number of seconds that the console will stay reserved without
hearing from the remote node before being available.

7.3.7.3 The LOADER and LOOPER Modules - The LOADER and LOOPER Modules
are not supported by DECnet-l~; however, DECnet-l~ NCP commands can be
sent to other operating systems which support these modules.
A node can request a down-line load or loopback assistance by sending
a multicast address. Of the nodes that respond to the address, one of
the responding nodes is selected according to criteria defined by the
operating system.
For example the node might choose the first node to
respond to the request. The LOOPER and LOADER modules'
ASSISTANCE
parameter
indicates whether or not the node will respond to a request
for a down-line load or loopback assistance.
The LOADER and LOOPER modules
ASSITANCE keyword:

have

the

following

choices

for

the

ASSISTANCE
ENABLED

The node will respond to a dump/load
assistance multicast address.

DISABLED

The node will not respond to a dump/load
loopback assistance multicast address.

does not support the setting of this parameter.
LOOPER ASSISTANCE is always ENABLED on DECnet-l~ nodes.

DECnet-l~

7.3.8

loopback

LOADER

or
and

The Area Entity

An area is a group of nodes. The system manager can group nodes for
hierarchical routing purposes.
The user can identify areas in two
major ways:
individually and
in groups.
To
identify an area
individually,
use the area number.
An area number is a decimal
integer in the range 1-63. Area 1 is usually used to designate a
single area network and Area ~
is used when communicating with a
DECnet phase III node.
7-15

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Area group identifications are as follows:

7.4

ACTIVE AREAS

All areas that the executor perceives routing
reach.

KNOWN AREAS

Same as ACTIVE AREAS.

can

GENERIC FORMAT OF NML/NCP COMMANDS

The generic format of NML/NCP commands is:
COMMAND ENTITY [KEYWORD) [argument] ••• [KEYWORD] [argument]
Although most commands will have a command entry, an entity entry, and
at least one keyword/argument combination, the command itself is the
only element that is always present. The [KEYWORD] [argument]
fields
can also take the form [KEYWORD] [KEYWORD], as in TYPE' ROUTING or
STATE OFF. In this form, the second KEYWORD acts as an argument for
the first keyword.
Under certain conditions, entity is understood.
The keyword ALL acts as a pluralistic parameter: used with SET/DEFINE
or CLEAR/PURGE, ALL indicates all information on the named entity.
Three pairs of commands - SET and DEFINE, CLEAR and PURGE, and SHOW
and LIST affect the same entities and accept the same arguments.
Thus, except for the command itself, you type the same information in
the same format. For example:
NCP)SET LINE KDP-0-0 CLOCK INTERNAL
NCP)DEFINE LINE KDP-0-0 CLOCK INTERNAL
The first command changes line parameters in the volatile data base;
the second changes parameters in the permanent data base (not
implemented for DECnet-10).
SET, CLEAR and SHOW refer to parameters in the volatile data base;
DEFINE, PURGE, and LIST refer to parameters in the permanent data
base. These three pairs are considered together in the detailed
descriptions that follow.
All other commands are described in
separate charts. Remember that neither TOPS-10 nor Mca supports a
permanent data base. Therefore, for DECnet-10 you can use only SET,
CLEAR, and SHOW. All commands are given because other operating
systems may implement a permanent data base.

7.5

CHANGING NETWORK DATA BASES:

SET AND DEFINE COMMANDS

In DECnet-10 V4.0, you can establish certain initial parameter values
during network generation. Command files are created that consist of
NCP SET commands that use these initial values as arguments.
These
commands are executed at system startup and the parameter values they
set become the initial volatile data base.
The operator or system
manager cannot change or set all parameter values.

7-16

NCP COMMANDS PROCESSED BY THE NETWORK MANAG~MENT LAYER
Values displayed in response to the various SHOW commands are the
values in the original data base (unless you have changed them). They
have been chosen to ensure a viable network. They may not be optimal
for your installation because of the many factors upon which network
performance depends. However, no value should be changed without good
reason and some planning.
It is suggested that the system manager
check performance with the SPEAR reports both before and after changes
have been made.
Whether you have improved or degraded the network
performance is best judged by actual results.
To change a value in the volatile data base, you use the appropriate
NCP SET command.
Values established with the SET command are in
effect for all commands following the SET command unless changed with
another SET command. Volatile data base values are lost when the node
is reloaded.
Access privileges are required to send a SET command to a DECnet-10
node from a remote node using the TELL prefix. The following access
information must be added to the command string:
USER ppn (with or without brackets) or user-name
PASSWORD password (password used at LOGIN)
NOTE·
NCP commands that are processed by the local Network
Management
function are described in Chapter 6.
Commands processed by the OPR program are described in
Chapter 5.

SET/DEFINE Entity ALL

7.5.1

Command
SET
}
{DEFINE

Entity

Keyword/Argument

}
CIRCUIT cktid
LINE lineid
LOGGING sink-type
{ MODULE module-type
NODE nodeid

ALL

Function:
When used with the keyword ALL, the SET command reads all known
permanent parameters for the named entity into the volatile data
base. Conversely, the DEFINE command reads all known volatile
parameters into the permanent data base of the identified entity
(not implemented by DECnet-10) •
Arguments:
You can use the keyword ALL with the commands SET/DEFINE and
CLEAR/PURGE to indicate all information on the entity identified
in the command. Refer to the singular form of each entity for a
complete list of all possible keywords and parameters.

7-17

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Remarks:
DEFINE and SET commands with the keyword ALL cannot be executed
by DECnet-lm executor nodes because of the lack of a modifiable
permanent data base.
Before attempting to send this command to a non-DECnet-lm node,
consult the documentation of that node's operating system. This
command depends upon the specific implementation.

7.5.2

SET/DEFINE CIRCUIT

Command

Entity

SET
}
{DEFINE

CIRCUIT cktid

Keyword/Argument
ACTIVE BASE base
ACTIVE INCREMENT increment
BABBLE TIME milliseconds
COST cost
COUNTER TIMER seconds
DEAD THRESHOLD count
DYING BASE base
DYING INCREMENT increment
DYING THRESHOLD count
INACTIVE INCREMENT incrmt
INACTIVE THRESHOLD count
LINE lineid
MAXIMUM BUFFER count
MAXIMUM TRANSMITS count
MAXIMUM ROUTERS number
OWNER ownerid
POLLING STATE polstate
ROUTER PRIORITY number
SERVICE srvcntl
STATE cktstate
TRANSMIT TIMER millisecs
TRIBUTARY tribaddr

Function:
These commands set volatile and permanent circuit parameters
the circuit(s} identified in the command.

for

Arguments:
Arguments for all circuits:
COUNTER TIMER seconds
Seconds is a decimal integer in the range 1-65535.
Counter
timer is a Network Management Timer.
When the seconds
indicated have elapsed, the circuit counters are recorded as
data in a logging event, and then zeroed. The logging
begins again, and the cycle continues as long as the node
remains up, or until the counter is cleared. The counter
timer value must be set for circuit counters to
be
automatically logged.

7-18

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
OWNER ownerid
Ownerid
consists
of
an
entity
type
and
entity
identification.
The only ownerid currently defined is the
executor node.
(This implies that the circuit is actually
reserved
for
Routing,
the
DECnet
routing module.)
Establishing an ownerid merely reserves the circuit.
There
is no
implication as to whether the circuit is open.
Network Management can always override the owner's exclusive
rights to the circuit.
STATE cktstate
Cktstate can be CLEARED, OFF, ON, or SERVICE.
7.3.4 for state definitions.)

(See

Section

Arguments for DDCMP circuits only:
LINE lineid
Lineid is the Data Link layer identification of the line
be used by the circuit.
(See Section 7.3.2 for format.)

SERVICE srvcnt1
Srvcnt1 can be ENABLED or DISABLED, indicating respectively
that
Network
Management
allows or disallows service
operations on a circuit.
(See Sections 7.3.4 for more
detail.)
Ar~uments

for all circuits owned by EXECUTOR:

COST cost
Cost is a decimal number in the range 1 to 25.
The COST
parameter is used in the routing algorithm to determine the
most cost-effective routing path.
(See Section 2.3 for more
information on routing concepts.)
HELLO TIMER seconds
Seconds is a decimal number in the range 1-65535.
This
value determines the frequency of Routing Hello messages
sent to the adjacent node on the circuit.
LISTEN TIMER seconds
Seconds is a decimal number in the range 1-65535.
This
value determines the seconds that can elapse before Routing
receives either a Hello message or a user message from the
adjacent node on the circuit.
Arguments for Ethernet circuits:
MAXIMUM ROUTERS number
This parameter applies to Ethernet circuits.
It specifies
the maximum number of routers (other than the executor node)
allowed by the Routing layer for the specified circuit.
Number is a decimal integer in the range 1-64. The default
is 16.

7-19

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
ROUTER PRIORITY number
This parameter applies to Ethernet circuits.
It specifies
the priority the specified router (the executor node on the
circuit) is to have in the selection of a designated router
for the circuit. Number is a decimal integer in the range
0-127. The default is 5.
NOTE
The DNA Routing Layer Specification contains detailed
information on the effect of changing parameter values
of timers used by Routing.
(See Appendix E for a
complete list of DNA Specifications.)
The following arguments are not implemented for circuits in DECnet-l0
V4.0.
Check the documentation for the operating system of the
executor to direct commands containing these arguments to a remote
node.
ACTIVE BASE base
This parameter applies to DDCMP CONTROL circuits only.
The
value of base represents the base priority to which a
tributary is reset after each time it has been polled. This
is the base priority for a tributary in the ACTIVE state.
Base is a value in the range 0 to 255.
If not set, the
default is 255.
ACTIVE INCREMENT incrmt
This parameter applies to DDCMP CONTROL circuits only.
The
value of incrmt represents the increment added to the
tributary priority each time the scheduling timer expires.
This increment applies to a tributary in the ACTIVE state.
Incrmt is a value in the range 0 to 255. If not set, the
default is 0.
BABBLE TIMER millisecs
This parameter applies to DDCMP CONTROL circuits only.
The
value of mil1isecs represents the number of milliseconds
that a selected tributary or remote half-duplex station can
transmit. Millisecs is a value in the range 1 to 65535. If
not set, the default is 6000 (6 seconds).
DEAD THRESHOLD count
This parameter applies to DDCMP CONTROL circuits only.
The
value of count represents the number of times to poll the
ACTIVE, INACTIVE, or DYING tributary before changing its
polling state to DEAD because of receive timeouts. Count is
a value in the range 0 to 255. If not set, the default is
8.

DYING BASE base
This parameter applies to DDCMP CONTROL circuits only.
The
value of base represents the base priority to which a
tributary is reset after each time it has been polled. This
is the base priority for a tributary in the DYING state.
Base is a value in the range 0 to 255.
If not set, the
default is 0.

7-20

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
DYING INCREMENT incrmt
This parameter applies to DDCMP CONTROL circuits only.
The
value of incrmt represents the increment added to the
tributary priority each time the scheduling timer expires.
This increment applies to a tributary in the DYING state.
Incrmt is a value in the range 0 to 255. If not set, the
default is 16.
DYING THRESHOLD count
This parameter applies to DDCMP CONTROL circuits only.
The
value of count represents the number of times to poll the
ACTIVE, INACTIVE, or DYING tributary before changing its
polling state to DYING because of receive timeouts. Count
is a value in the range 0 to 255. If not set, the default
is 2.
INACTIVE BASE base
This parameter applies to DDCMP CONTROL circuits only.
The
value of base represents the base priority to which a
tributary is reset after each time it has been polled. This
is the base priority for a tributary in the INACTIVE state.
Base is a value in the range ~ to 255.
If not set, the
default is ~.
INACTIVE INCREMENT incrmt
This parameter applies to DOCMP CONTROL circuits only.
The
value of incrmt represents the increment added to the
tributary priority each time the scheduling timer expires.
This increment applies to a tributary in the INACTIVE state.
Incrmt is a value in the range ~ to 255. If not set, the
default is 64.
INACTIVE THRESHOLD count
This parameter applies to DDCMP CONTROL circuits only.
The
value of count represents the number of times to poll the
ACTIVE tributary before changing its polling state to
inactive because of no data response. Count is a value in
the range ~ to 255. If not set, the default is 8.
MAXIMUM BUFFERS count
This parameter applies to DDCMP CONTROL circuits only.
The
value of count represents the maximum number of buffers the
tributary can use from a common buffer pool.
If not set,
there is no common buffer pool and buffers are explicitly
supplied by the higher level. The value of count is either
a value in the range 1 to 255 or the keyword UNLIMITED.
MAXIMUM TRANSMITS count
This parameter applies to DDCMP CONTROL circuits only.
The
value of count represents the maximum number of data
messages that can be transmitted at one time.
Count is a
value in the range 1 to 255. If not set, the default is 4.

7-21

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
POLLING STATE polstate
This parameter applies to DOCMP CONTROL circuits only.
The
value of polstate represents the state of the tributary
relative to the multipoint polling algorithm.
If not set,
the default is AUTOMATIC. The possible states are:
AUTOMATIC - state is allowed to vary according
operation of the polling algorithm.

the

ACTIVE/INACTIVE/OYING/OEAO - the tributary is locked in
the specified state.
TRANSMIT TIMER millisecs
This parameter applies to OOCMP CONTROL circuits only.
The
value of millisecs represents the number of milliseconds to
delay between data message transmits. Millisecs is a value
in the range 9 to 65535.
TRIBUTARY tribaddr
This parameter applies to multipoint DDCMP circuits only.
Tribaddr represents the Data Link physical tributary address
of the circuit. Tribaddr is a value in the range 9 to 255.
Examples:
1.

Set the circuit STATE to ON for the circuit DTE-9-1.
NCP)SET CIRCUIT DTE-9-1 STATE ON

Set the maximum number of routers permitted on
circuit ETH-0 to 5.

the

Ethernet

NCP)SET CIRCUIT ETH-0 MAXIMUM ROUTERS 5

Command

Entity

Keyword/Argument

}
SET
{ DEFINE

KNOWN CIRCUITS

ALL
}
{ COUNTER TIMER seconds
SERVICE srvcntl

Function:
SET KNOWN CIRCUITS ALL loads all permanent circuit parameter
values
into
the volatile data base.
(Not supported for
DECnet-10.) Other SET KNOWN CIRCUIT commands set the specified
values in the volatile data base of each circuit known to the
executor. DEFINE KNOWN CIRCUITS ALL has no meaning.
Other
DEFINE KNOWN CIRCUIT commands set the specified parameter values
in the permanent data bases of all circuits known to the
executor.
Arguments:
Same as for CIRCUIT cktid (singular).

7-22

See remarks below.

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Example:
1.

Disable service operations (loading and loop testing) for all
circuits.
NCP>SET KNOWN CIRCUITS SERVICE DISABLED

Remarks:
Although you can use all arguments allowed for SET CIRCUIT
(described in this section) in the SET KNOWN CIRCUITS commands,
many of the arguments are inappropriate for plural entities. The
arguments listed are those most likely to be meaningful. The NML
program processes all arguments listed under SET CIRCUIT for the
plural CIRCUITS.
However, you should consider the probable
results carefully before using arguments not listed.

7.5.3

SET/DEFINE LINE

Command

Entity

}
SET
{ DEFINE

LINE lineid

Keyword/Argument
CLOCK clock-mode
CONTROLLER controller-mode
COUNTER TIMER seconds
DEVICE device-id
DUPLEX duplex-mode
PROTOCOL protocol-name
RETRANSMIT TIMER milliseconds
SERVICE service-control
SERVICE TIMER milliseconds
STATE line-state
For DDCMP lines:
DEAD TIMER milliseconds
DELAY TIMER milliseconds
RECEIVE BUFFERS number
SCHEDULING TIMER milliseconds
STREAM TIMER milliseconds

Function:
These commands set volatile and permanent line parameters for the
line(s) identified in the command. SET sets volatile parameters,
and DEFINE sets permanent parameters for nodes that support a
permanent data base.
Arguments:
COUNTER TIMER seconds
Seconds is a decimal integer in the range 1-65535.
Counter
timer is a Network Management Timer.
When the seconds
indicated have elapsed, the line counters are recorded as
data
in a logging event, and then zeroed.
If no counter
timer value is set,
the
line's
counters
are
not
automatically logged.

7-23

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
DEVICE deviceid
The deviceid specifies the local hardware to be used.
It
consists of a device identification (dev) and a controller
number (c) if the device supports a single line.
For a
multiple line controller, the deviceid consists of a device
identification, a controller number, and a unit number (u).
For example:
dev-c-u
DEVICE DMR-l
DEVICE KDP-"'-2
PROTOCOL name
For DECnet-l"', this parameter is implemented for the MCB
node only and for KDP lines only. The protocol name can be
DDCMP DMC for DECnet-l'" lines and LAPB for X.25 lines.
Other DIGITAL operating systems may permit the values DOCMP
CONTROL, DDCMP TRIBUTARY, and LAPB.
See the appropriate
documentation. See Section 7.3.5 for definitions if needed.
RETRANSMIT TIMER milliseconds
Milliseconds is a decimal integer in the range 1-65535. The
RETRANSMIT TIMER is a Data Link timer. When the number of
milliseconds
specified
have
elapsed,
a
block
is
retransmitted.
This timer is used for normal operation of
the line.
SERVICE TIMER milliseconds
Milliseconds is a decimal integer in the range 1-65535. The
SERVICE TIMER is a Data Link timer that is used during
service operations.
Milliseconds represents the maximum
amount of time allowed to elapse before a receive request is
completed.
Arguments for DDCMP lines.

Not implemented for DECnet-l"':

DEAD TIMER milliseconds
This value represents the number of milliseconds between
polls for one of the set of dead tributaries. Milliseconds
is a decimal integer in the range 1-65535. If not set, the
default is 1"'''''''. (1'" seconds).
DELAY TIMER milliseconds
This value represents the mimimum number of milliseconds to
delay between polls. The delay timer limits the effect of a
very fast control station on slow tributaries. Milliseconds
is a decimal integer in the range 1-65535. If not set,
there is no delay.

7-24

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
RECEIVE BUFFERS number
Allocates buffers for data reception by the device driver
for a particular DDCMP line. The number of buffers you set
depends on throughput requirements and available memory
pool.
A value in the range of 2 to 4 is adequate for line
speeds of less than 56K bits.
For asynchronous lines, a
value of at least 4 is recommended. Megabit line speeds may
require eight or more buffers, depending on the observed
errors.
SCHEDULING TIMER milliseconds
This value represents the number of milliseconds between
recalculation of tributary polling priorities.
Milliseconds
is a decimal integer in the range 50-65535.
If not set, the
default is 200.
STREAM TIMER milliseconds
This value represents the number of milliseconds a tributary
or half duplex remote station is allowed to hold the line.
Milliseconds is a decimal integer in the range 0-65535.
If
not set, the default is 6000 (6 seconds).
CLOCK, CONTROLLER,
7.3.5.

DUPLEX,

SERVICE,

and

STATE:

See

Section

Examples:
1.

Tell a DECnet-VAX node to set line DMC-0 to the ON
full duplex mode.

state

NCP>TELL TOSCA USER ANDERSON PASSWORD NEWBURY SET LINE DMC-0 DUPLEX FULL STATE ON
2.

Tell a DECnet-VAX node to set
POINT for line DMC-0.

the

lirie

protocol

DDCMP

NCP>TELL ALFIE SET LINE DMC-0 PROTOCOL DDCMP POINT

7.5.4

SET/DEFINE MODULE

Command

Entity

Keyword/Argument

SET
}
{ DEFINE

MODULE CONFIGURATOR

[CIRCUIT ckt-id]
[KNOWN CIRCUITS]

{:~~VEILLANCE contrOl}

Function:
This command is not implemerited for DECnet-10.
Creates or modifies parameters of the
The configurator module constructs
specified Ethernet circuits.

7-25

Ethernet configurator module.
a list of systems active on the

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Arguments:
KNOWN CIRCUITS
Applies only to
Ethernet
circuits.
configurator information on all known
stored in the volatile database.

Specifies
that
circuits is to be

CIRCUIT circuit-id
Applies only to
Ethernet
circuits.
Specifies
that
configurator information on the specified circuit is to be
stored in the volatile database.
ALL
Copies all known permanent parameters for
into the volatile data base.

the

configurator

SURVEILLANCE control
This value indicates whether or not a list of active systems
is to be kept for the circuit. The control values are the
following:
ENABLED
DISABLED

The list is kept
The list is not kept

The default value is DISABLED.
Example:
1.

Tell node AURORA to keep a list of all active systems on
known Ethernet circuits.

all

NCP)TELL AURORA SET MODULE CONFIGURATOR KNOWN CIRCUITS SURVEILLANCE ENABLED
Remarks:
Once the configurator ceases surveillance of all
Ethernet
circuits it has been monitoring, for example, if you give the
command SET MODULE CONFIGURATOR SURVEILLANCE DISABLED KNOWN
CIRCUITS, the list of system information is deleted.
Command

Entity

SET
}
{DEFINE

MODULE CONSOLE

Keyword/Argument
RESERVATION TIMER seconds

This command is not implemented for DECnet-10.
The SET MODULE CONSOLE RESERVATION TIMER sets the number of seconds
that the console will stay reserved without hearing from the system
that reserved it. Seconds is a decimal integer in the range 1-65535.
Example:
Set node AURORA's console reservation timer to 10 seconds:
NCP)TELL NODE AURORA SET MODULE CONSOLE RESERVATION TIMER 18

7-26

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Command

Entity

Keyword/Argument

SET
}
{ DEFINE

MODULE LOADER}
{ MODULE LOOPER

ASSISTANCE control}
{ ALL

Function:
These commands are not implemented for DECnet-Im.
The MODULE LOADER
down-line load.
loopback testing.

command is
The MODULE

for Ethernet up-line dump and
LOOPER command is for Ethernet

Arguments:
ASSISTANCE state
This value indicates whether or not the node responds to the
dump/load assistance multicast address. The state is one of
the following:
ENABLED
DISABLED
The state of a

The node will respond
The node will not respond
DECnet-l~

node is always ENABLED.

ALL
Copies configurator module information from the permanent
data base into the volatile data base at the local node.
Example:
Tell node TEAL to enable loader assistance.
NCP)TELL TEAL SET MODULE LOADER ASSISTANCE ENABLED

7.5.5

SET/DEFINE NODE

Command

Entity

}
SET
{DEFINE

NODE nodename

Keyword/Argument
CIRCUIT cktld

Function:
This command sets the volatile or permanent address and circuit
for
the specified nodename. The CIRCUIT cktid parameter applies
to loop nodes and nodes by name only.
Arguments:
CIRCUIT cktid
Cktid is the identification of the circuit to be used for traffic
to the named node, which is a
loop node.
For example, the
command:
NCP)SET NODE FOOBAR CIRCUIT

DTE-~-3

will create the loop node FOOBAR, so it can be used in LOOP
commands.

7-27

NODE

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Command

Entity

Keyword/Argument

NODE nodeaddr

SET
DEFINE)
{

NAME nodename

Function:
This command sets the volatile or permanent parameter for the
nodename
to be associated with the specified address.
A
nodename/nodeaddr association is unique.
Argument:
Nodename consists of one to six alphanumeric characters with at
least one alpha character. A node name is associated with one,
and only one, node address.
Examples:
NCP>SHOW EXECUTOR<RET>
NCP>
9:35:43
NCP
Request # 279; Show Executor Node Summary Completed
Executor Node = 7.11~ (KL1~26)
State = On
Identification = RC177B KL #1026/1~42
NCP>SET NO
NCP>

7.11~

NAME ANYNAM<RET>

9:43:~~
NCP
Request , 28~; Set Node Failed, Component in wrong state
NCP>SET NO 7.129 NAME ANYNAM<RET>
9:43:1~
NCP
Request # 281; Set Node Completed
NCP>SHOW NODE 7.129<RET>
NCP>
9:43:14
NCP
Request , 282; Show Node Summary Completed
Remote Node = 7.129 (ANYNAM)

No information
Remarks:
does not support the SET NODE NAME command for the
executor.
(The failure of Request :I 28~ in the example
illustrates this.)

DECnet-l~

Node names are of local significance only. If used in a command
addressed to the network, the node address is substituted (using
a table lookup) for the name. This mapping is transparent to the
user.
Thus, although the network recognizes nodes by address
only, the operator has the convenience of using either nodename
or nodeaddress
(except for the few commands where one or the
other is specifically noted) •

7-28

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Command
SET
}
{DEFINE

Entity
NODE nOdeid}
{ EXECUTOR

Keyword/Argument
ADDRESS node-address
AREA MAXIMUM COST number
AREA MAXIMUM HOPS number
BROADCAST ROUTING TIMER seconds
BUFFER SIZE bytes
CONSOLE LOAD FILE file-id
CONSOLE SECONDARY LOADER file-id
COUNTER TIMER seconds
CPU cputyp
DELAY FACTOR number
DELAY WEIGHT number
DIAGNOSTIC FILE file-id
DUMP ADDRESS number
DUMP COUNT number
DUMP FILE fileid
HARDWARE ADDRESS eth-address
HOST nodeid
IDENTIFICATION idstring
INACTIVITY TIMER seconds
INCOMING TIMER seconds
LOAD FILE fileid
MAXIMUM ADDRESS number
MAXIMUM AREA number
MAXIMUM BROADCAST NONROUTERS number
MAXIMUM BROADCAST ROUTERS number
MAXIMUM BUFFERS number
MAXIMUM COST number
MAXIMUM HOPS number
MAXIMUM CIRCUITS number
MAXIMUM LINKS number
MAXIMUM VISITS number
OUTGOING TIMER seconds
RETRANSMIT FACTOR number
ROUTING TIMER seconds
SECONDARY DUMPER file-id
SECONDARY LOADER file-id
SEGMENT BUFFER SIZE bytes
SERVICE DEVICE devtype
SERVICE CIRCUIT cktid
SERIVCE NODE VERSION node-version
SERVICE PASSWORD password
SOFTWARE IDENTIFICATION fileid
SOFTWARE TYPE sftyp
STATE state
SUBADDRESSES subaddress-range
TERTIARY LOADER fileid
TYPE nodtyp

Function:
This command sets the volatile or permanent parameters
node identified as nodeid or set as executor.

7-29

for

the

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Arguments:
ADDRESS node-address
Specifies the address of the node to which you want the
database entry to refer. The format of the node address is:
area-number.node-number
where the area-number is in the range 1-63 and
the
node-number is in the range 1-255 for DN20 nodes and 1-1023
for Ethernet nodes.
AREA MAXIMUM COST number
This parameter applies only if the executor node is of
AREA.

type

Sets the maximum total path cost allowed from the executor
to any other level 2 routing node. The value is the maximum
cost of circuits on the longest path between level 2
routers. Number is a decimal in the range 1-1022.
AREA MAXIMUM HOPS number
This parameter applies only if the executor node is of
AREA.

type

Sets the maximum number of routing hops allowable from the
executor to any other level 2 routing node. Number is a
decimal in the range 1-30.
The AREA MAXIMUM COST and AREA MAXIMUM HOPS parameters are
used to determine whether an area is reachable. In effect,
AREA MAXIMUM HOPS and AREA MAXIMUM COST control the total
possible path between areas in the network.
BROADCAST ROUTING TIMER seconds
This parameter applies to the executor node only.
Specifies the maximum amount of time allowed between routing
updates on Ethernet circuits. When the timer expires before
a routing update occurs, a routing update is forced.
The
routing update produces a routing configuration message for
each adjacent node. Routing uses this timer to enforce a
maximum delay between routing updates. You can specify a
number in the range 1 to 65515. The default value is 40.
BUFFER SIZE bytes
This parameter applies to the executor node only.
This
means that entity must be executor or nodeid must refer to
the executor. If the executor has not been specified,
executor defaults to the node where NCP is running.
Sets the actual size of all circuit buffers, including
protocol overhead.
Size is a decimal number in the range
1-65535.

7-30

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
For DECnet-10 nodes, the permitted range is 290-576 for DN20
circuits and 290-1467 for Ethernet circuits. The default is
576 bytes. This value must be 576 to support all DIGITAL
operating systems.
For a KL10 with a DN29 MCB, the buffer
size must be equal or greater than 2 * MAXIMUM ADDRESS + 5.
The buffersize for all nodes in the network must be the
same.
This value cannot be set for DECnet-19.
It must be
configured at installation (refer to the TOPS-19 DECnet and
PSI Installation Guide).
CONSOLE LOAD FILE file-id
This parameter applies to Ethernet communications servers.
Identifies the file containing the software
loading
remote
console
software
into
communications server.

for
an

downline
Ethernet

CONSOLE SECONDARY LOADER file-id
This parameter applies to Ethernet communications servers.
Identifies the file containing the secondary boot loader for
downline loading remote console sofware into an Ethernet
communications server.
COUNTER TIMER seconds
This parameter applies to all nodes except loop nodes.
Seconds is a decimal integer in the range 1-65535.
Counter
timer is a Network Management Timer.
When the seconds
indicated have elapsed, the node counters are recorded as
data in a logging event, and then zeroed. The logging
begins again, and the log-record-zero cycle continues as
long as the remote node communicates with the local node, or
until the counter is cleared. The counter timer value must
be set for the circuit counters to be auto~atically logged.
CPU cputyp
This parameter applies to adjacent nodes only.
the node's CPU type as one of the following:

Identifies

DECSYSTEM-1929
PDP-8
PDP-II
VAX-II
TOPS-19 supports loading of DN29 and
Ethernet
nodes
(executor must be the KL19 node).
Refer to the appropriate
manuals to determine CPU types that can be downline loaded
by non-DECnet-10 nodes that are acting as executors in your
network.

7-31

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
DELAY FACTOR number
This parameter applies to the executor node only.
Sets the number used as a multiplier in an NSP algorithm
that determines when to retransmit a message. The delay
factor is multiplied by 1/16 of the round trip delay to set
the retransmission timer to that node. The default value
for DECnet-10 is 48. Number is a decimal number in the
range 1-255. The larger the value of number, the longer the
delay before retransmission.
DELAY WEIGHT number
This parameter applies to the executor node only.
This parameter is used as a weighting factor when updating
the estimated round trip delay to a node. Number is a
decimal in the range 1-255.
This value is initialized
during network generation but can be modified by Network
Management. The default for DECnet-10 is 10.
DIAGNOSTIC FILE file-id
This parameter
circuits.

applies

adjacent

nodes

Ethernet

Identifies the file to read from when the adjacent node is
down-line
loaded, and has requested diagnostics.
The
file-id is the name of the diagnostics file in the volatile
data base that the target node can read.
DUMP ADDRESS number
This parameter applies to adjacent nodes only.
Sets the memory address where the upline dump of an adjacent
node is to begin. This parameter value is not supported for
DECnet-10 nodes because a full dump is always taken.
DUMP COUNT number
Sets the default number of memory units to upline dump from
the adjacent node specified. This parameter value is not
supported for DECnet-10 nodes because a full dump is always
taken.
DUMP FILE fileid
This parameter applies to adjacent nodes only.
Identifies the file to receive the upline dump.
HARDWARE ADDRESS eth-address
Identifies the Ethernet address originally assigned to the
Ethernet
controller for the system.
This address is
necessary for communication with the system (for such
purposes as down-line loading). Eth-address is a string of
12 hexadecimal digits, represented by 6 bytes separated by
hyphens.

7-32

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
HOST nodeid
This parameter applies to an executor node
node.

adjacent

For the executor, identifies the node from which the
executor requests services. For an adjacent node, it is the
node providing service.
If no host is specified, the
default is the executor node.
IDENTIFICATION idstring
This parameter applies to the executor node only.
Sets the text identification string for the executor, for
example, "Development System" or "Research Lab." Idstring is
an arbitrary string of 1-32 characters.
An
idstring
containing blanks or tabs must be enclosed in quotation
marks; two adjacent quotation marks indicate a quotation
mark within a quoted string. The default for DECnet-1~ is
the system name set during the installation procedure.
INACTIVITY TIMER seconds
This parameter applies to the executor node only.
The value in seconds determines the maximum time allowed to
elapse with no activity in a logical link. When the number
of seconds specified have elapsed, NSP tests the link with
artificial traffic. The default for DECnet-1~ is 12~.
INCOMING TIMER seconds
This parameter applies to the executor node only.
Sets a timeout value for incoming connects. If the connect
is not accepted or rejected by the user within the number of
seconds specified, Session Control rejects it for the user.
Seconds is a decimal number in the range 1-65535. The
default for DECnet-l~ is 3~.
LOAD FILE fi1e-id
This parameter applies to an adjacent node only.
Sets the file identification of the file to read when the
node is downline loaded. Fi1e-id is in the format required
by the executor's file system.
MAXIMUM ADDRESS number
This parameter applies to the executor node only.
Sets the largest node address and, thus determines the
greatest number of nodes that can be addressed by the local
node. Number is a decimal value in the range 1-1~23 for
Ethernet communications, and 1-255 for DN2~ communications.
The default is 1023.
Lowering this value will decrease
system memory usage, therefore use the smallest number
possible.
This value cannot be set for DECnet-1~.
It must be
configured at installation (refer to the TOPS-1~ DECnet and
PSI Installation Guide).
7-33

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
MAXIMUM AREA number
This parameter is not implemented for DECnet-l~,
applies only if the executor node is of type AREA.

and

Sets the largest area number, and thus is the number of
areas that can be known about by the executor node's Routing
layer. Number is an integer in the range 1-63.
If this
parameter
is
not
specified, the Routing layer will
recongnize up to 63 areas.
MAXIMUM BROADCAST NONROUTERS number
This parameter is the maximum number of nonrouting nodes
(end nodes)
that the executor node can recognize on its
Ethernet circuits.
Number is an integer in the range
~-65535.
The default for DECnet-l~ is 64.
MAXIMUM BROADCAST ROUTERS number
This parameter is the maximum number of routers the executor
node can recognize on its Ethernet circuits. Each routing
node can be either a level 1 router (capable of routing
within its own area, if area routing is specified) or a
level 2 router (capable of routing within its own area and
outside of its area).
Number is an integer in the range
~-65535.
The default for DECnet-l~ is 32.
MAXIMUM BUFFERS number
This parameter applies to the executor node only.
Sets the total number of buffers allocated to all circuits.
Routing uses this number to determine the size df its buffer
pool.
This parameter applies to the DN2~ MCB node only and cannot
be set by the operator or system manager. It is generated
with NETGEN and can be changed only by repeating the NETGEN
procedure (see the TOPS-l~ DECnet and PSI Installation
Guide). You can display MAXIMUM BUFFERS when you type the
NCP command SHOW EXECUTOR CHARACTERISTICS when the executor
is the MCB front end.
MAXIMUM CIRCUITS number
This parameter applies to the executor node only.
Sets the maximum number of circuits that this node can
support in the network. Number is a decimal number in the
range l-2~. The default is 16.
This parameter applies to the DN2~ MCB node only and cannot
be set by the operator or system manager. MAXIMUM CIRCUITS
is
displayed
in
response
to
the
SHOW
EXECUTOR
CHARACTERISTICS NCP command when the executor is the DN2~
MCB node.

7-34

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
MAXIMUM COST number
This parameter applies to the executor node only.
Sets the maximum total path cost allowed from the executor
to any node.
Path cost is the sum of the circuit costs
along a path between two nodes.
If the path cost is greater
than the MAXIMUM COST, the node is considered unreachable.
Number is a decimal in the range 1-1022.
The default for
DECnet-10 is 100.
MAXIMUM HOPS number
This parameter applies to the executor node only.
Sets the maximum number of hops between any two nodes in the
network.
If the number of hops is greater than the MAXIMUM
HOPS, the node is considered unreachable.
Number is a
decimal number in the range 1-30. The default for DECnet-10
is 16.
MAXIMUM LINKS number
This parameter applies to the executor node only.
Sets the maximum allowable active logical link count for the
node. Number is a decimal in the range 1-65535.
This parameter applies to the DN20 MCB node only and cannot
be set by the operator or system manager. MAXIMUM LINKS is
displayed in response to the SHOW EXECUTOR CHARACTERISTICS
NCP command when the executor is the DN20 MCB node.
MAXIMUM VISITS number
This parameter applies to the executor node only.
Sets the maximum number of nodes a message coming into this
node can have visited.
If the number specified is exceeded
and the destination is not for this node,
the message is
discarded.
Number is a decimal number that cannot be less
than MAXIMUM HOPS.
The upper limit is 63.
The default for
DECnet-10 is 20.
OUTGOING TIMER seconds
This parameter applies to the executor node only.
Sets a timeout value for outgoing connects.
If the time
between the request of a connect and the acknowledgement of
the request is greater than the specified seconds, Session
Control returns an error. Seconds is a decimal number in
the range 1-65535. The default for DECnet-10 is 60.
RETRANSMIT FACTOR number
This parameter applies to the executor node only.
Sets the number of times the source NSP will
retransmit a
timed-out message.
If the value of number is exceeded, NSP
reports to Session Control a loss of confidence for this
logical link.
In DECnet-10, Session Control then aborts the
logical link.
The default for DECnet-10 is 10.

7-35

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
ROUTING TIMER seconds
This parameter applies to the executor node only.
Sets the number of seconds between transmissions of
messages on non-Ethernet circuits.

routing

Routing update messages contain information about the cost
and hops to each node in the network. These messages are
sent automatically whenever there is a change in the
information
(for example, when a line goes down). In
addition, routing update messages are sent periodically by
the routing timer. These periodic transmissions ensure that
routing tables are kept up to date in the unlikely event
that a routing update message is lost.
Seconds is a decimal in the range 1-65535.
DECnet-10 is 600.

The default

for

SECONDARY DUMPER fileid
This parameter applies to adjacent nodes only.
Identifies the secondary dumper file to be used for upline
dumping the adjacent node. See Section 4.5.8, Specifying
Files.
SECONDARY LOADER fileid
This parameter applies to adjacent nodes only.
Identifies the secondary loader file to be used for downline
loading the adjacent node.
SEGMENT BUFFER SIZE bytes
For DECnet-10, the value of this parameter is equal to the
value set for BUFFERSIZE;
SEGMENT BUFFER SIZE cannot be
changed.
Sets the maximum size of the end-to-end segment. This size
includes protocol overhead down to and including the End
Communication layer, plus a constant value of 6
(for
compatibility with the BUFFER SIZE parameter definition).
The size does not include the Routing or Data link overhead
(except for the constant value of 6).
The size is in bytes, and is a decimal integer in the
256-576.

range

SERVICE CIRCUIT cktid
This parameter applies to adjacent nodes only.
Sets the circuit to be used
to the adjacent node for
downline loading or upline dumping.
For downline loading
the NODE node parameter must be the target (adjacent)
node.
(See Section 7.3.2 for an explanation of cktid.)

7-36

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
SERVICE DEVICE devtype
This parameter applies to adjacent nodes only.
Sets the service device type the adjacent node uses when in
service slave mode
(MOP protocol).
The value typed for
devtype is one of the standard line device mnemonics.
The
options are the following:
CI
DLV
DMR
DPV
DUP
KDP
KMX
UNA

CNA
DMC
DMV
DQ
DV
KDZ
NI

DA
DMF
DN
DTE
DZ
KL
PCL

DL
DMP
DP
DU
ETH
KMY
QNA

See Appendix F for a description of DECnet line devices.
DECnet-l~

does not require the device type before using a
LOAD command;
however,
if devtype
is set,
the system
verifies that the node is associated with the named device.
SERVICE NODE VERSION node-version
Specifies the DECnet-l~ software version of the node which
downline loads its software to the target node. Version is
the number 1 for Phase IV and ~ for previous versions.
The
default value is 1 (Phase IV).
SERVICE PASSWORD password
This parameter applies to adjacent nodes only.
Sets the password
required
to trigger
the
bootstrap
mechanism on the adjacent node.
Password is a hexadecimal
number.
For DDCMP circuits, the range is ~ to FFFFFFFF; for
Ethernet circuits the range is ~ to FFFFFFFFFFFFFFFF.
SOFTWARE IDENTIFICATION softwareid
This parameter applies to adjacent nodes only.
Sets any descriptive string that will identify the software
to be loaded when the adjacent node is downline loaded
(example,
DN2~
files).
Softwareid contains up to
16
alphanumeric characters.
SOFTWARE TYPE sftyp
This parameter applies to adjacent nodes only.
Identifies the initial software to be loaded in
load operation as one of:
SECONDARY LOADER
TERTIARY LOADER
SYSTEM

7-37

downline

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
STATE state
For EXECUTOR node:

(Not implemented by DECnet-10)

ON
OFF
SHUT
RESTRICTED
(See Section 7.3.3 for definition of these parameter
values.)
For Remote nodes:

(Not implemented by DECnet-10)

REACHABLE
UNREACHABLE
(See Section 7.3.3 for definition of these parameter
values.)
TERTIARY LOADER fileid
This parameter applies to adjacent nodes only.
Identifies the tertiary loader file to be used for
loading the adjacent node.

downline

TYPE nodtyp
This parameter applies to the executor node only.
NML
parses the command, but TYPE cannot be set for DECnet-10.
If a node other than a TOPS-10 node is to execute this
command, consult the appropriate documentation. Type is one
of:
AREA-ROUTER
NONROUTING-III
NONROUTING-IV
ROUTING-III
ROUTING-IV
Examples:
1.

Set the name of node 5.14 to AURORA:
NCP)SET NODE 5.14 NAME AURORA

Set the default processor type to be downline loaded:
NCP>SET NODE BANGOR SOFTWARE INDENTIFICATION RSX-IIS-V3.2

Remarks:
As a user with operator privileges, if you change a parameter
value
(or several values) to improve a temporary condition or to
get a response specific to your own requirements, it is usually
good practice to restore the original setting before exiting from
NCP.
If you feel that the change should remain, consult your
system manager or
inform other users by message. The default
parameter values that are present when the system is brought up
are acceptable under normal conditions.
Be sure that you
understand the probable effect of any change before you make it.
For example,
it is strongly suggested that you refer to the NSP
specification before changing DELAY FACTOR or DELAY WEIGHT.

7-38

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Command

Entity

Keywo rd/Arg umen t

SET
}
{ DEFINE

KNOWN NODES

ALL
}
{ COUNTER TIMER seconds

Function:
SET KNOWN NODES ALL loads all node parameter values from the
permanent data base into the volatile data base (this command is
not supported by DECnet-10). Other SET KNOWN NODES commands set
the specified value in the volatile data base of each node known
to the executor. Note that many values that can be set for one
node do not apply logically to KNOWN NODES.
Arguments:
See SET/DEFINE NODE (singular).
Examples:
1.

Set the node logg.ing event for all known nodes to take
every 600 seconds:

place

NCP>SET KNOWN NODES COUNTERS 600
Remarks:
On the DN20 MCB node, setting COUNTER TIMERS for KNOWN NODES is
very demanding on NML resources and should be avoided if not
necessary.

7.5.6

SET/DEFINE LOGGING

Command

Entity

SET
}
{DEFINE

LOGGING sinktype}
{ KNOWN LOGGING

Keywo rd/ Arg umen t

ALL
EVENT eventl ist [sourcequal] [sinknode]
KNOWN EVENTS [sourcequal] [sinknode]
( NAME sinkname
STATE sinkstate

Function:
Used to control where events are logged (event sinks)
and which
events get logged.
(the DECnet-10 default is all events logged
to SYS:ERROR.SYS.)

7-39

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Arguments:
See Section 7.3.6 for sinktype, eventlist, and sinkstate.
See
Table 7-1 in the same section for the relationship between class
and entity required for sourcequal.
NAME sinkname
Identifies the name of the console, file, or monitor program
to which events will be logged:
If sinktype is
If sinktype is
If sinktype is
the monitoring

CONSOLE, enter device name
FILE, enter file name
MONITOR, enter identification string for
program

DECnet-10 does not support the MONITOR sink.
sourcequal
This argument selects a specific entity according
classes. The format is:

event

SINK

NODE

AREA area-id
CIRCUIT ckt-id
LINE line-id
MODULE type
NODE node-id,
sinknode
Specifies a node that receives events in format:
nodeid or SINK EXECUTOR.
Examples:
1.

Cause all events generated locally to
logging console on remote node TOSCA.

logged

the

NCP)SET LOGGING CONSOLE KNOWN EVENTS SINK NODE TOSCA

Cause all class 5 events for line ETH-0 to be logged
CONSOLE
NCP)SET LOGGING CONSOLE EVENT

7.6

CHANGING NETWORK DATA BASES:

the

5.* LINE ETH-0

CLEAR AND PURGE COMMANDS

The CLEAR command clears parameters from the volatile data base; for
systems that support a permanent data base, the PURGE command clears
parameters from the permanent data base. The entities are the same as
the entities for the SET and DEFINE commands.
However, not all
parameters can be purged or cleared by executing commands that specify
individual parameter values.
The allowed parameter keywords are,
therefore, a subset of the SET/DEFINE keywords.
Except for the
LOGGING entity, you need not supply values for keywords.
Refer to the arguments for the SET/DEFINE commands if you need to
refresh your memory on restrictions and exact meaning of keywords.
Complete information follows for only those commands that require
further description.
7-40

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Command

Entity

Keyword/Argument

CLEAR}
{ PURGE

LOGGING sinktype

EVENT eventlist [sourcequal] [SinknOde]}
KNOWN EVENTS [sourcequal] [sinknode]
{ NAME sinkname

Function:
Together with the SET/DEFINE LOGGING commands,
these commands
control
the logging of events:
both the events that will be
logged and where they will be logged.
Arguments:
Refer to Section 7.3.6 for details.
Command

Entity

CLEAR}
{ PURGE

CIRCUIT cktid }
{ KNOWN CIRCUITS

Keyword/Argument

~~tNTER TIMER}
{ OWNER
For systems supporting multipoint:
ACTIVE/INACTIVE/DYING BASE
ACTIVE/INACTIVE/DYING INCREMENT
BABBLE TIMER
INACTIVE/DYING/DEAD THRESHOLD
MAXIMUM BUFFERS
MAXIMUM TRANSMITS
TRANSMIT TIMER

CLEAR}
{ PURGE

LINE lineid}
{ KNOWN LINES

ALL
}
{ COUNTER TIMER
For systems supporting multipoint:
DEAD/DELAY/SCHEDULING/STREAM TIMER

CLEAR}
{ PURGE

NODE nOdeid}
{ KNOWN NODES
(EXECUTOR can be
substituted for
node id .)

ALL
CIRCUIT
CONSOLE LOAD FILE
CONSOLE SECONDARY LOADER
COUNTER TIMER
CPU
DUMP ADDRESS
DUMP COUNT
DIAGNOSTIC FILE
DUMP FILE
HARDWARE ADDRESS
HOST
IDENTIFICATION
INCOMING TIMER
LOAD FILE
NAME
OUTGOING TIMER
SECONDARY DUMPER
SECONDARY LOADER
SERVICE DEVICE
SERVICE CIRCUIT
SERVICE PASSWORD
SOFTWARE IDENTIFICATION
SOFTWARE TYPE
TERTIARY LOADER

7-41

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Function:
The CLEAR and PURGE commands remove the volatile
values, respectively, from the specified entity.

and

permanent

Arguments:
None.

(You specify the keyword only.)

Examples:
With the exception of CLEAR EXECUTOR to change the executor from
a remote node to the TOPS-l~ node, and the CLEAR NODE command to
remove a loopnode NAME, you will have little use for the CLEAR
command.
(These two uses have been shown.) It is not necessary
to CLEAR a parameter value for an entity to change it. Using the
SET command to establish the new value is sufficient. However,
in the case of changing a node name, you must remove the node
name before setting the new name, for example:
NCP>CLEAR NODE 255 NAME
NCP>SET NODE 255 NAME GOOSE
Remarks:
does not support the CLEAR command
parameters:

DECnet-l~

For CIRCUITS
OWNER
Multipoint parameters
X.25 parameters
For LINES
ALL
Multipoint parameters
X.25 parameters
For NODES
DUMP ADDRESS
DUMP COUNT
NAME (not for EXECUTOR)
X.25 parameters
Multipoint parameters

7-42

for

the

following

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYEH
7.7

MONITORING THE NETWORK:

LIST AND SHOW COMMANDS

NCP provides commands to display information about network components,
in the volatile and permanent database
(DECnet-H~
V4.0 does not
support the permanent database).
SHOW displays information about
components for the running network.
LIST performs a similar function,
but lets you display and verify information in the permanent database.
The SHOW and LIST commands allow you to select components and
types. You can choose from the following display types.

display

CHARACTERISTICS

Includes parameters that remain
constant
until cleared or reset. For example, timer
values and buffer sizes.

COUNTERS

Provides error and performance statistics.
For example, logical links in use.

EVENTS

Includes information about events currently
being logged by the logging entity.. Logged
events aid
in
detecting
failures
and
isolating problems.
This display type is valid only for 'the
LOGGING and LIST LOGGING commands.
dynamic
network

SHOW

STATUS

Includes
reflects
network.

SUMMARY

Includes only the most useful information
and STATUS display
from
CHARACTERISTICS
types.

If you do not specify a display type
command, SUMMARY is the default.

7-43

when

information that usually
operations for the running

issuing

SHOW

LIST

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Command
LIST}
{SHOW

Entity

Keyword/Argument

ACTIVE AREAS
}
AREA area number
KNOWN AREAS

CHARACTERISTICSI
COUNTERS
STATUS
SUMMARY
\

ACTIVE CIRCUITS}
CIRCUIT cktid
KNOWN CIRCUITS

CHARACTERISTIcsl
COUNTERS
STATUS
\ SUMMARY

ACTIVE LINES
KNOWN LINES
LINE lineid

CHARACTERISTICS I
COUNTERS
STATUS
\ SUMMARY

ACTIVE MODULES
KNOWN MODULES
EXECUTOR
ACTIVE NODES
KNOWN NODES
LOOP NODES
NODE nodeid
ADJACENT NODES

ACTIVE LOGGING
}
KNOWN LOGGING
LOGGING sink-type
MODULE CONSOLE

[ADJACNET NODE nodeid]

CHARACTERISTICSI
COUNTERS
STATUS
\ SUMMARY

[CIRCUIT cktid]
[KNOWN CIRCUITS]

[SINK NODE nodeid]
[KNOWN SINKS]

CHARACTERISTIcsl
EVENTS
STATUS
SUMMARY

CHARACTERISTICS}
{SUMMARY

MODULE CONFIGURATOR{STATUS }
SUMMARY
MODULE LOADER}
MODULE LOOPER

Qualifier

[KNOWN CIRCUITS]
[CIRCUIT cktld]

STATUS }
{SUMMARY

QUEUE
Function:
The SHOW command displays information from the volatile data
base; the LIST command displays information from the permanent
data base.

7-44

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYEn
Examples:
NCP>SHOW KNOWN CIRCUITS COUNTERS<RET>
6:32:38
NCP
Set Executor Complete
NCP>
6:34:14
NCP
Request # 262 Accepted
NCP>
6:34:15
NCP
Request # 262; Show Known Circuits Counters Completed
Circuit = DTE-0-1
6423
7272
9027

6701
7186

o
o
o

852561
510678
14361
16220

Circuit = DMC-0
2468

o
o
o

1615
1615

o
o

17910
230124
1233
1615

o
o
o
o
o
o
o
o

Seconds Since Last Zeroed
Terminating Packets Received
Originating Packets Sent
Terminating Congestion Loss
Transit Packets Received
Transit Packets Sent
Transit Congestion Loss
Ci rcui t Downs
Initialization Failures
Bytes Received
Bytes Sent
Data Blocks Received
Data Blocks Sent
Data Error Inbound
Data Errors Outbound
Remote Reply Timeouts
Local Reply Timeouts
Remote Buffer Errors
Local Buffer Errors
Selection Intervals Elapsed
Selection Timeouts

7-45

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Example 2:
.R OPR<RET>
OPR>ENTER NCP<RET>
NCP>SHOW ACTIVE NODES CHARACTERISTICS<RET>
NCP>
16:41:51 NCP
Request t 3~7 Accepted
NCP>
16:42:~g
NCP
Request t 3g7; Show Active Nodes Characteristics Completed
Executor Node = 7.123 (COURT)
Identification = DECnet-1~ Version 4.g
Management Version = 4.~.g
Host = 7.113 (KINGS)
Loop Count = 1
Loop Length = 127
Loop With = Mixed
Incoming Timer = 19
Outgoing Timer = 3g
NSP Version = 4.~.~
Maximum Links = 8
Delay Factor = 2
Delay Weight = 3
Inactivity Timer = 3g
Retransmit Factor = 5
Routing Version = 2.g.~
Type = Routing IV
Routing Timer = 6g
Maximum Address = 255
Maximum Circuits = 8
Maximum Cost = 1~~
Maximum Hops = 16
Maximum Visits = 32
Maximum Broadcast Nonrouters = 64
Maximum Broadcast Routers = 32
Maximum Buffers = 66
Buffer Size = 576
Segment Buffer Size = 576
Remote Node

= 7.113

(KINGS)

No Information
Remote Node = 7.118

()

No Information
NCP>EXIT<RET>
Remarks:
SHOW or LIST entity with no
follows plural entity or
SUMMARY.

information type
entity entityid)

(carriage return
will default to

To successfully display STATE, STATUS, SUMMARY, CHARACTERISTICS,
or COUNTERS for all DN2g lines and circuits, you must set the
executor to the communications front end
(DN2~).
The KL10
recognizes the DTE as the path it uses to load and dump the DN2g.
The characteristic needed to perform a dump or load is SERVICE
ENABLED.

7-46

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
7.8

CONTROLLING THE NETWORK:

DUMP, LOAD, LOOP, AND TRIGGER COMMANDS

The following section describe the commands for controlling the
in the network.

7.8.1

nodes

DUMP

Command
DUMP

Entity

Keyword/Argument

NODE nodeid

(VIA cktid]
(DUMP COUNT number]
(PHYSICAL ADDRESS eth-address]
(SECONDARY (DUMPER] fi1eid]
[SERVICE DEVICE devtype]
((SERVICE] PASSWORD password]
(TO dumpfileid]

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

the

Arguments:
VIA cktid
Identifies the circuit used for the dump.
TO dumpfileid
Identifies the host's file to receive the target's dump.
All other parameters and arguments are described
7.5.3, the SET/DEFINE NODE nodeid command.

Section

Example:
Copy the memory image of the 'DN2~ node JAZZ to the host node.
NCP>DUMP NODE JAZZ<RET>
Remarks:
This command is not needed to obtain a dump when the
automatically reloaded.
The dump is also automatic.
there may be times you wish to dump the MCB front end
automatic dump/load procedure is not indicated.

DN2~

is
However,
when an

Before dumping the DN2~, execute the NCP command SET CIRCUIT
DTE-~-l
SERVICE ENABLED, if necessary_
(The circuit you enable
is the circuit connecting the host and target node.)

7-47

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Command
DUMP

Entity

Keyword/Argument

VIA cktid

[[DUMP] ADDRESS number]
[[DUMP] COUNT number]
[PHYSICAL ADDRESS eth-address]
[SECONDARY [DUMPER] fileid]
[SERVICE DEVICE devtype]
[[SERVICE] PASSWORD password]
[TO dumpfileid]

Function and arguments as for DUMP NODE nodeid.
Remarks:
The DN2~ should not require this command.
The SERVICE CIRCUIT
for
the DN2~ is setup automatically when initial values are read
from a command file at system startup.
The VIA cktid parameter and argument in the entity position is
simply a more descriptive way of indicating the entity circuit.
DECnet-l~ software normally requires no parameters; that is,
the
commands
shown in the examples are executed under normal
conditions. The node data base for the host node contains the
needed dump parameter values when the system is brought up.
If a
needed parameter value is missing, the NCP response names the
missing parameter. Use the SET NODE command to enter the missing
parameter and repeat the DUMP NODE command.

7.8.2

LOAD

Command
LOAD

Entity
NODE nOdeid}
{ VIA cktid

Keyword/Argument
[ADDRESS nodeaddr]
[CPU type]
[FROM loadfileid]
[HOST nodeid]
[NAME nodename]
[PHYSICAL ADDRESS eth-address]
[SECONDARY [LOADER] fileid]
[SERVICE CIRCUIT cktid]
[SERVICE DEVICE devtype]
[SERVICE NODE VERSION node-version]
[[SERVICE] PASSWORD password]
[SOFTWARE IDENTIFICATION softwareid]
[SOFTWARE TYPE type]
[TERTIARY [LOADER] fileid]
[VIA cktid] (Not applicable if command is
LOAD VIA cktid.)

Function:
The LOAD command allows one node
in the network to load the
(See Remarks
system image file to a remote node in the network.
for conditions and restrictions.)

7-48

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
NOTE
All parameters and arguments for the LOAD command are
optional (with the exception of the PHYSICAL ADDRESS
parameter, which must be specified with the LOAD VIA
command).
This is because the permanent data base
contains values used as defaults by systems supporting
a permanent data base. In DECnet-l0, the values used
are those initial values established as the volatile
data base at system startup.
You type only those
keywords and values that you need to change.
(For
example, if you wish to load the DN20 with an
alternate load file, you type an alternate filename.)
In DECnet-l0, any missing parameters are indicated in
an error message, and can be set at that time and the
command re-tried.
Arguments:
VIA cktid
Identifies the circuit over which to load.
ADDRESS nodeaddr
Nodeaddr is the address the target node is to
initializes.

use

when

7.3.3

for

CPU type
This is the target
predefined arguments.

CPU

type.

See

Section

FROM loadfileid
Identifies the image file to be loaded.
HOST nodeid
Sends the target node the nodeid of the host node that will
provide services (such as a file system) for the target node
once it is loaded. Note that this mayor may not be the
same node as the executor. If HOST nodeid is not specified,
the executor is assumed to be the host node of the target
node.
NAME nodename
Specifies the name of the target node.
PHYSICAL ADDRESS eth-address
Identfies the Ethernet addressu This parameter is required
in the LOAD VIA command and is optional in the LOAD NODE
command.
SECONDARY [LOADER] fileid
Identifies the secondary loader file; that is, the file to
be requested by the primary loader (contained in the target
bootstrap) •

7-49

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
SERVICE DEVICE devtype
Identifies the target node's line controller for the service
line over which the operation is to take place. The options
are the following:
CI
DLV
DMR
DPV
DUP
KDP
KMX
UNA

CNA
DMC
DMV
DQ
DV
Km
NI

DA
DMF
DN
DTE
DZ
KL
PCL

DL
DMP
DP
DU
ETH
KMY
QNA

See Appendix F for a description of DECnet line devices.
SERVICE NODE VERSION node-version
This parameter is the DNA version of the adjacent node,
which is used to determine the TARGET SYSTEM ADDRESS
parameter in the MOP Parameter Load with Transfer Address
message.
Phase IV is indicated by 1, and Phase III is
indicated by~. The default is 1.
SERVICE PASSWORD password
Identifies the password required to trigger the bootstrap
mechanism on the target noda.
The password is a hexadecimal
number. For DDCMP circuits, it is in the range ~-FFFFFFFF;
for
Ethernet
circutis,
it
is
in
the
range
~-FFFFFFFFFFFFFFFF.
The SERVICE keyword is optional.
SOFTWARE IDENTIFICATION software type
See Section 7.5.4, SET NODE nodeid command for
of this keyword.

descriptions

SOFTWARE TYPE type
See Section 7.5.4, SET NODE nodeid command for
of this keyword.

descriptions

TERTIARY LOADER fileid
Identifies
second~ry

the tertiary loader file
(requested
loader file) for the target node.

Examples:
See Section 3.1 for examples.
Remarks:
See Section 3.1 for loading procedure.

7-5~

the

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYE:R
7.8.3

LOOP

Command
LOOP

Entity

Keyword/Argument

NODE node-id
EXECUTOR
LINE line-id

[USER user-id]
[ACCOUNT account]
[PASSWORD password]

[COUNT count]
[LENGTH number]
[WITH ONES]
ZEROS]
MIXED]

CIRCUIT

[ASSISTANT NODE node-id]
[ASSISTANT PHYSICAL ADDRESS eth-address]
[HELP help-type]
[NODE node-id]
[PHYSICAL ADDRESS eth-address]

Function:
This command tests a node, line, or circuit by transmitting
blocks of data.

test

Arguments :.
Access information (USER, ACCOUNT, and PASSWORD) refers to these
values for the node named in NODE nodeid.
If node is remote, the
conventions of the remote node are used.
COUNT count
This parameter is the number of blocks to be sent during
loopback testing.
The count is a decimal integer in the
range 1-65535.
LENGTH number
This parameter is the length (in bytes) of blocks to be sent
during loopback testing. The length is a decimal integer in
the range 1-65535.
WITH

ONES
ZEROS
MIXED
This parameter specifies the content of the test data.
default is MIXED (a combination of ones and zeroes).

The

Arguments for CIRCUIT
ASSISTANT PHYSICAL ADDRESS eth-address
This parameter is not supported by DECnet-l~.
Identifies the Ethernet physical address of the node that
will perform the role of loopback assistant for Ethernet
third-party loop testing. ASSISTANT PHYSICAL ADDRESS must
be specified if HELP is included in this command. The
address cannot be a multicast address.
Eth-address is a
string of 12 hexadecimal digits,
represented by 6 bytes
separated by hyphens. This parameter can be used instead of
the ASSISTANT NODE parameter.

7-51

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
ASSISTANT NODE node-id
This parameter is not supported by DECnet-10.
Identifies the name of the node or the address of the node
that will perform the role loopback assistant for Ethernet
third-party loop testing.
This parameter can be used
instead of the ASSISTANT PHYSICAL ADDRESS parameter.
HELP help-type
This parameter is not supported by DECnet-10.
Indicates the amount of assistance to be provided during
Ethernet loopback testing by the assistant node, whose
address is specified
in the ASSISTANT NODE ADDRESS or
node-id as specified in the ASSISTANT NODE parameter. There
are three possible values of help-type:
TRANSMIT
The assistant node relays the request to the
which replies directly to the
destination node,
executor node.
RECEIVE
The executor node sends the request directly to
the destination node, which relays the reply to
the assistant node for transmission
to
the
executor noda.
FULL
The assistant node relays the request
reply
between
the
executor
node
destination node.

and
and

the
the

NODE node-id
Identifies the destination node to be used for loopback
testing of the specified Ethernet circuit.
Can be used
instead of the PHYSICAL ADDRESS parameter.
PHYSICAL ADDRESS eth-address
Identifies the Ethernet physical address of the destination
node to be used
for
loopback testing of the specified
Ethernet circuit.
Eth-address is a string of 12 hexadecimal
digits, represented by 6 bytes separated by hyphens.
Examples:
1.

Start an Ethernet circuit-level loopback test with a
whose Ethernet physical address is AA-00-04-00-FF-04.
NCP)LOOP CIRCUIT ETH-8 PHYSICAL ADDRESS AA-00-S4-S0-FF-S4

7-52

node

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Remarks:
LOOP NODE (and LOOP CIRCUIT) are described in detail
3.7.1.
DECnet-19 supports the LOOP CIRCUIT command
only.

for

Section

Ethernet

lines

If any of the three access parameters
(USER, ACCOUNT, or
PASSWORD) are typed, they must precede other optional parameters.

7.8.4

TRIGGER

Command

Entity

Keyword/Argument

TRIGGER

NODE nodeid {

[PHYSICAL ADDRESS eth-address]
[[SERVICE] PASSWORD password]
[VIA cktid]

{

VIA c:ktid

PHYSICAL ADDRESS eth-address
[[SERVICE] PASSWORD password]

Function:
The TRIGGER command attempts to cause the target node
(the node
to be loaded)
to send a load request to the executor. The
executor must be an adjacent node. Use this command to initiate
the loading sequence for an unattended system.
Arguments:
PHYSICAL ADDRESS eth-address
This parameter is the Ethernet address currently in use for
the target node.
It is required in the TRIGGER VIA command
and optional in the TRIGGER NODE command.
[[SERVICE]

PASSWORD password]

This parameter specifies the password to trigger the target
node.
The entire parameter with its value is optional.
If
included, SERVICE (tor clarity) may be included or omitted
as an additional keyword.
VIA cktid
Identifies the circuit over which the operation is
place.

7-53

take

NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER
Examples:
1.

Trigger node TRMSRV to initiate a downline load.
NCP>TRIGGER NODE TRMSRV

Trigger Ethernet node SWIFT to initiate a downline load. The
executor node uses the Ethernet physical address to address
SWIFT on Ethernet circuit ETH-0.
NCP>TRIGGER NODE SWIFT PHYSICAL ADDRESS AA-00-04-00-07-04 VIA ETH-0

Provide a service password in order to trigger
initiate a downline load over circuit ETH-0.

node

NYC

NCP>TRIGGER NODE NYC SERVICE PASSWORD FEFEFEFFEFEFEFEFE VIA ETH-0
Remarks:
DECnet-10 V4.0 does not support the TRIGGER command for the DN20.
Other target nodes, such as terminal servers, are supported.

7.9

MONITORING NODE ACTIVITY:

Command
ZERO

ZERO COMMAND

Entity

Keyword/Argument

CIRCUIT cktid
KNOWN CIRCUITS
EXECUTOR
LINE 1ineid
KNOWN LINES
NODE nodeid
KNOWN NODES
KNOWN MODULES

COUNTERS

Function:
The ZERO command resets the counters for the specified entity
the local node.

Arguments:
None - counters are considered as an aggregate. Individual text
items, such as line down for line counters can not be addressed.
Examples:
1.

Resets all node counters maintained on
node AURORA.

the

local

NCP>ZERO NODE AURORA COUNTERS
28

Resets all circuit counters for all known circuits.
NCP>ZERO KNOWN CIRCUIT COUNTERS

7-54

node

for

CHAPTER 8
NETWORK MANAGEMENT PACKET SWITCHING INTERFACE

If the PSI Version l.~ software option is included in your TOPS-l~
system, your DECnet network supports the X.25 facility for using
Public Packet Switching Networks (PPSNs). You can then use the X.25
NCP commands and parameters.'
If the PSI softeware option is not included in your TOPS-l~ system,
you DECnet network may include nodes of DIGITAL systems that support
the X.25 facility for using PPSNs.
The Network Management modules
understand the syntax of X.25-related commands and parameters. You
can, therefore, by using the TELL node-id prewfix or the SET EXECUTOR
NODE node-id command, direct X.25-related commands to DECnet nodes
that support a Packetnet System Interface (PSI).
This chapter contains a complete list of X.25-related NCP commands as
specified by the DNA.
As was true of the DECnet utility commands
documented in previous chapters, the set of commands implemented, and
the way in which they are implemented, is a function of the operating
system of each node in the network.

8.1

THE MODULE ENTITY

You have already been introduced
to
five
possible
entities
(controllable objects)
that are addressable in Phase IV DECnet:
NODES, LINES, CIRCUITS, LOGGING, and maintenance MODULE.
With the
addition of the X.25 facility, another entity is provided. This is
the X.25 MODULE entity. The X.25 MODULE entity takes one of three
forms:
MODULE X25-ACCESS, MODULE X25-PROTOCOL, and MODULE X25-SERVER.
The general nature of the information contained in the data bases
associated with each is as follows:
MODULE X25-ACCESS
The access module data base contains the information needed
to connect to one or more Public Packet Switching Networks
(PPSNs). The information is indexed by network name.
NCP
commands that reference this data base must indicate the
name of the network to which the command applies unless
there is only one netowrk name in the data base.
This data
base resides in the TOPS-l~ host node.

8-1

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
MODULE X25-PROTOCOL
The protocol module data base contains the information
needed to maintain switched virtual circuits (SVCs) and
permanent virtual circuits (PVCs) through the public data
network.
Much of the SVC information is indexed by the local Data
Termination
Equipment
(DTE)
address.
This address is
assigned by the PPSN at the time the line is installed. You
must include this address whenever it is a parameter in an
NCP command, unless it is the only DTE address in the data
base. This data base resides in the gateway node.
MODULE X25-SERVER
The server module data base contains the information needed
to map incoming calls to a DECnet process. This information
is indexed by destination name.
You must associate each
destination
name
with
a
DECnet
node
and process
identification
and
with
the
necessary
X.25-related
information to
recognize the incoming call. NCP commands
that reference this data base must indicate to which
destination name they apply unless there is only one such
name defined in the data base. This data base resides in
the gateway node.

8.2

X.25-SPECIFIC COMMANDS

SET, CLEAR and SHOW refer to parameters in the volatile data base;
DEFINE,
PURGE, and
LIST refer to parameters in the permanent data
base. These three pairs are considered together in the detailed
descriptions that follow.
All other commands are described in
separate charts. Remember that neither TOPS-l~ nor the MCB supports a
permanent data base.
Therefore, only SET, CLEAR, and SHOW are used
for TOPS-l~ PSI. All commands are described because other operating
systems may implement a permanent data base.
Command
SET
}
{ DEFINE

Entity

Keyword/Argument
MAXIMUM DATA bytecnt
MAXIMUM WINDOW blockcnt
USAGE usagtyp
BLOCKING blockcntl
NUMBER callnum
MAXIMUM RECALLS recallcnt
RECALL TIMER seconds
CHANNEL chnlnum
DTE dteaddr
TYPE X25

CIRCUIT cktid }
{ KNOWN CIRCUITS

In addition to the parameters that are X.25-specific, the following
parameters are common to both DDCMP and X.25 circuits: COUNTER TIMER,
OWNER, and STATE. See Chapter 7 for definitions.
(Definitions are
the same except that there is no SERVICE value permitted for the STATE
parameter in X.25 because X.2S circuits do not support any of the
Network Management service functions.)

8-2

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
NOTE
TOPS-l~ PSI circuits are not owned
by the executor,
and the parameters are set at network generation time
(see the TOPS-l~ DECnet and PSI Installation Guide).
Thus, you cannot change the following arguments with a
SET/DEFINE command:

MAXIMUM BLOCK
MAXIMUM WINDOW
USAGE PERMANENT
CHANNEL
DTE
TYPE X25
Only circuits of USAGE permanent are supported.
Function:
These commands set volatile and permanent circuit parameters,
respectively, for the circuit(s) identified by cktid.
Arguments:
MAXIMUM DATA bytecnt
For Permanent Virtual Circuits (PVCs):
the data link
maximum X.25 block size permitted. For Switched Virtual
Circuits (SVCs) owned by the executor node:
the block size
that routing is to request from the X.25 protocol handler
module. Bytecnt Is an integer in the range 1-65535.
It
must be less than or equal to the maximum block size allowed
within the X.25 protocol handler.
MAXIMUM WINDOW blockcnt
For PVCs: the data link maximum number of X.2S blocks
allowed to exist with outstanding acknowledgements.
For
SVCs owned by the executor node:
the block count that
routing is to request from X.25 for the circuit. Blockcnt
is an integer in the range 1-255.
USAGE usagtyp
The value of usagtyp is one of the following:
INCOMING
This value is used for SVC incoming calls only and only
for circuits owned by the executor node.
OUTGOING
This value is used for SVC outgoing calls only and only
for circuits owned by the executor node.
PERMANENT
This value is used for all PVCs
(circuits
connected to the same remote station).

8-3

permanently

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
BLOCKING blockcntl
This parameter applies to circuits owned by the executor
node.
The value you enter determines whether or not
messages are blocked before being sent over the circuit.
The possible values for blockcnt1 are:
ENABLED: Perform blocking
DISABLED: No blocking
NUMBER ca11num
This parameter applies to outgoing X.25 circuits owned by
the executor node.
The value you enter in ca11num is the
full remote DTE address used to callout on the circuit.
The address value must be an integer of one to sixteen
digits.
MAXIMUM RECALLS reca11cnt
This parameter applies to outgoing X.25 circuits owned by
the executor node.
The value you enter determines the
number of automatic call retries. Reca11cnt is an integer
in the range 0-255.
If no value is set, there is no
maximum.
RECALL TIMER seconds
This parameter applies to outgoing X.25 circuits owned by
the executor node.
The value you enter determines the
number of seconds between automatic retries. Seconds is an
integer in the range 1-65535. If no value is set, there is
no wait.
CHANNEL chn1num
This parameter applies to PVCs only. The value you enter
for chn1num is the channel number used in running the X.25
protocol on the circuit. The channel number is an integer
in the range 0-409!.
DTE dteaddr
This parameter applies to PVCs only. The value you enter is
the data link X.25 local DTE address to which the circuit
belongs. DTE address is an integer from one to sixteen
digits.
TYPE X25
For X.25 circuits, you must enter this parameter as TYPE
X25.
If you do not make this entry, the circuit is not
usable.

8-4

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
Command

Entity

Keyword/Argument

SET
}
{ DEFINE

MODULE X25-ACCESS

~ALL network-qUalifier}
network-options

~network-qUalifier
NOTE
The use of SET MODULE X25-ACCESS ALL is meaningless if
there is no permanent data base.
Check the PSI
documentation for the DIGITAL system that will execute
the command.
If there is a permanent data base, this
SET command moves all permanent X.25 ACCESS module
data base values to the volatile data base. DEFINE
MODULE X25-ACCESS ALL is never meaningful with the
plural
entity
KNOWN
NETWORKS.
DEFINE
MODULl~
X25-ACCESS ALL with
NODE
nodeid
is
currently
undefined.

Function:
The SET and DEFINE MODULE X25-ACCESS command sets volatile and
permanent data base parameters, respectively, needed to connect
to the X.25 server for one or more networks.
Arguments:
network-qualifier
Network-qualifier indicates the network name to which the
command applies.
If only one network is known, it is the
default. Network name is the name of the PPSN:
TELENET,
TRANS PAC , or PSS,
for example.
The possible values for
network-qualifier are:
KNOWN NETWORKS
NETWORK network-name
network-options
Network options may be one or more of the following:
ACCOUNT account
The value of the access control account field to
be used by the access routines in connecting to
the PSI gateway. This value is used if the user
does not supply an account value when calling the
access routines (see the TOPS-l~ PSI User's Guide
for more information on access routines): If no
account is set, none is included in the access
control
on
connect by the access routines.
Account is a string of one to 16 characters for
TOPS-l~.

NODE node-id
The identification of the node containing the X.25
gateway module that gives access to the associated
PPSN. Node-id is a standard Network Management
node identification.

8-5

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
PASSWORD password
The value of the access control password field to
be used by the access routines in connecting to
the PSI gateway. This value is used if the user
does not supply a password when calling the access
routines (see the TOPS-10 PSI User's Guide for
more information on access routines).
If no
password is set, none is included in the access
control
on
connect by the access routines.
Password is a string of one to 16 characters for
TOPS-10.
USER user
The value of the access control user field to be
used by the access routines in connecting to the
PSI gateway. This value is used if the user does
not supply a user identification when calling the
access routines (see the TOPS-10 PSI User's Guide
for more information on access routines). If no
user is set, none is included in the access
control on connect by the access routines. User
is a string of one to 16 characters for TOPS-10.
NOTE
ACCOUNT and
DECnet-10.

USER

are

not

used

Examples:
NCP>SET MODULE X2S-ACCESS NODE DNX2S:: NETWORK TELENET
NCP>SET MODULE X2S-ACCESS PASSWORD SECRET
Remarks:
Consult the documentation for the operating system of the
executor node.
(Remember that DEFINE will be meaningless if the
executor node's operating system does not support a permanent
data base.)
Command

Entity

Keyword/Argument

SET
}
{ DEFINE

MODULE X2S-PROTOCOL

ALL dte-qualifier
group-qualifier
GROUP group-name
group-options
CALL TIMER seconds
CLEAR TIMER seconds
DEFAULT DATA bytecnt
DEFAULT WINDOW bloc kent
MAXIMUM DATA bytecnt
MAXIMUM CLEARS retrycnt
MAXIMUM RESETS retryent
MAXIMUM RESTARTS retryent
MAXIMUM WINDOW blockcnt
NETWORK network-name
RESET TIMER seconds
RESTART TIMER seconds
dte-options dte-qualifier

8-6

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
Functions:
The SET and DEFINE MODULE X25-PROTOCOL commands control the
parameters necessary to maintain switched and permanent virtual
circuits through a public packet switching network over the
assigned X.25 lines of the protocol module.
Arguments:
ALL
Refer to NOTE for SET/DEFINE MODULE X25-ACCESS.
ALL dte-qualifier
dte-qualifier indicates the local DTE address to
command applies. dte-qualifier may be one of:

~,hich

the

KNOWN DTEs
DTE dte-address
If only one DTE address is known to the X.25 protocol
module,
that address is the default.
If more than one DTE
address is known, you must give the applicable address.
ALL group-qualifier
Group-qualifier indicates the closed user group or bilateral
closed user group to which the command applies.
It may be
one of the following:
KNOWN GROUPS
GROUP group-name
Group name is an ASCII string of one to sixteen
characters. It can have any value decided upon by
the managers of the communicating systems.
(See
the TOPS-10 PSI User's Guide for a description of
the user groups.)
ALL has the same interpretation already defined.
GROUP group-name group-options
Group-name is defined
under
the
previous
Group-options is both of the following:

argument.

DTE dte-address
NUMBER group-number
TYPE group-type
DTE-address
The PPSN DTE
group-name.

address

associated

with

the

Group-number
This is the closed user group number (defined
by the PPSN).
It must be an integer in the
range 0-9999.

8-7

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
Group-type
If specified, the
BILATERAL.

only

value

permitted

CALL TIMER seconds
The value you set in seconds determines the elapsed time
between receiving no response on an outgoing call from the
DTE and the sending of a clear packet.
(The sending of the
clear packet is transparent to the user.) Seconds is an
integer in the range 1-255.
CLEAR TIMER seconds
The value you enter for seconds determines the elapsed time
between retransmissions of clear packets. Seconds is an
integer in the range 1-255.
If no value is set, there is no
retransmission.
DEFAULT DATA bytecnt
This is the default block size for SVCs.
The value you
enter must be an integer in the range 1-1021, which is used
when there is no negotiation for a packet size
(see the
TOPS-10 PSI User's Guide for more information on the flow
control parameter negotiation facility).
DEFAULT WINDOW blockcnt
This is the number of unacknowledged transmitted blocks on
an SVC that can be sent before an ack~owledgment is
received. Once you set this value,
it remalns in effect
until changed. The value that you enter must be an integer
in the range 1-255, which is used when there is no
negotiation for a window size (see the TOPS-10 PSI User's
Guide for more information on the flow control parameter
negotiation facility).
MAXIMUM DATA bytecnt
The value you enter for this parameter establishes the
maximum byte count for all X.25 circuits. Bytecnt must be
an integer in the range 1-1021, which is the maximum value
you can specify when negotiating for a packet size (see the
TOPS-10 PSI User's Guide for more information on the flow
control parameter negotiation facility).
MAXIMUM CLEARS retrycnt
The value you enter for this parameter determines the
maximum number of times that the X.25 protocol handler is to
retry the sending of a clear packet for SVCs.
The value
must be an integer in the range 1-255.
If you do not set a
value, there is no maximum.
MAXIMUM RESETS retrycnt
As for preceding parameter, but sets the maximum times for
retrying the sending of a reset packet. If you do not set
this value, there is no maximum. Retrycnt is an integer in
the range 1-255.

8-8

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
MAXIMUM RESTARTS retrycnt
The value you enter for retrycnt determines the maximum
number of times that the X.25 protocol handler retries the
sending of a restart.
If you do not set this value, there
is no maximum.
Retrycnt is an integer in the range 1-255.
MAXIMUM WINDOW blockcnt
The value you enter in blockcnt determines the maximum
number of unacknowledged transmitted blocks permitted on an
SVC. The value of blockcnt must be an integer in the range
1-255, which is the maximum value you can specify when
negotiating for a window size (see the TOPS-10 PSI User's
Guide for more information on the flow contro"l parameter
negotiation facility).
NETWORK network-name
Previously defined.
RESET TIMER seconds
The value you enter for seconds determines the number of
elapsed seconds between a transmission and a retransmission
of an unacknowledged reset packet.
Seconds must be an
integer in the range 1-255. If no value is set, there is no
retransmission.
RESTART TIMER seconds
The value you enter for this parameter determines the
elapsed seconds between transmission and retransmission of
an outgoing restart packet from the local DTE.
Seconds must
be an integer in the range 1-255. If no value is set, there
is no retransmission.
dte-options
DTE-options, indexed by the local DTE address,
following (not supported by TOPS-10 PSI):

include

the

CHANNELS list
List is one or more logical channel numbers that
can be used for outgoing calls or possibly taken
by incoming calls.
If more than one channel
number is specified, separate by commas.
COUNTER TIMER seconds
This is a Network Management timer.
The value
that
you enter determines the time interval
between successive recordings and zeroing
of
protocol module counters.
If no value is set,
there is no automatic logging of counters.
LINE lineid
Identification of the line associated with the DTE
address.
It cannot be set or defined by a Network
Management command.

8-9

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
STATE dte-state
The value you enter must be one of:
ON
OFF

- DTE is allowed to operate normally
- DTE is not operating; all virtual
circuits terminated immediately
SHUT - local DTE will not allow new virtual
circuits;
existing virtual circuits
continue
Examples:
NCP)SET EXECUTOR NODE DNX25
NCP)SET MODULE X23-PROTOCOL MAXIMUM DATA 128
NCP)SET MODULE X25-PROTOCOL CHANNELS lB-l DTE 311B3B3B1234

Command

Entity

}
SET
{ DEFINE

MODULE X25-SERVER

Keyword/Argument
(ALL destination-qualifier
) COUNTER TIMER seconds
MAXIMUM CIRCUITS count
destination-options
{
destination-qualifier

l
J

Function:
The SET/DEFINE MODULE X2S-SERVER commands control the parameters
related to the server module data base. Some parameter values
entered provide the information needed to map incoming X.2S calls
to a DECnet process; other parameters are independent of the
destination name but are needed for more general functions
related to incoming calls, for example, event recording.
Arguments:
ALL
ALL has the previously defined
server module data base.

meaning,

the

Indicates the destination to which the command applies.
be one of:

May

destination-qualifier

KNOWN DESTINATIONS - all destinations known to the
server module DESTINATION destination-name
destination-name
The name of a specific destination. Name is an ASCII string
of from one to sixteen characters. It is the responsibility
of the system manager to assign destination names for
input
to his node.
Because such names must be unique, this
involves cooperation between managers of
communicating
nodes.

8-1~

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
COUNTER TIMER seconds
This counter timer is the Network Management timer that
determines the elapsed time between the logging of a server
module logging event. Seconds is an integer in the range
1-65535.
MAXIMUM CIRCUITS count
The value you enter for count indicates the number of
circuits that the server module can have open at one time.
Count must be an integer in the range 1-65535.
destination-options
You can add new destination names at the initial reference
to the destination name in an NCP SET command. You can
remove old names from the data base using the CLEAR command.
Para~eters
of an existing destination can be modified. The
parameters accessed by destination name are described below.
These parameters are divided into two groups:
o

Parameters that are applied to a field in the incoming
call packet for the ~urpose of determining a match.

Parameters that define the
DECnet
characteristics
necessary to initiate a logical link connect to a DECnet
obj ect.
.

The parameters that ar~ applied to a field of the
packet are:
CALL MASK

incoming

call

hexadecimal string
This is a string of up to 32 hexadecimal
characters that is used to determine the
destination of the incoming call based
on toe content of the user call data
field 6f the incoming call packet. This
value is ANDed byte-by-byte 'wi th the
tiser call data field df the incoming
call packet.
The resultant string is
compared with the CALL VALUE.

CALL VALUE

hexadecimal string
This is a string of up to 32 hexadecimal
characters that is used to determine the
destination of an incoming call based on
the content of the user call data field
of the incoming call packet. This value
is compared byte-by-byte with the string
resulting from the CALL MASK operation
described
above
to
determine
the
destination of an incoming call.

GROUP

asci i-string
This is the closed user
group
or
bilateral closed user group name used to
determine the destination of an incoming
call based on user group membership. If
given, only incoming calls with this
user group name will be routed to this
destination.
8-11

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
NUMBER

ascii-string
This is the full remote DTE address used
to
determine the destination of an
incoming call based on the calling DTE
address in the incoming call packet.
This value must be a string of digits
and/or asterisks (*) from one to sixteen
characters.

PRIORITY

decimal number
This is the priority associated with a
given entry in the DESTINATION data
base. The highest priority is 255 and
the lowest is ~. If an incoming call
maps to more than one destination, the
one with the highest priority is chosen.
If there is more than one match with
equal priority, the first is chosen.

SUBADDRESSES

range
This is the range of the local DTE
subaddresses
used
to
identify the
destination of an incoming call.
If
given, only those calls with the called
DTE subaddresses in the specified range
will be routed to this destination. A
subaddress is a decimal number from
~-99.

Examples:
NCP)SET EXECUTOR NODE DNX2S
NCP)SET MODULE X2S-SERVER CALL MASK 81 DESTINATION X29SRV
NCP)SET MODULE X25-SERVER CALL VALUE 81 DESTINATION X29SRE
NCP)SET MODULE X2S-SERVER OBJECT 34 DESTINATION X29SRV
The following parameters are necessary to
connection to a DECnet destination object:
ACCOUNT

initiate

logical

link

ascii-string
This is the DECnet access control account string
used when the Server module connects to the
destination of an incoming call. The ascii-string
can contain 1 to 16 characters.

NODE

nodeid
This is the standard Network Management node name
used when the Server module connects to the
destination of an incoming call.
This is a
required parameter.

8-12

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
OBJECT

objectid
This is the DECnet object identification used when
the Server module connects to the destination of
an incoming call. The value objectid can be one
of the following:
An ASCII object name or numeric object
in quotes, of 1 to 16 characters

name

An object number, from 1 to 255
PASSWORD

ascii-string
This is the DECnet access control password used
when the Server module connects to the destination
of an incoming call; must be a string of 1 to 16
characters.

USER

ascii-string
This
is
the
DECnet
access
control
user
identification to be used when the Server module
connects to the destination of an incoming call;
must be a string of 1 to 16 characters.

Remarks:
To determine the destination for an
incoming
call,
the
information in the incoming call packet is compared with the CALL
MASK, CALL VALUE, GROUP, NUMBER, and SUBADDRESSES parameters in
each of the DESTINATION entries to see if there is a match.
If
there is a match, the ACCOUNT, NODE, OBJECT, PASSWORD, and USER
parameters are used to initiate a logical link connect.
If there
is more than one match, the match with the highest PRIORITY is
taken.
If multiple matches have the same PRIORITY, the first
entry in the data base is used.
If any of the fields used to identify the DECnet destination of
an incoming call are missing, then no values are used for the
missing fields
in the identification process.
It is
the
responsibility of the receiving node to take care of the
distribution of messages with missing values in these fields
(destination-options).
A match exists only if all the
true:

conditions

described

below

are

The user call data field of the incoming packet, logically
ANDed byte-by-byte with the CALL MASK, equals the CALL VALUE.
If the user call data field is longer than the CALL MASK,
then the strings need only be equal to the end of CALL MASK.
If the CALL MASK is longer than the user call data field, a
match can only be obtained if all bytes in thH CALL MASK
beyond the length of the user call data field are zero.

The GROUP parameter equals the closed user group from the
incoming call packet, or no GROUP parameter is defined.
If a
GROUP parameter is defined and there is no group present in
the incoming call packet, there is no match.

8-13

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
3.

The NUMBER parameter matches the calling DTE address in the
incoming call packet.
The match is determined by scanning
both ASCII strings from left to right. The NUMBER parameter
can be any combination of ASCII characters from ~ to 9 and
the wildcard character "*"
A match exists if the following
is true:
o

There is no NUMBER parameter defined; or

Up to the length of the shorter string, each character in
the NUMBER parameter string contains an "*" or the same
decimal digit as the DTE address string; and

If the NUMBER parameter string is the shorter of the
two strings, and the last character in the NUMBER
parameter string is an asterisk; or

If the NUMBER parameter string is the longer of the
two strings, the excess characters are all considered
to be asterisks.

If there is no calling DTE address,
then a match can
occur only if the NUMBER parameter string consists of one
or more asterisks.

The local DTE subaddress from the incoming call packet is
the
range
defined
by
SUBADDRESSES, or there is
SUBADDRESSES range defined.

in
no

For a job to receive incoming calls, it must set itself up as a
target task.
The procedure for doing this is described in the
TOPS-1~ PSI User's Guide.
Below are some examples showing the
relation~etween the TOPS-l~ target task file descriptor and the
DESTINATION parameters.
You can specify two types of target tasks.
The example below
shows these and the values of the DESTINATION parameters required
to connect to the target.
1.

Specify a numbered object in the TOPS-1~ program:
If the
user program specifies a target of the form '128', set the
DESTINATION parameters:
OBJECT
NODE :

128
TOPS-l~

node number

Specify a named object in the
program specifies a target
DESTINATION parameters:
OBJECT
NODE :

TOPS-1~

the

program:
If the user
form 'TASK~', set the

TASK~

TOPS-1~

node number

The parameters USER, PASSWORD, and ACCOUNT are optional.
If
the user program requires those parameters,
the system
manager must set them.

8-14

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
Command

SET
{ DEFINE)

Entity

Keyword/Argument

See Chapter 7 for all
applicable parameters
and values.

JNODE nOdeid
) KNOWN .N9D~S(

~EXECUTOR

Arguments:
There is one additional parameter specific to X.2S:
SUBADDRESSES range
Previously defined (see destination-options for SET MODULE
X25-SERVER).
The
subaddresses parameter distinguishes
between calls destined for routing and calls destined for
users.
<

'..

All DECnet nodes in which Routing will use X.25 circuits must
the SUBADDRESSES parameter.
Command

SET
{ DEFINE)

include

Entity

Keyword/Argument

LINE lineid

Specific to LAPB (X.25 lines):

(HOLDBACK TIMER seconds
)MAXIMUM BLOCK byte-count
)MAXIMUM RETRANSMITS block-count
~MAXIMUM WINDOW block-count
Common to DDCMP and
LAPB (X. 25) 1 i nes :
CLOCK clock-mode
CONTROLLER controller-mode
COUNTER TIMER seconds
DEVICE deviceid
DUPLEX duplex-mode
PROTOCOL protocol-name
RETRANSMIT TIMER mi 11 isec::onds
SERVICE service-control
STATE line-state
Arguments:

With the 'exception of PROTOCOL, keywords and arguments common to
DOCMP and LAPB lines are adequately defined in the previous
chapter.
For PROTOCOL, the protocol name for lines using X.25
protocol must be LAPB.
HOLDBACK TIMER seconds
The value you enter for seconds determines the length of
time an acknowledgement is held back to wait for a data
messag"e with which it can be included."
If you do not
specify 'a value,' there is no wait.
(This argument: is not
implemented for TOPS-1m PSI.)
MAXIMUM BLOCK byte-count
The value you enter determines the data link maximum byte
count of the block size on the line. Byte count must be an
integer in the range 1-65535.

8-15

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
MAXIMUM RETRANSMITS block-count
The value you enter in block-count determines the data link
maximum number of retransmissions of a block on the line.
Block-count must be an integer in the range 1-255.
If you
do not set a value, there is no maximum.
MAXIMUM WINDOW block-count
The value you enter for block-count determines the maximum
number of unacknowledged transmitted blocks permitted on a
line. Block-count must be an integer In the range 1-255.
Example:
NCP>TELL DNX25 SET LINE KDP-I-I MAXIMUM RETRANSMITS 21
Command

Entity

Keyword/Argument

SHOW}
{LIST

MODULE module-name

Specific to named
module; see "Arguments:"
for keywords and values
of each module name.

ACTIVE MODULES
KNOWN MODULES

CHARACTERISTICSI
COUNTERS
STATUS
SUMMARY

Function:
The SHOW command displays information from the volatile data
base; the LIST command displays information from a permanent data
base.
Arguments:
Arguments for the entities ACTIVE MODULES and KNOWN MODULES
defined in Section 7.7. Arguments for named modules are:
Entity
MODULE X25-ACCESS

MODULE X25-PROTOCOL

MODULE X25-SERVER

are

Keyword/Argument

CHARACTERISTICSI [KNOWN NETWORKS]
COUNTERS
[NETWORKS network-name]
STATUS
SUMMARY

CHARACTERISTIcSI [DTE dte-address]
COUNTERS
[KNOWN DTES]
STATUS
[GROUP group-name]
SUMMARY
[KNOWN GROUPS]

CHARACTERISTICSI [KNOWN DESTINATIONS]
COUNTERS
[DESTINATION destination-name]
STATUS
SUMMARY

All X.25-specific parameters for
defined in this chapter.

8-16

named

modules

are

previously

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
Examples:
NCP>SHOW MODULE X25-ACCESS CHARACTERISTICS KNOWN NETWORKS<RET>
NCP>
15:01:11
NCP
Request # 3, Show Module Characteristics Completed
Module = X25-ACCESS
Network = TELENET
Node = 7.129 (MRX25)
Password = X25-GATE
NCP>SET EXECTOR NODE MRX25<RET>
NCP>
15:01:24
NCP
Set Executor Complete
NCP>SHOW MODULE X25-PROTOCOL CHARACTERISTICS KNONW DTES<RET>
15:05:24
NCP
Request # 6 Accepted
NCP>
15:~5:25
NCP
Request # 6, Show Module Characteristics Completed
Module = X25-PROTOCOL
DTE = 311930300179
Line = KDP-0-0
Channels = 29-1
Maximum Channels = 20
NCP>SHOW MODULE X25-PROTOCOL CHARACTERISTICS(RET>
NCP>
15:05:35
NCP
Request # 7 Accepted
NCP>
15:05:35
NCP
Request # 71 Show Module Characteristics Completed
Module = X25-PROTOCOL
Network = TELENET
Default Data = 128
Default Window = 2
Maximum Data = 256
Maximum Window
2
Maximum Clears
6
Maximum Resets = 6
Maximum Restarts = 6
Call Timer = 180
Clear Timer = 180
Reset Timer = 180
Restart Timer = 180
NCP>SHOW MODULE X25-PROTOCOL COUNTEERS KNOWN DTES(RET>
NCP>
15:14:17
NCP
Request # 24 Accepted

8-17

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
NCP>
15:14:18
NCP
Request # 24; Show Module Characteristics Completed
Module = X25-PROTOCOL
DTE = 311~617~~~84
Seconds Since Last Zeroed
25783
Bytes Received
872951
Bytes Sent
17029
Data Blocks Received
28397
Data Blocks Sent
69
Calls Received
23
Calls Sent
~
Fast Selects Received
~
Fast Selects Sent
12
Maximum Switched Circuits Active
4
Maximum Channels Active
~
Received Call Resource Errors
8
Locally Initiated Resets
2
Network Initiated Resets
9
Remotely Initiated Resets
1
Restarts
~

NCP>SHOW MODULE X25-SERVER CHARACTERISTICS KNOWN DESTINATION(RET>
NCP>
15:16:12
NCP
Request i 25 Accepted
NCP>
15:16:15
NCP
Request # 25; Show Module Characteristics Completed
Module = X25-SERVER
Destination = X29
Node = 129
Object = 34 ()
Priority = 5
Call Mask = FF
Call Value = 91
Destination = KL2l37
Node = KL2137
Obj ect = 34 ()
Priority = 1
Call Mask = 91
Call Value = 91
Destination = X25
Node.= 129
Object = 9 (X25TST)
Priority = 9
Subaddresses = 1
NCP>SHOW MODULE X25-SERVER COUNTERS<RET>
NCP>
15:16:37·
NCP
Request , 26 Accepted
NCP>
15:16:37
NCP
Request , 26; Show Module Counters Completed
Module = X25-SERVER
9

12
9

Seconds Since Last Zeroed
Maximum Circuits Active
Incoming Calls Rejected, No Resources
Logical Links Rejected, No Resources
8-18

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
Command

Entity

Keyword/Argument

ZERO

MODULE X25-SERVER
KNOWN MODULES
MODULE X25-PROTOCOL

[COUNTERS]
COUNTERS [KNOWN DTES]
[DTE dte-address]

Function:
The zero command used with the module entity generates a counters
zeroed event that causes counters to be logged and then zeroed.
The counters zeroed are those the executor node supports for the
entity that you specified, and possibly qualified,
in the
command.
Ar:guments:
All arguments previously defined in this chapter.
Remarks:
The command ZERO MODULE X25-PROTOCOL COUNTERS can be used only if
there is no more than one DTE address on the executor node.
If
there is more than one DTE address, use the qualifier DTE
dte-address, that is,
ZERO MODULE X25-PROTOCOL COUNTERS DTE
dte-address. You can also use the command in the form ZERO
MODULE X25-PROTOCOL COUNTERS KNOWN DTES.
Examples:
NCP)SET EXECUTOR NODE MRX25
NCP)ZERO MODULE X25-SERVER COUNTERS
NCP)ZERO MODULE X25-PROTOCOL COUNTER KNOW DTES
Command

Entity

CLEAR}
{ PURGE

CIRCUIT cktid }
{ KNOWN CIRCUITS

Keyword/Argument
MAXIMUM RECALLS}
{ RECALL TIMER

Function:
All CLEAR and PURGE commands clear parameters from
and permanent data bases respectively.

the

Arguments:
No arguments specific to X.25.

See Section 7.6

Example:
NCP)CLEAR CIRCUIT KDP-9-1 RECALL TIMER
{CLEAR}
PURGE

{LINE
KNOWN lineid}
LINES

!ALL
COUNTER TIMER
HOLDBACK TIMER
MAXIMUM RETRANSMITS

8-19

volatile

NETWORK MANAGEMENT PACKET SWITCHING INTERFACE
Arguments:
ALL and COUNTER TIMER: see Section 7.6.
HOLDBACK TIMER and
MAXIMUM RETRANSMITS are X.25-specific and previously defined
under SET LINE lineid in this chapter.
Example:
NCP>TELL MRX25 CLEAR LINE KDP-S-S MAXIMUM RETRANSMITS
CLEAR}
{ PURGE

ALL network-qualifier~
network-options
(
network
qualifier
J
I

MODULE X25-ACCESS

Arguments:
network-options
May be one or more of:
All arguments are
X25-ACCESS.

previously

ACCOUNT, PASSWORD, USER.

defined.

See

SET/DEFINE

for

MODULE

Example:
NCP>CLEAR MODULE X25-ACCESS PASSWORD NETWORK TELENET
CLEAR}
{ PURGE

ALL dte-qualifier
group-qualifier
GROUP group-name
group-options
CAl..L TIMER
CLEAR TIMER
MAXIMUM CLEARS
MAXIMUM RESETS
MAXIMUM RESTARTS
RESET TIMER
dte-options dte-qualifier

MODULE X25-PROTOCOL

Arguments:
All arguments previously defined in this chapter.
for MODULE X25-PROTOCOL.

See SET/DEFINE

Example:
NCP>TELL MRX25 CLEAR MODULE X25-PROTOCOL MAXIMUM CLEARS
CLEAR"}
{ PURGE

MODULE X25-SERVER

(ALL destination-qualifier\
)COUNTER TIMER seconds
)destination-options
destination-qualifier

Arguments:
Previously defined
X25-SERVER.

this

chapter.

See

SET/DEFINE

Example:
NCP>TELL MRX25 CLEAR MODULE X25-SERVER SUBADDR DEST KL2137

8-2'"

MODULE

APPENDIX A
DECnet PARAMETER SUMMARY

A-I

DECnet PARAMETER SUMMARY
Table A-I:

Node Parameters
Digital Network Architecture

Paramo
Type No.
0

10
100
101

NCP Keywords

Applicability

STATE
o ON (Executor)
1 OFF(Executor)
2 SHUT(Executor)
3 RESTRICTED
(Executor)
4 REACHABLE
(Remote)
5 UNREACHABLE
(Remote)
PHYSICAL ADDRESS

All nodes except
Loop nodes

141

150

LOOP COUNT

Adjacent and
set only
EXECUTOR only
EXECUTOR only

151

LOOP LENGTH

EXECUTOR only

152

LOOP WITH
o zeroes
1 ones
2 mixed
LOOP ASSISTANT
PHYSICAL ADDRESS
LOOP HELP
o transmit
1 receive
2 full

EXECUTOR only

114
115

120
121
122
123
125

126
130
131
135
136
140

153
154

Restrictions

Ethernet loop
nodes only
EXECUTOR only
EXECUTOR only

IDENTIFICATION
MANAGEMENT VERSION
Version Number
ECO Number
User ECO Number
SERVICE CIRCUIT
SERVICE PASSWORD
SERVICE DEVICE
CPU
o PDP-8
1 PDP-ll
2 DECSYSTEM-1020
3 VAX
HARDWARE ADDRESS
SERVICE NODE VERSION
o phase III
1 phase IV
LOAD FILE
SECONDARY LOADER
TERTIARY LOADER
DIAGNOSTIC FILE
SOFTWARE TYPE
o SECONDARY LOADER
1 TERTIARY LOADER
2 SYSTEM
SOFTWARE IDENTIFICATION
DUMP FILE
SECONDARY DUMPER
DUMP ADDRESS
DUMP COUNT
HOST
Node address
Node name (if any)
HOST

110
111
112
113

DECnet-1 0 V 4.0 Implementation

Display only

TOPS-tO

MCB

Restrictions

Can not. be set
Can be displayed

X
X

X
X
X
X
X

Adjacent only
Adjacent only

X
X
X
X
X
X
X
X
X
X

Adjacent only
Adjacent only
Adjacent only
Adjacent only
Adjacent only

X
X
X
X'.
X

X
X
X
X

X
X

Can be set, displayed
as parameter #140

Used with LOOP
command only
Used with LOOP
command only
Used with LOOP
command only

Used with LOOP
command only
Used with LOOP
command only

Display only

Adjacent only
Adjacent only
Adjacent only
Adjacent only

Adjacent only
Adjacent only
Adjacent only
Adjacent only
Adjacent only
Adjacent and
EXECUTOR only

Display only

EXECUTOR only
EXECUTOR only

A-2

Can not be set
Can be displayed

Not implemented

DECnet PARAMETER SUMMARY
Table A-I:

Node Parameters (Cont.)
Digital Network Architecture

DECnet- 10 V4.0 Implementation

Paramo
Type No.

NCP Keywords

Applicability

Restrictions

155

LOOP NODE

EXECUTOR only

156

LOOP ASSISTANT NODE

EXECUTOR only

Used with LOOP
command only
Used with LOOP
command only

All nodes except
loop nodes
All nodes except
loop nodes

160

COUNTER TIMER

500

NAME

501

CIRCUIT

502

ADDRESS

510
511
600

INCOMING TIMER
OUTGOING TIMER
ACTIVE LINKS

601

DELAY

700

NSP VERSION
Version Number
ECO Number
User ECO Number
MAXIMUM LINKS

710
720
721
722
723
810

820

DELAY FACTOR
DELAY WEIGHT
INACTIVITY TIMER
RETRANSMIT FACTOR
TYPE
o ROUTING III
1 NONROUTING III
3 AREA
4 ROUTING IV
5 NONROUTING IV
COST

821

HOPS

822

CIRCUIT

830

NEXT NODE
Node address
Node name (if any)
ROUTING VERSION
Version Number
ECO Number
User ECO Number
TYPE
o ROUTING III
1 NONROUTING III
3 AREA
. 4 ROUTING IV
5 NONROUTING IV
ROUTING TIMER
SUBADDRESSES
Range beginning
Range end
BROADCAST ROUTING
TIMER
MAXIMUM ADDRESS
MAXIMUM CIRCUITS

900

901

910
911

912
920
921

TOP8-10

MCB

X
X

Special format

Display only

X
X
X

Display only

EXECUTOR only

EXECUTOR only
EXECUTOR only
EXECUTOR only
EXECUTOR only
Adjacent only

Display only

X
X
X
X
X

Display only

EXECUTOR only

EXECUTOR only
EXECUTOR only
X.25 only

X
X

EXECUTOR only

X
X
X
X

Special format

Loop nodes and
nodes by name
only
EXECUTOR only

EXECUTOR only
EXECUTOR only
All nodes except
loop nodes
All nodes except
EXECUTOR and
loop
EXECUTOR only

All nodes except
EXECUTOR and
loop
All nodes except
EXECUTOR and
loop
All nodes except
EXECUTOR and
loop
All nodes except
EXECUTOR and
loop
EXECUTOR only

EXECUTOR only
EXECUTOR only

A-3

Restrictions

X
X

Can not be set for
EXECUTOR, can be
set for other nodes.
Will be displayed
in node-id

Can not be set
Displayed in
node-id

Can not be set
Can be displayed

Can not be set in
MCB
Can be displayed
Can not be set in
MCB
Can be displayed
Can not be set in
MCB
Can be displayed

Can not be set
Can be displayed

Can not be set
inMCB

DECnet PARAMETER SUMMARY
Table A-I:

Node Parameters (Cont.)
Digital Network Architecture

Paramo
Type No.

NCP Keywords

Applicability
EXECUTOR only
EXECUTOR only
EXECUTOR only
EXECUTOR only
EXECUTOR only

928
929
930

MAXIMUM COST
MAXIMUM HOPS
MAXIMUM VISITS
MAXIMUM AREA
MAXIMUM BROADCAST
NONROUTERS
MAXIMUM BROADCAST
ROUTERS
AREA MAXIMUM COST
AREA MAXIMUM HOPS
MAXIMUM BUFFERS

931

932

922
923
924
925
926
927

DECnet-lO V 4.0 Implementation
Restrictions

TOPS-IO

MCB

X
X
X

X
X
X
Not implemented

EXECUTOR only
EXECUTOR only
EXECUTOR only

X
X
X
X
X
X
X

BUFFER SIZE

EXECUTOR only

SEGMENT BUFFER SIZE

EXECUTOR only

Table A-2:

EXECUTOR only

DECnet-11 Specific Node Parameters
Paramo
Type No.

Restrictions

NCP Keywords

Applicability

TOPS-IO

2511

CONSOLE SECONDARY
LOADER

Adjacent
Ethernet
Communications
Servers only

2512

CONSOLE LOAD
FILE

Adjacent
Ethernet
Communications
Servers only

A-4

MCB

Can not be set in
MCB
Can be displayed
Can not be set in
MCB
Can be displayed
Can not be set
Can be displayed

DECnet PARAMETER SUMMARY
Table A-3:

Line Parameters
Digital Network Architecture

Paramo
Type No.
0

100

110
1100
1105
1110

1111
1112

1113

NCP Keywords

Applicability

STATE
OON
1 OFF
2 SERVICE
3 CLEARED
Subs tate (not a keyword)
o STARTING
1 REFLECTING
2 LOOPING
3 LOADING
4 DUMPING
5 TRIGGERING
6 AUTOSERVICE
7 AUTOLOADING
8 AUTODUMPING
9 AUTOTRIGGERING
10 SYNCHRONIZING
11 FAILED
SERVICE
o ENABLED
1 DISABLED
COUNTER TIMER
DEVICE
RECEIVE BUFFERS

All lines

CONTROLLER
o NORMAL
1 LOOPBACK
DUPLEX
PROTOCOL
o DDCMP POINT
1 DDCMP CONTROL
2 DDCMP TRIBUTARY
3 (reserved)
4DDCMPDMC
5 LAPB
6 ETHERNET
7 CI
8 QP2 (DTE20)

1120

CLOCK
o EXTERNAL
1 INTERNAL
SERVICE TIMER

1121
1122
1130
1131
1132

RETRANSMIT TIMER
HOLD BACK TIMER
MAXIMUM BLOCK
MAXIMUM RETRANSMITS
MAXIMUM WINDOW

1150
1151
1152
1153
1160

SCHEDULING TIMER
DEAD TIMER
DELAY TIMER
STREAM TIMER
HARDWARE ADDRESS

All lines

DECnet-lOV4.0 Implementation
Restrictions

Display only

TOPS-lO

MCn

Restrictions

Code 2 in MCB
display only

DDCMP lines
only

All circuits

DDCMP lines

X
X

All lines

ALLDDCMP
lines

All lines

X.25 only

Ethernet lines
only

Display only

A-S

Can not be set
Can be displayed
Can not be set
Can be displayed

Can not be set
Can be displayed

Can not be set
displayed for KDP
lines only. * (state om
Parameter value
must be in
multiples of seconds
Not for DTE

Can not be set
Can be displayed

DECnet PARAMETER SUMMARY
Table A-4:

DECnet-10 Specific Line Parameters
Paramo
Type No.

NCP
Keywords

2500

RECEIVE
BUFFER SIZE

2650

CONTROLLER
REGISTER

DTE only
Can be displayed

2651

UNIT REGISTER

All line devices
except KDP

2655

INTERRUPT
VECTOR

All line devices
except KDP
Can be displayed

2660

INTERRUPT
PRIORITY

All line devices
except KDP
Can be displayed

2670

PAUSE TIMER

DTE only
Can be displayed

TOP8-IO MCB
X

Restrictions
CI and NI only
Can be displayed

None of the DECnet-lO specific line parameters can be set by the user.

Table A-S:

Circuit Parameters
Digital Network Architecture

Paramo
Type No.
0

100

110
120
121

200
201

NCP Keywords

Applicability

STATE
OON
I OFF
2 SERVICE
3 CLEARED
substate (not a keyword)
o STARTING
1 REFLECTING
2 LOOPING
3 LOADING
4 DUMPING
5 TRIGGERING
6 AUTOSERVICE
7 AUTOLOADING
8 AUTODUMPING
9 AUTOTRIGGERING
10 SYNCHRONIZING
11 FAILED
SERVICE
o ENABLED
1 DISABLED
COUNTER TIMER
SERVICE PHYSICAL
ADDRESS
SERVICE SUBSTATE
o STARTING
I REFLECTING
2 LOOPING
3 LOADING
4 DUMPING
5 TRIGGERING
6 AUTOSERVICE
7 AUTOLOADING
8 AUTODUMPING
9 AUTOTRIGGERING
10 SYNCHRONIZING
11 FAILED
CONNECTED NODE
Node address
Node name (if any)
CONNECTED OBJECT
Object number
Object name

All circuits

DECnet-lOV4.0 Implementation
Restrictions

TOPS-IO

MCB

Restrictions

Code 2 in MCB

Code 3 not
implemented

X
X

Display only

All circuits

Display only

All circuits used
for service
All circuits
Ethernet
Circuits only

Display only
Display only

X.25

Display only

A-6

DECnet PARAMETER SUMMARY
Table A-5:

Circuit Parameters (Cont.)
Digital Network Architecture

Paramo
Type No.
400
800

801

810
811
900
901

NCP Keywords
LOOPBACK NAME
ADJACENT NODE
Node address
Node name (if any)
DESIGNATED ROUTER
Node address
Node name (if any)
BLOCK SIZE
ORIGINATING
QUEUE LIMIT
COST
MAXIMUM ROUTERS

902

ROUTER PRIORITY

906
907

HELLO TIMER
LISTEN TIMER

910

BLOCKING
o ENABLED
1 DISABLED
MAXIMUM RECALLS
RECALL TIMER
NUMBER
USER
Entity type
Entity name (if entity
is not node)
Node address (if entity
is not node)
Node name (if entity
is not node)
POLLING STATE
o AUTOMATIC
1 ACTIVE
2 INACTIVE
3 DYING
4 DEAD
Polling substate
o ACTIVE
1 INACTIVE
2 DYING
3 DEAD
OWNER
LINE
USAGE

920
921
930
1000

1010

1011

1100
1110
1111

Applicability

DECnet-l 0 V 4.0 Implementation
Restrictions

TOPS-IO

Display only
Display only

X
X

Display only

MCB

Display only

X
X

Ethernet node
circuits only
Ethernet node
circuits only

X
X

EXECUTOR node
circuits only
X.25 only

X.25 only
X.25 only
X.25 only
EXECUTOR node
circuits only
Node circuits only

Display only

Not implemented

X.25 only

Only USAGE
PERMANENT
is supported.
Can not be set
Can be displayed

o PERMANENT

1120

1 INCOMING
2 OUTGOING
TYPE
o DDCMP POINT
1 DDCMP CONTROL
2 DDCMP TRIBUTARY
3 X25
4DDCMPDMC
5
6 ETHERNET
7 CI
8 QP2 (DTE20)
9 BISYNC
DTE

X.25 only

1121

CHANNEL

X.25 only

1122

MAXIMUM DATA

X.25 only

1123

MAXIMUM WINDOW

X.25 only

1140
1141
1142
1145

TRIBUTARY
BABBLE TIMER
TRANSMIT TIMER
MAXIMUM BUFFERS
1-254 Number of buffers
255 UNLIMITED

1112

Restrictions

Display only

A-7

Can not be set
Can be displayed
Can not be set
Can be displayed
Can not be set
Can be displayed
Can not be set
Can be displayed
Not implemented
Not implemented
Not implemented
Not implemented

DECnet PARAMETER SUMMARY
Table A-5:

Circuit Parameters (Cont.)
DECnet-l OV4.0 Implementation

Digital Network Architecture
Paramo
Type No.

NCP Keywords

1146
1150
1151
1152
1153
1154
1155
1156
1157
1158

MAXIMUM TRANSMITS
ACTIVE BASE
ACTIVE INCREMENT
INACTIVE BASE
INACTIVE INCREMENT
INACTIVE THRESHOLD
DYING BASE
DYING INCREMENT
DYING THRESHOLD
DEAD THRESHOLD

Table A-6:

Applicability

Restrictions

MCB

Restrictions
Not implemented
Not implemented
Not implemented
Not implemented
Not implemented
Not implemented
Not Implemented
Not implemented
Not implemented
Not implemented

Logging Parameters
DECnet-lOV4.0 Implementation

Digital Network Architecture
Paramo
Type No.

TOPS-IO

NCP Keywords

Applicability

STATE
OON
1 OFF
2 HOLD

The EXECUTOR
node's logging
state for the
specified logging
sink.

Implemented for
logging file only.

100

NAME

The specific sink
specified by the
EXECUTOR as
the event-receiver:
device name, file
name, or process
identification for
the sink types
CONSOLE, FILE,
and MONITOR.

For MONITOR
only

200

SINK NODE
Node address
Node name (if any)

The node that
the EXECUTOR
specifies as the
event-receiver

201

EVENTS
Entity type
-1 no entity
o node
1 line
3 circuit
4 module
5 area
Node address
(if entity type is node)
Node name
(if entity type is node)
Identification
Oineid or cktid as
indicated by entity type)
Entity class
o single class
2 all events for class
3 KNOWN EVENTS
Event class
(if entity class is 0 or 2)
Event mask
(if entity class is 0)

The events at the
source node to
be recorded at the
SINK NODE.

Restrictions

A-a

TOPS-IO

MCB

Restrictions

DECnet PARAMETER SUMMARY
Table A-7:

Event Parameters

Network Management Layer Parameters - Class 0

Session Control Layer Event Parameters - Clas. 2 (Cont.)

Type

Keywords

Type

Keywords

SERVICE
o LOAD
1 DUMP
STATUS
Return code
o REQUESTED
>0 SUCCESSFUL
<0 FAILED
Error detail (if error)
Error message (optional)
OPERATION
o INITIATED
1 TERMINATED
REASON
o Receive timeout
1 Receive error
2 Line state change by higher level
3 Unrecognized request
4 Line open error
Qualifier
Parameter type
Id string
NODE
Node address
Node name (if any)
DTE
Filespec
SOFTWARE TYPE
o SECONDARY LOADER
1 TERTIARY LOADER
3 SYSTEM

NEW STATE
OON
1 OFF
2 SHUT
3 RESTRICTED
SOURCE NODE
Node address
Node name (If any)
SOURCE PROCESS
Object type
Group code
User code
Process name
DESTINATION PROCESS
(same as for SOURCE PROCESS)
USER
PASSWORD
(0 means password set;
no parameter means not set)
ACCOUNT

6
7
8

3
4

5
6
7

Network Services Layer Event Parameters - Class 3
Type

Keywords

MESSAGE
Message flags
Destination link addr(lss
Source link address
Data
CURRENT FLOW CONTROL REQUEST COUNT
o No flow control
1 Segment flow control
2 Message flow control
SOURCE NODE
Node address
Node name (if any)

Session Control Layer Event Parameters - Class 2
Type

Keywords

REASON
o Operator command
1 Normal operation
OLD STATE
OON
1 OFF
2 SHUT
3 RESTRICTED

DECnet PARAMETER SUMMARY
Table A-7:

Event Parameters (Cont.)

Transport Layer Event Parameters - Class 4

Diita Link Layer Event Parameters - Class 5

Type

Keywords

Type

Keywords

PACKET HEADER (non-Ethernet)
Message flags
Destination node address (not for control
packet)
Source node address
Visit count (not for control packet)
PACKET (Ethernet)
Message flags
Destination area
Destination subarea
Destination Ethernet address
Source area
Source subarea
Source Ethernet address
Next area router
Visit count
Service class
Protocol type
PACKET BEGINNING
HIGHEST ADDRESS
NODE
Node address
Node name (if any)
EXPECTED NODE
Node address
Node name (if any)
REASON
o Circuit synchronization lost
1 Data errors
2 Unexpected packet type
3 Routing update checksum error
4 Adjacent node address change
5 Verification receive timeout
6 Version skew
7 Adjacent node address out of range
8 Adjacent node block size too small
9 Invalid verification seed value
10 Adjacent node listener receive

OLD STATE
o HALTED
IISTRT
2 ASTRT
3 RUNNING
4 MAINTENANCE
NEW STATE
o HALTED
1 ISTRT
2 ASTRT
3 RUNNING
4 MAINTENANCE
HEADER
SELECTED TRIBUTARY
PREVIOUS TRIBUTARY
TRIBUTARY STATUS
o Streaming
1 Continued send after timeout
2 Continued send after deselect
3 Ended Streaming
RECEIVED TRIBUTARY
BLOCK LENGTH
BUFFER LENGTH
DTE
REASON
o Operator command
1 Normal operation
OLD STATE (for event 5.12)
OON
1 OFF
2 SHUT
NEW STATE (for event 5.12)
OON
1 OFF
2 SHUT
PARAMETER TYPE
CAUSE
DIAGNOSTIC
FAILURE REASON
o Excessive collisions
1 Carrier check failed
2 (obsolete)
3 Short circuit
4 Open circuit
5 Frame too long
6 Remote failure to defer
7 Block check error
8 Framing error
9 Data overrun
10 System buffer unavailable
11 User buffer unavailable
12 Unrecognized frame destination
DISTANCE
ETHERNET HEADER
Destination address
Source address
Protocol type
HARDWARE ADDRESS

1
2
3

11 Adjacent node listener received
invalid data
12 Call failed
13 Verification password required from
Phase III node
14 Dropped by adjacent node
RECEIVED VERSION
Version number
ECO number
User ECO number
STATUS
o REACHABLE
1 UNREACHABLE
ADJACENT NODE
Node address
Node name (if any)

2
3
4
5

6
7
8
9
10

13
14
15
16

17
18

Physical Line Layer Parameters - Class 6
Type

Keywords

0
1

DEVICE REGISTER
NEW STATE
o OFF
ION

A-l~

DECnet PARAMETER SUMMARY
Module X25-ACCESS Parameters

Table A-8:

Digital Network Architecture
Parameter
Number

DECnet-1 OV 4.0 Implementation

NCP Keywords

Applicability

320

NODE
Node address
Node name (if any)

Qualified parameter

330

USER

Qualified parameter

Unused in TOPS-lO

331

PASSWORD (to set)
(0 means password
set; no parameter
means not set)

Qualified parameter

Set only

Can be displayed
in TOPS-10

331

PASSWORD (to read)
(0 means password
set; no parameter
means not set)

Qualified parameter

Display only

332

ACCOUNT

Qualified parameter

Unused in TOPS-10

1110

NETWORK

Qualifying parameter

Table A-9:

Restrictions

Module X25-PROTOCOL Parameters
Digital Network Architecture

Parameter
Number

TOPS-IO MCB

DECnet-IO V4.0 Implementation

NCP Keywords

Applicability

STATE
OON
1 OFF
2 SHUT

Qualified by DTE

Restrictions

Substate (not a keyword)
o Running
1 Sync
2 Unsync

100

COUNTER TIMER

Qualified by DTE

1000

ACTIVE CHANNELS

Qualified by DTE

Display only
Display only

TOPS-IO MCB

Restrictions

Display only

Non-qualified
parameter in MCB

1010

ACTIVE SWITCHED

Qualified by DTE

1100

DTE

Qualifying parameter

1101

GROUP

Qualifying parameter

1110

NETWORK

X
Display only in MCB

Display only in MCB

1120

LINE

Qualified by DTE

Display only in MCB

1130

CHANNELS
range beginning
range end (none if
same as beginning)

Qualified by DTE

'" (state om

1131

MAXIMUM CHANNELS

Qualified by DTE

1132

MAXIMUM CIRCUITS

Qualified by DTE

Display only

1140

DEFAULT DATA

1141

DEFAULT WINDOW

1150

MAXIMUM DATA

1151

MAXIMUM WINDOW

1152

MAXIMUM CLEARS

1153

MAXIMUM RESETS

1154

MAXIMUM RESTARTS

A-Il

DECnet PARAMETER SUMMARY
Table A-9 Module X2S-PROTOCOL Parameters (Cont.)
Digital Network Architecture

DECnet·lOV4.0 Implementation

Parameter
Number

NCP Keywords

1160

CALL TIMER

1161

CLEAR TIMER

Applicability

Restrictions

TOPS-to MCB

1162

RESET TIMER

1163

RESTART TIMER

1170

DTE

Qualified by GROUP

1171

NUMBER

Qualified by GROUP

1172

TYPE
1 BILATERAL

Qualified by GROUP

Restrictions

* Some DTE parameters can be set only when the DTE is off.

Module X2S-SERVER Parameters

Table A-I":

DECnet-lOV4.0 Implementation

Digital Network Architecture
Parameter
Number

NCP Keywords

Applicability

Restrictions

TOPS-lO MCB

Restrictions

100

COUNTER TIMER

200

ACTIVE CIRCUITS

300

DESTINATION

310

MAXIMUM CIRCUITS

320

NODE
Node address
Node name (if any)

Qualified parameter

330

USER user

Qualified parameter

331

PASSWORD (to set)
o Password set

Qualified parameter

Set only

331

PASSWORD (to read)
o Password set

Qualified parameter

Display only

332

ACCOUNT

Qualified parameter

340

OBJECT
object number
object name

Qualified parameter

350

PRIORITY

Qualified parameter

351

CALL MASK

Qualified parameter

352

CALL VALUE

Qualified parameter

353

GROUP

Qualified parameter

354

NUMBER

Qualified parameter

355

SUBADDRESSES
Range beginning
Range end
(none if same
as beginning)

Qualified parameter

Display only
Qualifying parameter

X
X
X

A-12

Display only in MCB

APPENDIX B
COUNTER SUMMARY

This appendi~ contains the-entity counters that may be zeroed or
displayed by the appropriate NCP commands (ZERO and SHOW). Section
B.l lists DECnet-19 specific: counters, and Section B.2 lists DECnet-lB
PSI specific 60~riters; Secticin B.3 describes all counters in textual
detail.

B.l

DECnet COUNTER SUMMARY

This counter summary is spedific to DECnet-lB version 4.B.
See the
appropriate documentation for other DIGITAL operating systems for
counter text displ~yed and counters zeroed.
Table B-1:

DECnet-10 Specific Counters

ALL COUNTERS (NODE, LINE, -AND CIRCUIT)
Mainta ined -B~'

Counter Text

Network

Seconds since last zeroed

Manag~ment

NODE COUNTERS
Maintained By

Counter Text

Network Services

Bytes received
Bytes sent
Messages received
Messages sent
Connects received
Connects sent
Response timeouts
Received connect resource errors

Routing
(Executor node only)

Aged packet loss
Node unreachable packet loss
Node out-of-range packet loss
Oversized packet loss
Packet format errors
Partial routing update loss
Verification reject

B-1

COUNTER SUMMARY
Table 8-1:

DECnet-l~

Specific Counters (Cont.)

LINE COUNTERS (for Mca lines)
Maintained By

Counter Text

Physical Link

Remote Process Errors
Local Process Errors

CIRCUIT COUNTERS

8.2

Maintained By

Counter Text

Routing

Terminating Packets Received
Originating Packets Sent
Terminating Congestion Loss
Transit Packets Received
Transit Packets Sent
Transit Congestion Loss
Circuit Downs
Initialization Failures
Bytes Received
Bytes Sent
Data Blocks Received
Data Blocks Sent

Data Link

Data Error Inbound, including:
NAKs Sent, Header Block Check Error
NAKs Sent, REP Response
Data Errors Outbound
Remote Reply Timeouts
Local Reply Timeouts
Remote Buffer Errors
Local Buffer Errors
Selection Intervals Elapsed
Selection Timeouts

X.2S SPECIFIC COUNTERS

The following tab1es describe
Version 1.9 software option.

X.2S

specific

The following table specifies the Data Link
permanent X.2S circuits.
Table 8-2:

counte~s

counters

for

the

PSI

that

apply

Data Link Circuit Counters for Permanent X.2S Circuits

Type
Number

Bit
Width

Standard Text

9
1000
1901
1010
1011
1240
1241
1242

16
32
32
32
32
8
8
8

Seconds since last zeroed
Bytes received
Bytes sent
Data blocks received
Data blocks sent
Locally initiated resets
Remotely initiated resets
Network initiated resets
B-2

COUNTER SUMMARY
The following table specifies the Data Link counters for LAPB lines.
Table B-3:

Data Link Line Counters for LAPB Lines

Type
Number

Bit
Width

Standard Text

~
1~~~
1~~1
l~l~
l~ll

16
32
32
32
32

1~2~

Seconds since last zeroed
Bytes received
Bytes sent
Data blocks received
Data blocks sent
Data errors inbound

1~21
1~3~
1~3l
1~4~

8
8
8
8

Data errors outbound
Remote reply timeouts
Local reply timeouts
Remote buffer errors

1~4l

Local buffer errors

ll~~

Remote process errors

ll~l

Local process error

The following table specifies
counters.
Table B-4:

the

Bit Number
Standard Text

X.25

3 Block too long
4 Block check error
5 REJ sent
3 REJ received
2 RNR received,
buffer
unavailable
2 RNR sent,
buffer
unavailable
4 Inval,id N (R)
received
5 FRMR sent,
header format
error
2 Transmit underrun
4 Receive overrun
5 FRMR received,
head format error

protocol

module

X.25 Protocol Module Counters

Type
Number

Bit
Width

Standard Text

~
1~~~
1~~1
1~1~
1~11
l2~~
12~1
121~

1241
1242

16
32
32
32
32
16
16
16
16
16
16
16
8
8
8

125~

Seconds since last zeroed
Bytes received
Bytes sent
Data blocks received
Data blocks s~nt
Calls received
Calls sent
Fast selects received
Fast selects sent
Maximum switched circuits active
Maximum channels active
Received call resource errors
Locally initiated resets
Remotely initiated resets
Network initiated resets
Restarts

1211
122~

1221
123~
124~

B-3

local

DTE

COUNTER SUMMARY
The following table specifies the X.25 server module counters.
Table 8-5:
Type
Number
0

20m
210

211

B.3

X.25 Server Module Counters
Bit
Width
16
16

8
8

Standard Text
Seconds since last zeroed
Maximum circuits active
Incoming calls rejected, no resources
Logical links rejected, no resources

COUNTER DESCRIPTIONS

Counters are listed in the same order that they appear in the NCP SHOW
command.

B.3.l

Circuit Counters

This section contains a description of each
circuit
counter.
(Includes the data link circuit counters for permanent X.2S circuits
and counters for Ethernet and PSI operations.)
Seconds since last zeroed
This counter indicates the number of seconds that elapsed since
the circuit counters were zeroed. This counter provides a time
frame for other counter values.
The software increments this
counter every second and clears it when other counters are
cleared. Applies also to MCB PSI operations.
Terminating packets received
This counter indicates the number of data packets received by the
Routing layer on the local node.
Originating packets sent
This counter indicates the number of data
Routing layer on the local node.

packets

sent

the

Terminating congestion loss
This counter indicates the number of packets intended for the
node that were discarded because Routing could not buffer them.
Transit packets received
This counter indicates the number of data packets received over
the circuit and to be routed through the local node to another
node. It is maintained only on full-routing nodes.
Transit packets sent
This counter indicates the number of data packets sent over the
circuit and being routed through the local node to another node.
It is maintained only on full-routing nodes.
B-4

COUNTER SUMMARY
Transit congestion loss
This counter indicates the number of transit data packets
discarded for congestion reasons.
This counter is maintained
only on full-routing nodes.
If congestion loss increases,
increase the MAXIMUM BUFFERS parameter for the local node.
Circuit downs
This counter indicates
software induced - for
any number of hardware-,
This counter corresponds

the number of failures - operator or
the circuit. These failures may include
software-, or operator-caused problems.
to events 4.7-9 (circuit down).

Initialization failures
This counter indicates the number of times the circuit failed to
initialize with remote Routing software.
These failures may
include any number of hardware-, software-, or operator-caused
problems.
This
counter
corresponds
to
events
4.11-13
(initialization failure).
Transmit packets discarded-b10cksize exceeded
This counter indicates the number of packets discarded by the
local node because the packet was larger than the local node's
buffer size. This occurs when the node has a buffer size that is
greater than 576 bytes for Ethernet communications and the
Ethernet goes down.
The
Router
attempts
to
send
the
"Ethernet-sized" packets through a line with a small buffer size,
forcing the packets to be discarded.
Bytes received
This counter indicates
the local node over
together,with the data
inbound traffic load.

the number of bytes of data received by
the circuit. You can use this information
blocks received counter to determine the
Applies also to MCB PSI operations.

Bytes sent
This counter indicates the number of bytes of data sent by t.he
local node over the circuit.
You can use this information
together with the data blocks sent counter to determine t.he
outbound traffic load. Applies also to MCB PSI operations.
Data blocks received
This counter indicates the number of data blocks received by the
local node.
You can use this information as a statistical be:se
when evaluating the number of inbound data errors, remote reply
timeouts, and local buffer errors. Applies also to TOPS-1~ PSI
operations.
Data blocks sent
This counter indicates the number of data blocks sent by the
local node.
You can use this information as a statistical b~se
when evaluating the number of outbound data errors, local reply
timeouts, and remote buffer errors. Applies also to Ethernet clnd
TOPS-1~ PSI operations.

B-5

COUNTER SUMMARY
Data errors inbound
This counter indicates the number of data errors that normally
result from errors on the inbound communications channel to the
local node.
These errors are caused usually by a
noisy
communications line or a poorly functioning modem. This counter
may include either or both of the following qualifiers if they
contribute to two errors:
o

NAKs sent, header block check error

NAKs sent, data field block check error

User buffer unavailable
This counter indicates the total number of
buffer was available.

times

that

user

This counter indicates the number of resets
circuit. Applies only to MCB PSI operations.

sent

over

the

This counter indicates the number of resets received
circuit. Applies only to MCB PSI operations.

over

the

resets originated by
Applies only to MCB

the
PSI

Locally initiated resets

Remotely initiated resets

Network initiated resets
This counter indicates the number of
PSDN received over the circuit.
operations.

B.3.2

Line Counters

This section contains a description of each line counter.
the PSI data link line and counters for LAPB lines.)

(Includes

Seconds since last zeroed
This counter indicates the number of seconds that elapsed since
the line counters were zeroed.
This counter provides a time
frame for other counter values.
The software increments this
counter every second and clears it when other counters are
cleared.
Blocks sent, initially deferred
This counter indicates the total number of times that a frame
transmission was deferred on its first transmission attempt.
Used in measuring Ethernet contention with no collisions.
Blocks sent, multiple collisions
This counter indicates the total number of times that a frame was
successfully transmitted on the third or later attempt after
normal collisions on previous attempts. Applies only to Ethernet
operations.

B-6

COUNTER SUMMARY
Blocks sent, single collision
This counter indicates the total number of times that a frame was
successfully transmitted on the second attempt after a nornal
collision on the first attempt.
Applies only to Ether1et
operations.
Bytes received
This counter indicates the number of bytes of data received
the line. Applies to Ethernet and MCB PSI operations.

OJer

Bytes sent
This counter indicates the number of bytes of data sent over
line. Applies to Ethernet and MCB PSI operations.

the

Data blocks received
This counter indicates the number of blocks received
line. Applies to Ethernet and MCB PSI operations.

over

the

over

the

Data blocks sent
This counter indicates the number of data blocks sent
line. Applies to Ethernet and MCB PSI operations.
Data errors inbound
This counter indicates the number of incoming data errors that
result from faults on the channel between the local DTE and DeE.
The counter can include up to three of the following qualifiers.
Block too long
Block check erro~
Reject sent
Applies only to MCB PSI operations.
Data errors outbound
This counter indicates the number of outgoing data errors that
result from faults on the channel between the local DTE and m~E.
The counter can include the following qualifier.
Reject received
Applies only to MCB PSI operations.
Data overrun
This counter indicates the total number of times the hardware
lost an incoming frame because it was unable to keep up with the
data rate.
Multicast bytes received
This counter indicates the total number of multicast data bytes
successfully received (includes bytes in Ethernet data field hut
not the Ethernet data link headers).

B-7

COUNTER SUMMARY
Send fa i 1 ures
This counter indicates the total number of times a transmit
attempt failed.
For each increment of the counter, a type of
failure is recorded, as follows:
Excessive collisions
Carrier check failed
Short circuit
Open circuit
Frame too long
Remote failure to defer
Transmit buffer parity (NIA2~)
Carrier detect failed
Applies only to Ethernet operations.
Receive failures
This counter indicates the total number of blocks received with
some data errors (the blocks are data f(ames that passed either
physical or multicast address comparison). For each increment of
the counter, a type of failure is recorded, as follows:
Block check error
Framing error
Frame too long
No free buffers
Free list parity error

(NIA2~)

Applies only to Ethernet operations.
Local reply timeouts
This counter indicates the number of times that a frame with a
poll bit set has been received over the line; that is, the number
of errors that result from faults on the line. Applies only to
MeB PSI operations.
Remote reply timeouts
This counter indicates the number of times that the (etransmit
timer for that line has expired. The retransmit timer can expire
for any of the following reasons:
1.

The line is not connected to a modem

The X.2S network is not responding fast enough

The retransmit timer is set too low

Applies only to MCB PSI operations.
Remote buffer errors
This counter indicates the number of receive-not-ready (RNR)
frames received. The counter can include the following qualifer:
RNR received, buffer unavailable
Applies only to MCB PSI operations.

B-8

COUNTER SUMMARY
Local buffer errors
This counter indicates the number of receive-not-ready (RNR)
frames sent. The counter can include the following qualifier:
RNR sent, buffer unavailable
Applies only to MCB PSI operationa.
Remote process errors
This counter indicates an invalid nCR) and a frame reject (FR~IR)
sent over the line.
The counter can include the follow5.ng
qualifiers:
Invalid nCR) received
FRMR sent, header format error
These errors usually indicate that the DCE is
incorrectly. Applies only to MCB PSI operations.

functionj,ng

Local process errors
This counter indicates that a frame reject (FRMR) has bf!en
received over the line or that your system is being overloadod.
The counter can include the following qualifiers:
Transmit under run
Receive overrun
FRMR received, header format error
The first two qualifiers usually indicate that the system is
overloaded and the third usually indicates that the MCB PSI
software is functioning incorrectly. Applies only to MCB PSI
operations.
Unrecognized frame destination
This counter indicates the number of times a frame was discarded
because there was no portal with the protocol type or multicast
address enabled. The count includes frames received for the
physical address, broadcast address, or multicast address.

B.3.3

Node Counters

This section contains a description of each node counter.
Seconds since last zeroed
This counter indicates the number of seconds that elapsed since
the node counters were zeroed.
It provides a time frame for
other counter values. The software increments this counter ev€!ry
second and clears it when other counters are cleared.
User bytes received
This counter indicates the number of user data bytes received
from a remote node.
This includes interrupt messages, but
excludes Connect, Accept, Reject, and Disconnect messages.

B-9

COUNTER SUMMARY
User bytes sent
This counter indicates the number of user data bytes
remote node.

sent

User messages received
This counter indicates the number of NSP messages
data that were received from a remote node.

carrying

user

carrying

user

User messages sent
This counter indicates the number of NSP messages
data that were sent to a remote node.
Total bytes received
This counter indicates the number of user data bytes received
from a remote node plus the NCP protocol bytes and the overhead
bytes, including Connect, Accept,
Reject,
and
Disconnect
messages.
Total bytes sent
This counter indicates the number of user data bytes sent to a
remote node plus the NSP protocol bytes and the overhead bytes,
including Connect, Accept, Reject, and Disconnect messages.
Total messages received
This counter indicates the
Program) messages received
overhead messages.

number of NSP
from a remote

(Network Services
node including the

Total messages sent
This counter indicates the number of NSP (Network Services
Program) messages sent to a remote node including the overhead
messages.
Connects received
This counter indicates the number of
requests received by the local node.

logical

link

connection

logical

link

connection

Connects sent
This counter indicates the number
requests sent by the local node.

Response timeouts
This counter indicates the number of times there was no response
to an NSP segment within the allotted timeout period. This
implies that the local node has to retransmit messages.
Such
retransmission can be caused either by messages being discarded
in the network or by a wide variance in the round-trip delay to
the node.
Normally, it indicates an overload condition in the
network.

B-10

COUNTER SUMMARY
Received connect resource errors
This counter indicates the number of inbound connect messages f')r
which the local node did not have sufficient resources. The.3e
errors may result from dynamic memory problems or too few logic.:.l
link slots; that is, the MAXIMUM LINKS parameter value is t<>o
small.
Maximum logical links active
This counter indicates the largest number of logical link
have been active since DECnet-19 software was started or
executor counters were zeroed.

th.:.t
sin~e

Aged packet loss
This counter indicates the number of data packets discarded fQr
visiting too many nodes. This usually occurs while the databas'~s
throughout the network are recovering from a disruption (f()r
example, when a circuit or line goes down) in the former path to
a destination. This counter is maintained only on full-routing
nodes and corresponds to event 4.9 (aged packet loss).
Node unreachable packet loss
This counter indicates the number of data packets lost becau::;e
the destination node could not be accessed. This counter is
maintained only on full routing nodes. This counter corresponds
to event 4.1 (node unreachable packet loss).
Node out-of-range packet loss
This counter indicates the number of data packets discardi~d
because the destination node's address is greater than the
maximum address defined for the local node.
This counb~r
corresponds to event 4.2 (node out-of-range packet loss).
Oversized packet loss
This counter indicates the number of received data packets that
were too large to forward because of the block size of the da;::a
link that would be used. This counter is maintained only on
full-routing nodes, and corresponds to event 4.3 (oversizf~d
packet loss).
Packet format error
This counter indicates the number of packet format errors
occur because of invalid packet control information.
counter corresponds to event 4.4 (packet format error).

that
Th:ls

Partial routing update loss
This counter indicates the number of received routing messages
that were too long to process. Part of a routing update may he
lost if it contains a reachable node with an address greater than
the maximum address defined for the local node. This counter ;ls
maintained only on full-routing nodes, and corresponds to event
4.5 (partial routing update loss).
Verification reject
This counter indicates the number of received verificati()n
messages
that were invalid.
It corresponds to event 4 .. 6
(verification reject).
8-11

COUNTER SUMMARY
8.3.4

X.2S Protocol Module Counters

This section contains a description of each X.25 protocol
counter. These counters apply only to MCB PSI operations.

module

Seconds since last zeroed
This counter indicates the number of seconds that have elapsed
since the module counters were zeroed. This counter provides a
time frame for other counter values.
The MCB PSI software
increments this counter every second and clears it when the
counters are zeroed.
Bytes received
This counter indicates the number of bytes of data received by
the local DTE.
You can use this information together with the
data blocks received counter to determine the total traffic load.
Bytes sent
This counter indicates the number of bytes of data sent by the
local DTE.
You can use this information together with the data
blocks sent counter to determine the total traffic load.
Data blocks received
This counter indicates the number of data blocks received by
local DTE.

the

Data blocks sent
This counter indicates the number of
local DTE.

data

blocks

sent

the

Calls received
This counter indicates the number of incoming calls received.
Calls sent
This counter indicates the number of outgoing calls made.
Fast selects received
This counter indicates the number of calls received with the fast
select facility specified.
Fast selects sent
This counter indicates the number of calls
select facility specified.

sent

with

the

fast

Maximum switched circuits active
This counter indicates the number of switched virtual circuits
that were active at anyone time since the counters were last
zeroed.
Maximum channels active
This counter indicates the maximum number of channels from the
logical channels list that were active at anyone time since the
counters were last logged.
B-12

COUNTER SUMMARY
These circuits are ones whose logical channel numbers appear in
the channels list regardless of whether the circuits are used for
incoming or outgoing calls.
Received call resource errors
This counter indicates the number of times an incoming call tlas
been rejected because of insufficient resources or an incorrE~ct
configuration (for example, no destination or object specified).
Locally initiated resets
This counter indicates the number of resets
DTE.

sent

the

local

Network initiated resets
This counter indicates the number of resets
PSDN ) received by the local DTE.

(originated

the

Remotely initiated resets
This counter indicates the number of resets
(originated
remote DTE or DTEs) received by the local DTE.

Restarts
This counter indicates the number of times
protocol procedure was used on the DTE.

8.3.5

that

the

rest&rt

each X.25 server
PSI operations.

module

X.25 Server Module Counters

This section contains a description
counter. These counters apply only to

TOPS-l~

Seconds since last zeroed
This counter indicates the number of seconds that have elapE:ed
since the module counters were zeroed.
This counter provides: a
time frame for other counter values. The TOPS-l~ PSI softw&re
increments this counter every second and clears it when the
counters are zeroed.
Maximum circuits active
This counter indicates the number of switched virtual circujts
that have been set up since the counters were last zeroed.
Incoming calls rejected, no resources
This counter indicates the number of times the incoming c&ll
handler rejected a request to set up a virtual circuit because of
insufficient resources.
Logical links rejected, no resources
This counter indicates the number of X.25 circuits that have bElen
set up by the TOPS-l~ host system but rejected by the MCB because
of insufficient resources at the Gateway.

B-13

APPENDIX C
NETWORK RELATED MESSAGES

When you are using NCP commands, messages related to the execution of
the commands and to the condition of the network are output. Selme
appear on the user's terminal, and some appear on the CTY.
If you eire
the system manager, you should check the network-related messages on
the CTY, or delegate this
responsibility.
If
you
are
an
operator-user, you should resolve those messages output to yClur
terminal. Only those messages output to the user's terminal eire
described in this appendix (see also Section 4.5.6).

C.I

OPR/NCP COMMAND SYNTAX MESSAGES

All NCP messages are first examined by aPR. aPR uses the NCP table to
check the command syntax. The parsed command is then sent in an IPCF
packet to ORION and QUASAR, where further errors or informational
messages can be added. The completely checked command returns to OPR
and aPR directs all messages on each command to the terminal where you
type the NCP command.
The syntax messages output by aPR all begin with a question mark
':?)
and are in readable text only (no codes or abbreviations).
In thHse
messages the "?" does not indicate a fatal error:
it questions the
accuracy of your input. You correct the command by retyping up to the
point of error (use CTRL/H) and substituting or adding the corroct
keyword or value.
If you are unsure of what is required, typn a
question mark to get a list of possible arguments.
possible syntax error messages follow in alphabetic order.
Seve~al
examples of NCP commands with errors, showing the desired corrections,
follow the alphabetic list.

? Ambiguous
? Does not match switch or keyword: "word"
? Filename was not specified
? File not found
? First nonspace character is not a digit
? Invalid character in number
? Invalid device terminator
? Invalid guide word
? Invalid node name
C-l

NETWORK RELATED MESSAGES
? Invalid wildcard designator
? Negative number improper
?

No help available for "word"

? No such file type
? Node name doesn't contain any alphabetic characters

? Not confirmed
? Null switch or keyword given
? Too many characters in node name

? Unrecognized switch or keyword: "word"
Examples:
NCP>SET EXECTOR NODE D2l02A<RET>
? Unrecognized switch or keyword: "exector"
NCP>SET EXECUTOR NODE D2l02A<RET)
NCP>
NCP
1~:2l:26
Set Executor Complete

**********
NCP>SET EXECUTOR INACTIVITY TIMER SECONDS 20<RET>
?First nonspace character is not a digit
NCP><CTRL/H)
NCP>SET EXECUTOR INACTIVITY TIMER20<RET)
? Unrecognized switch or keyword: "timer2~"
NCP><CTRL/H)
NCP>SET EXECUTOR INACTIVITY TIMER 20<RET>
NCP>
11:35:35
NCP
Set Node Complete

C.2

aPR/ORION/QUASAR INFORMATIONAL MESSAGES

Informational messages report major system changes:
they cannot be
"REFUSED" or "DISABLED." Depending on your current needs, these
messages mayor may not concern you, but you should read them.
Such messages are always time-stamped and have the general format:
NCP>
hh:mm:ss

text

An example of an informational message of interest
follows:
Example:
NCP>
16:17:44

--NCP is not running--

C-2

network

users

NETWORK RELATED MESSAGES
NCP commands that are syntactically correct (no errors reported
through OPR)
are executed immediately if they do not require use of
the NICE protocol. This includes the OPR/NCP commands (described in
Chapter 5)
and the commands processed locally by NCP (described in
Chapter 6). These comm~rids that are not sent in NICE protocol
messages receiv~oniy t~e me~sag~s described in Sections C.I and C.2.

C.3

NCP COMMAND RESPONSE MESSAGES

All commands processed by Network Management routines are assigned a
request number by NCP. They are then translated into NICE messages
and forwarded to NML in the central processor for local processing or
to NML in the remote node for remote processing. Results of this
processing return to the local NCP by means of NICE messages, which
are then formatted into response messages.
The generic format of NCP command response messages is:
hh:mm:ss

NCP
Request

nnn; command entity status, [error information]

where:
hh:mm:ss

is the time in hours, minutes, and seconds

nnn

is the request number assigned

command

is a command indicator

entity

is a specific entity

status

is one of Complete, Accepted, or Failed

error information is displayed only if status is Failed

C-3

NETWORK RELATED MESSAGES
C.3.l

Status Messages

Status is reported as Complete if the
command
has
executed
successfully.
Status reported as Accepted implies only that the
command is semantically (and syntactically) correct; the command
receives a further response of Complete or Failed when it is executed.
If the status is reported as Failed, an error message follows.
Examples:
NCP>SH KN NO STA<RET>
NCP>
9:37:29
NCP
Request # 96; Show Known Node Status Completed
Remote Node = 7.88 (KL253~)
State = Unreachable

**********
NCP>CLEAR EXEC<RET>
NCP>LOA NO D2102A<RET>
NCP>
11:18:16
NCP
Clear Executor Complete
11:18:16

NCP
Request # 2 Accepted

11:18:19

NCP
Request # 2; Load Node Completed

**********
NCP>SH NO XXYZZ CH(RET>
NCP>
11:0~:17
NCP
Request # 13; Show Node Failed, Unrecognized component
Entity = Node
Node = (XXYZZ)

C.3.2

Error Messages from Network Management Software

When the status is Failed, an error message gives the reason for the
failure.
This reason is followed by detail if such detail is
available. The detail, in turn, can be followed by additional
explanatory text.
NCP error messages are listed below in alphabetic order.
A brief
explanation is given; where possible, appropriate action is suggested.
The following NCP error messages are standard for most DECnet
implementations.
Since NICE errors only return an error code and not
the error message text, the NICE return codes are also listed.

C-4

NETWORK RELATED MESSAGES
Error Message Text

Description/Procedures

Bad loopback response
NICE error code (-28)

The message returned in a loopback
test did not match the message
sent.
Repeat the loopback test.
If the error persists,
use the
various loopback tests to try to
isolate the part of the line that
is
bad.
Follow
your
site's
procedures for notifying your Field
Service Representative.

Component in wrong state
NICE error code (-11)

There is a problem with the state
of the entity to which the command
applies, or to the secondary entity
(line,
for example,
in a
LOAD
command) •
Check the state of the
primary and secondary
entities.
Are nodes or lines ON, OFF, or in
SERVICE state as required by the
function being requested? Correct
and try again.

File I/O error
NICE error code (-18)

A hardware error
occurred
while
trying to read or write a file
required to execute the command.
The error detail indicates
the
problem is in one of the following:
DUMP FILE
LOAD FILE
Permanent Data Base
SECONDARY DUMPER
SECONDARY LOADER
TERTIARY LOADER
Volatile Data Base
Repeat the command.
persists,
follow
standard procedure
hardware errors.

If the error
your
site's
for
reporting

File open error
NICE error code (-13)

A file needed for processing could
not be
opened.
Error
detail
specifies same files as for AFile
1/0 error. A System-specific detail,
if present, may suggest procedure.
If no detail
is
given,
check
directory or file restrictions.

Hardware failure
NICE error code (-24)

The hardware needed to satisfy the
request could not
perform
the
function requested. Try again.
If
the error message is
repeated,
check
the hardware for obvious
errors
(not up,
no
paper
in
printer, and the like).
If devices
appear to be in order, follow your
standard rules for contacting your
Field Service Representative.

C-5

NETWORK RELATED MESSAGES
Error Message Text

Description/Procedures

Incompatible Management version
NICE error code (-7)

The function requested cannot be
performed because the version skew
between the NMLs in the source and
destination nodes is too great.
This
problem cannot be solved.
Make
a
record
of
the
incompatibility for the future.

Invalid file contents
NICE error code (-14)

The error detail indicates the file
that contains invalid information.
The file is one of:
Permanent Data Base
LOAD FILE
SECONDARY LOADER
TERTIARY LOADER
Although
DECnet-l~
does
not
currently support a permanent data
base, you can receive this message
if you have another node acting as
executor.
If the file in error is a remote
file, the system manager at the
remote site should be notified. If
the file is local, the user should
check to be sure the filename typed
is the correct file. If it was,
next check the directoryo
The
TOPS-l~
Operating System Commands
Manual describes the procedures to
follow.

Invalid identification
NICE error code (-9)

the primary or
The
format of
secondary entity identification is
invalid.
The
error
detail
indicates identity type.
Correct
the error.

Invalid message format
NICE error code (-2)

NML has received a message that is
not properly formatted. This could
indicate
a
problem
with
the
software on either the transmitting
or receiving end. Try the command
again.
If the error
persists,
follow procedures for a Software
Performance Report (SPR).

C-6

NETWORK RELATED MESSAGES
Description/Procedures

Error Message Text
Invalid parameter grouping
NICE error code (-27)

A
request
to change
~ultiple
parameters
included
an
entity
parameter group that could not be
changed
the command was
not
executed.
Check
all
entity-parameter combinations for
validity,
completeness,
and an
in-bounds value.
Are there any
contradictions
or
duplications?
DECnet-l~
does
not
accept
multiple-parameter commands. Each
parameter must be in a separate
command.
Repeat specifying one
parameter per command.

Invalid parameter value
NICE error code (-16)

The error detail indicates the name
of the invalid parameter.
Check
the range of length, size, and
number values.
Is
the
value
permitted with the entity to which
it refers?

Line communication error
NICE error code (-1~)

This error occurs only on direct
use of a line such as for looping,
downline load, or upline dump. The
error can be in transmitting or in
receiving.
If further detail is
given, the device may be specified.
Check (or have the system operator
check) the operating condition of
the
indicated
device.
If the
problem remains, follow procedures
for reporting to your Field Service
Representative.

Line protocol error
NICE error code (-17)

This error
can refer to the Data
Link protocol
or
the
Service
Operation protocol.
The error is
given only on direct use of a line
(as for a line loop or down1ine
load). Repeat the command. If the
error persists, follow procedures
for a Software Performance Report
(SPR).

C-7

NETWORK RELATED MESSAGES
Error Message Text
Listener link connect failed

Description/Procedures
A connect to the NML NICE Listener
could
not be completed.
Error
detail will vary depending upon the
operating system being connected
to.
Be guided by
detail,
if
present.
There
are
several
possible conditions
that
could
cause this error:
The remote node name or the access
control information is incorrect.
Correct the error and repeat the
command.
The remote node or the local node
is in the process of shutting down
and will accept no more logical
link connections. Try later.
Either the local or remote node has
insufficient network resources to
connect the logical link.
Try
later.
There is no path to the remote
node.
Check the status of the
remote node (use the SHOW NODE
nodeid STATUS command). If status
is "Unreachable" wait until it is
"Reachable" and try again.
A remote node you wish
to
may
not
have
Management

to
a

connect
Network

Listener.
A connection is
not
possible.
Note
for
future
reference. The procedure you use
following this message depends on
detail given.
If
the
detail
indicates
an easily correctable
cause,
missing
or
invalid
parameters, for example, correct
and repeat the command.
If the
detail
suggests
a
transient
problem, wait appropriately and try
again later ("appropriately" might
be when a remote node comes back on
line, depending on the reason for
the failure to connect).
Listener link disconnected

A successful connection to the NML
NICE Listener was made, but the
logical link then failed. Both the
error detail and the procedure are
as described for "Listener link
connect failed."

C-8

NETWORK RELATED MESSAGES
Error Message Text

Description/Procedures

Management program error
NICE error code (-5)

A software error
iri the DECnet-l~
software
was
detected.
A
system-level
message may supply
detail.
Follow procedures for a
Software Performance Report ( SPR).

Mirror connect failed
NICE error code (-21)

A connect
to ~he NML Loopback
Mirror could not be
completed.
Error detail and procedure as for
"Listener link connect failed."

Mirror link disconnected
NICE error code (-19)

A successful link was made to the
Loopback Mirror, but the link was
then disconnected.
Error detail
and procedure as for "Listener link
connect failed."

No room for new entry
NICE error code (-20)

Insufficient
room exists in some
data base for an entry required by
the requested function.

Operation failure
NICE error code (-25)

A requested operation failed.
NML
supplies no detail;
there mayor
may
not
be
system-level
or
system-specific detail.
In
the
absence
of
detail,
check the
following; correct if possible, and
try again.
If the error persists,
follow procedures for contacting
your Software Specialist.
Check to see if there is a required
parameter for this command that is
missing or invalid.
Check to see if the executor in the
proper state.
Check to see if are
messages on the CTY.

any

helpful

Oversized management
command message
NICE error code (-4)

A message size was too long. The
NICE message was too long
for the
Management Listener to
receive.
Follow procedures for a Software
Performance Report (SPR).

Parameter missing
NICE error code (-29)

You failed to
include a
required
parameter. The error detail will
specify the name of the missing
parameter. Repeat the command with
the required parameter.

C-9

NETWORK RELATED MESSAGES
Description/Procedures

Error Message Text
Parameter not applicable
NICE error code (-22)

You have included a parameter that
is not allowed with the entity to
which it refers. The parameter is
named in the error detail. Correct
and repeat the command.

Parameter value too long
NICE error code (-23)

You have included a parameter that
is too long to be accepted by the
implementation.
The error detail
identifies the parameter type.
If
the parameter identified is a file
specification,
be
aware
that
maximum
file
length
is
system-specific
(VAX/VMS,
for
example, allows a maximum of 64
characters
for
a
file
specification;
RSX-llM allows a
maximum of 34). If the executor is
not your local node, you may need
to refer to documentation for the
executor's operating system.

Privilege violation
NICE error code (-3)

You
do not
have, or
have not
enabled, the privilege required for
the function you have requested.

Resource error
NICE error code (-15)

A resource required to perform the
requested
function
was
not
available.
Repeat
the command
later.

System-specific Management
function not supported
NICE error code (-26)

System-specific functions
return
this message if the executor
node
is running an operating
system
other than the one for which the
function was implemented.

Unrecognized component
NICE error code (-8)

An entity (component) is not known
to the system.
The error detail
indicates
the
entity.
Usually
caused by an error in typing.
Try
the command again.

Unrecognized function or option
NICE error code (-1)

The requested function or option is
not implemented by the executor.

Unrecognized parameter type
NICE error code (-6)

The parameter
indicated in the
error detail is not implemented in
the executor.

C-10

NETWORK RELATED MESSAGES
C.4
C.4.l

EVENT MESSAGES
Event Class and Type Summary

Following is a summary of NCP events in terms of their class and type.
In general, event classes relate to specific layers of the DECnet
architecture. The event logging components support the event classes
summarized below.
Table C-l:

EVENT Classes
EVENT
Class
fiJ
1

2
3
4

5
6

7-31
32-63
64-95
96-127
128-159
l6fiJ-19l
192-223
224-255
48fiJ-5ll

Description
Network Management Layer
Applications Layer
Session Control Layer
Network Services Layer
Routing Layer
Data Link Layer
Physical Link Layer
Reserved for other common classes
RSTS System specific
RSX System specific
TOPS-lfiJ/2fiJ System specific
VMS System specific
RT System specific
CT system specific
Communication server specific
Customer specific

DECnet-lfiJ logs events only for specific event classes and types.
If the logging console is enabled, DECnet-lfiJ uses the OPR program to
display event messages on all operator terminals enabled to received
messages with the OPR command ENABLE OUTPUT-DISPLAY NCP-MESSAGES,
which is the default.
Event messages have the following format:
event type class.type, event-text
from node address [(node-name)] dd-mmm-yy hh:mm:ss.ms
component-type, event-qualifiers, •••
The event text is a standard text message as described below for each
event class and type.
The message format also includes the source
node (address and node name, if available) and time stamp for when the
event occurred.
For most events, the message format includes the
component type and name for which the event applies.
Finally, the
message format may include the cause of the event.
The following sections describe the event
layer. The format is:
class.type

event-message-text

C-1l

messages

for

explanation

each

DECnet

NETWORK RELATED MESSAGES
C.4.2

Network Management Layer Events

The following specific event classes and types are supported for
layer.
0.0

Event records lost
Events occurred too rapidly for the event logger
them.

0.1

each

buffer

Automatic node counters
A node counter timer expired, thus prompting this event.
This message displays the name of the node for which the
event applies, along with the node counters for that node.

0.2

Automatic line counters
A line counter timer expired, thereby producing this event.
This message displays the name of the line for which the
event applies, along with the line counters for that line.

0.3

Automatic service
An adjacent node requested an automatic circuit service
operation.
This message displays the name of the circuit
for which the event applies, along with the service function
performed (load or dump), the status of the operation
(requested, successful, or failed), the node address, the
file specification, and the software type. If the operation
fails, this status includes an NML error message and
details.

0.4

Line counters zeroed
Line counters were zeroed. This message displays the name
of the line for which the event applies. The event logger
logs these counters prior to the execution of a request to
zero them.

0.5

Node counters zeroed
Node counters were zeroed. This message displays the name
of the node for which the event applies. The event logger
logs these counters prior to the execution of a request to
zero them.

0.6

Passive loopback
The software initiated or terminated a passive loopback test
on behalf of an adjacent node. This message displays the
name of the line for which the event applies, along with the
state of the operation (initiated or terminated).

C-12

NETWORK RELATED MESSAGES
0.7

Aborted service request
An adjacent node requested a service over a line connected
to the local node.
However, a problem prevented it from
being processed at the local node.
This message displays
the name of the line for which the event applies, along with
the reason for the failure. The reason may be one of the
following:
Line open error
NML received an MOP message and was unable to acquire
control of the line.
Either NML did not have the
privilege to perform the operation or it could not set
the substate of the line; or the line had another
owner.
Line state change by higher level
The line was preempted by a higher priority function.
For example, you used NCP to turn the line off.
Operation failure
A load or dump operation was started but
occurred in the loading or dumping process.

failure

Receive error
A line error
request.

occurred

while

trying

receive

the

Receive timeout
The line message receive timer expired before the
request could be received from the adjacent node.
Either the timer was too short, the line error level
was too great for any message to get through, or the
adjacent node stopped requesting.
Unrecognized request
A message was received but was not recognizable as a
request
for upline dumping, down1ine loading, or
passive 100pback testing. The adjacent node may be
running an incompatible version of the line service
protocol.
0.8

Automatic counters
A counter timer for a node, circuit, or line has expired.
This message displays the name of the component for which
the event applies, along with the counters for that line.

0.9

Counters zeroed
Counters were zeroed for the node, circuit, or line.
This
message displays the name of the component for which the
event applies. The event logger logs these events prior to
the execution of a request to zero them.

C-13

NETWORK RELATED MESSAGES
C.4.3

Session Control Layer Events
2.0

Local node state change
The operational state of the local node changed because of
an operator commapd.
Note, however, that the transition
from SHUT to OFF also happens automatically when the last
logical link is disconnected (under normal operation).
This message displays the reason for the state change
(operator command or normal operation), the old state ON,
OFF, SHUT, or RESTRICTED), and the new state.

2.1

Access control reject
The local node rejected a connection
invalid access control information.

request

because

This message displays the name and address of the source
node; the object type number and process 1D of the source
process requesting the connection; the object type number
and process ID of the destination process to receive the
connectipn request; and
the
invalid
access
control
information.

C.4.4

End Communication Layer Events
3.0

Invalid message
NSP received a message that could not be interpreted.
This
may indicate a software malfunction in either the local or
remote NSP. This message displays the NSP message that, was
invalid.
Refer
to
the
Network Services Functional
Specification for a description of NSP messages.

3.1

Invalid flow control
The remote NSP attempted to modify the local flow control
value in an invalid manner. This may indicate a software
malfunction in either the local or remote NSP. This message
displays the current flow control value.
Refer to the
Network Services Functional Specification for a description
of flow control.

3.2

Database reused
The local node received a connection request from a node for
which there is no counter block. All counter blocks have
been previously used, and one of the previously used blocks
is available for this new node. This results in the loss of
node counters for the node that formerly occupied the
database entry.
This message displays the name of the
database entry was formerly used,
counters for that node.

C-14

node for which the
along with the node

NETWORK RELATED MESSAGES
C.4.S

Routing Layer Events
4.~

Aged

pack~d

loss

Routing discarded a packet because it had visited too many
nodes.
This can be a normal occurrence when the network is
reconfiguring its routing databases. It can be a failure
when the MAXIMUM HOPS value is set too small. This can
cause the MAXIMUM VISITS value to be too small for a path
that should be usable.
This message displays the name of the line for which the
event applies, along with the packet header.
This is
information from the beginning of
the
packet.
For
non-Ethernet packets, it consists of a hexadecimal byte of
flags, the decimal destination and source node addresses,
and a hexadecimal byte of forwarding data. For Ethernet
packets, it also includes the Ethernet address of the
destination and source, the service type. and the protocol
type. Refer to the Routing Functional Specification for
additional information.
4.1

Node unreachable packet loss
Routing discarded a packet because the local node found that
the destination node was unreachable. This event provides a
trace of what has happened to packets that are not reaching
their destination.
This message displays the name of the line for which the
event applies, along with the packet header (as described
for event 4.~).

4.2

Node out-of-range packet loss
Routing discarded a packet because the destination node
number was greater than the maximum node number known to the
local node. Typically, this results from the addition of a
new node to the network without increasing the MAXIMUM
ADDRESS value on the local node, yet expecting the local
node to route packets to that node.
This message displays the name of the line for which the
event applies, along with the packet header (as described
for event 4.~).

4.3

Oversized packet loss
Routing discarded the packet because it was too large to
forward to the appropriate adjacent node. Typically, this
occurs when the adjacent node's buffer size is too small or
when the source node sends a packet that is too large.
This message displays the name of the line over which the
packet was to be forwarded, along with the packet header (as
described for event 4.~).

4.4

Packet format error
Routing discarded a packet because of a format error in the
packet header.
This usually results from a programming
error in the packet formatting by the adjacent node, though
it could result from a line error that was not detected by
the line protocol.
C-lS

NETWORK RELATED MESSAGES
4.5

Partial routing update loss
Routing received a routing message that contained· node
addresses greater than the maXlmum address known to the
local. node. Subsequently, information on these nodes was
lost.
This occurs when the MAXIMUM ADDRESS value on an
adjacent node has been increased to accommodate more nodes,
but the local node's value has not increased.
The message displays the name of the line over which this
message was received, along with the packet header (as
described for event 4.~) and the highest node address in the
routing update that was lost.

4.6

Verification reject
An attempt to initialize with another node failed.
The
local node received an invalid password in the verification
requested of the adjacent node during routing initialization
over the line.
Either the local node expected the wrong
receive password, or the adjacent node sent the wrong
transmit password.
The message displays the name of the line for which the
event applies, along with the address of the adjacent node
that failed to initialize.

4.7

Circuit down, circuit fault
An error has occurred for the circuit.
This message
displays the name of the circuit for which the event
applies, along with the reason for the event.
The reason
could be one of the following:
Adjacent node address change
The adjacent node changed addresses without going
through the normal initialization sequence. This is
also logged when an adjacent
node
attempts
to
initialize with the local node, but the adjacent node's
address is not in the database.
Adjacent node address out of range
The adjacent node's address is greater than the maximum
address defined for the local node. This may be caused
by an incorrectly defined node address or by a failure
to update the local node's database when a new node was
added.
Adjacent node block size too small
The line block size provided by the adjacent node is
too small for normal network operation. The block size
may be set incorrectly at the adjacent node.
Adjacent node listener receive timeout
The node has received no message over the data link
within the last 3~ seconds. This usually means that
the remote node is not running.

C-16

NETWORK RELATED MESSAGES
Adjacent node listener received invalid data
A test message sent by the adjacent node contained
invalid Data or corrupted data. This is most likely
caused by a hardware problem.
Call failed
An outgoing SVC call failed.

This is an X.25 event.

Data errors
The line was declared down by the
protocol handler when the line
threshold.

local node's line
exceeded an error

Dropped by adjacent node
The adjacent node was
circuit connection.

responsible

for

breaking

the

Invalid verification seed value
A Routing initialization message sent by an adjacent
node is not formatted properly. This is most likely
caused by a remote network software problem.
Line synchronization lost
The normal line protocol was restarted or terminated by
the adjacent node.
Either a line exceeded an error
threshold, or network management initiated a line state
change.
DMR/DMC
failures
that
cause
a
line
synchronization error are as follows:
o

Threshold errors, including
more
attempts
to transmit a message,
received in a row.

Start message received in the RUN state (that is,
the remote system detected an error and restarted
the line).

Maintenance requested while in the RUN state (that
is,
the
remote
system
tried to perform a
maintenance operation such as LOOP CIRCUIT).

Message was lost because no buffer was available in
CPU memory.

Nonexistent memory error.

Procedure error,
hardware failure.

Timeout on request to transmit
seconds.

Power failure.

because

than
eight
or eight Ns

driver
a

failure

message

or
255

Routing update checksum error
A routing update packet failed its
test.
C-17

internal

integrity

NETWORK RELATED MESSAGES
Unexpected packet type
A packet was received out of the normal protocol
sequence.
For example, the local node received a
normal data packet when it expected a verification
packet.
Verification password required from Phase III node

A required routing initialization password was not
specified before an attempt was made to initialize the
Phase III node in a Phase IV network.
Verification receive timeout
A required verification packet was not received from
the adjacent node within the required response time.
Either packets were lost on the line or a failure
occurred at the adjacent node.
version skew
The routing version
of
the
adjacent
node
is
unacceptable to the local node. The operator may have
installed incorrect software at the adjacent node.
4.8

Circuit down
An error has occurred for the circuit.
This message
displays the name of the circuit for which the event
applies, along with the packet header (as described for
event 4.~), the reason (as described for event 4.7), and the
address of the adjacent node.

4.9

Circuit down, operator fault
An operator error has occurred for the circuit.
This
message displays the name of the circuit for which the event
applies, along with the packet header (as described for
event 4.~), the reason, (as described for event 4.7) and the
addresses of the expected node and the adjacent node.

4.l~

Circuit up
A remote node has initialized on one of the physical lines
connected to the local node. This message displays the name
of the line for which the event applies, along with the
address of the newly initialized node.
Be sure to note that this event does not imply that the node
is
reachable.
Reachability
is
determined
by
the
higher-level routing algorithms.

4.11 Initialization failure, line fault
A remote node failed to initialize with the local node
because of a physical line error. This message displays the
name of the line for which the event applies, along with the
reason for the event (as described for event 4.7)

C-18

NETWORK RELATED MESSAGES
4.12 Initialization failure, software fault
A remote node failed to initialize with the local node
because of a software error. This message displays the name
of the line for which the event applies, along with the
packet header (as described for 4.0) and the reason (as
described for event 4.7).
4.13 Initialization failure, operator fault
A remote node failed to initialize with the local node
because of an operator error. This message displays the
name of the line for which the event applies, along with the
packet header (as described for event 4.0), the reason (as
described for event 4.7), and the version received from the
adjacent node.
4.14 Node reachability change
Because of Routing operation, the reachability of a remote
node has changed.
This message displays the name of the
node for which the event applies, along with the routing
status of the node (reachable or unreachable).
4.15 Adjacency up
The adjacent node on the circuit is initialized.
This
message displays the name of the circuit for which the event
applies, and the address of the adjacent node.
4.16 Adjacency rejected
The adjacent node on the circuit is not initialized.
The
message displays the name of the circuit for which the event
applies, and the address of the adjacent node and the reason
for the event (as described for event 4.7).
4.17 Area reachability change
Because of Routing operation, the reachability of an area
has changed. This message displays the name of the area for
which the event applies, along with the routing status of
the area (reachable or unreachable).
4.18 Adjacency down
An error has occurred for an adjacency on the circuit. This
message displays the name of the circuit for which the event
applies, along with the reason (as described for event 4.7),
the packet header (as described for event 4.4), and the
address of the adjacent node on the circuit.
4.19 Adjacency down, operator fault
An adjacency on the circuit is down because of an operator
error.
This message displays the name of the circuit for
which the event applies, along with the reason (as described
for event 4.7), the packet header (as described for event
4.0), and the addresses of the expected node and the
adjacent node on the circuit.

C-19

NETWORK RELATED MESSAGES
C.4.6

Data Link Layer Events
5.0

Locally initiated state change
The line state changed because of an operator command. This
message displays the name of the line for which the event
applies, along with the old DDCMP state (HALTED, ISTRT,
ASTRT, RUNNING, or MAINTENANCE) and the new DDCMP state.
Refer to the DDCMP
Functional
Specification
for
a
description of these states.

5.1

Remotely initiated state change
A remote user changed the line state. This message displays
the name of the line for which the event applies, with the
old and new ODCMP line states (see event 5.0).

5.2

Protocol restart received in maintenance mode
The remote node restarted normal operation while the local
node had the line in maintenance mode.
This message
displays the name of the line for which the event applies.

5.3

Send error threshold
Too many data transmission errors occurred.
This message
displays the name of the line for which the event applies,
along with the line counters for that line and the address
of the received station (node).

5.4

Receive error threshold
Too many data reception errors occurred.
This message
displays the name of the line for which the event applies,
along with the line counters for that line and the address
of the received station (node).

5.5

Select error threshold
Too many selection errors occurred. This message displays
the name of the line for which the event applies, along with
the line counters for that line and the address of the
received station (node).

5.6

Block header format error
DOCMP received an invalid block header.
This message
displays the name of the line for which the event applies,
along with the invalid block header.
Refer to the ODCMP
Functional Specification for a description of the block
header format.

5.7

Selection address error
The wrong tributary responded in the polling process.
The
event occurs only for a multipoint control station when one
receives a message that does not match the address of the
currently selected tributary.
This message displays the name of the line for which the
event applies, along with the tributary addresses of the
selected tributary, the received tributary, and the previous
tributary.

C-20

NETWORK RELATED MESSAGES
5.8

Streaming tributary
A tributary on the line is impeding the use of that line.
This message displays the name of the line for which the
event applies, along with the tributary address of the
received tributary and the status of the tributary. The
status may be any of the following:

5.9

Streaming

Continued send after timeout

Continued send after deselect

Ended streaming

Local buffer too small
A local buffer is too small for receiving a block of data.
This message displays the name of the line for which the
event applies, along with two qualifiers---the length (in
bytes) of the received block and the length (in bytes) of
the buffer.

5.10 Restart (X.25 protocol)
A restart occured at the frame level in the X.25 Gateway.
5.11 State change (X.25 protocol)
The operational state of the X.25 line changed because of an
operator command or a communication loss with the packet
switch network.
5.13 Line initialization failure
An initialization failure occurred over an Ethernet line.
This message displays the name of the line for which the
event applies.
5.14 Send failure on line *
A data transmission attempt failed on an Ethernet line.
This message displays the name of the line for which the
event applies, along with the reason for the failure and the
distance. Failure reasons can include excessive collisions,
short or open circuits, too long a frame, a framing error,
an unrecognized frame destination, a remote failure to
defer, a block check error, or data overrun.
5.15 Receive failed on line *
Data was not received on an Ethernet line.
This message
displays the name of the line for which the event applies,
along with two event qualifiers---the reason for the failure
(as described in event 5.14) and the Ethernet header which
includes the source and destination node addresses and the
protocol type.

C-21

NETWORK RELATED MESSAGES
5.16 Collision detect check failed on line
A check for collision detection failed on an Ethernet line.
The message displays the name of the line for which the
event applies.
5.17 DTE up
From node 7.99 (NONAME) ,
311060300052

15-April-1984

18:36:34:04

DTE

15-April-1984

18:36:25:89

OTE

5.18 OTE down
From node 7.99 (NONAME) ,
311060300052

C-22

APPENDIX D
X.29 CONFIGURATION FILE

D.1

MANAGING X29SRV

The system manager can tailor the
the requirements of the site
command. The commands are stored
be changed at any time.
However,
at startup time. While X29SRV is
static.

characteristics of X29SRV to suit
by using variations of the DEFINE
in the file SYS:X29SRV.INI and can
X29SRV processes these commands only
running, the characteristics remain

There is, however, no need for the file SYS:X29SRV.INI to exist before
X29SRV can function.
X29SRV is designed to run and to interact with
the remote PAD software using the CCITT X.3, X.28, and
X.29
recommendations.
Thus,
the system manager can choose to simply
install the program and let it run without any intervention.

D.l.1

Security Considerations

The system manager can use the DEFINE commands to determine the degree
of X29SRV's user-friendliness. An example of user-friendliness is the
abundance of help text, prompts, and other system messages that guide
the users in accessing systems successfully. This is particularly
helpful to users who are not familiar with the installation and its
access procedure.
On the other hand, the system manager can choose not to provide these
features
to
users who happen to connect to the PSI Gateway
accidentally. The system manager may want to make it harder for those
who are not familiar with the access procedure to gain access to any
of the systems on the DECnet network. This can be done, for example,
by having X29SRV disconnect the terminal after an unsuccessful attempt
to connect to a system.
These options are decided by the system managers. While there are no
fool-proof ways of preventing illegal break-ins of systems over the
Public Network, these options provide the system manager with a means
to build the first line of defense against such practices. The
responsibility of maintaining a system's security rests with the
systems manager and the operating system.

D.2

SAMPLE DIALOGUE

The following sample of initialization set-up and dialogue illustrates
the normal procedure for managing the TOPS-10 PSI X.29 software and
using the software to access the TOPS-10 host. The system is assumed
to be connected to the TELENET network.
D-l

X.29 CONFIGURATION FILE
0.2.1

X29SRV.INI

The file SYS:X29SRV.INI, which contains the following commands, is
created by the system manager to define the characteristics of X29SRV.
DEFINE DEFAULT HOST DISABLED
DEFINE HERALD Digital Equipment Corp. TOPS-l~ PSI Gateway X.29 Server
DEFINE MAXIMUM CIRCUITS 8
DEFINE MAXIMUM CONNECT ERRORS 1
DEFINE NETWORK TELENET
DEFINE PROMPT "X29SRV> "
DEFINE RESPONSE VERBOSE
DEFINE REVERSE CHARGING ALLOWED
DEFINE SET DEFAULT 1:1,2:1,3:126,4:1~,5:1,6:1,7:1,8:~,9:~,1~:~,12:1, l3:~,14:~,15:~,16:127,17:21,18:18,~:33,1:~,10:~,
18:~,27:127,28:21,29:18,37:1,57:1,63:0

DEFINE SET FDX

1:1,2:0,3:~,4:1,5:1,6:1,7:1,8:0,9:~,10:~,12:~,13:4,

14:~,15:~,16:127,17:21,18:18,~:33,1:4,10:~,18:0,

27:127,28:21,29:18,37:1
DEFINE SET HDX

1:1,2:1,3:6,4:~,5:1,6:1,7:1,8:~,9:0,1~:~,12:1,13:~, 14:0,15:1,16:127,17:21,18:18,~:33,1:~,1~:0,18:4,27:127,

28:21,29:18,37:1
DEFINE SET KERMIT 1:1,2:1,3:~,4:1,5:1,6:1,7:1,8:0,9:0,1~:0,12:0,13:4, 14:~,15:~,16:127,17:21,18:18,~:33,1:4,1~:~,18:~, 27:127,28:21,29:18,37:1,57:~,63:~

0.2.2

Dialogue

The following example shows the terminal session as seen by the user
accessing the TOPS-1~ system from a public access PAD on the TELENET
network.
TELENET
617 18I
TERMINAL=D1 <RET>
@C 61772 <RET>
617 72 CONNECTED
Digital Equipment Corporation TOPS-1~ PSI Gateway X.29 Server
Friday, April 13, 1984 11:06:31:AM
V1.~(~) #110(0~)
X29SRV> CONNECT KL1~26 <RET>
RL175D DEC10 Development 11:1~:47 TTY52 system
Connected to Node KL1026 (26) Line # 52
Please LOGIN or ATTACH
.TTY NO ECHO
.<BREAK>
BREAK
X29SRV> DISC <RET>

D-2

1~26/1~42

X.29 CONFIGURATION FILE
HOST SYSTEM DISCONNECTED
X29SRV> CONNECT KS4l45 FOX <RET>
CSSE KS 4145 7.~2 11:12:29

.[ Idle line disconnected by host ]
HOST SYSTEM DISCONNECTED
X29SRV> CLEAR <RET>
DISCONNECTING •••••
617 72 DISCONNECTED

0.3

0~:0~:~1:17

30 25

MANAGEMENT COMMANDS

The management commands can be used to define the characteristics of
X29SRV.
They are saved in the file SYS:X29SRV.INI. The commands are
listed in alphabetical order in the following sections.
All of theSe commands can be abbreviated. For example, "DEF D H E"
can be used to represent the command DEFINE DEFAULT HOST ENABLED. A
long command may be entered as several text lines as follows:
DEFINE SET DEFAULT

1:1,2:l,3:l26,4:l~,5:l,6:l,7:l,8:0,9:~,1~:~, l2:l,13:~,14:0,15:~,16:l27,17:2l,18:l8, ~:~,1:~,1~:~,18:0,27:127,28:2l,29:l8,37:l,57:l,63:~

The character "-" (dash) at the end of the first two lines
to X29SRV that the command is continued on the next line.

0.3.1

indicates

Error Conditions

If you compose a command that is syntactically incorrect, X29SRV
responds with the following error message at the console when it
processes the SYS:X29SRV.INI file at startup time:
?Illegal X29SRV command <text>
<diagnostic>
where <text> is the text string that X29SRV acknowledges reading from
the SYS:X29SRV.INI file and <diagnostic) is the explanation why X29SRV
thinks the command is incorrect.
Following are samples of X29SRV
detection of syntactical errors.
For example, a misspelling of the
parameter "HERALD" in the command line:
DEFINE HERRALD clark College Atlanta, Georgia
may cause the following response:
?Illegal X29SRV command "DEFINE HERRALD Clark College Atlanta, Georgia"
Unrecognized switch or keyword: "HERRALD"

D-3

X.29 CONFIGURATION FILE
Too much of abbreviation in the command line (for
intended to represent CIRCUITS in this command) :

example,

"C"

DEF MAX C 8
may cause ambiguity as follows (There are two parameters
with the character "C" -- CIRCUITS and CONNECT ERRORS):

that

start

?Illegal X29SRV command ."DEF MAX C 8"
Ambiguous switch or keyword: "C"

D.3.2

DEFINE DEFAULT HOST Command

This command, if enabled, lets you automatically connect the X.29
terminal to the TOPS-l~ host system without specifying the CONNECT
command. This may be desirable if the TOPS-l~ PSI Gateway services
only one TOPS-l~ system. If your PSI Gateway node services more than
one TOPS-l~ host system, and this command is used, the X.29 terminal
will be connected to the system that has X29SRV running.
Syntax:
DEFINE DEFAULT HOST control
Arguments:
control

is one of the following:
DISABLED
ENABLED

Messages:
None
Remarks:
If control is ENABLED, the default X.3 parameter set will be used
to define the terminal connection characteristics.
Default control is DISABLED.
Example:
DEFINE DEFAULT HOST ENABLED

D-4

X.29 CONFIGURATION FILE
D.3.3

DEFINE HERALD Command

This command defines the herald text to be displayed at
terminal at the beginning of the X.29 terminal session.

the

user's

Syntax:
DEFINE HERALD

text

Arguments:
text

the herald text in the format of a list of octal
representation of a-bit bytes, quoted and unquoted
strings of up to 2~47 characters in length.
An
unquoted string
is only allowed to be the last
element of the list, and it must be terminated by
a carriage return.

Messages:
None
Remarks:
X29SRV automatically adds a pair of carriage return and line feed
characters at the end of the herald text string if none are
there.
Default is no herald text.
Example:
DEFINE HERALD 15,12,"Digita1 Equipment Corporation ETC, Va1bonne",15,12
DEFINE HERALD Clark College, Atlanta Georgia

D.3.4

DEFINE MAXIMUM CIRCUITS Command

This command defines the maximum number of simultaneously active
terminal connections serviced by X29SRV.

X.29

Syntax:
DEFINE MAXIMUM CIRCUITS count
Arguments:
count

number of circuits range from 1 to

2~.

Messages:
NUMBER OF MAXIMUM CIRCUITS EXCEEDED LIMIT
The specified number of maximum circuits that
be active simultaneously exceeded 2~.
Remarks:
Default is 8.
Example:
DEFINE MAXIMUM CIRCUITS 16
D-5

can

X.29 CONFIGURATION FILE
0.3.5

DEFINE MAXIMUM CONNECT ERRORS Command

This command sets the limit of the allowed number of unsuccessful
attempts to connect to a host system on the DECnet network before the
connection between the PAD and the TOPS-10 PSI Gateway is terminated.
Syntax:
DEFINE MAXIMUM CONNECT ERRORS count
Arguments:
count

number of attempts allowed.

Messages:
None
Remarks:
Default is 1.
Example:
DEFINE MAXIMUM CONNECT ERRORS 3

0.3.6

DEFINE NETWORK Command

This command notifies X29SRV of the PPSN that the TOPS-l~ PSI Gateway
software is connected to.
This command is necessary only when the
PPSN that your system is connected to does not provide the full
implementation of CCITT X.3, X.28 and X.29 interface.
Syntax:
DEFINE NETWORK name
NETWORK CLASS number
Arguments:
name

is the name of the PPSN.
following PPSN names:
DATEX-P
PSS
TELENET
TRANS PAC
TYMNET

X29SRV

recognizes

Federal Republic of Germany
The United Kingdom
The United States
France
The United States

D-6

the

X.29 CONFIGURATION FILE
number

The class of the PPSN.
Some of the leading PPSN
vendors
market
their
network
software and
technology to other PPSN vendors.
The network
class identification is a means used by X29SRV to
classify similar PPSNS with those it is familiar
with.
Class
0
1
2
3
4

Network
DATAPAK
TELENET
TRANS PAC
DATEX-P
DATANET-1
PSS
TYMNET

Country
Norway
The United States
France
Federal Republic of
Germany
The Netherlands
The United Kingdom
The United States

Messages:
UNKNOWN NETWORK CLASS
The specified Network
recognized by X29SRV.

Class

number

not

Remarks:
If your PPSN name is not on the above network name list, contact
your DIGITAL software specialist for your PPSN's network class.
Example:
DEFINE NETWORK DATEX-P
DEFINE NETWORK CLASS 4

D.3.7

DEFINE PROMPT Command

This command lets you define the prompt text string that is displayed
at the user's terminal in X29SRV's Command Mode when it is ready to
receive user's commands.
Syntax:
DEFINE PROMPT text
Arguments:
text

the prompt text in the format of a list of octal
representation of a-bit bytes, quoted and unquoted
strings of up to 127 characters in length.
An
unquoted string is allowed only to be the last
element of the list, and it must be terminated by
a carriage return.

Messages:
None
Remarks:
Default is no prompt.

D-7

X.29 CONFIGURATION FILE
Example:
DEFINE PROMPT 15,12,"Please, enter CONNECT host",15,12,12
DEFINE PROMPT X29SRV>

0.3.8

DEFINE RESPONSE Command

This command determines the verbosity of X29SRV
remote terminals.

while

servicing

the

Syntax:
DEFINE RESPONSE control
Arguments:
control

is one of the following:
QUIET
VERBOSE

Messages:
None
Remarks:
Default is QUIET.
Example:
DEFINE RESPONSE VERBOSE

D.3.9

DEFINE REVERSE CHARGING Command

This command allows X29SRV to accept incoming calls with the reverse
charge facility (such as calls that originate from public PAD
facilities of the PPSN).
Otherwise, those incoming calls
are
rejected.
Syntax:
DEFINE REVERSE CHARGING control
Arguments:
control

is one of the following:
ALLOWED
DISALLOWED

Messages:
None
Remarks:
Default is ALLOWED.

D-8

X.29 CONFIGURATION FILE
Example:
DEFINE REVERSE CHARGING DISALLOWED

0.3.10

DEFINE SET Command

This command defines various sets of CCITT and national X.3 par~meters
to be requested by the users to define the characteristics of their
terminal connections. The maximum number ~f X.3 parameter sets that
can be defined is 18 (including the default parameter set DEFAULT).
See Section 0.4 for a description of the CCITT X.3 parameters.
Syntax:
DEFINE SET DEFAULT list
name list
Arguments:
name

is the text string representing the name of the
X.3 parameter set of up to 6 characters in length.

list

is the list of the CCITT and national
X.3
parameters to be defined in the set. The list has
the following format:
parameter:value [, parameter:value]
where parameter is the X.3 parameter number ranges
from 1 to 127 and value is the associated X.3
parameter value.
All values are in decimal.
X29SRV will not attempt to validate the X.3
parameter values. The values however must not be
greater than 255 decimal.

Messages:
NUMBER OF X.3 PARAMETER SETS EXCEEDED LIMIT
You have defined more than 17 X.3 parameter sets.
DUPLICATED NATIONAL X.3 PARAMETER DEFINITION
You have specified more than one
parameter separator
(see remarks
list of X.3 parameters.

national X.3
below) in the

X.3 PARAMETER NUMBER IS OUT OF RANGE
The value of an X.3 parameter number
the range of 1 to 127 decimal.

outside

greater

X.3 PARAMETER VALUE OCCUPIES MORE THAN ONE OCTET
The value of an X.3
than 255 decimal.

0-9

parameter

value

X.29 CONFIGURATION FILE
Remarks:
The reserved X.3 parameter set name
default X.3 parameter set.

DEFAULT,

which

the

When you specify the list of X.3 parameters, you can include the
national X.3 parameters in the list by preceding them with the
X.3 separator 0:0.
The national X.3 parameter numbers may range
from 1 to 127. The number of defined national X.3 parameters in
each set should not exceed 45.
X29SRV will not attempt to
validate the X.3 parameter values.
However, the values must not
be greater than 255 decimal.
If X29SRV encounters errors while processing the parameter
definitions,
the entire X.3 parameter set is discarded and the
set name will be undefined.
Example:
DEFINE SET DEFAULT 1:1,2:0,3:0,4:1,5:1,9:0,11:2,15:1,16:127,17:21,18:18
DEFINE SET EMACS 0:0,57:1,63:0
DEFINE SET VMS 3:2,4:0,0:0,57:1,63:0

0-10

X.29 CONFIGURATION FILE
D.4

VALUES OF THE PAD PARAMETERS

This appendix assumes that your n~twork suppots PAD~ that conform to
the CCITT X~3 Recommendation of 1980. Table D-1 provides a summary of
the PAD parameter values.
Table D-l:

Summary of PAD Parameter Values

Parameter
Number

Values

0, 1
32-126 (optional)

O,1

0, 2, 126
6, 18 (optional)

0, 2O, 255
1-19, 21.-254 (optional)

fJ, 1

0, 2, 8, 21
1 (optional)

0, 1

O-7

1fJ

fJ, 1-255

fJ, 2, 8
1, 2, 4-7, 9-18 (optional)

fI,

fJ, 1, 4, 5, 6, 7

fJ-7

fJ, 1

fJ-127

24
0-23, 25-127 (optional)

fJ-127

0-11

X.29 CONFIGURATION FILE
D.4.l

Parameter 1 - PAD Recall Using a Character

This parameter controls the action of the PAD on receipt of a OLE
«CTRL/P»
from the terminal, when the PAD is in the Data Transfer
state. The parameter values are:
No escape from the Data Transfer state
except with break signal (see parameter 7)

allowed,

Escape from the Data Transfer state to the Waiting
for Command state occurs when a DLE is received from
the terminal

32-126

Escape from the Data Transfer state to the Waiting
for Command state occurs when the graphic character
specified by the ASCII code (decimal) given here is
received

The preferred value of this parameter for an X.29 terminal is Ii
this allows interaction with the PAD (for example, to read the
values of PAD parameters) •

D.4.2

Parameter 2 - Echo

This parameter determines whether the PAD echoes characters received
from the terminal. The parameter values are:
~

The PAD does not echo.

The PAD echoes, except when buffer space limitations
cause it to ignore a character from the terminal.

D.4.3

Parameter 3 - Selection of Data Forwarding Signals

This parameter defines which characters (received from the terminal)
cause the PAD to forward the current packet to the host DECsystem-l~
computer. The parameter values are:

6
18

126

0-12

X.29 CONFIGURATION FILE
These values are a combination of one or more of the following:
Forwarding on receipt of the 129th character
1

Alphanumerics, that is, A-Z, a-z, and 0-9

<RET>

<HT>, <LF>, <VT>, <FF> \

All other control characters not in the above list.

The value 6 is the combination of 2+4, 18 is the
2+16, and 126 is the combination of 2+4+8+16+32+64.

combination

The PAD never transmits empty data packets.
The PAD normally
includes the forwarding character in the packet it causes to be
forwarded.
If the packet is full, the PAD includes the forwarding
character in the next packet.

D.4.4

Parameter 4 - Selection of Idle Timer Delay

This parameter controls whether there is data-forwarding
and, if so, its length. The parameter values are:

timeout

No data forwarding timeout
20

Data forwarding timeout of 1 second

255

Data forwarding timeout of 12.75 seconds

1-19,21-254

The data forwarding timeout length in
1/20 second

D.4.5

units

the

Ancillary device control (the PAD transmits X-ON
X-OFF to the terminal)

and

Parameter 5 - Ancillary Device Control

This parameter enables or disables ancillary device control
terminal by the PAD. The parameter values are:
No ancillary device control
1

D-13

X.29 CONFIGURATION FILE
0.4.6

Parameter 6 - Control of PAD Service Signals

This parameter determines whether PAD service signals are suppressed
or transmitted to the terminal. The parameter values are:

PAD service signals suppressed

PAD service signals transmitted to your terminal

PAD service signals and the prompt PAD service signal
transmitted to the terminal

0.4.7

Parameter 7 - Action of PAD on Receipt of Break Signal

This parameter specifies the action to be taken by the PAD on
receipt of a BREAK signal from the terminal. The parameter values
are:

o
1

These values are a combination of one or more of the following:
No action or receipt of (BREAK)
1

The PAD sends an interrupt to the TOPS-10 system

The PAD sends a reset to the TOPS-10 system

The PAD sends an Indication Break PAD message to
TOPS-10 system

The PAD leaves the Data Transfer state and enters the
Waiting for Command state

The PAD discards output to the
parameter 8 to the value 1

terminal

the

setting

where 21 is a combination of 1+4+16.

D.4.8

Parameter 8 - Discard Output

This parameter specifies that the PAD delivers data to the terminal.
The parameter values are:

Normal data delivery

No data delivery to the terminal; the PAD
any data received from the host computer

D-14

discards

X.29 CONFIGURATION FILE
D.4.9

Parameter 9 - padding After Carriage Return

This parameter specifies the number of padding
<RET>. The parameter values are:

characters

after

No padding after <RET>

1-7

One to seven padding characters inserted after <RET>

D.4.1~

Parameter

- Line Folding

This parameter specifies whether or not line folding is to be
performed, and, if so, it specifies the maximum length of the line •.
The parameter values are:
~

No line folding performed

1-225

Enables line folding and specifies the maximum line
length for all data transmitted or echoed by the PAD
to the terminal

Parameter 11 - Speed of Start-Stop Mode Terminal

D.4.11

This parameter specifies the receive-transmit
terminal.
The parameter values are:
~

1
2
3
4
5
6
7
8
9
1~

11
12
13
14
15
16
17
18

speed

the

user

the

bits/s
11~
134.5 bits/s
bits/s
3m~
bits/s
12~~
bits/s
6~~
75 bits/s
bits/s
15~
bits/s
18~~
bits/s
2~~
bits/s
1~~
bits/s
5~
bits/s
75/12~~
bits/s
24~~
bits/s
48~~
bits/s
96~'"
192"'''' bits/s
48"''''''' bits/s
bits/s
56"'~~
bits/s
64~"'~

Note that the support of any of these values
supported data transmission rates of the PAD.

depends

Neither the terminal nor the host computer can set parameter 11.
The PAD sets this parameter by detecting the line rate from the
Service Request sequence from the terminal.

D-15

X.29 CONFIGURATION FILE
0.4.12

Parameter 12 - Flow Control of the PAD

This parameter enables or disables flow control of data between
PAD and the terminal. The parameter values are:

No flow control on

Flow control on (that is, the PAD
«CRTL/Q»
and X-OFF «CRTL/S»
terminal) •

0.4.13

the

responds to X-ON
transmitted by the

Parameter 13 - Line Feed Insertion After Carriage Return

This parameter controls <LF> insertion after <RET>.
values are:

The

parameter

No <LF> insertion

<LF> inserted after every <RET> transmitted (but
echoed) to the terminal

not

<LF> inserted
terminal

every

<RET>

echoed

the

<LF> inserted after every
echoed to the terminal

<RET>

transmitted

and

<LF> inserted after every <RET> echoed to
terminal and transmitted to the host computer

the

<LF> inserted after every <RET> transmitted to your
terminal, echoed to the terminal, and transmitted to
the host computer

0.4.14

after

Parameter 14 - Padding After Line Feed

This parameter specifies the number of padding
<LF>. The parameter values are:

characters

after

No padding after <LF>

1-7

One to seven padding characters inserted after a <LF>

0.4.15

Parameter 15 - Editing

This parameter determines whether buffer editing is available
in the Data Transfer state. The parameter values are:

while

No editing in the Data Transfer state
1

Editing in conjunction with parameters 16, 17 and 18.

0-16

X.29 CONFIGURATION FILE
0.4.16

Parameter 16 - Character Delete

This parameter specifies if character deleting in the Data Transfer
state is enabled and, if so, it specifies the character delete
character. The parameter values are:

No character delete in the Data Transfer state

1-127

The decimal code of the character
Character Delete character

0.4.17

chosen

the

Parameter 17 - Line Delete

This parameter specifies if line (or buffer) deleting in the Data
Transfer state is enabled and, is so, it specifies the line delete
character. The parameter values are:
No buffer delete in the Data Transfer state
be

the

If parameter 4 (data forwarding timeout) is set to a low value,
PAD will forward the data before you have time to edit it.

the

1-127

0.4.18

The decimal code of the character chosen
Buffer Delete character

Parameter 18 - Line Display

This parameter specifies if line displaying is enabled and, if so,
specifies the Line Display Character. The parameter values are:
1-127

The decimal code of the character chosen
line display character

D-17

the

APPENDIX E
BIBLIOGRAPHY

The following DIGITAL documents contain detailed information on the
protocols used in DECnet. The appendix section of the Overview of
Digital Networking Products contains a complete list of DECnet
manuals as well as manuals pertinent to DECnet, such as Ethernet and
PSI.
Each of the following subtitles is preceded by "DECnet DIGITAL
Network Architecture" and followed by "Functional Specification" or
(for DDCMP) "Specification" (except for Introduction to DECnet).
Introduction to DECnet
General Description
This is an overview of the
provides an introduction
following documents.

architecture
to each of

and
the

Data Access Protocol (DAP)
Digital Data Communications Message Protocol (DDCMP)
Maintenance Operation Protocol (MOP)
Network Management Protocol
Network Services Protocol (NSP)
Routing
Session Control
The following lists CCITT recommendations relevant to users of the
TOPS-10 PSI software and the CCITT publications in which those
recommendations are discussed.
For more information, contact the
CCITT.

E-I

BIBLIOGRAPHY
Recommendation

Document

X.3

Document AP VII-No.

6-E

X.2S

Document AP VII-No.

X.28, X.29

Document AP VII-No.

The following document contains a complete and unabridged form of the
key CCITT recommendations as they appear in the Fascile VIII.2 of the
Yellow Book of the Consultative Committee for International Telegraph
and Telephone, 1981 edition.
The X.2S Protocol and Seven Other Key CCITT Recommendations X.l,
X.2,
X.3,
X.21
bis,
X.28, and X.29.
Lifetime Learing
Publications, Belmont, California, 1981
The following published books are a source of general network
information.
The list is both arbitrary and abbreviated and is
intended to be a catalyst to stimulate the reader's interest.
Title

Author

Publisher

Application Design Handbook
for Distributed Systems

Patrick,
Robert L.

CBI Publishing Co.

Basics of Data Communication

Karp, ed.

McGraw-Hill

Communications Networks for
Computers

Davies and
Barker

Wiley and Sons

Computer Networks and
Distributed Processing:
Software, Techniques,
and Architecture

Martin,
James

Prentice-Hall

Data Communications

Doll

Wiley Interscience

Design and Strategy
for Distributed Data
Processing

Martin,
James

Prentice-Hall

Handbook of Data
Communications

Editors

National Computing
Centre Publications
(United Kingdom)

Introduction to Data
Communications

Murphy and
Kalis

DIGITAL
DIGITAL

Introduction to MiniComputer Networks
Introduction to
Teleprocessing

Martin,
James

Prentice-Hall

Technical Aspects of Data
Communication

McNamara,
John E.

DIGITAL

E-2

APPENDIX F
DECnet LINE DEVICES

Table F-l:

DECnet Line Devices

Mnemonic

Multiline

Multipoint

DECnet-I"
Support

TOPS-I" PSI
Support

Yes

CI20
Computer
interconnect

DAII-B
DAII-AL
link

DLII-C,
DLll-WA,
and
DLll-E
asynchronous
line interface

DLV

DLVll-E
asynchronous
lin'e interface
(11/03
and
11/23 onl y)

DMC

Yes (MCB)

DMCll-DA/AR,
DMCll-MA/AL,
DMCII-MD/AL,
DMCII-FA/AR
interprocessor
links

DMR

Yes (MCB)

DMRll-AA,
DMRII-AB,
DMRll-AC,
DMRII-AE
interprocessor
links

DMF

DMF-32
synchronous
line unit

F-I

Description

or
UNIBUS

DECnet LINE DEVICES
Table F-l:

DECnet Line Devices (Cont.)

Mnemonic

Multiline

Multipoint

DECnet-lCtJ
Support

TOPS-lCtJ PSI
Support

DMP

Yes

DMP-ll
multipoint
synchronous
line device

DPll-DA
synchronous
line interface

DPV

DPVll-DA
synchronous
line interface

DQll-DA
synchronous
line
serial
interface

DTE

Yes

DTE20
interprocessor
link

DUll-DA
synchronous
line interface
(includes
DUVll)

DUP

Yes (MCB)

DUP-llDA
synchronous
line interface

Yes

DVll-AA/BA NPR
synchronous
line
multiplexer

ETH

Yes

NIA20
multiaccess
communications
link

KDP

Yes

KMC-ll/DUP-ll-DA
NPR synchronous
line
multiplexer

F-2

Description

DECnet LINE DEVICES
Table F-l:

DECnet Line Devices (Cont.)

Mnemonic

Multiline

Multlpoint

DECnet-l9
Support

TOPS-l9 PSI
Support

KDZ

Yes

KMC-ll/DZll
NPR
-A/B/C/D
asynchronous
line
multiplexer

serial
KL8-J
line interface

KMV

Yes

KMSll-BD/BE
synchronous
line interface
combined
with
level 2
X.25
microcode

KMX

Yes

KMSll-BD/BE
synchronous
line interface
combined
with
level 2
X.25
microcode

KMY

KMSIl-PX
synchronous
line interface
combined
with
level 2
X.25
mircrocode

PCL

Yes

PCLll-B
multiple
link

Description

CPU

QNA

Yes

DEQNA
multiaccess
communications
link

Yes

DZll-F, DZ32-F,
or
DZVll-D
asynchronous
serial
line
multiplexer

DMF-32/DMZ-32
asynchronous
line unit

F-3

DECnet LINE DEVICES
Table F-l:

DECnet Line Devices (Cont.)
Multiline

Multipoint

DECnet-l~

TOPS-l~

Mnemonic

Support

Yes

PSI
Description
NIA2~

multiaccess
communications
link

F-4

APPENDIX G
GLOSSARY

The definitions and explanations in
their use in this manual.

this

glossary

are

specific

Active

A designation for plural entities that
limits
them to those that meet an
activity criterion.
The criterion is
defi~ed individually for each entity.

Active lines

Known lines in the ON or SERVICE state.

Active 109ging

All known sink types that are in the
or HOLD state.

Active nodes

All reachable nodes
the executor node.

Adjacent node

A node connected to the executor node by
a single physical line.

Aged packet

A packet that has exceeded
number of visits.

Area

A group of nodes in a network that
run independently as a subnetwork.

Area router

A level 2 router.

Area routing

A technique for grouping the nodes in a
network into areas for routing purposes.
Routing in a multiple-area network is
hierarchical, with one level of routing
within an area (called level 1 routing)
and a second, higher level of routing
between areas (called level 2 routing).

perceived

the

ON
from

maximum
can

Bilateral Closed User Group (BCUG)
An optional PPSN facility that restricts
a pair of DTEs to communicating with
each other.
The
basic
BCUG
also
prevents this pair from accessing or
being accessed by other DTEs. Additions
to the BCUG facility allow one or both
of the DTEs to access or be accessed by
DTEs outside the group. These additions
are known as BCUG with Outgoing Access
and
BCUG
with
Incoming
Access
respectively. See also related Closed
User Groupo

G-l

GLOSSARY
Broadcast addressing

A special type of multicast addressing,
in which a message is sent to all nodes.

Broadcast circuit

A circuit on which multiple nodes are
connected and on which there is a method
for transmitting a message that will be
received by multiple receivers.

CCITT

Comite
Consultatif
International
Telegraphique
et
Telephonique.
An
international
consultative
committee
that sets international communications
usage standards.

Central Management Node

Any node that is capable of parsing all
DNA NCP commands, including those that
the central management node cannot or
does not implement for its operating
system. A central management node is
capable of managing the entire network
of which it is a member; it can set
parameters and initiate and terminate
the operation of nodes, circuits, lines,
and
events
and
alter the logical
configuration of the network.

Characteristics

Parameters that are generally static
values in volatile memory or permanent
values in a permanent data base.
A
Network
Management information type.
Characteristics can be set or defined.
Examples
of characteristics are the
values assigned in response to
the
keywords NAME, TYPE, and LOAD FILE.

Circuit

A logical point-to-point connection.
A
circuit
is
identified
by
device,
controller, unit, and
(if
present)
tributary. For example, KDP-2-0.l.

Closed User Group (CUG)

An optional PPSN facility that restricts
two or more DTEs in the same group to
communicating with each other.
The
basic CUG also prevent~ these DTEs from
accessing or being accessed by other
DTEs outside the group. Additions to
the basic CUG facility allow one or more
DTEs to ,access or be accessed by DTEs
outside the group. These additions are
known as CUG with Outgoing Access and
CUG with Incoming Access respectively.

Command node

The
node
originates.

Controller

That part of a line identification that
denotes the control hardware for a line.
For a multiplex device, that controller
is responsible for one or more units.
For example, in the line identification
KDP-0-l, the controller is KMC-0.
(The
KDP is a KMC controller with up to four
DUPs.)

G-2

where

NCP

command

GLOSSARY
Cost

An integer value assigned to a circuit
between two adjacent nodes. According
to the routing algorithm, packets are
routed on paths with the lowest cost.

Counters

Error and performance statistics
on a node's network activity.

Datagram

A unit of data sent over the network
that is handled independently of all
other units of data so far as the
network is concerned.
When a route
header is added, a datagram becomes a
packet.

Data Link

A physical connection between two nodes.
In the case of a multipoint line, there
can be multiple data links for one
physical connection.

Data Transmission

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

DCE

Data Communications Equipment (DeE)
is
an X.25 PPSN node to which a DTE is
connected
with
a
leased
data
communications line.

DOCMP

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

Designated router

A routing node on the Ethernet selected
to perform routing services on behalf of
end nodes.

OMCll

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

DMRll

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

DN2~

The

Oownline Loading

Transmitting a program's memory image
over a physical link to an adjacent node
and starting execution of it.

DTE

Data Terminal Equipment (DTE) is a host
processor or communications processor
directly connected to an X.25 PPSN with
a leased data communications line.

DTE29

The hardware interface between the main
processor in a DECsystem-1090/I09II095
and the PDP-II processor in the DN20
communication front end.

DECnet-l~

G-3

based

communication front end.

GLOSSARY
End node

A node
that
can
rec~ive
packets
addressed to it and send packets to
other nodes, but cannot route packets
through from other nodes. Also called a
nonrouting node.

Entity

AREA, CIRCUIT, LINE, LOGGING, MODULE, or
NODE.
These are ~he major Network
Management keywords.
Each entity has
its
own
parameters
and
options.
CIRCUIT, LINE, and NODE have counters
also.
Allowed plural forms are KNOWN
and ACTIVE AREAS,
CIRCUITS,
LINES,
MODULES and NODES. NODES can also take
the form LOOP NODES.
Entities
are
components that can be displayed and
controlled.

Ethernet

A communications concept
for
local
communication
networks, which employ
coaxial
cable
as
a
passive
communications medium to interconnect
different kinds of computers, without
requiring switching logic or control by
a central computer

Ethernet protocol

In the data-link layer of DNA (DIGITAL
Network Architecture), the protocol that
implements
the
Ethernet
data-link
protocol
for
communication
between
adjacent nodes connected by an Ethernet
local area network.

Event

A network- or system-specific occurrence
for which the logging entity maintains a
record.

Event Class

A subset of events, currently consisting
of groups of events associated with each
of the DNA layers or with specific
operating systems.

Event Filter

A set of on/off states for a logging
event class that indicates whether or
not each event type in that class is to
be recorded.

Event Type

A particular type of
within an event class.

Executor Node

The node where the active Local Network
Management Function is running (that is,
the
node
actually
executing
the
command);
the
active
network node
physically connected to one end of a
line
being used for a load, dump,
trigger, or line loop test.

Frame

A unit, delimited
by
flags,
that
includes a header used by the link level
to exchange data packets as well as
control and error information between
the DTE and DCE.

G-4

event,

unique

GLOSSARY
Full-duplex

Simultaneous independent transmission in
both directions.

Full Routing Node

A node that allows communication between
non-adjacent nodes.
If all nodes in a
network are full routing nodes, then
each node can communicate with every
other node in the network.

Global Filter

A filter that applies to all entities
within an event class and type.

Half-duplex

Transmission in either direction, but
not in both directions simultaneously.

Hardware address

For an Ethernet device, the
unique
Ethernet
physical address associated
with
a
particular
Ethernet
communications controller (usually in
read-only memory) by the manufacturer.

Hold State

A logging state in which the sink is
temporarily unavailable and events for
it should be queued.

Hop

A hop is one unit of path length.
When
a request is routed from node A to node
C by way of Node B, two hops are
involved:
node A to node B is one hop;
node B to node C is another hop.
(See
path cost.)

Host Computer

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

Host Node or Host

The node that provides services for
another node (for example, the storage
of files needed for a downline load).

Information Type

One
of
CHARACTERISTICS,
COUNTERS,
EVENTS, or SUMMARY. Used with the NCP
SHOW command to control the type of
information
returned.
Each
entity
parameter and counter is associated with
one or more information types.

KOP

A OECnet term
that
refers
to
a
combination of a KMCII (controller) and
one to four OUPlls. With the KMCII, a
microprocessor-based system, the DUPII
functions as a direct memory access
device. The interface to the network is
synchronous.

KNOWN

The classification for a plural entity
that includes all perceived occurrences
of the entity type.

G-5

GLOSSARY
KNOWN LINES

All
lines
addressable
by
Network
Management in the appropriate data base
(volatile or permanent) on the executor
node.
They may not all be in a usable
state.

Level 1 router

A node that can send
and
receive
packets, and route packets from one node
to another, only within a single area.

Level 2 router

A node that can send
and
receive
packets, and route packets from one node
to another, within its own area and
between areas.
Also known as an area
router.

Line

A distinct physical data path.
a Network Management entity.

Line Cost

An arbitrary positive integer
value
assigned to a physical path. Because
the routing
algorithm
selects
the
least-cost path to a destination, an
operator can dynamically affect the path
to be taken by changing line costs.

Line Identification

The device, controller, unit
and/or
tributary assigned to a line. Examples
are KDP-0-1, DMC-I.

Line Level Loopback

Testing a specific data link by sending
a repeated message directly to the data
link layer and over a wire to a device
that returns the message to the source.

Load

To read data into memory.

Local DTE

The communications node that connects to
the public network.

Local Node

From the user's standpoint, a relative
term indicating the node at which your
terminal is logged in.
From Network
Management's standpoint, the node at
which your requested task executes.
If
at your local node you SET the executor
to another node, that other node is the
local node to Network Management and the
node where your terminal is attached is
a remote node.

Local User

A user of the User Acess Module who
communicates with the public network
through the node running TOPS-10 PSI
Gateway Software. Also called user.

G-6

Line

GLOSSARY
Logging

Recording information from an occurrence
that has potential significance in the
operation and/or maintenance of
the
network in a potentially permanent form.
Logging is the Network Management entity
that routes event data to logging sinks
such as a console or file.
Logging
sinks can be accessed by persons and/or
programs.

Logging Console

A logging sink that is to receive a
human-readable record of events, for
example, a terminal or printer.

Logging Event Type

The identification of a particular type
of event, for example, a line restarted
or a node down.

Logging File

A logging sink that is
machine-readable record
later retrieval.

Logging Identification

The sink type associated
with
the
console, or
logging
entity
(file,
monitor) •

Logging Monitor

A logging sink that is to receive a
machine-readable record of events for
possible real-time
decision
making.
Typically, the logging monitor is a
user-defined program.

Logging Sink

A place where a copy of an event
be recorded.

Logging Sink Flags

A set of flags in an event record that
indicate the sinks on which the event is
to be recorded.

Logging Sink Node

A node
comes.

Logging Source Process

The process that recognized an event.

Logical Connectivity

The ability of nodes to communicate with
each other.

Logical Link

A node-to-node
connection
that
established
and
controlled
by
Session Control, Network Services,
Routing layers.

Loopback

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

G-7

which

to
of

logging

receive a
events for

information

is
the
and

GLOSSARY
Loopback Node

A special name for a node that is
associated with a line for loopback
testing purposes. The SET NODE CIRCUIT
command sets the loopback node name. A
loopback node is treated as if it were a
remote
node.
All
traffic to the
loopback node is
looped
over
the
associated line.

Maximum Cost

The greatest total cost the path to a
node may have if the node is to be
reachable.
When the cost associated
with transmitting a message from one
node to another exceeds the maximum
cost, the transmission is not made.

Maximum Hops

The maximum number of hops a path to a
node can contain if the node is to be
reachable. Currently, the maximum hops
supported is 30.

Maximum Visits

The maximum number of nodes a message
coming into this node can have visited.
If the number specified as
MAXIMUM
VISITS is exceeded, and the destination
is not this node, then the message is
discarded.

Maximum Node Address

The largest node address with which
local node can communicate.

Maximu~

Path Cost

the

The greatest value assigned to
the
least-cost path between any two nodes in
the network.

Module

A network management component.

Multiaccess Channel

A medium (for example, Ethernet) on
which
many transmitters contend for
access.

Multicast Addressing

An addressing mode in which a given
message packet is targeted to a group of
logically related nodes.

Multicast Group Address

An address assigned to a number of nodes
on an Ethernet and used to send a
message to all nodes in the group in a
single transmission.

Multipoint Line

A line connected to more than two nodes.

Monitor Sinktype

An event sink that is to receive a
machine-readable record of events for
possible real-time decision making.

Network diameter

The reachability distance between the
two nodes on the network having the
greatest
reachability
distance.
Reachability distance is the length of
the shortest path between a given pair
of nodes.

G-8

GLOSSARY
Network Interconnect (NI)

A multiaccess interconnect that allows
up
to
1024
different stations to
communicate over the Ethernet.

Network Services Protocol
(NSP)

A formal set of conventions used in
DECnet to exchange messages over logical
links.
NSP also refers to the program
that implements the NSP protocol.
(In
the text of this manual, NSP refers to
the program; NSP Protocol is used to
refer to the protocol.) This protocol is
implemented by the End Communications
Layer of the DNA architecture.

Node

An computer system that supports DECnet.
Used alone in this manual, node implies
support of Routing, NSP, and Session
Control.
A node that does not support
these three layers is called a Phase II
node.
Node is a Network Management
entity.

Node Address

The
required
unique
numeric
identification of a specific node.

Node Identification

Either a node name or a node address.
In some cases, an address must be the
node identification. In other cases, a
name must be used. DECnet contains a
table for converting one to the other.

Node Level Loopback

Testing a logical link using repeated
messages that flow with normal traffic
through the Session Control, Network
Services, and Routing layers within one
node or from one node to another and
back. In some cases node level loopback
involves using a loopback node name
associated with a particular line.

Node Name

An
alphanumeric
identification
associated with a node address in a
strict one-to-one mapping.
The node
name must contain at least one letter
and cannot be more than six characters
long.

Nonrouting Node

An end node. It can deliver and receive
packets,
but
cannot route messages
through to other nodes.

Off State

Applied to a node:
a state
where
network traffic is no longer processing.
Applied to a line: a state where the
line is unavailable for any kind of
traffic. Applied to logging:
a state
where the sink is not available for
receiving events; in this state any
events
for the sink are discarded.
Applied to circuits:
the state where
the
circuit is not in use by any
network-related software.

G-9

GLOSSARY
On State

Applied to a node: a state of normal
network operation.
Applied to a line:
normal
a state of availability for
a state
usage.
Applied to logging:
where a sink is available for receiving
events.

OPR

OPR is the Operator Command Language
program that provides the operator with
one command language to communicate with
several
TOPS-10
components.
CPR
processes commands for syntax and passes
syntactically correct commands to ORION.
(See ORION.)

Originating Packet

A packet that originated in the
Services layer of a node.

ORION

ORION is the operator control program
that
accepts commands from OPR and
forwards the commands to the proper
program for execution. ORION forwards
NCP commands to the Network Control
Program.

Packet

A group of bits, comprising data and
control
information,
which
is
transmitted as a composite whole over a
physical link.
The data, control, and
any error information are arranged in a
specific format.
(A packet is the basic
transmission unit of DDCMP.)

Path

The route a packet takes from source
destination node.

Path Cost

The sum of the line costs along a
between two nodes. See line cost.

path

Path Length

The sum of the hops along a path between
two nodes.

Permanent Data Base

Default
information
about
network
entities
that is kept in permanent
memory (for example, files).
Generally
established at network generation. A
permanent data base can be changed with
the NCP commands PURGE and DEFINE; you
can change the volatile data base with
CLEAR and SET commands. DECnet-l0 does
not support a permanent data base.

Network

Permanent Virtual Circuit (PVC)
A virtual circuit always associated with
the
same
remote DTE address.
The
software references a PVC by its logical
channel
number
(LCN).
The public
network
vendor
establishes
the
correspondence between a PVC and its
LCN.

G-l0

GLOSSARY
Physical Address

The unique address value associated with
a given system on an Ethenet circuit.
An Ethernet physical address is defined
to be distinct from all other physical
addresses on Ethernet.

Physical Connectivity

The condition of nodes being attached to
each other by active lines.

Physical Link

A
communication
path
between
two
adjacent nodes.
This can be a dial-up
line, radio, satellite link,
or
a
channel-to-channel connector such as a
DTE20.

Port

The resources required
virtual circuit.

PPSN

Public Packet Switching Network.

Plural Entity

A set of entities classified as
active, or loop (nodes only).

known,

Point-to-point

A circuit that connects two
operating over a single line.

nodes,

Processed Event

An event after local processing in final
form.

Protocol

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

Reachable Node

A node to which the executor node's
routing process believes it has a usable
communication path.

Remote DTE

The DTE on the public network with which
the local user in a DECnet network
wishes to communicate. The remote DTE
may give access to another network in
addition to the DECnet network of the
local user, and the public network with
which the local user communicates.

Remote Node

A node in a network
local node.

Remote Task

A task executing in a remote node.

Remote User

A user at the remote DTE with whom the
local user communicates over a virtual
circuit.

Restricted State

A node state where no new logical
from other nodes are allowed.

Routing

The network function that determines the
path along which data travels to its
destination.

Routing Node

A node that contains the full set of
Routing
modules,
and
can deliver,
receive, and route through packets.
G-II

that

manage

not

your

links

GLOSSARY
Server Task

An alternate designation for a task that
has declared itself willing to accept a
network connection, usually to provide
some system service.

Service Password

The
password
required
to
permit
triggering of a node's bootstrap ROM.

Service Slave Mode

That mode where the processor is taken
over and the adjacent, executor node is
in control, typically for execution of a
bootstrap program for downline loading
or for upline dumping.

Service State

A line state where such operations as
downline load, upline dump, or line
loopback are performed.
This
state
allows direct access to the line by
Network Management.

Shut State

A node state where existing logical
links are undisturbed, but new ones are
prevented.

Singular Entity

A specific entity; for example, a
a logging sink type, a node,
circuit.

Sink

See logging sink.

Sink Node

A node where
located.

Sink Type

A particular final
destination
for
logging events, either a file or a
console.

Source Node

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

Source Task

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

Specific Filter

A filter that applies to a specific
entity within an event class and type.

Status

Dynamic
information
relating
to
entities, such as their state. Status
is a Network Management
information
type.
Also,
a
message indicating
whether or not an NCP command succeeded.

Substate

An intermediate line state that appears
as a tag on a line state display.

Summary

An information type meaning the most
useful information for an entity; the
default if no information
type
is
requested.

G-12

logging

sink

types

line,
or a

are

GLOSSARY
Switched Virtual Circuit (SVC)

A temporary logical association between
two DTEs connected to a PPSN, analogous
to connection by a dial-up line. An SVC
is set only when there is data to
transmit; the SVC is cleared when the
data transfer is complete.

Target Node

The node that receives a memory image
during a downline load, generates an
upllne dump or loops back
a
test
message.

Terminal Server

An Ethernet node that enables a number
of
terminals
to
communicate
with
multiple host nodes.
Terminal servers
are connected to an Ethernet cable.
Terminals using the terminal server can
only communicate with DECnet hosts on
the Ethernet cable.

Terminating Packet

A packet whose destination is this node.

Topology

The_
physical
arrangement
and
relationship of interconnected nodes and
lines in the network. A legal topology
satisfies all DNA requirements.

Transit Packet

A packet arriving at this node from a
source node and intended for another
node.

Tributary

A physical termination on a multipoint
line that is not a control station.
Part of the line identification for a
multipoint line.

Unit

Part of a line/circuit identification.
Together with the controller, a unit
forms
a
station.
In
the
line
identification KDP-2-0, "KDP" identifies
the device (KMCll/DUPll), "2" identifies
the controller , and "0" identifies the
unit.

Unreachable Node

A node is unreachable when the path
length to that node is longer than the
maximum number of hops in the network.

Upline Dumping

Transmitting a copy of a memory image
over a line to a file at the host node.

Virtual Call

The process of establishing
circuit between two DTEs.

Virtual Circuit

A logical path between the user process
in a DECnet node and a cooperating
process in a remote DTE.
A virtual
circuit is similar to a DECnet logical
link.

G-13

virtual

GLOSSARY
Volatile Data Base

The volatile, or temporary data base
consists of dynamic values currently in
memory. It can contain parameters such
as
status, line or node state, or
characteristics, such as CPU type or
timer values, that remain constant until
cleared or reset.
Volatile data base
values are lost when the system shuts
down. When the system is first brought
up, data from the permanent data base,
if any, is read into the volatile data
base.
The operator can change certain
of these values with the
SET
NCP
command.
Changes made to the permanent
data base with the DEFINE command are
not reflected in the volatile data base
until the system is brought up again.
DECnet-10 does not support the permanent
data base.

X.3

A CCITT recommendation that spe~ifies
the Packet Assembly/Disassembly (PAD)
facility in a public data network.

X.2S

A CCITT recommendation that specifies
the
interface between Data Terminal
Equipment and Data Circuit-terminating
Equipment for equipment-operating in the
packet mode on public data networks.

X.29

A CCITT recommendation that specifies
procedures for the exchange of control
information and user data between a
packet-mode
DTE
and
a
packet
Assembly/Disassembly (PAD) facility.

G-14

INDEX

Access control, 4-5
parameters, 6-6
Accessing NCP commands, 4-5
Adjacent node, 2-1
Area entity, 7-i5
identification, 7-4
Area routing, 2-9
Areas, 2-9
Bibliography, E-l
Buffer size, 2-12
setting, 3-34
Buffers
maximum number of, 3-35
Cache, 2-11
CANCEL QUEUE REQUEST command, 6-5
CCITT recommendations, E-1
Changing network data bases, 7-16,
7-40
CHK11 output, 3-29
Circuit, 2-1
controlling state, 3-8
entity, 7-7
Circuit counters, 8-4
Circuit entity identification,
7-3
Circuit level loopback testing,
3-28
Circuits
Ethernet, 1-9
maximum number of, 3-35
CLEAR CIRCUIT command, 7-41
(X.25},8-19
CLEAR EXECUTOR command, 6-3
CLEAR EXECUTOR example, 6-4
CLEAR KNOWN CIRCUITS command,
7-41
(X. 25), 8-19
CLEAR KNOWN LINES command, 7-41
(X.25), 8-19
CLEAR KNOWN NODES command, 7-42
CLEAR LINE command, 7-41
(X.25},8-19
CLEAR LOGGING command, 7-41
CLEAR MODULE X25-ACCESS command,
8-20
CLEAR MODULE X25-ACCESS example,
8-20
CLEAR MODULE X25-PROTOCOL command,
8-20
CLEAR MODULE X25-PROTOCOL example,
8-20
CLEAR MODULE X25-SERVER command,
8-20
CLEAR MODULE X25-SERVER example,
8-20
CLEAR NODE command, 7-42

Command files
manual startup with, 3-4
Command input, 4-6
Command node, 2-1
in downline load, 3-13
Command output response, 4-6
Commands
CANCEL QUEUE REQUEST, 6-5
CLEAR CIRCUIT, 7-41
CLEAR EXECUTOR, 6-3
CLEAR KNOWN CIRCUITS, 7-41
CLEAR KNOWN LINES, 7-41
CLEAR KNOWN NODES, 7-42
CLEAR LINE, 7-41
CLEAR LOGGING, 7-41
CLEAR MODULE X25-ACCESS, 8-20
CLEAR MODULE X25-PROTOCOL~ 8-20
CLEAR MODULE X25-SERVER, 8-20
CLEAR NODE, 7-42
DEFINE EXECUTOR, 6-3
DUMP, 7-47
editing, 4-3
ENTER, 5-1
EXIT, 5-1
for network monitoring, 3-9
HELP, 6-8
LOAD, 7-48
LOOP, 7-51
LOOP CIRCUIT, 3-24
LOOP LINE, 3-24
LOOP NODE, 3-24
multiple lines, 4-4
NCP processed by NML, 7-1
OPR/NCP, 5-1
PURGE EXECUTOR, 6-4
PUSH, 5-1
RETURN, 5-1
SET CIRCUIT, 7-18
SET CIRCUIT (X.25), 8-2
SET CIRCUIT ALL, 7-17
SET EXECUTOR, 6-1, 7-29
SET EXECUTOR (X.25), 8-15
SET KNOWN CIRCUITS, 7-22
SET KNOWN CIRCUITS (X.25), 8-2
SET KNOWN NODES, 7-39
SET KNOWN NODES (X.25), 8-15
SE'r LINE, 7-23
SET LINE (X.25), 8-15
SET LINE ALL, 7-17
SET LOGGING, 7-39
SET MODULE CONFIGURATOR, 7-25
SET MODULE CONSOLE, 7-26
SET MODULE LOADER, 7-27
SET MODULE LOOPER, 7-27
SET MODULE X25-ACCESS, 8-5
SET MODULE X25-PROTOCOL, 8-6
SET MODULE X25-SERVER, 8-10
SET NODE, 7-29
SET NODE (X.25), 8-15

Index-l

Commands (Cont.)
SET NODE ALL, 7-17
SET NODE CIRCUIT, 7-27
SET NODE NAME, 7-28
SHOW, 7-44
SHOW MODULE (X.25), 8-16
SHOW QUEUE, 6-5
TAKE, 5-1
TELL prefix, 6-6
TRIGGER, 7-53
typing, 4-3
using comments, 4-4
WAIT, 5-1
X.25-specific, 8-2
X29SRV management, D-3
ZERO, 7-54
ZERO (X.25), 8-19
Comments
in commands, 4-4
Communications s~rver
downline loading, 3-21
Compatibility
Phase III/Phase IV, 2-13
CONFIGURATOR module, 7-14
Connecting remote console, 3-24
CONSOLE module, 7-15
Controlling node, circuit, DTE,
and line state, 3-8
Controlling the network, 7-47
Counters
circuit, B-4
DECnet-10 specific, B-1
Line, B-6
node, B-9
summary, B-1
X.25 Protocol module, B-12
X.25 server module, B-13
X.25 specific, B-2

DN20 (Cont.)
upline dump, 3-23
DN20 commmunications front end,
1-8
DN20 coummunications front end
see MCB
DNA
Data Link Layer, 1-8
End Communication Layer, 1-7
layered structure of, 1-3
major features of, 1-3
Network Application Layer, 1-7
Network Management Layer, 1-5
Physical Link Layer, 1-8
Routing Layer, 1-7
·Session Control Layer, 1-7
User Layer, 1-4
DNA model, 1-1
Downline loading, 3-13
bootstraps, 3-16
communications server, 3-21
DN20, 3-21
operator initiated, 3-14
requirements, 3-15
target initiated, 3-14
Downline loading parameters, 3-18
DTE
controlling state, 3-8
Dump
upline, 3-22
Dump assistance multicast address,
3-22
DUMP command, 7-47
DUMP example, 7-47

Data link control, 3-34
Data Link Layer (DNA), 1-8
Data Link Layer events, C-20
Data Link Watcher, 1-6
Data links, 2-1
DECnet counter summary, B-1
DECnet implementations, 1-10
DECnet line devices, F-l
DECnet restart procedures, 3-6
DECnet startup procedures, 3-1
DECnet-10
capabilities, 1-10
extensions, 7-2
hardware, 1-9
host services, 3-12
implementation, 7-2
Version 4.0 implementation, 1-8
DECnet-10 specific counters, 8-1
DEFINE EXECUTOR command, 6-3
Designated router (Ethernet),
2-11
DN20
downline loading, 3-21
events, 7-13

Editing commands, 4-3
End Communication Layer (DNA),
1-7
End Communication Layer events,
C-14
End node caching, 2-11
End nodes, 2-8
see Ethernet nodes
ENTER command, 5-1
Entities, 7-2
area, 7-15
area identification, 7-4
circuit, 7-7
circuit identification, 7-3
line, 7-7
line identification, 7-3
10gg ing, 7-10
logging identification, 7-4
Maintenance module, 7-14
MODULE (X. 25), 8-1
module identification, 7-5
node, 7-5
node identification, 7-4
Entity, 2-6
Entity identification, 7-3
Error messages
Nep, C-4
ERROR.SYS file, 3-10

Index-2

Ethernet
designated router, 2-11
end node caching, 2-11
Ethernet address
format of, 3-31
Ethernet circuit, 1-9
Ethernet multicast address, 3-32
Ethernet nodes, 2-8
Ethernet physical address, 3-32
Ethernet routers, 2-11
Event
processor, 1-6
receiver, 1-6
recorder, 1-6
transmitter, 1-6
Event classes, C-11
Event messages, C-ll
Events, 7-11
data link layer, C-20
DN20, 7-13
end communications layer, C-14
10ggings at remote node, 7-14
Network Management Layer, C-12
Routing layer, C-15
selecting, 7-12
session control layer, C-14
Examples
CLEAR EXECUTOR command, 6-4
CLEAR MODULE X25-ACCESS, 8-20
CLEAR MODULE X25-PROTOCOL, 8-20
CLEAR MODULE X25-SERVER, 8-20
DUMP, 7-47
LOOP, 7-52
LOOP LINE, 3-27
LOOP NODE, 3-25
OPR/NCP commands, 5-1
request for characteristics,
4-7
request for status of known
circuits, 4-7, 4-8
SET CIRCUIT, 7-22
SET EXECUTOR NODE, 6-2
SET KNOWN CIRCUITS, 7-23
SET KNOWN NODES, 7-39
SET LINE command, 7-25
SET LOGGING, 7-40
SET MODULE CONFIGURATOR, 7-26
SET MODULE CONSOLE, 7-26
SET MODULE LOADER, 7-27
SET MODULE X25-ACCESS, 8-6
SET MODULE X25-PROTOCOL, 8-10
SET MODULE X25-SERVER, 8-12
SET NODE, 7-38
SET NODE CIRCUIT, 7-27
SET NODE NAME, 7-28
SHOW, 7-45
SHOW MODULE (X.25), 8-16
SHOW QUEUE command, 6-5
SPEAR program, 3-11
TELL prefix, 6-7
TRIGGER, 7-54
ZERO, 7-54
ZERO (X.25), 8-19

Executor
specifying the, 4-8
Executor node, 2-1
in down1ine load, 3-13
EXIT command, 5-1
FAL program, 3-35
File Access Listener
see FAL program
File specifications
in NCP commands, 4-9
Gateway Access Library, 2-4
Gateway Access Protocol, 2-4
Generic format of NCP/NML
commands, 7-16
Glossary, G-l
Hardware
KL10, 1-9
KS10, 1-9
Help
from NCP, 4-4
HELP command, 6-8
Host node, 2-1
Hosting, 3-12
Informational messages, C-2
INITIA program, 3-1
KL10 hardware, 1-9
KS10 hardware, 1-9
Levell routers, 2-9, 2-10
Level 2 routers, 2-9, 2-10
Line
controlling state, 3-8
entity, 7-7
Line counters, 8-6
Line devices
DECnet, F-1
Line entity identification, 7-3
LOAD command, 7-48
LOADER module, 7-15
Loaders
primary, 3-15
secondary, 3-15
tertiary, 3-15
Loading
downline, 3-13
Local node, 2-1
Logging
entity, 7-10
event identification, 7-11
events at remote nodes, 7-14
parameters, 7-13
Logging entity identification,
7-4
Logical link, 2-1
LOOP CIRCUIT command, 3-24
LOOP command, 7-51
LOOP example, 7-52
LOOP LINE command, 3-24

Index-3

LOOP LINE example, 3-27
Loop Message Generator, 1-7
LOOP NODE command, 3-24
LOOP NODE examples, 3-25
Loopback Mirror, 1-7
Loopback tests, 3-24
LOOPER module, 7-15
Maintenance Module entity, 7-14
Managing X29SRV, D-l
Manual startup
with command files, 3-4
Manual startup of MCB, 3-3
Maximum address parameters, 3-30
MCB
manual startup of, 3-3
Mca software, 1-9
Messages
events, C-ll
informational, C-2
NCP command response, C-3
NCP error, C-4
network related, C-l
OPR/NCP syntax, C-l
status, C-4
MODULE entity (X.25), 8-1
Module entity identification, 7-5
MODULE X25-ACCESS, 8-1
MODULE X25-PROTOCOL, 8-2
MODULE X25-SERVER, 8-2
Monitoring network activity, 3-9
Monitoring node activity, 7-54
Monitoring the network, 7-43
Multicast address
ethernet, 3-32
looping to, 3-28
Multiple line commands, 4-4
Multiple-area network, 2-9
NCP, 4-1
accessing commands, 4-5
features, 4-3
File specifications, 4-9
functions, 4-2
getting help, 4-4
restricting commands, 4-5
NCP command keywords
overview, 1-11
NCP command response messages,
C-3
NCP commands
process by OPR, 5-1
processed by NML, 7-1
processed internally by NCP NML,
6-1
NCP error messages, C-4
NCP/NML commands
generic format, 7-16
Network
monitoring, 7-43
testing, 3-24
Network Application Layer (DNA),
1-7

Network architecture, 1-1
Network Control Program, 4-1
Network data bases
changing, 7-16
Network Management Layer (DNA),
1-5
Network Management Layer Events,
C-l'2
Network related messages, C-l
Network Remote Terminal Protocol,
2-4
Networks
controlling, 7-47
Multiple-area, 2-9
Public packet switching, 8-1
single-area, 2-9
NIA20, 1-9
NICE receiver, 1-6
NICE return codes, C-4
NML
restart procedures, 3-6
NML concepts, 7-2
Node
controlling state, 3-8
Node addresses
removing, 3-31
Node counters, B-9
Node entity, 7-5
Node entity identification, 7-4
Node identification, 3-29
Node names
remov ing, 3-31
Nodes, 2-1
adjacent, 2-1
command, 2-1
Ethernet, 2-8
executor, 2-1
host, 2-1
local, 2-1
nonrouting, 2-8
Phase II, 2-13
Phase III, 2-13
Phase IV, 2-13
rem'ote, 2-1
routing, 2-8
subordinate, 3-22
target, 2-1, 3-13
X.25, 2-2
nodes
command, 3-13
executor, 3-13
Nonrouting nodes, 2-8
NRT Server, 2-4
Operator
functions, 2-14
responsibilities, 2-14
Operator command language OPR,
1-6
Operator initiated downline
loading, 3-14
OPR/NCP command syntax messages,
C-l

Index-4

OPR/NCP commands
examples, 5-1
ORION process
restart procedures for, 3-6
ORION program, 3-1

Routing Layer (DNA), 1-7
Routing Layer events, C-15
Routing nodes, 2-8

Packet delivery
and congestion, 2-12
Packet Switching Interface, 8-1
PAD parameter values, D-ll
Phase II nodes, 2-13
Phase III nodes, 2-13
Phase III/Phase IV compatibility,
2-13
Phase IV compatibility, 1-11
Phase IV nodes, 2-13
Physical address
ethernet, 3-32
Physical link, 2-1
Physical Link Layer (DNA), 1-8
PPSN, 2-2
Primary loader, 3-15
PSI Gateway, 2-2
PSI restart procedures, 3-6
PSI software option, 1-9
PSITSB restart procedure, 3-7
Public Packet Switching Network,
2-2
Public Packet Switching Networks,
8-1
PURGE EXECUTOR command, 6-4
PUSH command, 5-1
Remote console
connecting, 3-24
Remote file access, 3-35
Remote node, 2-1
looping to, 3-28
Remote nodes
logging events at, 7-14
Removing node addresses, 3-31
Removing node names, 3-31
Restart procedures, 3-6
for NML, 3-6
for ORION process, 3-6
for PSITSB, 3-7
fo r X29SRV, 3-7
Restricting NCP commands, 4-5
Restrictions
topological, 2-13
RETURN command, 5-1
RMTCON facility, 3-24
Routers
designated, 2-11
Ethernet, 2-11
levell, 2-9, 2-10
level 2, 2-9, 2-10
Routing
area, 2-9
level 1, 2-9
level 2, 2-9
Routing algorithm, 2-12
Routing concepts, 2-6

Secondary loader, 3-15
Secondary loader files, 3-19
Service circuit identification,
3-20
Service device identification,
3-20
Service passwords, 3-20
Session Control Layer (DNA), 1-7
Session Control Layer Events,
C-14
SET CIRCUIT ALL command, 7-17
SET CIRCUIT command, 7-18
(X.25), 8-2
SET CIRCUIT example, 7-22
SET gXECUTOR command, 6-1, 7-29
(X. 25), 8-lS
SET EXECUTOR NODE examples, 6-2
SET KNOWN CIRCUITS command, 7-22
(X.2S), 8-2
SET KNOWN CIRCUITS example, 7-23
SET KNOWN NODES command, 7-39
(X. 2S), 8-lS
SET KNOWN NODES example, 7-39
SET LINE ALL command, 7-17
S~T LINE command, 7-23
(X.2S), 8-lS
SET LINE example, 7-25
SET LOGGING command, 7-39
SET LOGGING example, 7-40
SET MODULE CONFIGURATOR command,
7-2S
SET MODULE CONFIGURATOR example,
7-26
SET MODULE CONSOLE command, 7-26
SET MODULE CONSOLE example, 7-26
SET MODULE LOADER command, 7-27
SET MODULE LOADER example, 7-27
SET MODULE LOOPER command, 7-27
SET MODULE X25-ACCESS command,
8-S
SET MODULE X25-ACCESS example,
8-6
SET MODULE X25-PROTOCOL command,
8-6
SET MODULE X25-PROTOCOL example,
8-10
SET MODULE X2S-SERVER command,
8-10
SET MODULE X25-SERVER example,
8-12
SET NODE ALL command, 7-17
SET NODE CIRCUIT command, 7-27
SET NODE CIRCUIT example, 7-27
SET NODE command, 7-29
(X. 2S), 8-15
SET NODE example, 7-38
SET NODE NAME command, 7-28
SET NODE NAME example, 7-28
Setting buffer size, 3-34

Index-S

SHOW command, 7-44
SHOW example, 7-45
SHOW MODULE (X.25) examples, 8-16
SHOW MODULE command
(X. 25), 8-16
SHOW QUEUE command, 6-5
SHOW QUEUE example, 6-5
Single-area network, 2-9
SPEAR program, 3-10
example, 3-11
Specifying the executor, 4-8
Startup procedure
automatic DECnet, 3-1
Startup procedures
DECnet, 3-1
manual of MC8, 3-3
manual with command files, 3-4
Status messages, C-4
Subordinate node, 3-22
System manager
functions, 2-15
responsibilities, 2-15
TAKE command, 5-1
Target initiated downline loading,
3-14
Target node, 2-1
in downline load, 3-13
TELL prefix, 6-6
TELL prefix example, 6-7
Tertiary loader, 3-15
Tertiary loader files, 3-19
Testing
circuit level loopback, 3-28
Testing the network, 3-24

Topological restrictions, 2-13
TRIGGER command, 7-53
TRIGGER example, 7-54
Typing commands, 4-3
Upline Dumping
requirements, 3-23
Upline dumping, 3-22
DN20, 3-23
User Layer (DNA), 1-4
Using nodes addresses, 3-31
Using nodes names, 3-31
WAIT command, 5-1
X.25
X.25
X.25
X.25

facility, 8-1
network, 2-2
node, 2-2
protocol module counters,
8-12
X.25 server module counters, 8-13
X.2S Specific counters, B-2
X.25-specific commands, 8-2
X.29 configuration file, D-l
X.29 Server, 2-4
X29SRV
managing, D-l
restart procedure, 3-7
X29SRV management commands, D-3
X29SRV.INI file, D-2
ZERO (X.25) examples, 8-19
ZERO command, 7-54
(X. 25), 8-19
ZERO example, 7-54

Index-6

TOPS-10
DECnet and PSI
System Manager's and
Operator's Guide
AA-L413B-TB

READER'S COMMENTS
NOTE: This form is for document comments only. DIGITAL will use comments submitted
on this form at the company's discretion. If you require a written reply and are eligible
to receive one under Software Performance Report (SPR) service, submit your comments
on an SPR form.
Did you find this manual understandable, usable, and well organized? Please make
suggestions for improvement.

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

Please indicate the type of user/reader that you most nearly represent:

o Assembly language programmer
o Higher-level language programmer
o Occasional programmer (experienced)
o User with little programming experience
o Student programmer
o Other (please specify)
Name _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Date _ _ _ _ _ _ _ _ _ _ _ _ __
Organization _______________________________
Street __________________----___________________
City __________________ State _ _ _ _ _ _ Zip Code _ _ __
or Country

-.;. Do Not Tear - Fold Here and Tape -

No Postage
Necessary
if Mailed in the
United States

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

SOFTWARE PUBLICATIONS

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

III"", II, II, '" II"" I, 11,1 •• 1.1,,1.1 •• 11 ••••• 1.11
-

Do Not Tear - Fold Here