Digital PDFs

AA-Y512C-TE

April 1986

402 pages

Original

44MB

Document:	VMS 4.4 VAX VMS Networking Manual
Order Number:	AA-Y512C-TE
Revision:
Pages:	402
Original Filename:	https://archive.org/download/stx_AA-Y512C-TE_VMS_4.4_VAX_VMS_Networking_Manual_Apr86/AA-Y512C-TE_VMS_4.4_VAX_VMS_Networking_Manual_Apr86.pdf

OCR Text

VAX/VMS
Networking Manual
Order Number: AA-Y512C-TE

April 1986
This book presents conceptual and usage information for VAX/VMS users
who wish to manage DECnet-VAX and/or perform operations over the
network. The guide is divided into the following parts: Introduction to
DECnet-VAX and VAX PSI; Network System Management; Network
Configuration, Installation, and Testing; and Network User Operations.

Revision/Update Information:

This revised manual supersedes the
Guide to Networking on VAX/VMS for
Version 4.2.

Software Version:

VAX/VMS Version 4.4

digital equipment corporation
maynard, massachusetts

April 1986

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.

Copyright ©1986 by Digital Equipment Corporation
All Rights Reserved.
Printed in U.S.A.
The postpaid READER'S COMMENTS form on the last page of this document
requests the user's critical evaluation to assist in preparing future documentation.
TELENET is a registered trademark of GTE Telenet Communications Corp.
PSS is a trademark of British Telecommunications pic.
The following are trademarks of Digital Equipment Corporation:
DEC
DEC/CMS
DEC/MMS
DECnet
DECsystem-10
DECSYSTEM-20
DECUS
DECwriter

DIBOL
EduSystem
IAS
MASSBUS
PDP
PDT
RSTS
RSX

UNIBUS
VAX
VAXcluster
VMS
VT

BDBDIED
ZK-3039

HOW TO ORDER ADDITIONAL DOCUMENTATION
DIRECT MAIL ORDERS
USA & PUERTO RICO*

CANADA

INTERNATIONAL

Digital Equipment Corporation
P.O. Box CS2008
Nashua, New Hampshire
03061

Digital Equipment
of Canada Ltd.
100 Herzberg Road
Kanata, Ontario K2K 2A6
Attn: Direct Order Desk

Digital Equipment Corporation
PSG Business Manager
c/o Digital's local subsidiary
or approved distributor

In Continental USA and Puerto Rico call 800-258-1710.
In New Hampshire, Alaska, and Hawaii call 603-884-6660.
In Canada call 800-267-6215.
Any prepaid order from Puerto Rico must be placed with the local Digital subsidiary (809-754-7575).
Internal orders should be placed through the Software Distribution Center (SDC), Digital Equipment
Corporation, Westminster, Massachusetts 01473.
This document was prepared using an in-house documentation production system. All page
composition and make-up was performed by T^X, the typesetting system developed by
Donald E. Knuth at Stanford University. T^X is a registered trademark of the American Mathematical
Society.

Contents
PREFACE

xxi

NEW AND CHANGED FEATURES

xxv

PART 1::

INTRODUCTION TO DECNET-VAX
AND VAX PSI
OVERVIEW OF DECNET-VAX AND VAX PSI

1 1

1.1

GENERAL DESCRIPTION OF A DECNET NETWORK

1 -1

1.2

DECNET-VAX AND VAX PSI
1.2.1
DECnet Interface with VAX/VMS
1.2.2
VAX Packetnet System Interface
1.2.3
DECnet Functions

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

1.3

DECNET-VAX CONFIGURATIONS
1-4
1.3.1
DECnet-VAX Ethernet Local Area Network
Configuration
1-5
1.3.1.1
Ethernet Datagrams • 1 -6
1.3.1.2
Transmission and Reception of Ethernet Packets • 1-6
1.3.1.3
Ethernet Routers and End Nodes • 1-7
1.3.2
DDCMP Network Configurations
1 -7
1.3.2.1
DDCMP Point-to-Point and Multipoint Connections • 1-7
1.3.2.2
Synchronous DDCMP Connections • 1-8
1.3.2.3
Asynchronous DDCMP Connections • 1-8
1.3.2.4
Static Asynchronous Connections • 1-9
1.3.2.5
Dynamic Asynchronous Connections • 1-9
1.3.3
DECnet—VAX Configurations for VAXclusters
1-10

SECTION 1

1.3.4

X.25 Network Configurations

1.3.4.1
1.3.4.2

1.4

1-17

X.25 and X.29 Recommendations • 1-12
X.25 Connections • 1-12

MANAGING THE NETWORK
1.4.1
Network Control Program
1.4.2
Network Management Responsibilities
1.4.3
DECnet-VAX Licenses

1 -13
1-14
1-14
1-15
iii

Contents

1.4.4
1.4.5

DECNET-VAX and VAX PSI Network Management
Software _
Configuring a Network _
1.4.5.1
Configuring a DECnet-VAX Node • 1-17
1.4.5.2
Configuring VAX PSI DTEs • 1-17
1.4.5.3
A Network Topology • 1-17

1-15
1-17

1.5 USER INTERFACE TO THE NETWORK
1 -20
1.5.1
Performing Network Operations _
1-20
1.5.1.1
Designing User Applications for Network Operations • 1 -21
1.5.1.2
Choosing a Language for a Specific Network
Application • 1-22
1.5.2
Accessing the Network _
1-23
1.5.2.1
Using File and Task Specifications in Network
Applications • 1-23
1.5.2.2
Using Access Control for Network Applications • 1-24
1.5.2.3
Using Logical Names in Network Applications • 1-25

SECTION 2

DECNET-VAX COMPONENTS AND CONCEPTS

2.1 NODES AND DTES
2.1.1
Nodes _
2.1.1.1
Node Address and Name • 2-2
2.1.1.2
Node Characteristics • 2-3
2.1.1.3
Identifying a VAXcluster as a Single Node • 2-4
2.1.2
DTEs _
2.1.2.1
X.25 Protocol Module • 2-5
2.1.2.2
X.25 Connector and Host Nodes • 2-6

2-1
2-2

2-5

2.2 CIRCUITS
2.2.1
Classes of DECnet—VAX Circuits _
2.2.2
DDCMP Circuit Devices _
2.2.3
Cl Circuit Device _
2.2.4
Ethernet Circuit Device _
2.2.5
Ethernet Configurator Module _
2.2.6
X.25 Circuit Devices _
2.2.7
X.25 DLM Circuits _

2-6
2-6
2-7
2-10
2-10
2-10
2-11
2-11

2.3

2-11
2-12
2-12

LINES
2.3.1
2.3.2

2.3.3
2.3.4
iv

2 1

Classes of DECnet—VAX Lines _
DDCMP Lines _
2.3.2.1
DDCMP Line Devices • 2-12
2.3.2.2
Static Asynchronous Lines • 2-14
2.3.2.3
Dynamic Asynchronous Lines • 2-14
Cl Line Device _
Ethernet Line Device _

2-17
2-18

Contents

2.3.5 X.25 Line Devices

2-18

2.4 ROUTING
2-19
2.4.1
Routing and Nonrouting Nodes _
2-19
2.4.1.1
Types of DECnet Nodes • 2-20
2.4.1.2
DECnet-VAX Phase IV Nodes • 2-21
2.4.1.3
Routing Features of DECnet-VAX License Options • 2-21
2.4.2
Area Routing _
2-22
2.4.3
Level 1 and Level 2 Routers _
2-23
2.4.4
Ethernet Routers and End Nodes _
2-24
2.4.4.1
Ethernet Designated Routers • 2-24
2.4.4.2
Ethernet End Node Caching • 2-24
2.4.4.3
Area Routing on an Ethernet • 2-25
2.4.5
Routers and End Nodes on Cl Data Links _
2-25
2.4.5.1
Cl End Nodes • 2-25
2.4.5.2
Cl Routers • 2-25
2.4.6
Routing Concepts and Terms _
2-25
2.4.7
Routing Messages _
2-27
2.4.7.1
Segmented Routing Messages • 2-27
2.4.7.2
Timing of Routing Message Transmissions • 2-27

2.5

LOGICAL LINKS

2-27

2.6

OBJECTS
2.6.1
DECnet-VAX Objects _
2.6.2
Objects Using the Cluster Alias Node Identifier _
2.6.3
Creating DECnet—VAX Network Server Processes _
2.6.4
Potential Causes of Network Process Failures _
2.6.5
VAX PSI Objects _

2-28
2-29
2-30
2-30
2-31
2-32

2.7

X.25 AND X.29 SERVER MODULES
2.7.1
Destination of Calls from a Remote DTE _
2.7.2
Handling Incoming Calls at the Local DTE _

2-32
2-32
2-33

2.8

X.25 ACCESS MODULE

2-34

2.9 LOGGING

2.10 NETWORK ACCESS CONTROL
2.10.1 Routing Initialization Passwords

2-34

2-35
2-36

Contents

2.10.2 System-Level Access Control
2.10.2.1
2.10.2.2
2.10.2.3
2.10.2.4

2.10.3 Access Control for Remote Command Execution _
2.10.4 Node-Level Access Control _
2.10.5 Proxy Login Access Control _
2.10.5.1
2.10.5.2

2-40
2-40
2-41

Proxy Accounts • 2-41
Controlling Proxy Login Access • 2-41

2.10.6 Security for DDCMP Point-to-Point Connections

PART II:

2-37

Setting Access Control Information for Outbound
Connects • 2-37
Sources of Access Control Information for Logical Link
Connections • 2-37
Network Security and Passwords • 2-39
Inbound Default Access Control for Objects • 2-40

2-42

NETWORK SYSTEM
MANAGEMENT

SECTION 3 MANAGING AND MONITORING THE NETWORK

3-1

3.1 THE DECNET-VAX CONFIGURATION DATABASE
3.1.1
The Volatile Database _
3.1.2
The Permanent Database _
3.1.3
VAX PSI Configuration Database _

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

3.2

3-3

THE NETWORK CONTROL PROGRAM

3.3 NODE COMMANDS
3.3.1
Executor Node Commands
3.3.1.1
3.3.1.2

3.3.2

3.3.3

3-7

Maximum Address Parameter • 3-8
Local Node Identification Parameter • 3-8
Using and Removing Node Names and Addresses • 3-9

Identifying Cluster Nodes
3.3.3.1
3.3.3.2

3.3.4

SET EXECUTOR NODE Command • 3-5
TELL Prefix • 3-6

Node Identification
3.3.2.1
3.3.2.2
3.3.2.3

3-4
3-5

3-9

Setting an Alias Node Identifier for the Executor • 3-10
Enabling Aliases for Nodes in a Cluster • 3-10

Ethernet Addresses of Nodes

3-11

3.3.4.1 Format of Ethernet Addresses • 3-11
3.3.4.2
Determining the Ethernet Physical Address of a Node • 3-12
3.3.4.3
Ethernet Physical and Multicast Addresses • 3-13
3.3.4.4
Values of DIGITAL Ethernet Physical and Multicast
Addresses • 3-13
VI

Contents

3.3.5

Node Parameters
3.3.5.1
3.3.5.2

3.3.6

Copying Node Databases
3.3.6.1
3.3.6.2
3.3.6.3
3.3.6.4

3.3.7

3.4

3-14

Data Link Control • 3-17
Operational State of the Local Node • 3-20

3-20

COPY Command Parameters and Qualifiers • 3-21
Clearing and Purging the Local Node Database • 3-21
Copying the Node Database from a Remote Node • 3-22
Example of Copying Remote Node Data • 3-23

Node Counters

3-24

X.25 PROTOCOL MODULE COMMANDS
3.4.1
Network Identification _
3.4.2
Local DTE Identification _

3-24
3-25
3-25

3.4.2.1
3.4.2.2
3.4.2.3
3.4.2.4
3.4.2.5

3.4.3

Data Packet Control
3.4.3.1
3.4.3.2

3.4.4
3.4.5
3.4.6
3.4.7
3.4.8
3.4.9

Operational State of DTE • 3-25
Line Identification • 3-26
Channel Identification • 3-26
Maximum Circuits • 3-26
INTERFACE Parameter • 3-27

Call Request Packet Control _
Clear Request Packet Control _
Reset Control _
Restart Control _
ISO Networks _
Group Identification _
3.4.9.1
3.4.9.2
3.4.9.3

3.5 CIRCUIT COMMANDS
3.5.1 Circuit Identification

3.5.2

3.5.3

3-31

3-31
3-31

3-37

DDCMP Circuit Level Verification • 3-38
DDCMP Tributary Control • 3-39

Ethernet Circuit Parameters _
Ethernet Configurator Module Commands _
3.5.5.1
3.5.5.2
3.5.5.3

3-33

Operational State of the Circuit • 3-36
Circuit Timers • 3-37

DDCMP Circuit Parameters
3.5.3.1
3.5.3.2

3.5.4
3.5.5

DDCMP Circuit Identification • 3-31
Cl Circuit Identification • 3-32
Ethernet Circuit Identification • 3-33
X.25 Circuit Identification • 3-33

Circuit Parameters
3.5.2.1
3.5.2.2

3-28
3-28
3-29
3-29
3-30
3-30

Local DTE Identification • 3-30
Group Number • 3-30
Group Type • 3-31

3.4.10 X.25 Protocol Module Counters

3.5.1.1
3.5.1.2
3.5.1.3
3.5.1.4

3-27

Packet Size • 3-27
Window Size • 3-27

3-40
3-41

Enabling Surveillance by the Ethernet Configurator • 3-42
Obtaining a List of Systems on Ethernet Circuits • 3-42
Disabling Surveillance by the Ethernet Configurator • 3-43
VII

Contents

3.5.6

X.25 Circuit Parameters
3.5.6.1
3.5.6.2
3.5.6.3

3.5.7

DLM Circuit Parameters
3.5.7.1
3.5.7.2
3.5.7.3
3.5.7.4
3.5.7.5
3.5.7.6

3.5.8

3.6

LINE COMMANDS
3.6.1
Line Identification
3.6.2

3.6.3

3.6.4
3.6.5

3.7

3.7.3.2

3.7.5
3.7.6

3-48
3-48
3-50

3-53

3-57
3-57

Frame Control for X.25 Lines • 3-57
Receive Buffers for X.25 Lines • 3-59
Interface of X.25 Lines • 3-59
Network for X.25 Lines • 3-59

3-59

3-60
3-60
3-61
3-61

Maximum Number of Ethernet Routers and End Nodes
Allowed • 3-61
Maximum Number of Areas Allowed • 3-62

Routing Control Parameters
3.7.4.1
3.7.4.2
3.7.4.3
3.7.4.4

3-47

Line Buffers • 3-54
Duplex Mode • 3-54
Line Timers • 3-54
Satellite Transmission Control • 3-55
Asynchronous DDCMP Line Parameters • 3-56

ROUTING COMMANDS
3.7.1
Specifying the Node Type _
3.7.2
Specifying the Area Number in a Node Address _
3.7.3
Setting Routing Configuration Limits _

3.7.4

3-44

Operational State of Lines • 3-52
Buffer Size • 3-53

Line Counters

3.7.3.1

VIII

Ethernet Line Parameters _
X.25 Line Parameters _
3.6.5.1
3.6.5.2
3.6.5.3
3.6.5.4

3.6.6

DDCMP Line Parameters
3.6.3.1
3.6.3.2
3.6.3.3
3.6.3.4
3.6.3.5

Line Protocols • 3-49

Line Parameters
3.6.2.1
3.6.2.2

3-43

DLM Circuit Owner • 3-45
Remote DTE Addresses • 3-45
Recalls for DLM Circuits • 3-45
DLM Circuit Usage • 3-46
Executor Node Subaddresses • 3-46
Setting Up a DLM Circuit • 3-47

Circuit Counters

3.6.1.1

Parameters Common to X.25 Circuits • 3-43
Permanent Virtual Circuit Parameters • 3-43
Data Packet Control • 3-44

3-62

Circuit Cost Control Parameter • 3-62
Maximum Path Control Parameters • 3-64
Route-Through Control Parameter • 3-64
Area Path Control Parameters • 3-65

Routing Message Timers _
Cl End Node Circuit Failover _

3-65
3-66

Contents

LOGICAL LINK COMMANDS
3.8.1
Maximum Number of Links
Disconnecting Logical Links
3.8.2
3.8.3
Logical Link Protocol Parameters
3.8.3.1
3.8.3.2
3.8.3.3
3.8.3.4

3.9

3.9.2

3-73

VAX PSI Object Identification • 3-73
VAX PSI Command Procedure Identification • 3-73
VAX PSI Object Account Information • 3-74

X.25/X.29 SERVER MODULE COMMANDS
3.10.1 X25—SERVER and X29—SERVER Module Identification
3.10.2 Destination Identification _
3.10.2.1
3.10.2.2
3.10.2.3
3.10.2.4
3.10.2.5
3.10.2.6
3.10.2.7
3.10.2.8
3.10.2.9
3.10.2.10

3-70
3-70

DECnet-VAX Object Identification • 3-70
Using the Cluster Alias Node Identifier for the Object • 3-71
Example of Using the Cluster Alias Node Identifier • 3-72
DECnet-VAX Command Procedure Identification • 3-72

VAX PSI Objects
3.9.2.1
3.9.2.2
3.9.2.3

3.10

Incoming and Outgoing Timers • 3-68
Inactivity Timer • 3-68
NSP Message Retransmission • 3-68
Pipeline Quota • 3-69

OBJECT COMMANDS
3.9.1
DECnet-VAX Objects
3.9.1.1
3.9.1.2
3.9.1.3
3.9.1.4

3-66
3-67
3-67
3-67

3-74
3-74
3-74

DTE Subaddress Range • 3-75
Group Identification • 3-75
Remote DTE Identification • 3-75
User Data Field • 3-76
Address Extension • 3-76
Call Redirection • 3-77
Receiving DTE • 3-77
Priority • 3-77
Object Identification • 3-78
Host Node Identification • 3-78

3.10.3 Maximum Circuits _
3.10.4 Operational State of Server _

3-78
3-79

X.25 ACCESS MODULE COMMANDS
3.11.1 Network Identification in an X.25 Access Module _
3.11.2 X.25 Connector Node Identification _
3.11.3 Access Control Parameters in an X.25 Access Module

3-79
3-79
3-80
3-80

3.12 LOGGING COMMANDS
3.12.1 Event Identification _
3.12.2 Identifying the Source for Events _
3.12.3 Identifying the Location for Logging Events _
3.12.4 Controlling the Operational State of Logging _

• 3-80
3-82
3-83
3-83
3-83

3.11

Contents

3.12.5
3.12.6

3.13

Event Logging Example _
Using a Logging Monitor Program _

3-84
3-84

NETWORK ACCESS CONTROL COMMANDS
3.13.1 Specifying Passwords for Routing Initialization _
3.13.2 System-Level Access Control Commands _

3-85
3-86
3-87

3.13.2.1
3.13.2.2
3.13.2.3
3.13.2.4

3.14

Establishing Default Privileged and Nonprivileged
Accounts • 3-87
Specifying Privileges for Objects • 3-87
Setting Default Inbound Access Control Information
Indicating Access Controls for Remote Command
Execution • 3-88

3.13.3 Node-Level Access Control Commands _
3.13.4 Proxy Login Access Control Commands _

3-88
3-89

MONITORING THE NETWORK

3-90

SECTION 4 DECNET-VAX HOST SERVICES
4.1

LOADING UNATTENDED SYSTEMS DOWNLINE
4.1.1
Downline System Load Operation _
4.1.1.1
4.1.1.2

4.1.2

4.3

4-1
4-2

4-5

TRIGGER Command • 4-6
LOAD Command • 4-7
Host Identification *4-10
Load File Identification *4-10
Software Type • 4-12
CPU and Software Identification *4-12
Service Device Identification *4-13
Service Circuit Identification • 4-13
Service Passwords • 4-13
Diagnostic File *4-13

DUMPING MEMORY UPLINE FROM AN UNATTENDED
SYSTEM
4.2.1
Upline Dump Procedures _
4.2.2
Upline Dump Requirements _

4-14
4-14
4-15

LOADING RSX-1 IS TASKS DOWNLINE
4.3.1
Setting Up the Satellite System _
4.3.2
Host Loader Mapping Table _
4.3.3
HLD Operation and Error Reporting _

4-16
4-16
4-18
4-19

4.3.3.1
x

4-1

Load Sequence • 4-4
Load Requirements • 4-5

Operator-Initiated Downline Load Parameters
4.1.2.1
4.1.2.2
4.1.2.3
4.1.2.4
4.1.2.5
4.1.2.6
4.1.2.7
4.1.2.8
4.1.2.9
4.1.2.10

4.2

3-87

HLD Error Messages • 4-19

Contents

4.3.4
4.3.5

Checkpointing RSX—11S Tasks _
Overlaying RSX—11S Tasks _

4.4 CONNECTION TO REMOTE CONSOLE

PART III:

4-20
4-20

4-20

NETWORK CONFIGURATION,
INSTALLATION, AND TESTING

SECTION 5 CONFIGURATION OF A NETWORK

5 1

5.1 PREREQUISITES FOR ESTABLISHING A NETWORK
5.1.1
User Accounts and Directories _
5.1.2
Required Privileges _

5-1
5-1
5-2

5.2 CONFIGURATION PROCEDURES
5.2.1
Using NETCONFIG.COM

5-3
5-4

5.2.1.1
5.2.1.2

5.2.2

Executing NETCONFIG.COM • 5-5
NETCONFIG.COM Example • 5-6

Tailoring the Configuration Database
5.2.2.1
5.2.2.2
5.2.2.3
5.2.2.4

5.3 NETWORK CONFIGURATION EXAMPLES
5.3.1
Synchronous DDCMP Point-to-Point Network Example
5.3.2
DDCMP Multipoint Network Example _
5.3.3
Static Asynchronous DDCMP Network Example _
5.3.4
Dynamic Asynchronous DDCMP Network Example _
5.3.4.1
5.3.4.2

5.3.5
5.3.6

5.3.7
5.3.8

5.3.9

5-21
5-22

Node CHCAGO Database • 5-23
Node SDIEGO Database • 5-24

X.25 Native Mode Network Example _
X.25 Multihost Mode Network Example _
5.3.8.1
5.3.8.2
5.3.8.3

5-12
5-13
5-15
5-17
5-18

Node BIGVAX Database • 5-19
Node MYNODE Database • 5-20

Ethernet Network Example _
X.25 Data Link Mapping Example _
5.3.6.1
5.3.6.2

5-7

Running DECnet over the Cl • 5-7
Running DECnet over Terminal Lines • 5-8
Installing Static Asynchronous Lines • 5-8
Installing Dynamic Asynchronous Lines • 5-10

5-25
5-26

Building the Ethernet Network • 5-27
Configuring the X.25 Connector Node • 5-28
Configuring the Host Nodes • 5-29

X.25 Multinetwork Example

5-30
XI

Contents

5.4 SYSTEM CONFIGURATION GUIDELINES
5.4.1
Normal Memory Requirements _
5.4.1.1
5.4.1.2
5.4.1.3

5.4.2
5.4.3
5.4.4
5.4.5

5-31
5-32

NPAGEDYN Parameter • 5-32
IRPCOUNT Parameter • 5-33
LRPCOUNT and LRPSIZE Parameters • 5-33

Critical Routing Node Requirements _
CPU Time Requirements _
UNIBUS Adapter Map Register Considerations _
Permanent Database Considerations in VAXclusters _

5-34
5-35
5-36
5-38

INSTALLATION OF A NETWORK

6-1

6.1

INSTALLING A DECNET-VAX KEY

6-1

6.2

BRINGING UP YOUR NETWORK NODE USING STARTNET.COM

6-1

6.3

BRINGING UP YOUR VAX PSI DTE

6-2

6.4

TESTING THE INSTALLATION WITH UETP TEST PROCEDURE

6-2

6.5

SHUTTING DOWN YOUR DECNET-VAX NODE

6-2

SECTION 6

SECTION 7 TESTING THE NETWORK
7.1

NODE-LEVEL TESTS
7.1.1
Remote Loopback Test
7.1.2
Local and Remote Loopback Tests Using a Loop Node
Name
7.1.2.1
Local-to-Remote Testing • 7-3
7.1.2.2
Local-to-Local Testing • 7-4
7.1.3
Local Loopback Test

7.2 CIRCUIT-LEVEL TESTS
7.2.1
Software Loopback Test _
7.2.2
Controller Loopback Test _
7.2.3
Circuit-Level Loopback Testing _
7.2.3.1
7.2.3.2

Testing with the PHYSICAL ADDRESS and NODE
Parameters • 7-9
Loopback Assistance • 7-11

7-1

7-1
7-2
7-2

7-5

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

Contents

7.3

X.25 LINE-LEVEL LOOPBACK TESTS

7-12

7.4 DUMPING KMS11 AND KMV11 MICROCODE

7-13

PART IV:
SECTION 8

NETWORK USER OPERATIONS

PERFORMING NETWORK USER OPERATIONS

8-1

8.1 RETRIEVING NETWORK STATUS INFORMATION

8-1

8.2 ESTABLISHING COMMUNICATION WITH A REMOTE NODE

8-2

8.3 ACCESSING FILES ON REMOTE NODES
8.3.1
Using DCL Commands and Command Procedures _
8.3.2
Using Higher-Level Language Programs _
8.3.3
Using MACRO Programs _

8-3
8-4
8-4
8-5

8.4 PERFORMING TASK-TO-TASK OPERATIONS
8.4.1
Transparent and Nontransparent Task-to-Task
Communication _

8-6

8.4.1.1
8.4.1.2

8.4.2
8.4.3

Task Specification Strings in Task-to-Task
Applications _
Functions Required for Performing Task-to-Task
Operations _
8.4.3.1
8.4.3.2
8.4.3.3
8.4.3.4

8.5

8-9
8-9

Initiating a Logical Link Connection •8-10
Completing the Logical Link Connection • 8-1 1
Exchanging Messages • 8-12
Terminating the Communication Process • 8-13

PERFORMING TRANSPARENT TASK-TO-TASK OPERATIONS
8.5.1
Using DCL Commands and Command Procedures _
8.5.2
Using Higher-Level Language Programs _
8.5.3
Using RMS Service calls in MACRO Programs _
8.5.4
Using System Service Calls in MACRO Programs _
8.5.4.1
8.5.4.2
8.5.4.3
8.5.4.4
8.5.4.5

8-6

Transparent Communication • 8-7
Nontransparent Communication • 8-7

8-14
8-14
8-14
8-15
8-15

Requesting a Logical Link • 8-16
Completing the Logical Link Connection • 8-17
Exchanging Messages • 8-17
Terminating the Logical Link • 8-17
Status and Error Reporting • 8-17

xiii

Contents

8.5.5 Summary of System Service Calls for Transparent
Operations_8-18
8.5.5.1
$ ASSIGN • 8-18
8.5.5.2
$QIO (Sending a Message to a Target Task) • 8-19
8.5.5.3
$QIO (Receiving a Message from a Target Task) • 8-20
8.5.5.4
$DASSGN (Terminating a Logical Link) • 8-21

8.6

PERFORMING NONTRANSPARENT TASK-TO-TASK
OPERATIONS
8-21
8.6.1
Using System Services for Nontransparent Operations .
8-22
8.6.1.1
Assigning a Channel to —NET: and Creating a Mailbox • 8-23
8.6.1.2
Mailbox Message Format • 8-24
8.6.1.3
Requesting a Logical Link Connection • 8-24
8.6.1.4
Using the Network Connect Block • 8-25
8.6.1.5
Completing the Logical Link • 8-26
8.6.1.6
Disconnecting or Aborting the Logical Link • 8-28
8.6.1.7
Terminating the Logical Link • 8-29
8.6.2
System Service Calls for Nontransparent Operations _
8-29
8.6.2.1
SASSIGN (I/O Channel Assignment) • 8-29
8.6.2.2
$QI0 (Requesting a Logical Link Connection) • 8-30
8.6.2.3
$QIO (Accepting Logical Link Connection Request) • 8-31
8.6.2.4
$QIO (Rejecting a Logical Link Connection Request) • 8-32
8.6.2.5
$QIO (Sending a Message to a Target Task) • 8-33
8.6.2.6
$QIO (Receiving a Message from a Target Task) • 8-33
8.6.2.7
$QIO (Sending an Interrupt Message to a Target
Task) • 8-34
8.6.2.8
$QIO (Synchronously Disconnecting a Logical Link) • 8-34
8.6.2.9
$QIO (Aborting a Logical Link) • 8-35
8.6.2.10 $QIO (Declaring a Network Name Or Object Number) • 8-36
8.6.2.11 $DASSGN (Terminating a Logical Link) • 8-37

8.7

DESIGNING TASKS
8 37
8.7.1
DCL Command Procedure for Task-to-Task
Communication_8-37
8.7.2
FORTRAN Program for Task-to-Task Communication _
8-38
8.7.3
MACRO Program for Transparent Task-to-Task
Communication _
8-41
8.7.4
MACRO Program for Nontransparent Task-to-Task
Communication_8-43

SECTION 9

xiv

FILE OPERATIONS IN A HETEROGENEOUS NETWORK
ENVIRONMENT

9-1

9.1 GENERAL DECNET-VAX RESTRICTIONS

9-1

9.2 VAX/VMS TO IAS NETWORK OPERATION

9-2

Contents

9.2.1

File System Constraints
9.2.1.1
9.2.1.2
9.2.1.3

9.2.2

DCL Considerations
9.2.2.1
9.2.2.2

9.3.2

9.4

9-4

APPEND • 9-4
COPY • 9-4

9.3 VAX/VMS TO P/OS NETWORK OPERATION
9.3.1
File System Constraints _
9.3.1.1
9.3.1.2
9.3.1.3

9-2

File Formats and Access Modes • 9-2
VAX RMS Interface • 9-3
File Specifications • 9-3

9-5
9-5

File Formats and Access Modes • 9-5
VAX RMS Interface • 9-5
File Specifications • 9-6

DCL Considerations

9-6

VAX/VMS TO RSTS/E NETWORK OPERATION
9.4.1
File System Constraints _

9-6
9-6

9.4.1.1
9.4.1.2
9.4.1.3

9.4.2

File Formats and Access Modes • 9-6
VAX RMS Interface • 9-7
File Specifications • 9-7

DCL Considerations
9.4.2.1
9.4.2.2
9.4.2.3
9.4.2.4
9.4.2.5

9.5 VAX/VMS TO RSX NETWORK OPERATION USING RMS-BASED
FAL
9.5.1
File System Constraints _
9.5.1.1
9.5.1.2
9.5.1.3

9.5.2

9-8

APPEND • 9-8
COPY • 9-8
DELETE • 9-9
DIRECTORY • 9-9
DUMP/RECORDS and TYPE Commands • 9-9

9-9
9-9

File Formats and Access Modes *9-10
VAX RMS Interface *9-10
File Specifications • 9-10

DCL Considerations

9-11

9.5.2.1 COPY* 9-11

9.6 VAX/VMS TO RSX NETWORK OPERATION USING FCS-BASED
FAL
9.6.1
File System Constraints _
9.6.1.1
9.6.1.2
9.6.1.3

9.6.2

File Formats and Access Modes *9-17
VAX RMS Interface *9-12
File Specifications • 9-13

DCL Considerations
9.6.2.1
9.6.2.2

9-11
9-11

9-13

APPEND *9-13
COPY *9-13

9.7 VAX/VMS TO RT-11 NETWORK OPERATIONS

9-14
xv

Contents

9.7.1

File System Constraints
9.7.1.1
9.7.1.2
9.7.1.3

9.7.2

9-14

File Formats and Access Modes • 9-14
VAX RMS Interface • 9-15
File Specifications • 9-16

DCL Considerations

9-16

9.7.2.1 COPY *9-16
9 7.2.2
DELETE • 9-17

9.8 VAX/VMS TO TOPS-10 NETWORK OPERATIONS
9.8.1
File System Constraints _
9.8.1.1
9.8.1.2
9.8.1.3

9.8.2

File Formats and Access Modes *9-17
VAX RMS Interface • 9-18
File Specifications • 9-19

DCL Considerations
9.8.2.1
9.8.2.2

9.9.2

9.10.2

9-22

COPY • 9-23
DIRECTORY • 9-23

9.10 VAX/VMS TO VAX/VMS NETWORK OPERATIONS (VERSION 4 TO
VERSION 3)
9.10.1 File System Constraints _
9.10.1.1
9.10.1.2
9.10.1.3

9-20
9-20

File Formats and Access Modes • 9-20
VAX RMS Interface • 9-22
File Specifications • 9-22

DCL Considerations
9.9.2.1
9.9.2.2

9-19

COPY* 9-19
DIRECTORY • 9-20

9.9 VAX/VMS TO TOPS-20 NETWORK OPERATIONS
9.9.1
File System Constraints _
9.9.1.1
9.9.1.2
9.9.1.3

9-17
9-17

9-23
9-23

File Formats and Access Modes • 9-23
VAX RMS Interface • 9-24
File Specifications • 9-24

DCL Considerations

9-24

9.11 VAX/VMS TO VAX/VMS NETWORK OPERATIONS (VERSION 4.4 TO
PREVIOUS VERSION)
9-24
9.11.1 File System Constraints _
9-25
9.11.1.1 File Formats and Access Modes • 9-25

Contents

APPENDIX A

AREA ROUTING CONFIGURATION

A-1

A.1

AREA ROUTING CONFIGURATION GUIDELINES

A-1

A.2

DESIGNING A MULTIPLE-AREA NETWORK

A-2

A.3

SAMPLE MULTIPLE-AREA NETWORK CONFIGURATION

A-5

A.4

CONVERTING AN EXISTING NETWORK TO A MULTIPLE-AREA
NETWORK

A-8

PROBLEMS IN CONFIGURING A MULTIPLE-AREA NETWORK
A.5.1
Partitioned Area Problem
A.5.2
Problems in Mixed Phase Ill/Phase IV Networks

A-10
A-10
A-12

A.5

A.5.2.1
A.5.2.2

A.6

Problem of a Phase III Node in a Phase IV Path • A-13
Area Leakage Problem • A-14

AREA ROUTING ON AN ETHERNET

GLOSSARY

A-15

Glossary-1

INDEX

EXAMPLES
8-1
8-2
8-3
8-4

Network Connect Block Format
FORTRAN Task-to-Task Communication
Transparent Communication Using System Services
Nontransparent Communication Using System Services

8-25
8-39
8-41
8-44

DECnet Functions and Related DNA Layers and Protocols
Sample DECnet—VAX Phase IV Configuration
Typical DDCMP Point-to-Point and Multipoint Connections
Typical VAXcluster Configuration Using Cl as a Data Link
X.25 Connections in a DECnet Network Configuration

1-4
1-5
1-8
1-10
1-13
1-15
1-18

FIGURES
1-1
1-2
1-3
1-4
1-5
1-6
1-7

DECnet-VAX and VAX PSI Software

Topology of a Single-Area DECnet Network

xvii

Contents

1-8
1-9
1—10
1— 11
2— 1
2-2
2—3
2—4
2— 5
3— 1
3— 2
4— 1
4—2
4-3
4—4
4-5
4—6
4—7
4- 8
5- 1
5-2
5—3
5—4
5—5
5—6
5-7
5—8
5-9
7-1
7-2
7-3
7—4
7—5
7— 6
8— 1
8—2
A—1
A-2
A—3
A—4
A-5
A—6
A—7
xviii

Topology of a Multiple-Area DECnet Network _
1-19
Network Access Levels and DECnet-VAX User Interface _
1-22
Remote File Access Using Access Control String Information _
1-25
Remote File Access Using Default Access Control Information _
1-26
Multipoint Circuits and Associated Lines _
2-9
Multipoint Lines _
2-13
Dynamic Switching of Asynchronous DDCMP Lines _
2-15
Routing Initialization Passwords _
2-36
Access Control for Inbound Connections _
2-38
Remote Command Execution _
3-6
Network Circuit Costs _
3-63
Target-Initiated Downline Load _
4-3
Operator-Initiated Downline Load _
4-4
Operator-Initiated Downline Load over DDCMP Circuit (TRIGGER
Command) _
4-7
Operator-Initiated Downline Load over Ethernet Circuit (TRIGGER
Command) _
4-8
Operator-Initiated Downline Load over Ethernet Circuit (LOAD
Command) _
4-9
Operator-Initiated Downline Load over DDCMP Circuit (LOAD
Command) _
4-11
Upline Dumping of RSX—11S Memory _
4-1 5
Downline Task Loading _
4-17
A Synchronous DDCMP Point-to-Point Network Configuration _
5-13
A DDCMP Multipoint Network Configuration _
5-15
A Static Asynchronous DDCMP Network Configuration _
5-17
A Dynamic Asynchronous DDCMP Network Configuration _
5-19
An Ethernet Network Configuration _
5-21
An X.25 Data Link Mapping Network Configuration _
5-22
An X.25 Native-Mode Network Configuration _
5-25
An X.25 Multihost Mode Network Configuration _
5-27
A Multinetwork Configuration _
5-30
Remote Loopback Test_7-3
Local-to-Remote Loopback Test Using a Loop Node Name _
7-4
Local-to-Local Loopback Test Using a Loop Node Name _
7-5
Local Loopback Test _
7-6
Software Loopback Test _
7-7
Controller Loopback Testing _
7-8
Mailbox Messages _
8-8
Mailbox Message Format _
8-24
Level 2 Router Subnetwork of a Multiple-Area Network _
A-3
Example of Multiple-Area Network Design _
A-4
Area 7 of a Multiple-Area Network _
A-6
Partitioned Area Problem _
A-11
Problem of Phase III Node In Phase IV Path _
A-13
Area Leakage Problem _
A-15
Area Routing on an Ethernet _Glossary-1

Contents

TABLES
1—1
3—1
3-2
3—3
3—4
3—5
3—6
3— 7
4— 1
5— 1
5—2
5—3
5- 4
6— 1
8—1
8—2

Network Access Levels _
Node Parameters and Their Functions _
Types of Circuits and Applicable Circuit Parameters _
Circuit Parameters and Their Function _
Types of Lines and Applicable Line Parameters _
Line Parameters and Their Functions _
Object Parameters and Their Functions _
Logging Parameters and Their Function _
Default Loader Files by Target Device Type _
Required DECnet—VAX Privileges __
Required VAX PSI Privileges _
Driver Sizes _
Permanent Configuration Database Files _
Local Node States and Network Operations _
System Service Calls for Transparent Communication _
System Service Calls for Nontransparent Communication _

1-21
3-14
3-33
3-35
3-50
3-51
3-70
3-81
4-12
5-2
5-3
5-33
5-38
6-3
8-16
8-22

Preface
The VAX/VMS Networking Manual presents an introduction to networking
software used on VAX/VMS systems. It provides a conceptual description
of DECnet-VAX software used to access the DECnet network, and VAX
Packetnet System Interface (PSI) software used to access packet switching
data networks. The manual explains how to configure and manage the
network using the VAX/VMS Network Control Program (NCP), the
primary tool for network management. It also explains how to perform
user operations over the network.

Intended Audience
The VAX/VMS Networking Manual is intended for those who will be
performing network management functions to control, monitor, or test
DECnet-VAX and VAX PSI software running on a VAX/VMS operating
system. The manual is also intended for VAX/VMS users who will be
performing remote file access or task-to-task operations using DECnet-VAX.
The manual assumes the reader is familiar with VAX/VMS, but may or may
not have experience with DECnet operations.

Structure of This Document
The VAX/VMS Networking Manual is divided into four major parts:
•

Part I, Introduction to DECnet-VAX and VAX PSI, introduces the user
to basic networking concepts required to understand DECnet-VAX
operations, and indicates how the user can interact with the network.

•

Part II, Network System Management, provides usage information to those
responsible for DECnet-VAX system management, and explains how to
use the Network Control Program to manage the network and perform
VAX/VMS host services to remote systems (such as downline loading and
upline dumping).

•

Part III, Network Configuration, Installation, and Testing, specifies the
procedures for configuring, installing, and testing DECnet-VAX and VAX
PSI on a VAX/VMS operating system.

•

Part IV, Network User Operations, describes the techniques for carrying
out user operations over the network, including accessing remote files and
performing task-to-task communications.

Preface

Associated Documents
The networking concepts and operations described in the VAX/VMS
Networking Manual are directly related to the following two manuals:
VAX/VMS Network Control Program Reference Manual
VAX/VMS DECnet Test Sender/DECnet Test Receiver Utility Reference
Manual
DECnet-VAX messages are documented in the VAX/VMS System Messages and
Recovery Procedures Reference Manual. The procedure for installing the key
for the DECnet-VAX license is described in the DECnet-VAX Key Installation
Guide.
The information in the networking manual is also related to these other
VAX/VMS manuals:
Introduction to the VAX/VMS Document Set
VAX/VMS System Manager's Reference Manual
VAX/VMS DCL Concepts Manual
VAX/VMS DCL Dictionary
VAX/VMS System Routines Reference Volume
Guide to VAX/VMS Pile Applications
Writing a Device Driver for VAX/VMS
VAX/VMS System Services Reference Manual
VAX/VMS Authorize Utility Reference Manual
VAX/VMS System Generation Utility Reference Manual
See also the VAX/VMS Release Notes.
The Introduction to DECnet manual, not part of the VAX/VMS documentation
set, provides an overview of DECnet software.
For information concerning VAX PSI, refer to the following manuals which
make up the VAX PSI documentation set.
Introduction to VAX PSI
VAX PSI Installation Procedures
VAX PSI X.25 Programmer's Guide
VAX PSI X.29 Programmer's Guide
VAX PSI Management Guide
VAX PSI Packet Assembler/Disassembler (PAD) and Mail Utilities
VAX PSI Problem Solving Guide
VAX PSI Public Network Information Cards
VAX PSI Release Notes
The following functional specifications define DIGITAL Network Architecture
(DNA) protocols to which all implementations of DECnet adhere:
DECnet DIGITAL Network Architecture General Description
DIGITAL Data Communications Message Protocol Functional Specification
Network Services Protocol Functional Specification
Maintenance Operation Protocol Functional Specification
Data Access Protocol Functional Specification
Routing Layer Functional Specification
DNA Session Control Functional Specification
DNA Phase IV Network Management Functional Specification
Ethernet Node Product Architecture Specification
Ethernet Data Link Functional Specification

xxii

Preface

Conventions Used in This Document

•

Convention

Meaning

SET LINE line-id COST cost

Example command words are shown in a
command line in capital letters, and they
must be entered as shown. Arguments
are shown in command lines as lowercase
letters. (In this case, you replace the
argument shown in the command format
with the precise information requested.)

Command words or arguments within
braces indicate that you must choose only
one of the command words or arguments.
(Do not include the braces when entering
the command.)

] RESTRICTED
v SHUT

SET KNOWN LINES ALL
SE KN LINE ALL

You can abbreviate any command verb
to its fewest unique letters. (In this
manual, however, commands, formats,
and examples use the complete command
words.)
A vertical series of periods, or an ellipsis,
means either that not all the data that the
system would display in response to the
particular command is shown or that not
all the data a user would enter is shown.

•
•

LOAD NODE ...

Horizontal ellipsis indicates that additional
parameters, values, or information can be
entered.

NCP> EXIT

Command examples show all output lines
or prompting characters that the system
prints or displays in black letters.
This document uses red lettering to
indicate all user-entered commands.

|CTRL/x|

The phrase CTRL/x indicates that you
must press the key labeled CTRL while
you simultaneously press another key,
for example, CTRL/C, CTRL/Y, CTRL/O.
In examples, this control key sequence
is shown as ~x, for example, X, *Y, X,
because that is how the system echoes
control key sequences.

[ret]

A symbol with a one- to three-character
abbreviation indicates that you press a key
on the terminal, for example, 1 ret| .

[opt-arg]

Square brackets indicate that the enclosed
item is optional.

xxiii

New and Changed Features
The following technical changes have been made to DECnet-VAX software as
described in the VAX/VMS Networking Manual for VMS V4.4:
•

Addition of the capability of treating the nodes in a VAXcluster as a
single node, while retaining the ability to address each node in the
cluster individually. The mechanism is the alias node identifier, which
is a node name or address common to some or all nodes in the cluster.
The NCP executor parameter ALIAS NODE node-id specifies the alias
your cluster node assumes. The executor parameter ALIAS INCOMING
indicates whether your node will accept incoming connection requests
addressed to the alias node identifier. The executor parameter ALIAS
MAXIMUM LINKS limits the number of logical links you can initiate
using the alias node address. The object parameter ALIAS OUTGOING
identifies the network services that are to use the alias node address for
outgoing connections, while the object parameter ALIAS INCOMING
specifies whether certain network services will respond to incoming
connect requests directed to the alias node address.

•

Files composing the permanent database can now be shared between
nodes in a VAXcluster. To aid in sharing, the Version 4.3 permanent
node file NETNODE.DAT will be converted during the VMS Version
4.4 upgrade to two files: NETNODE_LOCAL.DAT and NETNODE_
REMOTE.DAT. This change results in a revision to the procedure for
converting an existing network to a multiple-area network.

•

Addition of a new Ethernet circuit device, the DELUA, similar in function
to a DEUNA.

•

Addition of a new DMR11 line parameter, TRANSMIT PIPELINE, which
provides for more efficient use of satellite links.

•

Addition of VAX PSI support for multiple networks. A VAX PSI system
can now be configured for more than one DTE and for several network
connections to several PSDNs. Therefore, for certain configurations,
references in this manual to your local DTE, network, or PSDN may
actually apply to multiple DTEs, networks, or PSDNs. New NCP
parameters identify the network connections for DTEs, destinations,
circuits and lines. Specifically, the NETWORK/KNOWN NETWORKS
parameter in the X.25 protocol module command identifies the networks
to which the DTEs are connected. The NETWORK parameter is used
in the X.25 server module command to indicate from which network a
destination will accept calls, and in circuit and line commands to associate
an X.25 circuit or line with a network. An example of a multinetwork
configuration appears in this manual.

•

Addition of certain NCP parameters for an X.25 protocol module being
used with an ISO standard 8208 network. The two parameters used with
the DTE qualifier in the X.25 protocol module command are INTERRUPT
TIMER and INTERFACE. The INTERFACE parameter, which indicates
whether the processor acts as a DTE or DCE, can also be specified for an
X.25 line.

•

Association of several existing X.25 protocol module parameters with
particular DTEs.

XXV

New and Changed Features

•

Addition of the following new NCP parameters to the X.25/X.29 server
module to identify destinations and support the called address extension
facility:
CALLED ADDRESS
EXTENSION MASK
INCOMING ADDRESS
EXTENSION VALUE
RECEIVING DTE
REDIRECT REASON
SENDING ADDRESS

•

Use of VAX PSI for DCE to DTE operations, enabling the X.25 protocol to
be used for back-to-back operations.
Deletion of support for the tracing facility with VAX PSI. The
SET/DEFINE MODULE X25-TRACE command is no longer supported
except for control of VAX PSI software prior to Version 4.0.

The VAX/VMS Networking Manual, now a reference manual, was previously
published as a guide, the Guide to Networking on VAX/VMS, in VAX/VMS
Version 4.2.

XXVI

PART I: Introduction to DECnet-VAX and
VAX PSI

Overview of DECnet—VAX and VAX PS I

This chapter presents an overview of the networking software used on
VAX/VMS systems: what the software is, how to manage it, and how to
interface with it as a user. The chapter introduces DECnet-VAX software,
which enables access to the DECnet network, and VAX PSI software, which
provides access to a packet switching network. The same VAX/VMS network
management tools are used to manage both DECnet-VAX and VAX PSI.
The following sections introduce the network terms and concepts that you
will encounter throughout this manual, identify network software, describe
network configurations, and provide a brief summary of network management
responsibilities. The chapter also defines the application user's relationship to
the network.
For details about specific topics, you should consult the pertinent chapters
of this manual, other manuals in the VAX/VMS document set, and VAX PSI
manuals (see the Preface).

1.1

General Description of a DECnet Network
Computer processes communicate with one another over a data network.
This network consists of two or more computer systems called nodes and the
logical links between them. A logical link is a connection, at the user level,
between two processes. Adjacent nodes are connected by physical lines over
which circuits operate. A circuit is a communications data path over which
all input and output (I/O) between nodes takes place. A circuit can support
many concurrent logical links.
Nodes can also be physically connected to a packet switching data network
(PSDN) to allow DECnet circuits to be mapped to PSDN virtual circuits.
Virtual circuits are logical associations between nodes for the exchange
of data; the actual circuit employed is invisible to the user. Alternatively,
computers or terminals can be attached directly to a PSDN without using a
DECnet data link, or can use a connector node as a gateway to communicate
with remote nodes over a PSDN.
In a network of more than two nodes, the process of directing a data message
from a source to a destination node is called routing. DECnet supports
adaptive routing, which permits messages to be routed through the network
over the most cost-effective path; messages are rerouted automatically if a
circuit becomes disabled.
Nodes can be either routing nodes (called routers) or nonrouting nodes
(known as end nodes). Both routing nodes and end nodes can send messages
to and receive messages from other nodes in the network. However, routing
nodes have the ability to forward or route messages from one node to another
when the two nodes exchanging these messages have no direct physical link
between them, except for the path that includes the node forwarding the
message. End nodes can never have more than one circuit connecting them
with the network. Any node that has two or more circuits connecting it to
the network must be a router.

1-1

Overview of DECnet-VAX and VAX PSI

Phase IV DECnet supports the configuration of very large, as well as small,
networks. In a network that is not divided into multiple areas, 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, consisting 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 subnetwork.
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 referred to as level 1 routers; those that perform routing between areas as
well as within their own area are called level 2 routers (or area routers).

1.2

DECnet-VAX and VAX PSI
DECnet-VAX networking software can be configured on all VAX/VMS
operating systems and all MicroVMS operating systems. VAX PSI software
can also be installed and configured on VAX/VMS and MicroVMS systems.
These software products are identified and described below.

1.2.1

DECnet Interface with VAX/VMS
DECnet is the collective name for the software and hardware products
that are a means for various DIGITAL operating systems to participate in
a network. DECnet-VAX is the implementation of DECnet that causes
a VAX/VMS operating system to function as a network node. As the
VAX/VMS network interface, DECnet-VAX supports both the protocols
necessary for communicating over the network and the functions necessary
for configuring, controlling, and monitoring the network. A DECnet-VAX
node can communicate with other DECnet-VAX nodes in the network or with
any other DIGITAL operating system that supports DECnet.
A DECnet multinode network is decentralized; that is, many nodes connected
to the network can communicate with each other without having to go
through a central node. As a member of a multinode network, your node can
communicate with any other network node, not merely the nodes that reside
next to you, and gain access to software facilities that may not exist on your
local node. An advantage of this type of network is that it allows different
applications running on separate nodes to share the facilities of any other
node.
Optionally, very large DECnet networks can be divided into multiple areas,
for the purpose of hierarchical (area) routing. Area routing introduces a
second, higher level of routing between areas (groups of nodes), which results
in less routing traffic throughout the network. Each node in a multiple-area
network can still communicate with all other nodes in the network.

Overview of DECnet—VAX and VAX PSI

1.2.2

VAX Packetnet System Interface
VAX Packetnet System Interface (PSI) is a software product that allows
the VAX/VMS user to communicate across PSDNs. VAX PSI implements
the CCITT X.25 and X.29 recommendations (described in Section 1.3.4),
providing a user interface to a PSDN. A PSDN consists of switching nodes
connected by high-speed links, to which computers or terminals can be
attached.
You can use VAX PSI in the following ways:
•

To link DECnet nodes across a PSDN through data link mapping (DLM).
This permits an X.25 virtual circuit to be used as a DECnet data link.

•

To communicate directly across a PSDN to a DIGITAL or non-DIGITAL
computer over an X.25 virtual circuit.

•

To communicate directly across a PSDN to a character-mode terminal that
is connected to a packet assembly/disassembly (PAD) device. The PAD
may be privately owned or located within the PSDN.

•

To communicate by way of a PSDN between terminals on a local VAX PSI
node and remote DIGITAL or non-DIGITAL computers. VAX PSI contains
a host-based PAD that provides this capability.

An alternative version of VAX PSI, called VAX PSI Access, can be used on a
VAX/VMS node that does not connect directly to a PSDN. VAX PSI Access
provides all the capabilities of VAX PSI, except that it uses DECnet to connect
to a VAX PSI node, which in turn connects to a PSDN. The VAX PSI node is
known as a connector node and the VAX PSI Access node is known as a host
node. Each connector node can connect to one or more PSDNs, and each
host node can connect to one or more connector nodes.
In addition, two VAX/VMS nodes with VAX PSI may communicate with each
other using the X.25 protocol, but without a PSDN. The nodes are linked by
a cable or leased line. One node acts as a DTE and the other node as a DCE.

1.2.3

DECnet Functions
Networking functions you can perform using DECnet-VAX are listed below.
These functions are introduced in this chapter and described in detail in later
chapters of this manual, as indicated.
•

Network management functions
— Controlling the network (Chapters 2 through 7)
— Providing DECnet-VAX host services to other DECnet nodes
(Chapter 4)
— Performing routing configuration and control (Chapters 2 and 3)
— Establishing DECnet-VAX configurations (Chapters 2, 3 and 5)

•

Applications user functions
— Accessing files across the network (Chapters 8 and 9)
— Using a heterogeneous command terminal (Chapter 8)
— Performing task-to-task communications across the network
(Chapter 8)

1-3

Overview of DECnet-VAX and VAX PSI

DECnet products are based on the layered network design specified in the
DIGITAL Network Architecture (DNA). Figure 1-1 illustrates the DECnet
functions, the various DNA layers at which they are initiated, and the DNA
protocols by which these functions are implemented. Each DNA layer is a
client of the next lower layer and does not function independently. For a
complete description of DNA, see the DNA specifications. The DECnet-VAX
configurations that use the Ethernet, DDCMP, Cl, and X.25 protocols are
defined in the following section.
Figure 1-1

DECnet Functions and Related DNA Layers and
Protocols

DECnet Functions
File Access
Command Terminals
Host Services
Network Control
i—
z
LU

Task-to-Task Communications

DNA Layers

DNA Protocols

USER

User Protocols

NETWORK APPLICATION

Data Access Protocol (DAP)
and others

SESSION CONTROL

Session Control Protocol

END COMMUNICATION

Network Services Protocol (NSP)

Adaptive Routing

Host Services

o
£
f—
LU

ROUTING

Routing Protocol

DATA LINK

DDCMP
-;

Packet Transmission/Reception

PHYSICAL LINK

1
w

F "

- c
uT

Ethernet
1
l

1
|

|
Cl

1
|X.25

1
t

1
i

ZK-1850-84

1.3

DECnet—VAX Configurations
DECnet supports the following network connections:
•

A connection to an Ethernet circuit in a local area network configuration

•

A connection to a node running DECnet using the DIGITAL Data
Communications Message Protocol (DDCMP): either a synchronous
point-to-point or multipoint connection or an asynchronous static or
dynamic point-to-point connection

•

A connection over the computer interconnect (Cl) to another node running
DECnet

•

An X.25 connection to a node running DECnet (either a direct connection
over a PSDN or a connection made by means of an X.25 multihost
connector node that accesses a PSDN)

Overview of DECnet-VAX and VAX PSI

Figure 1-2 is a sample DECnet-VAX Phase IV configuration that illustrates
various kinds of DECnet-VAX nodes (MicroVMS end nodes, VAX/VMS
routers and end nodes, and VAX/VMS routers in a VAXcluster) connected to
an Ethernet, and two Ethernets connected by means of routers. The figure
shows the use of a DDCMP synchronous line to connect a router to additional
DECnet nodes, and static (permanent) asynchronous DDCMP lines to connect
MicroVMS end nodes to a router. It also indicates a dialup connection
between a MicroVMS system and a routing node in the VAXcluster over a
dynamic asynchronous DDCMP line (switched on for the length of the call).
The figure demonstrates two kinds of connections to a PSDN: a VAX/VMS
node connected directly to a PSDN by means of an X.25 circuit, and
VAX/VMS host nodes connected to a PSDN by means of a VAX/VMS
connector node that serves as a gateway to the PSDN. DECnet-VAX
connections are described below. A detailed discussion of the various types
of circuits and lines used in a DECnet network is presented in Chapter 2.
Figure 1-2

Sample DECnet-VAX Phase IV Configuration

ZK-1859-84

1.3.1

DECnet—VAX Ethernet Local Area Network Configuration
The Ethernet is a local area network component that provides a reliable high¬
speed communications channel, optimized to connect information processing
equipment in a limited geographic area, such as an office, a building, or a
complex of buildings (for example, a campus).

1-5

Overview of DECnet-VAX and VAX PSI

Local area networks (LANs) are designed for a wide variety of technologies
and arranged in many configurations. Digital Equipment Corporation,
Intel Corporation, and Xerox Corporation collaborated in producing the
Ethernet specification to develop a variety of LAN products. DIGITAL's
implementation of the Ethernet specification that was originated by the Xerox
Corporation appears at the lowest two levels of the overall DNA specification:
the Physical layer and the Data Link layer.
At the Physical layer, the Ethernet topology is a bus, in the shape of a
branching tree, and the medium is a shielded coaxial cable that uses
Manchester-encoded, digital baseband signaling. The maximum data rate
is 10 million bits per second. Maximum utilization of an Ethernet's data
transmission capability occurs when multiple pairs of nodes communicate
simultaneously. In practice, DECnet transmission between a pair of nodes on
an Ethernet occurs at a considerably lower rate. Each Ethernet can support
up to 1023 nodes; the maximum possible distance between nodes on the
Ethernet is 2.8 kilometers (1.74 miles).
At the Data Link layer, network control for the Ethernet is multiaccess, fairly
distributed to all nodes. Ethernet access control is CSMA/CD. The frame
length allocation is from 64 to 1518 bytes (including an 18-byte envelope).
Ethernet circuit devices supported by DECnet-VAX are the DEUNA and
DELUA (both known as the UNA) and the DEQNA (called the QNA). The
VAX/VMS system uses the DEUNA or the DELUA, and the Micro VMS
system uses the DEQNA.
1.3.1.1

Ethernet Datagrams
Message packets sent over Ethernet are called datagrams. Because there is
no guarantee that a datagram will be received by the intended destinations,
reliable connections (in the form of virtual circuits) may be provided by
interposing a protocol between the user and the Ethernet datagram service.
In DNA, this virtual circuit is provided by the Network Services Protocol
(NSP) in the End Communication layer.
Initialization of nodes on Ethernet is based on multicast addressing and the
use of datagrams. It differs from initialization of nodes on DDCMP circuits in
that it does not involve guaranteed delivery of routing messages.

1.3.1.2

Transmission and Reception of Ethernet Packets
An Ethernet is a single shared network channel, with many nodes demanding
equal access to it. The technique used to mediate these demands is CSMA
/CD (Carrier Sense, Multiple Access with Collision Detect). A good
analogy for this technique is the interaction of people at a social gathering.
To be polite, one does not speak while someone else is talking; that is, one
listens before speaking; on the Ethernet, listening to determine whether the
communication medium is already in use is called carrier sense. Messages
are said to be initially deferred if they are not sent on the Ethernet because a
transmission is in progress.
At a social gathering, anyone may begin to talk once he or she determines
that no one else is; the ability of any station on the Ethernet to use the
communication medium is known as multiaccess. If two or more people,
detecting silence, start to talk at about the same time, they note the fact
and stop talking (that is, each listens while talking and stops if interfering
with someone else); the noting of the fact that more than one station is
transmitting, followed by the cessation of communication, is called collision
detect.

1—6

Overview of DECnet-VAX and VAX PSI

When two or more people at a social event start talking simultaneously, they
stop talking, wait some random time, and start talking again; on an Ethernet,
this situation is known as backoff and retransmission, and it is expected that
a random delay before retransmission will eventually clear the collision
situation.
There is a further useful analogy between Ethernet and a social event. When
one is talking to a group of people, everyone can hear everything said. Some
of what is said is intended for everyone, some is intended for a subset of
the group (say, everyone over 21), and some is intended for an individual.
Stations on an Ethernet can hear every message. Some messages are intended
for all stations (broadcast address), some are intended for a subset (multicast
address), and some are intended for individual stations (physical address).
On an Ethernet, every station can listen to every message, and messages
can be addressed to their intended recipient(s). These two features greatly
increase the communications efficiency of a network that uses Ethernet over
that of a completely connected DDCMP network.
1.3.1.3

1.3.2

Ethernet Routers and End Nodes
Ethernet supports connections to routers and end nodes. On an Ethernet, a
routing node selected as a designated router can perform routing services on
behalf of end nodes. In addition, routers can route packets between Ethernet
nodes and non-Ethernet nodes (such as nodes on DDCMP circuits). An end
node on an Ethernet can communicate directly with any other node (router
or end node) on the same Ethernet by sending a message directly to the
addressed node. Note that an end node on a non-Ethernet circuit can only
communicate with an adjacent node on the same circuit.

DDCMP Network Configurations
DDCMP provides a low-level communications path between systems. The
DDCMP protocol performs the basic communications function of moving
information blocks over an unreliable communication channel. (The protocol
detects any bit errors introduced by the channel and requests retransmission
of the block.) DDCMP is also used to manage the orderly transmission and
reception of blocks on channels with one or more transmitters and receivers.
The DDCMP protocol is supported on synchronous and asynchronous
communications devices. DDCMP connections can be point-to-point or
multipoint configurations. Point-to-point connections are either synchronous
or asynchronous. The two types of asynchronous connections are static
(permanent) and dynamic (switched temporary). Multipoint connections are
always synchronous. These connections are described below.
1.3.2.1

DDCMP Point-to-Point and Multipoint Connections
Figure 1-3 illustrates DDCMP point-to-point and multipoint configurations.
A point-to-point configuration consists of two systems connected by a single
communication channel.
A multipoint configuration consists of two or more systems connected by a
communications channel, with one of the systems (called the control station)
controlling the channel. All other systems on the communications channel
are known as tributaries. (Note that if only two systems are connected in a
multipoint configuration, one is the master and one is the tributary. However,
this is not a very efficient use of the communication channel.) The control
station is responsible for telling the tributaries, in turn, when they may use
the channel; this procedure is known as polling. Tributaries are not allowed
to use the channel until they are polled. The control station, however, may
1-7

Overview of DECnet-VAX and VAX PSI

use the channel whenever it is available. Also, the tributaries on a multipoint
line are not allowed to communicate directly with each other, but only
through the master.
Figure 1-3

Typical DDCMP Point-to-Point and Multipoint
Connections

ZK-1862-84

Point-to-point circuits and multipoint circuits perform as virtual circuits:
nodes on these circuits interact as though a specific circuit were dedicated
to them throughout the transmission; in fact, however, the actual physical
connection is allocated by the routing mechanism. Initialization of nodes
on DDCMP circuits involves guaranteed delivery of routing messages. Also,
individual nodes on DDCMP circuits must be addressed directly; no multicast
or broadcast addressing capability is available as with an Ethernet circuit.
1.3.2.2

Synchronous DDCMP Connections
Synchronous communications devices are used for high-speed point-to-point
or multipoint communication (for example, connecting two VAX-11/780
systems).
The synchronous DDCMP protocol can run in full- or half-duplex operation.
This allows DDCMP the flexibility of being used for local synchronous
communications, or for remote synchronous communications over a telephone
line using a modem. DDCMP has been implemented in microcode in such
devices as the DMC11 and DMR11 to run at speeds up to one megabit per
second in a point-to-point configuration. The DDCMP multipoint protocol
(point-to-point also) has been implemented in microcode in the DMP11
device to run at speeds up to 500 kilobits per second. For the DMF32,
DDCMP has been implemented in the driver software for the synchronous
communications port.

1.3.2.3

Asynchronous DDCMP Connections
Asynchronous connections provide for low-speed, low-cost, point-topoint communication (for example, as an inexpensive way of connecting
a Micro VAX system to a VAX-11/780 system). Asynchronous DDCMP
is implemented in software and can be run over any terminal line that
VAX/VMS supports. The asynchronous DDCMP protocol provides for a fullduplex connection and can be used for local asynchronous communications
or for remote asynchronous communications over a telephone line using
a modem. Asynchronous connections are not supported for maintenance
operations or for controller loopback testing.
Two kinds of asynchronous connections can be made over the network:
•

1-8

A static connection: the asynchronous line is permanently configured as a
communications device

Overview of DECnet—VAX and VAX PSI

•

1.3.2.4

A dynamic connection: a line connected to a terminal port is switched to
an asynchronous communications line for the duration of a call

Static Asynchronous Connections
A static asynchronous DDCMP connection is a permanent DECnet connection
between two nodes (for example, a Micro VMS node and a VAX/VMS node)
physically connected by terminal lines. The terminal lines are converted
to static asynchronous DDCMP lines by issuing commands to set the lines
to support the DDCMP protocol. The user at each node then turns the
appropriate circuits and lines on for DECnet use. Once the communications
link is established, it remains available until a user turns off the circuit and
line and clears the entries from the DECnet database.
Static asynchronous DDCMP configurations require that the asynchronous
DDCMP driver be connected. The asynchronous DDCMP protocol can
run in full-duplex operation on local asynchronous communication devices.
Examples of these devices are the DZ11 and the DMF32 asynchronous
communications port.
The user can configure a dialup line as either a static or dynamic
asynchronous line, but may find the dynamic connection more secure and
convenient to use.

1.3.2.5

Dynamic Asynchronous Connections
A dynamic asynchronous connection is a temporary connection between two
nodes, generally over a telephone line using modems. The terminal lines
at both ends of the connection can be switched to asynchronous DDCMP
communications lines and then switched back to terminal lines.
You can use dynamic asynchronous connections to establish a DECnet link to
another computer for a limited time or to create links to different computers
at different times.
For example, as a Micro VMS system user, you can cause a dynamic
asynchronous connection to be made for the length of the telephone call
to a VAX-11/780 system. You must first establish your system as a terminal
emulator (enabling the processor to perform as though it were a terminal
line). You dial in over a telephone line to the other system (which is
established as a virtual terminal) and log in. You can then issue a command
which causes the terminal lines at each end of the connection to be switched
to asynchronous lines for DECnet use. When you hang up or turn the circuit
off, the lines are automatically switched back to terminal lines.
Security measures provide protection against a caller at an unauthorized
node being able to form a dynamic asynchronous connection with another
node (see Section 2.10.6). Before a dialup node can establish a dynamic
connection with a remote node, the remote node verifies that the dialup
node is authorized to make a connection. It checks that the node is of
the appropriate type (router or end node), and, without revealing its own
password, verifies the routing initialization password sent by the dialup node.
Also, for increased security, the connection will be ended automatically when
the telephone is hung up.
A dynamic asynchronous connection can also be established over a hardwired
terminal line. The connection is maintained for the duration of the DECnet
session. The dynamic connection permits the system to be used as a terminal
emulator when not switched to DECnet use.

1-9

Overview of DECnet-VAX and VAX PSI

1.3.3

DECnet—VAX Configurations for VAXciusters
A VAXcluster is an organization of VAX/VMS systems that communicate over
a high-speed communications path, the Cl, and share processor resources
as well as disk storage. Figure 1-4 shows a typical VAXcluster. The Cl is
the physical link between the nodes in a VAXcluster. Cl cables from the
individual nodes in the cluster are connected to a star coupler. The HSCs are
hierarchical storage controllers that enable VAXcluster nodes to share disks.
Figure 1-4

Typical VAXcluster Configuration Using Cl as a Data
Link

ZK-1861-84

DECnet-VAX connections are required for all VAX/VMS systems in the
VAXcluster. Use of DECnet-VAX ensures that VAXcluster system managers
can access each node in the cluster from a single terminal, even if terminal¬
switching facilities are not available. DECnet-VAX is also required by the
User Environmental Test Program (UETP).
The choices for DECnet-VAX physical links for use in the VAXcluster are
•

Connecting each VAX/VMS node in the cluster to an Ethernet (as shown
in Figure 1-2)

•

Using the Cl that connects the cluster nodes as the DECnet-VAX data link
(as shown in Figure 1-4)

Connecting each VAXcluster node to an Ethernet provides distinct advantages:

1-10

•

Each node in the cluster can be an end node, resulting in lower overhead
for these nodes, decreased routing traffic throughout the network, and
simpler installation procedures. Note that there must be at least one
router on the Ethernet to which the cluster end nodes are attached.

•

Ethernet provides for better performance in DECnet transmissions than
the Cl, despite the higher data link bandwidth of the Cl, because the
Ethernet communications protocol allows larger buffer sizes.

Overview of DECnet-VAX and VAX PSI

•

Terminal servers can be used when nodes in a VAXcluster are connected to
an Ethernet. DIGITAL's terminal servers offer a number of benefits to the
VAXcluster user, such as load balancing and easier cluster management.

If only one physical link is used to connect each cluster node to the network,
the Ethernet link should be used instead of the Cl data link, because of
the better DECnet performance of the Ethernet. In this case, the Cl should
perform the functions of a system bus and not be enabled as a DECnet data
link.
A VAXcluster node connected to an Ethernet may require additional DECnet
links in order to communicate with remote nodes not on the Ethernet. A
VAXcluster node connected to more than one DECnet link must be configured
as a router, not an end node.
If the nodes in the VAXcluster are not connected to an Ethernet, the Cl should
be used as the DECnet data link between the nodes. Cl circuit devices are
configured as though they were multipoint devices, but each node on the Cl
can talk directly to every other node and no polling is involved.
A two-node VAXcluster that uses the Cl as the data link can be configured
using end nodes. If additional nodes are configured in the cluster, however,
at least one router is required. The Cl does not have a broadcast capability
(such as that of the Ethernet). Thus, the router is needed so that the nodes
in the cluster can identify each other. If the router in a three-node cluster
fails, the cluster reverts to being a two-node cluster and can consist of end
nodes only. Network management commands can be used to create a circuit
between the end nodes. For a cluster of four or more nodes, more than one
router is required in order to prevent the loss of communications capability
between the remaining nodes if one router fails. Also, backup circuits can be
provided between end nodes in case of router failure.
A VAXcluster can be configured so that the whole cluster appears to other
network nodes as though it were a single node, with an address different from
that of any DECnet node within the VAXcluster. This address usually has a
node name associated with it. Thus it is possible to access the VAXcluster
as a whole by an alias node identifier, which can be either its node name
or its node address. All or some of the nodes in a VAXcluster can elect
to use this special node identifier as an alias, while retaining their unique
individual node names and addresses. Each node that assumes the alias node
identifier can specify whether it will accept incoming connections directed
to the alias address. It can also specify the network services for which the
cluster alias node identifier is to be used on outgoing connections and the
network services that will accept incoming calls.
At least one of the nodes in the cluster that accepts the alias node identifier
must be a router. The router informs other nodes in the network of the alias
node address for the cluster. When the router receives packets addressed
to the alias node address, it forwards them to the appropriate nodes in the
cluster. The cluster alias node identifier can be very useful in network
operations involving shareable resources. Network users outside the
VAXcluster can access cluster resources without knowing which nodes are
active in the cluster. For example, if a user on a cluster node sends a MAIL
message, it does not matter whether that particular node is active when a
reply to the message is received.

1-11

Overview of DECnet-VAX and VAX PSI

1.3.4

X.25 Network Configurations
Packet switching data networks provide fast, dependable communications
between geographically distributed nodes. Data transmitted over a PSDN
is divided into packets, each of which has a header containing control and
destination information. The PSDN interleaves packets from many users over
shared transmission lines and delivers the packets in the correct order to the
proper destinations. The routing of packets through the PSDN is handled by
the PSDN itself and is invisible to the user.
In X.25 network terminology, your computer or terminal is called data
terminal equipment (DTE) and the PSDN interface to which it is connected
is known as data circuit-terminating equipment (DCE). The DTE can
operate in packet mode or in character mode. A character-mode terminal is
also known as an X.29 terminal.
1.3.4.1

X.25 and X.29 Recommendations
Recommendations for standard network interfaces for DTEs have been
established by the CCITT (Comite Consultatif International Telegraphique
et Telephonique). The X.25 recommendation defines the interface between
the packet-mode DTE and the DCE. The X.25 recommendation defines
three levels of protocols for this interface: Level 1 covers physical and
electrical characteristics; Level 2, link access procedures; and Level 3, packet
procedures.
The X.29 recommendation defines the procedures for information exchange
between a packet-mode DTE (an asynchronous terminal) and the packet
assembly/disassembly (PAD) facility of the PSDN or host.
Communication between a local DTE and a remote DTE is by means of a X.25
virtual circuit, a logical association between the two DTEs set up specifically
to handle the exchange of data between them. An X.25 virtual circuit can
be permanent or temporary. The permanent virtual circuit (PVC) is similar
to a leased line. The temporary or switched virtual circuit (SVC) is similar
to a dialup line and requires that calls be set up and cleared. A local DTE is
connected to the PSDN by a synchronous X.25 line, over which X.25 virtual
circuits operate. Examples of X.25 line interfaces are the DUP11 and the
DMF32 synchronous line unit.
As well as supporting various PSDNs, VAX PSI can also support an ISO
standard 8208 network. IS 8208 is the International Standards Organization's
definition of the CCITT X.25 recommendations.
Note that a single VAX PSI system can support several DTEs. These may
either be connected to different PSDNs or provide different routes to the
same PSDN.

1.3.4.2

1—12

X.25 Connections
Figure 1-5 illustrates typical X.25 connections that permit a VAX/VMS node
to communicate with a remote node over a PSDN. A VAX/VMS node can be
configured to communicate over a PSDN in the following ways:

Overview of DECnet-VAX and VAX PSI

Figure 1-5

X.25 Connections in a DECnet Network
Configuration

•

By means of a data link mapping (DLM) circuit, an X.25 virtual circuit
used as a DECnet data link (provided the remote node runs PSI and
DECnet-VAX or DECnet-RSX)

•

Through a direct connection to a PSDN over an X.25 virtual circuit (this is
called native-mode operation)

•

As a host node using a VAX/VMS multihost connector node to access a
PSDN

You must have VAX PSI software installed on your DECnet-VAX node to
configure your node for VAX PSI native-mode operation or multihost-mode
operation. Native-mode operation permits incoming and outgoing calls to be
made between the local node and a remote DTE. Multihost-mode operation
allows the local node to be a connector node or gateway, which host nodes
can use to communicate over a PSDN with remote DTEs. Each host node
must have VAX PSI Access software installed.
Alternatively, a VAX/VMS node with VAX PSI Access software installed can
access a PSDN by means of an Ethernet communications server, the DECnet
Router/X.25 Gateway.

1.4

Managing the Network
As system manager of a VAX/VMS operating system, you can use a network
management utility program to configure the system as a DECnet-VAX node
in the network, and perform network management and maintenance functions
for your own node and other nodes in the network. This section summarizes
network management functions.
1—13

Overview of DECnet-VAX and VAX PSI

1.4.1

Network Control Program
To configure, control, monitor, and test the network, use the Network Control
Program (NCP), a VAX/VMS utility program. The types of users who employ
NCP are
•

Users of both DECnet-VAX and VAX PSI. These users can employ all
NCP commands.

•

Users of DECnet-VAX only. DECnet-VAX users employ all NCP
commands except those that relate to X.25 modules.

•

Users of VAX PSI only. PSI native-mode and multi-host-mode users (who
are not using DECnet-VAX circuits) employ only NCP commands that
relate to X.25 modules, circuits, lines, objects, and logging.

The network components the system manager configures are listed in
Section 1.4.5.3 and described in detail in Chapter 2. The use of NCP
commands and parameters to perform network management is discussed
in Chapter 3. The NCP commands and parameters and guidelines for using
them, including restrictions on the use of individual NCP parameters, are
specified in the VAX/VMS Network Control Program Reference Manual.

1.4.2

Network Management Responsibilities
As system manager of a DECnet-VAX network, you have a number of key
responsibilities, which include:
•

Defining network components and their parameters in a central
configuration database at the local node and, optionally, at remote
nodes. (The local node is the node at which you are physically located; a
remote node is any node other than the local node in your network.)

•

Coordinating with the system managers of other nodes in the network
to ensure uniform assumptions about network parameter settings such as
circuit cost.

•

Configuring your node to ensure proper network routing operation and
updating VAX/VMS SYSGEN procedures to allow enough space for the
networking software.

•

Controlling and monitoring local and remote network operation.

•

Testing network hardware and software operation.

•

Loading systems downline to unattended remote nodes.

•

Connecting to an unattended remote node to serve as its console.

If your network includes VAX PSI, you have the following additional
responsibilities:

1-14

•

Defining VAX PSI components and their parameters in the network
configuration database and thus configuring VAX PSI.

•

Monitoring the operation of VAX PSI using PSI management utilities.

•

Analyzing hardware and software operation and diagnosing problems
related to PSI operation.

Overview of DECnet—VAX and VAX PSI

The following sections outline the network-related tasks that you perform as
system manager and describes several of the facilities DECnet-VAX and VAX
PSI provide to perform those tasks.

1.4.3

DECnet—VAX Licenses
Licenses are available for either a DECnet-VAX full function kit or a DECnetVAX end node kit. If you have purchased either license, you must install the
key for the license to enable inter-node communication. The procedure for
installing the appropriate license key is described in the DECnet-VAX Key
Installation Guide, distributed with the key.
If you have purchased a license for a DECnet-VAX end node kit and now
require the additional capabilities of the DECnet-VAX full function license,
you can purchase a DECnet-VAX license that upgrades the end node license
to a full function license. This upgrading license is applicable to all DECnetVAX nodes. The full function kit contains the material to implement this
upgrade.
The DECnet-VAX full function kit allows the node on which it has been
installed to be configured as either a routing node or an end node. The end
node kit allows the node to be configured only as an end node.

1.4.4

DECNET-VAX and VAX PSI Network Management Software
Figure 1-6 displays the DECnet-VAX and VAX PSI software that the system
manager uses to configure, control, and monitor the network.
Figure 1-6

DECnet-VAX and VAX PSI Software

Network management software components are described below.
•

Ethernet configurator (NICONFIG). NICONFIG is a network image
that listens to system identification messages on Ethernet circuits, and
maintains a user-accessible database of configuration information on all
systems on the Ethernet.

1-15

Overview of DECnet—VAX and VAX PSI

•

Event logger (EVL). EVL is an image that logs significant events to
provide information to the system manager for possible intervention or
future reference.

•

File access listener (FAL). FAL is a network image that receives and
processes remote file access requests for files at its node on behalf of
remote users.

•

Host loader (HLD). HLD is an image that communicates with the DECnetRSX Satellite Loader (SLD) to load tasks downline to an RSX-11S node.

•

Loopback mirror (MIRROR). MIRROR is a network image that participates
in Network Service Protocol (NSP) and Routing layer loopback testing.

•

Network ancillary control process (NETACP). NETACP is a VAX/VMS
ancillary control process that controls all lines and circuits, maintains a
picture of the network topology, and creates a process to receive inbound
logical link connection requests.

•

Network Control Program (NCP). NCP is an interactive utility program
that permits you to control and monitor the network.

•

Network driver (NETDRIVER). NETDRIVER is a VAX/VMS pseudo¬
device driver that provides logical link and routing services. It implements
NSP and Routing, and provides a user process with a Queue I/O (QIO)
interface to a logical link service.

•

Network management listener (NML). NML is an image that receives
network management commands, such as NCP commands, from the
Network Management layer through the Network Information and Control
Exchange (NICE) protocol. NML performs all local network management
functions as well as control and information functions requested by remote
nodes. NML spawns a subprocess, the maintenance operation module
(MOM), for maintenance functions such as downline load, upline dump,
and loopback testing.

•

PSI ancillary control process (PSIACP). PSIACP is a VAX/VMS ancillary
control process that controls all X.25-related functions. It is present only if
VAX PSI is started. PSIACP has the VAX PSI volatile database.

•

Permanent database. The permanent database is a collection of diskresident files that define the network as known to the local node. If VAX
PSI is configured in the network, a subset of the permanent database is
maintained as the VAX PSI permanent database for the local DTE(s).

•

Volatile database. The volatile database, maintained by NETACP, is
a memory-resident database containing current network configuration
parameters. If VAX PSI is configured in the network, a subset of the
volatile database is maintained as the PSI volatile database in PSIACP for
the local DTE(s).

Many of these software components are user-transparent processes over
which the system manager has no control. This manual describes DECnetVAX and VAX PSI software only as it serves to highlight and clarify the
functions and operation of NCP. The various DNA specifications describe the
different protocols that facilitate network communication.

1-16

Overview of DECnet-VAX and VAX PSI

1.4.5

Configuring a Network
The system manager must configure each DECnet-VAX node and VAX PSI
DTE as part of the network.
1.4.5.1 Configuring a DECnet-VAX Node
At the outset, the system manager is responsible for configuring the network
from the perspective of local node network operation. This involves
supplying information at the local node about various network components
such as nodes, circuits, lines, and objects. This information constitutes what
is called the configuration database for the local node. Each node in the
network has such a database. You supply information about the configuration
database through NCP.
If you are configuring a DECnet-VAX node for the first time or wish
to rebuild the configuration database for your local node, you can use
the interactive NETCONFIG.COM procedure to configure your node
automatically. To update an existing node database to contain current
information about other nodes in the network, you can copy the information
from the node database of another node to which you have access.
Chapter 3 discusses the function of the configuration database and the general
use of NCP and most NCP commands. Chapter 5 describes the use of the
NETCONFIG.COM procedure to configure your node automatically, and
presents sample configuration commands for various network configurations.
The VAX/VMS Network Control Program Reference Manual contains a summary
description of NCP operation, command prompting, and the syntax of all
NCP commands.
1.4.5.2 Configuring VAX PSI DTEs
If VAX PSI is to be run, the system manager is responsible for installing
and configuring VAX PSI for the local DTEs. Configuring VAX PSI involves
supplying information about various VAX PSI components, such as circuits,
lines, modules, and objects. The information is contained in the PSI
configuration database for the local DTE and, if both DECnet-VAX and VAX
PSI are configured, in the DECnet-VAX configuration database for the local
node. You use NCP commands to supply information to the configuration
database.
If your node is to serve as an X.25 multihost connector node to provide access
to PSDNs for host nodes, you must configure VAX PSI software in multihost
mode. If your node is to be a host node that uses the multihost connector
node to access a PSDN, you need to install and configure only the VAX PSI
Access software. The procedures for configuring VAX PSI software or VAX
PSI Access software on your DECnet-VAX node are described in Chapter 5.
1.4.5.3 A Network Topology
Figure 1-7 illustrates a hypothetical network topology made up of various
DIGITAL operating systems. Figure 1-8 illustrates the same topology for
a network that has been divided into multiple areas. These examples are
referred to as the "network examples" throughout this manual.

1-17

DENVER

(1.14)
VAX/VMS

Physical line
-Circuit

(1.17)
RSX-11S
ZK-1863-84

1-18

Overview of DECnet-VAX and VAX PSI

Figure 1-8

Topology of a Multiple-Area DECnet Network
AREA 44

ZK-2003-84

Figures 1-7 and 1-8 show some, but not all, of the network components
about which the system manager gathers and consolidates information in the
configuration database. The six network components that you can control
using NCP are described below.
•

Nodes. Nodes are DIGITAL operating systems using DECnet software to
communicate with other operating systems across the network.

•

Modules. VAX PSI modules include the X.25 protocol module, which
performs data packet handling and multiplexing of X.25 circuits over
lines to PDSNs; and the X.25 and X.29 server modules, which handle
X.25 and X.29 calls, respectively. DECnet-VAX modules include the X.25
access module, which permits a VAX/VMS host node to communicate
over a PSDN by means of a connector node, and the Ethernet configurator
module, which lists all nodes on the Ethernet.

1-19

Overview of DECnet—VAX and VAX PSI

•

Circuits. Circuits are virtual communications paths between nodes and
between DTEs. Circuits operate over physical lines and are the medium
on which all I/O occurs. DECnet processes "talk" over circuits by means
of logical links. These links carry a single stream of full-duplex traffic
between two user-level processes. There can be multiple logical links on
each DECnet circuit.

•

Lines. Lines are physical data paths between nodes, or between DTEs and
DCEs (X.25 network interfaces).

•

Objects. Objects are processes that receive logical link requests. They
perform specific network functions. An example is FAL, which is used for
remote file access. Objects also receive incoming X.25 calls.

•

Logging. Logging is a network feature that enables the automatic
recording of useful network events that occur during network operation.

These components, the DECnet and PSI software modules and databases, and
the hardware make up the network. NCP command examples in this manual
relate to the components illustrated in the network example.

1.5

User Interface to the Network
This section describes the user interface to the DECnet-VAX network. It
includes a general description of operations that you can perform over
the network and a list of the programming languages that you can use
for designing network applications. This section also presents general
information that you need to know to access the DECnet-VAX network.

1.5.1

Performing Network Operations
You can use the DECnet-VAX software to perform a variety of operations
over the network. For example, you can
•

Manipulate files on remote nodes (for example, transfer, delete, or rename
files)

•

Access remote files at the record level

•

Perform task-to-task communications

DECnet-VAX allows you to access files on remote nodes as though they
were on your local node. It also allows you to design applications that
communicate with each other over the network. For detailed information
on remote file access and task-to-task communication, including examples of
each type of network application, see Chapter 8.
Throughout this document, the term task refers to an image running in the
context of a process, the term local refers to the node at which you are located
physically, and the term remote refers to that node with which you establish
a connection. Note that in certain situations such as testing, a logical link can
be established between two processes on the same node.
The VAX/VMS operating system and DECnet-VAX communications software
are integrated to provide a high degree of transparency for user operations.
For some applications, however, it is desirable (and sometimes necessary) to
have more direct access to network-specific information and operations. For
this purpose, DECnet-VAX provides nontransparent communication.

1-20

Overview of DECnet-VAX and VAX PSI

The following sections describe some of the general transparent and
nontransparent features of DECnet-VAX in terms of the user interface to the
network. For more detailed information, including examples of transparent
and nontransparent DECnet-VAX applications, see Chapter 8.
In addition to remote file access and task-to-task communication, DECnetVAX also allows you to communicate with remote nodes through the
heterogeneous command terminal facility (SET HOST). This feature is
described in Chapter 8.
When designing user applications to perform network operations, you can use
standard DCL commands, higher-level language I/O statements, VAX RMS
service calls, and system service calls.
1.5.1.1

Designing User Applications for Network Operations
DECnet-VAX supports several programming languages for network
applications:
•

DCL commands and command procedures

•

Higher-level language programs

•

MACRO programs using RMS service calls or system service calls

You can use several higher-level languages to develop networking
applications, including VAX Ada, VAX FORTRAN, VAX BASIC, VAX
BLISS, VAX PASCAL, VAX C, VAX PL/I, and VAX COBOL. With any of
these languages, you can access remote files and create tasks that exchange
information across the network.
Table 1-1 summarizes the normal use of the programming languages for
specific network operations that you can perform with DECnet-VAX.
Table 1-1

Network Access Levels

User Language

Network Operation

Language Calls

Access Level

DCL

Network command
terminals

DCL commands

Transparent network access using
DCL

Remote file
manipulation
Task-to-task
communication
Higher-level
languages

Remote file access
(files and records)

Higher-level
language
I/O statements

Task-to-task
communication
MACRO or
higher-level
languages

Remote file access
(files and records)

Transparent network access using
RMS
RMS service
calls

Task-to-task
communication
MACRO or
higher-level
languages

Task-to-task
communication

System service
calls

Transparent and nontransparent
network access using QIO

1-21

Overview of DECnet-VAX and VAX PSI

1.5.1.2

Choosing a Language for a Specific Network Application
The way you access the network is directly related to the language you use
and the network operation you perform. For example, you may want to use
standard VAX RMS calls in a VAX MACRO program to access remote files,
then use system service calls to communicate between MACRO programs
in a task-to-task communication application. Figure 1-9 shows three access
levels and the corresponding network operations. The various levels of
network access provide a convenient context in which to discuss typical user
operations over the network.
Figure 1-9

Network Access Levels and DECnet-VAX User
Interface

ZK-1851-84

1-22

Overview of DECnet—VAX and VAX PSI

The first two levels of access, DCL and RMS, are entirely transparent to the
network user. Because you use standard DCL commands and RMS service
calls to access remote files, no DECnet-specific calls are required at these
levels of access. You need only specify in your file specification the remote
node on which the file resides. Likewise, higher-level language tasks can use
a variation of the standard VAX/VMS file specification in conjunction with
standard I/O statements to access remote tasks and exchange information;
thus, this form of task-to-task communication is also transparent. As with
device-independent input/output (I/O) operations, transparent network
access allows you to move data across the network with little concern for the
way this operation is performed.
The third level of access, system services, provides both a transparent and
a nontransparent user interface to the network. Transparent communication
at the system-service level provides all the basic functions necessary for
two tasks to exchange messages over the network. As with the higher-level
language I/O interface, these operations are transparent because they do
not require DECnet-specific calls. Rather, you use standard system service
calls to implement them. Nontransparent communication extends this
basic set of functions to allow a nontransparent task to receive multiple
inbound connections and to use additional network protocol features such as
optional user data and interrupt messages. As with device-dependent I/O,
nontransparent communication allows you to exploit certain network-specific
characteristics to coordinate a more controlled communication environment
for exchanging information.

1.5.2

Accessing the Network
This section presents general information that you need to know to access the
network via DECnet-VAX software. This information covers network file and
task specifications, access control parameters, and the use of logical names in
network applications.
The format for file specifications is applicable to file-handling operations for
both the DCL and the RMS interfaces to the network. The task specification
format pertains to task-to-task communication. The information on access
control is significant because it defines the way that both local and remote
nodes grant access to their system resources.

1.5.2.1

Using File and Task Specifications in Network Applications
DECnet-VAX uses the standard VAX/VMS file specification format for remote
file-handling applications. A node specification string that includes a node
name must be present. You can also include an optional access control string
in the node specification to specify explicitly the user name and password of
a specific account to use on the remote system.
For example, the file specification
TRNTO"SMITH JOHN"::W0RK_DISK:TEST.DAT;1

contains explicit access control information and can be used to access the file
TEST.DAT, which resides in user Smith's top-level directory on the device
WORK—DISK on node TRNTO.
The following file specification, which does not contain explicit access control
information, can also be used to access the remote file TEST.DAT provided
that a proxy or default nonprivileged DECnet account exists on the target
node:
TRNTO::DBA1:[SMITH]TEST.DAT;1

1-23

Overview of DECnet-VAX and VAX PSI

For more information on file specification strings, including format examples,
see the VAX/VMS DCL Concepts Manual.
Task-to-task communication requires the use of a task specification string
enclosed in quotation marks. This string identifies the target task to which
you want to connect on a remote node. For example, the following task
specification string
BOSTON: : ,,TASK=TEST2,,

identifies the task TEST2 by means of the TASK= form of task specification.
You can also use the 0= form to specify a task. For example,
BOSTON"JONES KC"::"0=TEST2"

also identifies the task TEST2. Note that in this case, explicit access control
information is also included in the node specification string. For more
information on task specifications, see Chapter 8.

1.5.2.2

Using Access Control for Network Applications
Access control is the control that a node exercises over inbound logical link
connections. The terms inbound and outbound refer to the direction of
the logical link connection request. A node receives and processes inbound
requests; it processes and sends outbound requests. This distinction is useful
for discussing access control as it relates to VAX/VMS nodes in a network.
Refer to appropriate DECnet documentation if the node to which you want to
connect is not a VAX/VMS system.
When DECnet-VAX software sends an outbound connection request in
response to either a remote file access or a task-to-task communication
operation, certain access control information may be necessary to connect
successfully to the remote node and log in. As in logging in at your local
VAX/VMS node, you can supply specific access control information in
the form of a user name and password that the remote node recognizes.
The remote node processes inbound connection requests containing
this information to verify that you are a valid user of the system. For
more information on inbound and outbound connection requests, see
Section 2.10.2.
Figure 1-10 illustrates the access control processing that takes place for a
simple DCL command.
When explicit access control information is not provided in the connection
request, DECnet-VAX software uses the remote node name specified in
the connection request as a key to locate the appropriate record in the
local configuration database. This record contains default access control
information applicable to the remote node. Your system manager creates this
entry when establishing the configuration database. (Refer to Chapter 3 for
additional information on the configuration database.)
Depending on the privileges required by the object to which you want to
connect and those of the user process (see Figure 1-11), one of three possible
sets of default access control information is sent to the remote node: default
privileged, default nonprivileged, or null. Because these defaults are node
parameters, all privileged operations requested with default access control
for a given node run under the same default account. The same is true for
nonprivileged operations requested with default access control.
If the target node is running DECnet-VAX, it can associate incoming connect
requests with specific accounts other than the default nonprivileged DECnet
account. This type of access is known as proxy login and requires that
the originator of the request have a proxy account on the target node and

1-24

Overview of DECnet—VAX and VAX PS/

Figure 1-10

Remote File Access Using Access Control String
Information

loop until timeout
ZK-1869-84

that proxy login access be enabled at that node. Proxy login is described in
Section 2.10.5.
Figure 1-11 illustrates the access control processing that takes place for the
same DCL command as in the example in Figure 1-10, except that the DCL
command does not specify an access control string.

1.5.2.3

Using Logical Names in Network Applications
The use of logical names for network operations allows you to refer to
network file and task specifications without using actual names that you give
these elements. Logical names serve as a kind of shorthand for specifying all
or a portion of a full file specification. By using logical names, you can pass
file specifications defined at the DCL level to an executing image at run time.
For example, logical names allow a program to access local or remote files
without changing the program. You can also use logical names to conceal
access control information from other users by embedding it in a logical name
defined in the process logical name table. Logical names provide convenient
and powerful multilevel access control specification.

1-25

Overview of DECnet-VAX and VAX PSI

Figure 1-11

Remote File Access Using Default Access Control
Information

The rules that govern the use of logical names for network operations are as
follows:

1—26

•

Both the device name and node name in a full file specification string
can be logical names. However, once a node specification is encountered
during file parsing, a device name that follows is not translated locally.
Instead, it is passed unaltered to the remote node, where it is subject to
logical name translation.

•

A logical name appearing in the device name position in a file specification
can supply any file specification string elements when translated.

•

A logical name appearing in the node name position can supply only a
node-spec when translated. Therefore, its equivalence string must end
with a double colon.

•

An access control string associated with a logical node name becomes the
new access control string for the node-spec of the equivalence string, even
if the node-spec contained an access control string. Thus, you can easily
specify a default (or override any) access control string defined for the
node-spec resulting from logical name translation.

•

After a logical node name is translated, the new node name becomes a
candidate for logical node name translation.

Overview of DECnet-VAX and VAX PSI

•

A maximum of ten logical device name translations and ten logical
node name translations is permitted. If you exceed these limits, an error
message is returned.

For more information on logical names, including examples of logical names
that can be used for network applications, see the VAX/VMS DCL Concepts

Manual.

1-27

DECnet-VAX Components and Concepts

This chapter presents networking concepts relevant to understanding the
operatioji pfJthe .DECnet network, in terms of the functions performed by
DECnet-VAX components and VAX PSI components.
To establish your VAX/VMS operating system as part of the DECnet network,
you must build and maintain a network configuration database, consisting of
records that describe the specific network components your particular system
requires. This chapter describes the DECnet-VAX components and their
characteristics: nodes, circuits, lines, routing, logical links, objects, logging,
and network access control. It also describes VAX PSI components used
in communicating over a packet switching data network (PSDN): the X.25
protocol module, X.25/X.29 server modules, and X.25 access module.
Chapter 3 discusses how you can use a DECnet-VAX utility program, the
Network Control Program (NCP), to enter in your configuration database
specific parameters for each network component your system will use.

2.1

Nodes and DTEs
A node is an operating system that uses DECnet software to communicate
with other operating systems across a network. A VAX/VMS node uses
DECnet-VAX software to communicate with other DECnet-VAX nodes and
with any other DIGITAL operating system that supports DECnet.
The X.25 equivalent of a node is a DTE (data terminal equipment). A DTE
is a computer or terminal that uses VAX PSI software to communicate with
remote nodes across a PSDN. You can configure your DECnet-VAX node as a
DTE if VAX PSI software is installed on your node.
Note: A single VAX PSI system can now support several DTEs. (The limit is
the physical communications capability of the system.)
A DECnet-VAX node can also be an X.25 connector node, serving as a
gateway that permits DECnet-VAX host nodes on an Ethernet to access one
or more PSDNs. To configure your DECnet-VAX node as a connector node,
you must have VAX PSI software in multihost mode installed. To configure
your DECnet-VAX node as an X.25 host node, you must have VAX PSI
Access software installed.
This section describes the characteristics of nodes and the kinds of parameters
you can associate with them. It also describes DTEs and indicates how you
use X.25 protocol modules to define DTEs and the parameters related to them.
Chapter 3 discusses the use of NCP commands to establish the parameters
for nodes and DTEs.

2-1

DECnet-VAX Components and Concepts

2.1.1

Nodes
The VAX/VMS operating system at which you are physically located is called
the local node. By issuing network management commands at your local
node, you can perform configuration, control, and monitoring functions that
affect both the local node and other nodes in the network. The node on
which network management functions are actually performed is called the
executor node. Usually, the executor node will be the local node. You have
the option, however, of entering at the local node one or more commands to
be executed at a remote node. For those commands, the remote node serves
as the executor node.

2.1.1.1

Node Address and Name
To configure an operational network at the local node, you must establish
configuration database entries for the local node and for all adjacent nodes
that are connected by circuits. It is recommended that you specify names
and addresses for all nodes in the network. Once you have done so, you can
reach any other node by its name.
To satisfy routing requirements, each node in the network must have a unique
address. The node address is a number in the form
area-number.node-number
The area-number is the number of the area in which the node resides and the
node-number is the address of the node within that area. Each area number
must be unique within the network and each node number unique within the
area. If the area number is not specified in a node address, the area number
of a remote node defaults to the area number of the executor node, and the
area number of the executor defaults to the number 1.
Node identification has two forms: a node address and a node name. A node
address, a number in the format described above, is assigned to each node in
the configuration database. A node name is an optional alphanumeric string.
In the single-area network example in Chapter 1, the node assigned node
address 1.11 is also identified by the node name BOSTON. In the multiplearea network example in Chapter 1, node BOSTON in area 2 has the node
address 2.11.
Because it is often easier to remember a name rather than an address, you
may prefer to associate a name with an address. You can do so at any
time. Note, however, that node names are known only to the local node
network software while node addresses are known network-wide by the
routing function. To avoid potential confusion, you should give each node a
unique name that all nodes in the network will assign to that node and use to
address it.
Nodes on Ethernet lines can also be accessed under certain circumstances
by their Ethernet addresses. All nodes connected to an Ethernet line are
equally accessible, because the Ethernet is a multiaccess, broadcast device.
Therefore, each node on an Ethernet is assigned a unique Ethernet physical
address, which is set by the software at the node. You do not normally
have to specify the Ethernet address of an individual node to configure your
network or perform normal network operations. You do need to know a
node's Ethernet physical address for service functions (such as downline load,
circuit loopback test, and configurator operations). You can send a message
to one, several, or all nodes on an Ethernet line simultaneously, depending
on the Ethernet address used. To send a message to more than one node,
use an Ethernet multicast address: either a multicast group address to reach

2-2

DECnet—VAX Components and Concepts

a selected group of nodes, or a broadcast address to reach all nodes on the
Ethernet.

2.1.1.2

Node Characteristics
The configuration database for the local node must contain certain
information about the local node and may contain node information for
all nodes with which you want to communicate. For the local node, you
must specify the node address and should specify the node name and buffer
size (which determines the largest size message the node can forward).
You should also indicate or use the default value for the highest address
the local node will recognize, and for the node type (which determines the
routing capabilities of the local node). Optionally, you can specify data link
control information for the local node. For remote nodes, you should specify
names and addresses. You can also specify default information to be used
in performing downline load or upline dump operations involving remote
nodes. For any or all nodes, you can specify access control information and
node counter event logging information.
To update your configuration database with current information about remote
nodes in your network, you can copy the names and addresses of remote
nodes from the database of another node to which you have access. You can
specify the node database (volatile or permanent) to be copied, and the local
node database (either or both volatile and permanent) to which information
is to be copied. You also have the option of clearing or purging your local
node database before copying the remote node data, thus avoiding possible
conflicts between original and updated data. The executor node information
is preserved during the clear or purge operation. Being able to copy a node
database permits you to keep your network information current even if you
are part of a large network that changes frequently. Alternatively, if you
configure your node without a permanent node database, you could obtain
current information on other nodes in the network when required by copying
it from another node (for example, from a node on your Ethernet that serves
as a master by keeping its node database up to date).
The data link control information you can specify for the local node controls
certain characteristics of physical line operation, including the size and
number of transmit and receive buffers and the number of circuits the local
node can use. These values should be set to levels that ensure reasonable
system operation. It is important to set the buffers for all nodes in the
network to the same size. Otherwise, packets will be dropped when routed
through nodes with smaller buffer sizes. A procedure for changing the size
of buffers on all nodes in the network without bringing down the whole
network is given in Section 3.3.5.1.
You can control the operational state of the local node and thereby control
its active participation in the network. This control is usually a function
of whether or not inbound logical link connections can be established or
maintained with the local node. You can use this control to restrict the
operation of the node or to shut it down altogether.

2-3

DECnet—VAX Components and Concepts

2.1.1.3

Identifying a VAXcluster as a Single Node
A whole VAXcluster or some of the nodes in a VAXcluster can be represented
by a special identifier called the alias node identifier, which appears to other
nodes in the network to identify an actual node. This mechanism allows
users on DECnet nodes outside the cluster to access cluster resources without
knowing what the cluster nodes are or which are active.
Any node in the cluster can elect to assume the alias node identifier while
retaining its own unique node name and address. Use of the alias never
precludes use of the individual node name and address. Thus a remote node
can address the cluster as a single node, and address any cluster member
individually.
You can designate that your cluster node is assuming the alias node identifier
by specifying in your configuration database either the alias node address or
the alias node name (if you have previously associated that name with the
alias address of the cluster).
You then have the option of indicating whether you want to use the alias
for incoming and/or selected outgoing connections. Specifically, you can
indicate whether or not your node will accept incoming connection requests
directed to the alias node address. By default, a node that assumes the alias
will be available to receive incoming connections addressed to the alias, but
a small node that uses the alias for outgoing traffic may elect not to handle
the extra incoming traffic. You can also select which DECnet-VAX objects
(software components that provide network services) are to use the alias
by specifying in the object database that the alias address is to be used for
outgoing connections originated by those objects. In addition, you can specify
which objects will receive incoming connect requests directed to the alias
node address.
MAIL is an example of a network object that can effectively treat the cluster
as a single node. Ordinarily, replies to mail messages are directed to the node
that originated the message; the reply is not delivered if that node is not
available. If the node is in a duster and uses the cluster alias, an outgoing
mail message is identified by the alias node address rather than the individual
address of the originating node. An incoming reply directed to the alias
address is given to any active node in the cluster and is delivered to the
originator's mail file.
Objects that involve multiple incoming links (such as PHONE) should not
use the alias node address because each incoming link may be routed to a
different node that uses the same alias. Also, objects whose resources are
not accessible clusterwide should not be allowed to receive incoming connect
requests directed to the alias node address. Section 2.6 describes network
objects and discusses the type of object for which the alias node identifier is
suitable.
The alias node identifier permits you to set a proxy to a remote node for the
whole cluster rather than for each node in the cluster. The clusterwide proxy
can be quite useful if the alias node address is used for outgoing connections
originated by the object FAL, which accesses the file system.
The alias node identifier should be used only for fully shareable resources in
a VAXcluster. All processors in the cluster must be able to access and share
all resources (such as files and devices). Nodes that assume the alias node
identifier should have a common authorization file.

2-4

DECnet—VAX Components and Concepts

At least one of the cluster nodes that uses the alias node identifier must be
a router. It can be a level 1 router, because all cluster nodes sharing the
same alias node address must be in the same area. The cluster router informs
other nodes in the network of the existence of the alias node address. Other
routers in the network perceive the cluster router as the shortest path to the
cluster node address and send the router packets addressed to the cluster
node address. If the router receives a packet addressed to the alias node
address, it forwards the packet to the appropriate cluster node: if the packet
is for an existing logical link, the link identifier in the packet is sufficient to
select the node; if the packet is initiating a new logical link, the router selects
a participating node in round-robin fashion.
The network manager or cluster manager should select a suitable alias node
name and address for the cluster nodes. You can specify either the alias node
name or address as an executor parameter in your node database. If you
specify the alias node name, you must first have associated the name with the
agreed-upon alias node address. You can then assign the same parameters to
this node as to other nodes, except that routing initialization passwords are
not required. No point-to-point initialization can occur because a node cannot
set up a circuit to an alias node address. The alias node address and name
will appear in the node databases of other nodes in the network.
You can optionally set a maximum value on the number of logical links that
your node can initiate using the alias node identifier (see Section 2.5).

2.1.2

DTEs
A VAX/VMS operating system with VAX PSI software installed can function
as a DTE (or DTEs) capable of sending and receiving packets over PSDNs to
which the system is connected. To configure a local DTE, you must establish
in the configuration database an X.25 protocol module entry, which identifies
a network to which your DTE is connected. This network represents a path
to a PSDN. You must also establish X.25/X.29 server database entries that
indicate the destinations of incoming X.25 and X.29 calls (see Section 2.7).

2.1.2.1

X.25 Protocol Module
The X.25 protocol module is a software component that controls the
transmission of data packets over PSDNs. The configuration database for
the X.25 protocol module identifies the networks to which your DTEs are
connected, defines the DTEs, and specifies any user group to be associated
with the DTEs.
The first step in configuring the X.25 protocol module is to identify the
particular networks to which your DTE or DTEs will belong. Note that the
term "network" as used here refers to a network you define with NCP. In this
context, network does not refer to a PSDN, but rather a route to a PSDN.
You must associate the network name with a profile that determines the
characteristics of subscription to the PSDN. When you specify a network
profile, default values for a number of parameters that affect data-packet
control are entered in the configuration database. Defaults set the size and
control the flow of data packets over switched virtual circuits, and control
call setup and clearing of these circuits; they also control the transmission of
resets and restarts over permanent and switched virtual circuits.
You identify your local DTE or DTEs by DTE address and network name.
Each local DTE must have a unique address for each network to which it
belongs. The DTE address format is determined by the PSDN whose profile
is specified for the network. For each DTE, you can specify the operational

2-5

DECnet—VAX Components and Concepts

state and maximum number of circuits supported, and identify the associated
line and the channels for outgoing calls.
You should also identify any user group of which you are a member. A user
group is an optional PSDN facility to which you can subscribe: a closed user
group (CUG) permits two or more DTEs to communicate only with each
other; a bilateral closed user group (BCUG) restricts communication to a
pair of DTEs. Specify the unique name of your CUG or BCUG and associate
with it the local DTE address and group number; for a BCUG, specify that the
group type is bilateral.

2.1.2.2

X.25 Connector and Host Nodes
A VAX/VMS node that has VAX PSI software in multihost mode installed
can serve as a connector node, a gateway that provides access to a PSDN
for host nodes. To configure your node with VAX PSI software in multihost
mode, establish in the database an X.25 protocol module entry as described in
Section 2.1.2.1, then indicate in the X.25 server database the host destinations
to which incoming calls are to be forwarded.
A VAX/VMS host node must have VAX PSI Access software installed. To
configure your node as a host node, you must establish in the database the
X.25 access module (see Section 2.8) and indicate in the X.25 server database
the destination on your node for incoming calls.

2.2

Circuits
Circuits are high-level communications data paths between nodes or DTEs;
communication between nodes takes place over circuits. Circuits operate over
physical lines, which are low-level communications paths (see Section 3.6).

2.2.1

Classes of DECnet—VAX Circuits
DECnet-VAX employs four classes of circuits: DDCMP, Cl, Ethernet, and
X.25.
DDCMP circuits provide the logical point-to-point or multipoint connection
between two or more nodes. There are currently three types of DDCMP
circuits: point-to-point, multipoint control, and multipoint tributary. A pointto-point circuit operates over a corresponding synchronous or asynchronous
DDCMP point-to-point line. Asynchronous lines can be either static
(permanent) or dynamic (switched).
Multipoint control circuits operate over synchronous DDCMP control lines.
You can specify multiple circuits from the control (master) end of a control
line, but each circuit must have a unique physical tributary address. On the
tributary (slave) end, you can specify only one multipoint tributary circuit per
line.
Cl circuits are available only on those nodes that are attached to a CI-780
or CI-750 interconnect. Cl circuits are similar in many ways to DDCMP
multipoint circuits, but use their own protocol.
Ethernet circuits provide for multiaccess connection between a number of
nodes on the same broadcast circuit. An Ethernet circuit differs from other
DECnet circuits in that there is not a single node at the other end. An
Ethernet circuit is a path to many nodes. Each node on a single Ethernet
circuit is considered as being adjacent to every other node on the circuit
and equally accessible. Every node must have a unique node identification:

2-6

DECnet—VAX Components and Concepts

an Ethernet physical address. (Ethernet node addressing is described in
Section 3.3.4.) Ethernet circuits use the Ethernet protocol.
X.25 circuits use the X.25 level 3 protocol (the packet level) and provide for
communication over PSDNs. VAX PSI provides X.25 circuits for use by PSI
user application programs (also referred to as "native X.25 user programs")
or by DECnet data link mapping (DLM). DLM permits the use of X.25 as a
DECnet data link through the mapping of data link information between the
DECnet Routing layer and the X.25 protocol module. The two types of X.25
circuits are X.25 native circuits and X.25 DLM circuits.
Each X.25 circuit is a virtual circuit connecting a local DTE and a remote DTE.
An X.25 virtual circuit can be either of the following:
•

A permanent virtual circuit (PVC), providing a permanent path between
the local DTE and the remote DTE

•

A switched virtual circuit (SVC), providing a temporary path between the
local DTE and the remote DTE

The PVCs can be used by DECnet and native X.25 user programs for X.25
communications with a PSDN. SVCs can be used by both DECnet and
native X.25 user programs, but only SVCs used by DECnet through data
link mapping (DLM) need to be set up by means of NCP commands. VAX
PSI sets up X.25 native SVCs with parameters taken from the X.25 protocol
module component when calls on these circuits are requested. You do not
need to use NCP to set up X.25 native SVCs.
Just as you must specify the local node, you must also specify parameters for
all DECnet circuits connected to the local node and all X.25 virtual circuits
connected to local DTEs.
You must identify each circuit by name and specify information that directly
affects the circuit's operation. You can also specify the operational state of
circuits connected to your local node or DTE. Thus you can control circuit
traffic and perform service functions. The state of a circuit may ultimately
affect the system's ability to reach an adjacent node or DTE. The circuit state
can have a similar effect on routing.
This section describes the circuit component. For a discussion of using NCP
commands to specify circuits, see Chapter 3.

2.2.2

DDCMP Circuit Devices
DDCMP circuit devices can be synchronous or asynchronous. DECnet-VAX
supports the following synchronous DDCMP circuit devices:
•

DMC11

•

DMR11

•

DMP11

•

DMV11

•

DMF32 synchronous line unit

2-7

DECnet-VAX Components and Concepts

The DMC11 and the DMR11 are point-to-point circuit devices and are
considered identical. The DMP11 can be a point-to-point, multipoint control,
or multipoint tributary circuit device. The DMV11 is similar to the DMP11;
DECnet refers to both devices as the DMP11. The DMF32 synchronous line
unit is either a point-to-point or multipoint tributary circuit device.
DECnet-VAX supports the following asynchronous DDCMP circuit devices:
•

DHU11

•

DHV11

•

DZ11

•

DZ32

•

DZV11

•

DMZ32

•

DMF32 asynchronous line unit

The DZ11, DZ32, and DZV11 are represented by the mnemonic TT.
The DHU11, DHV11, DMZ32, and DMF32 asynchronous line units are
represented by the mnemonic TX. The asynchronous circuit devices are pointto-point circuit devices used for static or dynamic asynchronous connections.
Note that asynchronous DDCMP circuits need not be predefined for dynamic
connections. They are established automatically during dynamic switching of
terminal lines (see Section 2.3.2.3).
Other DECnet implementations may support other DDCMP circuit devices.
If a node in your network uses a circuit device other than one of these, refer
to the appropriate DECnet documentation. This section provides a general
discussion of point-to-point and multipoint circuits. The VAX/VMS Network
Control Program Reference Manual lists DECnet circuit and line devices by
name and operational category.
Every DDCMP circuit provides a logical point-to-point connection between
two nodes. The circuit operates over the corresponding DDCMP line (for
example, the DMC11 circuit operates over the DMC11 line). The DMP11,
operating as a multipoint control circuit, also provides a logical, multipoint
connection (over one physical line) between a control station and several
tributaries (as illustrated in Figure 2-1). The DMP11 and DMF32 can also
operate as multipoint tributary circuit devices that provide a logical connection
between a tributary and a control station.
The following terms are used in describing the operation of multipoint
circuits:

2-8

•

Control Station. The control station is the node at the controlling end of
a multipoint circuit. It controls the tributaries for that circuit.

•

Polling. Polling is the activity that the control station performs on
tributaries of a multipoint circuit. The control station regularly sends
request messages to (that is, polls) each eligible tributary in the polling
list. The request message asks the tributary if it has anything to send
(essentially giving it permission to use the bus).

•

Tributary. A tributary is a physical termination point on a multipoint
circuit that is not a control station.

DECnet—VAX Components and Concepts

Figure 2-1

LINE

—

CIRCUIT

—

Multipoint Circuits and Associated Lines

ZK-544-81

•

Tributary Address. A tributary address is a numeric address that
identifies a tributary node on a multipoint circuit.

It is possible to connect both a multipoint control circuit and a multipoint
tributary circuit to the same node. The node could then serve as the control
station for one multipoint circuit and as a tributary for another multipoint
circuit.
The system manager must supply tributary addresses for a control station to
use when polling each tributary in a polling list.

2—9

DECnet—VAX Components and Concepts

2.2.3 Cl Circuit Device
DECnet supports the CI-780 interconnect (on VAX-11/780, VAX-11/782, or
VAX-11/785 processors only) and the CI-750 interconnect (on VAX-11/750
processors only). All nodes connected to the same Cl bus can communicate
directly with each other. Only one Cl controller per node is required. DECnet
treats the Cl controller as a multipoint data link and requires a single entry
in the line database and multiple entries in the circuit database. The line
database entry describes the Cl controller (see Section 3.6). Each circuit
database entry describes a virtual connection to a single remote node on
the Cl. Cl multipoint circuits and DDCMP multipoint circuits differ in the
following ways:
•

Each station on the Cl can talk directly to every other station. These
stations are called tributaries and all stations are alike. There are no
"control" and "tributary" stations as with DDCMP multipoint circuits.

•

There are no polling parameters on the Cl.

•

Cl circuits use their own communication protocol.

If you plan to use a Cl circuit, you must first connect the device CNAO to
the driver CNDRIVER. To connect CNAO to the CNDRIVER and load the
CNDRIVER, add the following to the LOADNET.COM command procedure
in SYS$MANAGER:
$ RUN SYS$SYSTEM:SYSGEN
CONNECT CNAO/NOADAPTER

2.2.4 Ethernet Circuit Device
DECnet supports the DEUNA, DELUA, and DEQNA circuit devices, which
provide for multiaccess connections between many nodes on the same
Ethernet circuit. The VAX/VMS system uses the DEUNA or DELUA circuit
device (each of these devices is called the UNA). The DELUA is a newer
version of the DEUNA that provides higher throughput. The MicroVMS
system uses the DEQNA (referred to as the QNA), which is similar in
function to the DEUNA. The UNA and QNA use the Ethernet protocol.
Ethernet messages are sent over the Ethernet as datagrams, which means
messages may be lost because of errors. DECnet provides for automatic
retransmission of lost messages. The Ethernet device allows multiple users of
the device at the same time; therefore, other users may be using the UNA or
QNA on another type of protocol while DECnet is running.

2.2.5 Ethernet Configurator Module
All nodes on an Ethernet circuit are logically adjacent, because the Ethernet
is a multiaccess device. To obtain a list of all systems on an Ethernet circuit,
you can use the Ethernet configurator module. The configurator module
listens to system identification messages transmitted periodically by every
DIGITAL-supported node on the Ethernet circuit, and builds the configuration
list from the received messages.
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. For
a random distribution of nodes with possible loss of system identification
datagrams, the configurator would require 40 minutes to collect all node

2-10

DECnet—VAX Components and Concepts

addresses. In practice, the configurator normally requires about 12 minutes to
complete a list.
The Ethernet configurator module requires a default nonprivileged DECnet
account. Use NCP commands to access and control the configurator module.
The configurator runs as a separate process and, once it is started, becomes
available to all users on the system. The configurator module will continue
to execute and will maintain and update its database of information on active
nodes.
When you request information on the current configuration of nodes on
Ethernet circuits, the following is displayed for each system: its Ethernet
physical and hardware addresses, the device connecting it to the circuit,
maintenance functions it can perform, and the time of the last system
identification message from the system.

2.2.6

X.25 Circuit Devices
X.25 circuits differ from DDCMP circuits in that there is no direct
correspondence between circuit and line. All X.25 circuits pass through
the X.25 protocol handler module (see Section 2.1.2.1), which multiplexes
circuits to lines that it "owns." There is no direct relationship between the
name of an X.25 circuit and an X.25 line. One line is specified for each DTE.
All X.25 circuits are virtual circuits that connect a local DTE with a remote
DTE. The association between DTEs can be permanent or temporary. X.25
PVCs are analogous to leased lines between the local DTE and the remote
DTE. They are similar to DDCMP circuits in that both have predefined end
points.
X.25 SVCs are analogous to dialup lines. SVCs are set up only when there
is data to transmit and are cleared when the transfer is complete. They are
temporary paths between local and remote DTEs.

2.2.7

X.25 DLM Circuits
Data link mapping (DLM) circuits extend normal DECnet capabilities to
include communication over a PSDN with other DECnet nodes connected to
the PSDN. Data link mapping permits an X.25 virtual circuit to be used as a
DECnet data link. A DLM circuit is owned by the executor node; the Routing
layer has exclusive rights to use the circuit. A DLM circuit can be either a
PVC or an SVC. A DLM SVC can be used for either incoming or outgoing
calls.
To establish a DLM SVC with a remote DTE, DECnet-VAX uses the DTE
address of the remote node. Subaddresses can be used to limit the DLM
calls accepted at the local DTE. DECnet-VAX will try to recall a number if
previous attempts to establish a DLM SVC have not succeeded. The number
and frequency of recall attempts can be regulated.

2.3

Lines
Lines provide physical communications and are the lowest level
communications path. Circuits are high-level communications paths that
operate over lines.

2-11

DECnet-VAX Components and Concepts

2.3.1

Classes of DECnet—VAX Lines
DECnet-VAX supports four classes of lines: DDCMP, Cl, Ethernet, and X.25.
A DDCMP line provides the physical point-to-point or multipoint connection
between two or more nodes. A Cl line provides a high-speed connection
between two or more nodes. An Ethernet line is a multiaccess connection
between two or more nodes. An X.25 line is the physical link between your
DTE and a PSDN.
For DDCMP, Cl, and Ethernet configurations, each circuit is directly related to
a corresponding line. For X.25 configurations, however, the circuits and lines
do not correspond directly. X.25 circuits are multiplexed to lines owned by
the X.25 protocol handler module (see Section 2.1.2.1).
Just as you must establish node and circuit parameters, you must also
establish parameters for all physical lines connected to the local node or
DTE. You must identify each line by name and specify information that
directly affects the line's operation. You can control the operational state of
the line, and thus control line traffic and perform service functions. The state
of a line may ultimately affect the reachability of an adjacent node or DTE,
affecting the routing.
This section describes the line component. For a discussion of using NCP
commands to specify line parameters, see Chapter 3.

2.3.2

DDCMP Lines
DDCMP lines can be synchronous point-to-point or multipoint lines
or asynchronous point-to-point lines. Asynchronous lines can be static
(permanent) or dynamic (temporarily switched).

2.3.2.1

DDCMP Line Devices
DDCMP line devices can be synchronous or asynchronous. DECnet-VAX
supports the following synchronous DDCMP line devices:
•

DMC11

•

DMR11

•

DMP11

•

DMV11

•

DMF32 synchronous line unit

The DMC11 and the DMR11 are point-to-point line devices and are
considered identical. The DMP11 can be either a point-to-point, multipoint
control, or multipoint tributary line device. The DMV11 is similar to
the DMP11; DECnet refers to either device as the DMP11. The DMF32
synchronous line unit is a point-to-point or multipoint tributary line device.
DECnet-VAX supports the following asynchronous DDCMP line devices:

2-12

•

DHU11

•

DHV11

•

DZ11

•

DZ32

•

DZV11

DECnet—VAX Components and Concepts

•

DMZ32

•

DMF32 asynchronous line unit

The DZ11, DZ32, and DZV11 line devices are represented by the mnemonic
TT. The DHU11, DHV11, DMZ32, and DMF32 asynchronous line units are
represented by the mnemonic TX. The asynchronous line devices are pointto-point line devices used for static or dynamic asynchronous connections.
Note that asynchronous DDCMP lines need not be predefined for
dynamic connections. They are established automatically when a dynamic
asynchronous DDCMP connection is made (see Section 2.3.2.3).
Every DDCMP line provides a point-to-point connection between two nodes.
Circuits, the actual communications path, operate over the line. The DMP11
and DMF32 also provide a multipoint connection between two or more
nodes. In Figure 2-2 a multipoint line controlled by the DMP11 provides the
physical connection between a control node and several tributary nodes.
Figure 2-2

Multipoint Lines

LINE IDENTIFICATION = DMP-0
PROTOCOL =. TRIBUTARY

LINE IDENTIFICATION = DMF-0
PROTOCOL = TRIBUTARY
ZK-545-81

It is also possible to connect two multipoint lines to the same node. The
node could then serve as the control station for one multipoint line and as a
tributary for another multipoint line.

2-13

DECnet—VAX Components and Concepts

Because a heterogeneous network such as the network example in this
manual may have DDCMP line devices other than one of the above, you
should be familiar with the entire range of devices and their impact on
network management. Refer to the appropriate DECnet documentation if a
node in your network uses a line device other than these. The VAX/VMS
Network Control Program Reference Manual lists DECnet line devices by name
and operational category.

2.3.2.2

Static Asynchronous Lines
A static asynchronous DDCMP connection is a permanent connection
established between two nodes (such as a Micro VMS end node and a
VAX/VMS router). The two nodes are connected by a physical line attached
to a terminal port at each end (for example, port TTAO on the end node and
port TXB7 on the router). A static asynchronous connection can also be made
over a dialup line.
Before the DECnet connection is made, the terminal lines must be converted
to static asynchronous DDCMP lines. Each terminal port must have an
asynchronous DDCMP line device installed, and the system manager at
each node must load the asynchronous DDCMP driver, NODRIVER. The
system manager at each node should insert the following command in the
LOADNET.COM command procedure:
$ SET TERMINAL/PROTOCOL=DDCMP device-name:

The device-name is the name of the appropriate terminal port. For example,
the Micro VMS manager should specify the command
$ SET TERMINAL/PROTOCOL=DDCMP TTAO:

and the VAX/VMS manager should specify
$ SET TERMINAL/PROTOCOL=DDCMP TXB7:

Each system manager should then specify the appropriate line and circuit
commands in the configuration database to turn the line and circuit on for
DECnet use. (The commands required to install static asynchronous lines and
the NCP commands to configure a network using static asynchronous lines
are given in Chapter 5.)

2.3.2.3

Dynamic Asynchronous Lines
A dynamic asynchronous line differs from a static asynchronous line or other
DECnet-VAX line in that it is normally switched on for network use only for
the duration of a dialup connection between two nodes. When the telephone
is hung up, the line reverts to being a terminal line.
Figure 2-3 illustrates a typical configuration in which dynamic asynchronous
switching occurs over a dialup line. The local node in the figure is a
standalone Micro VAX system; the remote node is a VAX-11/780. After
the user at the local node dials in to the remote node, he can cause the
lines connected to terminal ports TTA1 and TXB1 to be switched to dynamic
asynchronous DDCMP lines for use in DECnet communications.
Dynamic switching of terminal lines to asynchronous DDCMP lines can
occur provided both nodes have DECnet-VAX licenses installed. The system
manager at each node must have loaded the asynchronous driver NODRIVER
and installed the privileged shareable image DYNSWITCH. The system
manager at the remote node must have enabled virtual terminals on the
system. In particular, the system manager must have enabled the virtual
terminal for the line over which you are going to log in and must have-set
the DISCONNECT attribute for that line.

2-14

DECnet—VAX Components and Concepts

Figure 2-3

Dynamic Switching of Asynchronous DDCMP Lines

$ SET HOST/DTE TTA 1 :
Username:
Password:

$ SET TERMINAL /PROTOCOL = DDCMP/SWITCH DECNET

TTAO

LOCAL NODE
MicroVAX

TERMINAL

>>
O

EMULATOR

u
§
Q O
Q Z

CC
Q.

TTA1

(

Q W S

MODEM

mi
MODEM

TXB1

co
co

iu
O

O
OC
a

VIRTUAL
TERMINAL

REMOTE NODE
VAX-11/780

2-15

DECnet—VAX Components and Concepts

The procedure for dynamic switching of lines is as follows:
1

You should log in to the Micro VMS system through the terminal port
TTAO, causing a process (PROCESS—L) to be created on your system.

2 You must issue the following DCL command:
$ SET HOST/DTE[/DIAL=NUMBER:number] TTA1:

This command causes the local system to function as a terminal emulator,
and causes the modem to dial the number of the remote system. The
terminal emulator permits the local processor to function as though it
were a terminal line: characters can be read from one port and written
to another port. In this figure, the terminal emulator on the Micro VAX
reads characters from port TTAO and writes characters to port TTA1. Note
that the /DIAL qualifier in the SET HOST/DTE command is optional
and works only if you have written a program to dial your modem. The
default program supplied with VAX/VMS dials a DF03 modem.

3 Once the dialup connection is made and you receive the remote system
welcome message, you should perform the regular procedure for logging
in to your account on the remote node. In this example, you would supply
your user name and password to the VAX/VMS system.
4

When you log in over a modem line, a process (PROCESS—R) is created
at the remote node and connected to a virtual terminal as well as the
physical terminal. The virtual terminal permits PROCESS—R to continue
running even if the physical terminal is disconnected (for example, if you
lose the carrier signal on your telephone line).

5 You can then initiate dynamic switching by specifying the following DCL
command from your account on the remote node:
$ SET TERMINAL/PROTOCOL«DDCMP/SWITCH=DECNET

(To switch your line manually, see step 10.)

6 When the SET image at the remote node recognizes the
/SWITCH=DECNET qualifier, it calls the shareable image DYNSWITCH.
DYNSWITCH verifies that the device is a virtual terminal and then sends
an escape sequence to the terminal emulator running on the Micro VAX.
The escape sequence notifies the terminal emulator that the line connected
to the remote terminal port is becoming an asynchronous DDCMP line.

7 When the terminal emulator at the local node receives the escape
sequence, it calls the image DYNSWITCH, which causes the line
connected to terminal port TTA1 to be switched to an asynchronous
DDCMP line. It assigns a channel to the network and supplies the
appropriate line and circuit entries to the NCP volatile database at the
local node. (Note that the modem line is not dropped; redialing is not
required.)
8

2-16

The asynchronous DDCMP protocol on the local node then sends
a DDCMP start message to DYNSWITCH on the remote node.
DYNSWITCH at the remote node disconnects the physical terminal from
the virtual terminal, and causes the line connected to the physical terminal
port (in the figure, the port TXB1) to be converted to an asynchronous
DDCMP line. DYNSWITCH assigns a channel to the network and
supplies the appropriate line and circuit parameters to the volatile database
to start up the line and circuit.

DECnet—VAX Components and Concepts

9 After DECnet is started on the local node, the terminal emulator is exited
and control is returned to the local node with the following message:
'/, REM-S-END - control returns to local-node-name::

A prompt appears on the local terminal and you can then use DECnet to
perform operations over the network.

I 0 If the terminal emulator does not recognize escape sequences, you must
specify the /MANUAL qualifier in the SET TERMINAL command
indicated in step 5. The /MANUAL qualifier prevents DYNSWITCH
at the remote node from sending the escape sequence. Instead,
DYNSWITCH sends the following message to the local node
V. SET-I-SWINPRG The line you are currently logged in
over is becoming a DECnet line

After receiving this message, if you decide not to switch the line, you can
type CTRL/C or CTRL/Y to abort the switch. If you want to continue the
switch, you should exit the terminal emulator and switch your terminal
line to an asynchronous DDCMP line manually by specifying
$ SET TERMINAL/PROTOCOL=DDCMP TTA1:

and entering NCP commands to turn your line and circuit on.
DYNSWITCH waits 60 seconds for the DDCMP start message and then
times out the switch.
Note that the SET TERMINAL command is a VAX/VMS DCL command.
If you are on a non-VAX/VMS node, you should specify the equivalent
function for your system.
II When you hang up the line, it is switched back to a terminal line.
(DECnet-VAX automatically clears the line and circuit entries from the
volatile database). Alternatively, you can switch the asynchronous line
back to a terminal line by issuing an NCP command to turn the line or
circuit off.
If you specified the /NOHANGUP qualifier in the SET TERMINAL
command in step 5, the modem signal is not dropped if you specify an
NCP command to turn off the DECnet line. You will not have to redial
the connection to the remote node when you want to convert your line
to DECnet use. The modem signal is dropped when you hang up the
telephone.
Examples of the commands required to install dynamic asynchronous lines
and the NCP commands required to configure a network using dynamic
asynchronous lines are given in Chapter 5.
NCP command parameters required for asynchronous connections are
described in Chapter 3. Security for dynamic asynchronous connections
is summarized in Section 2.10.

2.3.3

Cl Line Device
The CI-780 and CI-750 lines are high-speed devices, each of which provides
a connection between two or more nodes. If you plan to run DECnet over
a Cl, you must first connect the device CNAO to the driver CNDRIVER. To
connect CNAO to the CNDRIVER and load the CNDRIVER, add the following
to the LOADNET.COM command procedure in SYS$MANAGER:
$ RUN SYS$SYSTEM:SYSGEN
CONNECT CNAO/NOADAPTER

2-17

DECnet—VAX Components and Concepts

2.3.4

Ethernet Line Device
A VAX/VMS Ethernet node is connected to the Ethernet line by the
DEUNA communications controller, a transceiver, and a transceiver cable.
(Alternatively, a DELUA controller can be used instead of the DEUNA;
both devices are referred to as UNA devices.) A MicroVMS Ethernet node
uses the DEQNA controller to perform the same functions as the DEUNA
controller. (The DEQNA device is called the QNA.) The Ethernet line device
that provides the physical connection between two or more nodes on the
same Ethernet cable is the UNA, for a VAX/VMS node, or the QNA, for a
MicroVMS node. The UNA and QNA use the Ethernet line protocol. The
Ethernet circuit operates over the Ethernet line.
A particular Ethernet node is identified by the Ethernet hardware address
of its line device; this hardware address is stored in read-only memory in
the DEUNA, DELUA, or DEQNA. When DECnet starts an Ethernet line, it
causes the DEUNA, DELUA, or DEQNA connected to the line to construct
an Ethernet physical address for the node (see Section 3.3.4). Conditions that
cause the DEUNA, DELUA, or DEQNA to reset the physical address to the
original hardware address are shutting off machine power or changing the
state of the Ethernet line to OFF.

2.3.5

X.25 Line Devices
VAX PSI supports the following line devices:
•

DMF32 synchronous line unit

•

DUP11-DA

•

DPV11

•

KMS11-BD

•

KMS11-PX/PY

•

KMV11

The DPV11 is equivalent to a DUP11. The DMF32 synchronous line unit
is a point-to-point or multipoint tributary circuit device. The DUP11-DA
is a low-speed synchronous interface. The combination of the KMS11-BD
controller hardware and the X.25 level 2 microcode provides a medium-speed
synchronous interface called the KMX. The KMS11-BD supports eight lines,
but all lines that are used must be connected to the same PSDN. Similarly,
the combination of the KMS11-PX controller hardware and the X.25 level 2
microcode provides a medium-speed synchronous interface called the KMY,
supporting one line. The KMV11 is equivalent to a KMY.
Refer to the VAX PSI documentation set for the most recent list of supported
X.25 line devices.

2-18

DECnet—VAX Components and Concepts

2.4

Routing
Routing is the network function that determines the path or route along
which data (called "packets" in this context) travels to its destination. The
Routing layer of DECnet handles routing functions. Because the need for
routing pervades network operation, as much as possible is done in software
to relieve the user from worrying about the configuration of the network.
As system manager, however, you need to be concerned with the
configuration of the network in terms of routing. You must configure each
network node as either a routing or a nonrouting node, and you have the
option of dividing the whole network into different areas. In addition, certain
parameters in the configuration database permit a degree of indirect control
over network routing, but, for most networks, the default values of these
parameters are reasonable.
For very large networks, it may be helpful to have a network manager
oversee the operation of the network as a whole. The network manager could
ensure that all node addresses are unique and that routing control parameters
provide for efficient data flow through the network.
This section explains the different types of routing and nonrouting nodes
and configurations, describes the levels of routing, and summarizes special
routing techniques used with Ethernet. It also introduces basic terms and
concepts involved in routing control. The NCP command parameters that
affect routing are discussed in Chapter 3.

2.4.1

Routing and Nonrouting Nodes
Routing nodes (routers) are nodes that can send and receive packets and
route packets from one node to another. Routers have two 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, Cl, Ethernet, or X.25 circuits as their data links.
In a multiple-area network, all routers in a particular area can route packets
within the area; certain of these routers can also route packets to and from
other areas. The two kinds of routers used in area routing configurations are
level 1 routers and level 2 routers.
The level 1 router performs intra-area routing within a single area of the
network. Note that if all nodes are configured in the same area, the whole
network is considered as a single area, and all routers are level 1 routers. The
level 2 router performs intra-area routing within its own area and interarea
routing between its area and one or more other areas of the network.
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. End nodes have a single circuit 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 elected the
designated 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 network nodes not on the Ethernet.

2-19

DECnet—VAX Components and Concepts

2.4.1.1

Types of DECnet Nodes
DECnet supports a variety of types of nodes developed during different
phases of DNA implementation. Phase II, III, and IV nodes can all exist on a
network. The following types of nodes can be configured as being adjacent to
each other:
•

Phase II/Phase II

•

Phase II/Phase III

•

Phase Ill/Phase III

•

Phase Ill/Phase IV

•

Phase IV/Phase IV

Phase II nodes can communicate with each other as long as there is a physical
data link between them. They support only point-to-point connections. There
is no Phase II support for Ethernet.
Phase III DECnet introduced adaptive routing, which allows a reasonably
large number of nodes to communicate conveniently. A network composed
of Phase III nodes is limited to a practical size of approximately 100
nodes, because of the overhead of routing update messages that have to
be exchanged among routers. (The design limit for the address of a DECnetVAX Phase III node is 255; this limit may vary for other DECnet Phase III
systems.) Phase III introduced routers and end nodes. Phase III depends
on data links that guarantee delivery of messages in order to accomplish
initialization among routers. Therefore, there is no Phase III support for
Ethernet.
Phase IV DECnet permits the configuration of very large networks and
expands the types of data links available for use. Phase IV supports area
routing, which allows configuration of a network of up to 63 areas, each
containing up to 1023 nodes. Phase IV software supports Ethernet circuits, as
well as DDCMP, Cl and X.25 circuits.
Phase IV nodes can speak to Phase III nodes. Certain restrictions apply,
however, in a mixed Phase Ill/Phase IV network:
•

A Phase III node should not be included in a path between Phase IV
nodes.

•

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

•

Routing initialization passwords (described in Section 2.10.1) are required
when a Phase III node is initialized in a Phase IV network.

Restrictions on the use of Phase III nodes in Phase IV networks are discussed
in detail in Section A.5.

2-20

DECnet—VAX Components and Concepts

2.4.1.2

DECnet-VAX Phase IV Nodes
DECnet-VAX Phase IV nodes are either of the following two types:
•

Phase IV routers. These nodes deliver packets to and receive packets from
other nodes, and route packets from other source nodes through to other
destination nodes. They use Ethernet, DDCMP, X.25, and Cl circuits. In
an area network configuration. Phase IV routers exist at two routing levels:
— The level 1 router, which performs routing within a single area. The
node type is ROUTING IV.
— The level 2 router, which performs routing within its own area and to
and from other areas. The node type is AREA.

•

Phase IV nonrouting nodes (end nodes). These nodes deliver packets
to other nodes and receive packets from other nodes, but do not route
packets through. They can be attached to an Ethernet, DDCMP, X.25, or
Cl circuit. The node type is NONROUTING IV.

DECnet-VAX Phase IV nodes can also communicate with the other types of
nodes supported by DECnet. Area numbers are dropped when a Phase IV
node communicates with a node that is not a Phase IV node. A Phase IV
node will add its executor area number to the node address of a message that
it receives from a Phase III node. Nodes with which Phase IV DECnet-VAX
nodes can communicate include:

2.4.1.3

•

Phase III routers. These nodes deliver packets to and receive packets from
other nodes, and route packets from other source nodes through to other
destination nodes whose addresses are less than 256. They use DDCMP,
X.25, and Cl circuits, but do not support Ethernet circuits.

•

Phase III nonrouting nodes (end nodes). These nodes send packets to
other nodes and receive packets from other nodes, but do not route
packets through. These nodes cannot support the Ethernet. DECnet-VAX
never provided this type of node, but can communicate with Phase III end
nodes (for example, RSX Phase III end nodes).

•

Phase II nodes. These nodes can send packets to adjacent Phase III routers
or to other adjacent Phase II nodes. However, Phase II nodes can send
packets only in point-to-point configurations. In addition, a Phase III node
cannot communicate with a Phase II node through another Phase III node.

Routing Features of DECnet-VAX License Options
The DECnet-VAX license you purchase determines the types of nodes you
can configure. DECnet-VAX offers the option of installing a key for either of
two kinds of DECnet-VAX license:
•

The full function license permits the node on which the appropriate key
has been installed to be configured as either a router or an end node.

•

The end node license permits the node on which the appropriate key has
been installed to be configured only as an end node.

Both licenses permit the use of any kind of data link (DDCMP, Cl, Ethernet,
X.25). Installation of the DECnet-VAX license key is described in Section 6.1.
A configuration consisting only of end nodes offers certain advantages:
•

Less use of the central processor is required for routing.

2-21

DECnet-VAX Components and Concepts

•

Data link efficiency is increased: there is no routing overhead and no
route-through traffic occurs over the circuit.

End nodes also involve the following limitations:

2.4.2

•

The user on an end node cannot directly see the status of other nodes in
the network, because end nodes rely on routing nodes to maintain that
information. However, a Phase IV end node can communicate with all
nodes in the network, including nodes outside its own area.

•

At most, only one circuit is allowed to be active. If that one link to the
network fails, no alternative connection is available until the system
manager turns on a standby data link, if one exists.

Area Routing
Phase IV DECnet permits implementation of very large networks through
the use of area routing techniques, while still supporting configuration of
smaller networks that are not divided into areas. The network manager has
the option of partitioning a large network into areas. Each area is a group of
nodes. Nodes are grouped together in areas for hierarchical routing purposes.
Hierarchical routing involves the addition of a second level of routing to the
network. Routing within an area is referred to as level 1 routing; routing
between areas is called level 2 routing.
Area routing offers the following advantages:
•

It permits configuration of very large networks of more than 1023 nodes.

•

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

•

It allows different organizations to manage their nodes separately within a
large network.

•

It makes the merging of existing networks easier.

When a level 1 router receives a packet destined for a node in another area,
it uses level 1 routing to send the packet to the nearest node within its own
area that can perform level 2 routing. That router forwards the packet by
level 2 routing to a level 2 router in the destination area, which in turn sends
the packet by level 1 routing to the destination node in its area.
Note that if two or more level 2 routers exist in the same area, each level 1
router in that area sends packets destined for other areas to the nearest level
2 router, regardless of which level 2 router is closest to the destination area.
The level 1 router has no access to level 2 routing information.
Each area in the network is assigned an area number. Every node in the area
is uniquely identified by the addition of its area number as a prefix (followed
by a period) to its node number. For example, node 15 in area 7 is addressed
as node 7.15. The node/lumber must be unique within the area, but may be
used again within another area. Thus node identification within an area is
independent of node identification within other areas.
Phase IV DECnet permits configuration of a maximum of 63 areas (areas 1
through 63), each containing up to 1023 nodes. A Phase IV node address
is a 16-bit number: the most significant six bits define the area number,
and the least significant 10 bits specify the node number within the area.
The Phase IV node address can be converted to its decimal equivalent

2-22

DECnet—VAX Components and Concepts

for use in commands, such as COPY and MAIL commands, that do not
recognize the area prefix (the conversion procedure is given in Section 3.7.2).
It can be converted to its hexadecimal equivalent for use in determining the
Ethernet physical address of the node (the conversion procedure is given in
Section 3.3.4.2).
You assign the node address to your own node when you configure it. If you
do not specify the area number when addressing a remote node, that node is
assumed to be in the same area as your local node.
In a network not divided into multiple areas, each router performs level 1
routing throughout the network.
The characteristics of level 1 and level 2 routing nodes are described in the
following section. Appendix A presents rules for configuring hierarchical
networks using area-routing techniques. This appendix also describes the
configuration of mixed area networks, involving Phase III and Phase IV
nodes, and recommends procedures for converting a nonarea network to an
area network.

2.4.3

Level 1 and Level 2 Routers
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. Level 1 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:
•

Level 2 routers connect areas together.

•

Level 2 routers also act as level 1 routers within their own 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 it is not physically
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.

•

Level 2 routers exchange level 2 routing messages among themselves.

•

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

•

Each level 2 router indicates it is the nearest level 2 router to each level 1
node in its own area, but each level 1 node decides what its level 2 router
is on the basis of cost.

2-23

DECnet—VAX Components and Concepts

2.4.4

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
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 (the router priority parameter is set as a CIRCUIT characteristic in
its database) is elected router for the circuit. In case of a tie, the node with
the highest address is elected as the designated router. 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.
Ethernet end nodes can also exchange messages directly without using a
router. Routers are needed, however, when messages are to be routed to
nodes off the Ethernet.
Ethernet end nodes are informed of the identity of the designated router on
that Ethernet. 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, then the next packet can be sent directly, rather than by means of the
designated router.

2-24

DECnet—VAX Components and Concepts

2.4.4.3

Area Routing on an Ethernet
All nodes on an Ethernet need not be in the same area; more than one area
can be configured on a single Ethernet. The areas on the same Ethernet are
logically separate from each other. When two level 1 routing nodes on an
Ethernet are configured in different areas, the nodes do not communicate
directly with each other. Each level 1 router communicates with a level 2
router in its own area, which sends the message to a level 2 router in the
other area. The level 2 router that receives the message then transmits it
to the second level 1 router. Area routing on an Ethernet is illustrated in
Section A.6.

2.4.5

Routers and End Nodes on Cl Data Links
Nodes in a VAXcluster using a Cl data link can be configured as routers or
end nodes.

2.4.5.1

Cl End Nodes
A two-node VAXcluster using a Cl data link can be configured using end
nodes only, but at east one router is required if additional nodes are
configured in the cluster. The Cl protocol does not include the multiaccess
capabilities of the Ethernet protocol.

2.4.5.2

Cl Routers
One or more Cl routers are necessary if a VAXcluster consists of three or more
nodes. Cl circuit devices are treated as though they were multipoint devices
(like the DMP device) rather than as multiaccess devices such as the Ethernet
circuit device. Although only one router is required in a cluster of more than
two nodes, having more routers in the cluster environment increases the
overall availability of the network within the cluster.
If the VAXcluster configuration includes end nodes as well as routers, a
backup, higher-cost circuit could be provided for each end node. This backup
circuit could take over if the primary circuit connecting the end node to its
router fails (see Section 3.7.6).
Note that end nodes communicating through a router send all data through
that router even though they are connected to the same Cl. The best
performance and availability are achieved by defining all VAXcluster nodes as
routers if the Cl is used as the datalink.

2.4.6

Routing Concepts and Terms
This section briefly explains routing concepts and defines those routing
parameters that provide some control over network routing. Use of NCP
commands to set these routing parameters is described in Chapter 3. A more
detailed explanation of routing concepts and the routing algorithms for the
routing layer can be found in the Introduction to DECnet manual.
The following terms are used to describe DECnet routing and routing
parameters:
•

Hop. The logical distance between two nodes is measured in hops. The
distance between two adjacent nodes is one hop.

•

Path. A path is the route a packet takes from source to destination.

2-25

DECnet-VAX Components and Concepts

•

Path length. The path length is the number of hops along a path between
two nodes; it is the number of circuits a packet must travel across to
reach its destination. The path length never exceeds a maximum number
of hops, a value that the system manager sets relative to the size and
configuration of each network. For an area network, the network manager
should determine the maximum number of hops permitted within an area
and between areas.

•

Cost. The cost is an integer value assigned to a circuit between two
adjacent nodes. It is usually proportioned to transmission delay. Each
circuit has a separate cost. In terms of the routing algorithm, packets are
routed on paths with the least cost. Nodes on either end of a circuit can
assign different costs to the same circuit.

•

Path cost. The path cost is the sum of the circuit costs along a path
between two nodes. The path cost never exceeds a maximum cost value
the network manager specifies for the network. For an area network, the
network manager sets the maximum cost for a path within an area, and
for a path between areas.

•

Reachable node. A reachable node is a destination node to which the
Routing layer on the local node has a usable path; that is, the path does
not exceed the values for maximum cost or hops between nodes specified
in the executor database. For an area network, a reachable area is one
to which the path does not exceed the values for maximum cost or hops
between areas set in the executor database.

•

Maximum visits. The maximum number of nodes through which a
packet can be routed before arriving at the destination node is referred
to as the maximum number of visits the packet can make. If a packet
exceeds the maximum number of visits, the packet is dropped.

When configuring a network, the network manager establishes the routing
parameters for circuit cost control and route-through control. These
parameters allow you to control the path that data is likely to take when
being transmitted through the network, and also to minimize congestion at
particular nodes in the network. For most networks, the default values for
these parameters are reasonable.
As network manager, you must assign a circuit cost to every circuit that
connects the local node with adjacent remote nodes. These costs serve as
values that DECnet software uses to determine the path over which data is
transmitted. When the node is up and running, you can dynamically change
the cost of a circuit to a higher or lower value. Altering circuit costs can
change packet routing paths and thereby affect the use and availability of
network circuits and resources.
Along with defining circuit costs, you should also consider the path lengths
and total path cost for routing packets over the network. For routing
purposes, DECnet software identifies the least costly path to each destination
in the network. As network manager, you are responsible for defining both
the maximum cost of all circuits and the maximum hops that a packet can
take when routed to the destination node. If you are configuring an area
network, you should define the maximum cost and hops for a path between
nodes within your own area, and the maximum cost and hops for a path
between level 2 routers in the whole network.

2-26

DECnet—VAX Components and Concepts

The Routing layer in each node of the network uses congestion-control
algorithms to maintain an efficient level of routing throughput. In addition, as
network manager, you can maintain indirect control over routing throughput
by defining the maximum visits a packet can make before being received by
the destination node. Packets that have exceeded this limit are discarded.
This control prevents packets from looping endlessly through the network.

2.4.7

Routing Messages
Adjacent routing nodes exchange routing update messages. A routing update
message is a packet that contains information about the cost and hops for
each node in the network. In an area network, a level 1 router sends routing
update messages about all nodes within its own area to adjacent routers in
the area. Level 2 routers send routing update messages containing cost and
hop information about all areas to adjacent level 2 routers in the network.
Whenever this routing information changes (for instance, when a circuit
goes down) new routing messages will be sent automatically. For example,
if someone were to change the state of a circuit, rendering a remote node
unreachable, this change would be reflected automatically in the routing
update messages exchanged by the routing nodes.

2.4.7.1

Segmented Routing Messages
The number of nodes that Phase IV DECnet can support in a single-area
network is increased to a maximum of 1023 from the limit of 256 for Phase
III DECnet. This increase is due to changes in the routing update messages.
In Phase III, a legal network was restricted in size to the number of nodes
for which cost and hop information could be fit into a single routing update
message. Furthermore, Phase III routers had to send complete updates
containing information about all nodes, whether or not their reachability had
changed. Phase IV allows segmented routing messages to be sent, that is,
messages that contain only the information that has been changed. Phase IV
also permits routing updates to be sent in multiple messages. Therefore, the
size of the routing messages and the number of buffers required to receive
them are reduced.

2.4.7.2

Timing of Routing Message Transmissions
The network manager can set a timer for transmission of routing messages,
controlling the intervals at which nonconfiguration change routing updates
are transmitted. The routing timer controls the frequency of transmission of
these messages on non-Ethernet circuits. The broadcast routing timer controls
their frequency for Ethernet circuits. Expiration of the broadcast routing timer
causes the local node to send a multicast routing configuration message to all
routers on the Ethernet.

2.5

Logical Links
DECnet uses a mechanism called a logical link to allow communication
between processes running on either the same node or on separate nodes in
the network. A logical link carries a stream (consisting of regular data and
interrupt data) of full-duplex traffic between two user-level processes. Each
logical link is a temporary data path that exists until one of the two processes
terminates the connection.

2-27

DECnet—VAX Components and Concepts

As system manager, you can control various aspects of logical link operation
on the local node. You can
•

Define the maximum number of logical links that can be active at the local
node. If your node can also use an alias node address (which is common
to some or all nodes in a VAXcluster), you can specify the maximum
number of logical links that can use the alias for incoming and outgoing
connections. Note that the upper limit on the number of logical links that
your node can originate using the individual node address is reduced if
your node also uses an alias.

•

Specify the number of packets that can be transmitted on a logical link
before an acknowledgment is received (the pipeline quota).

•

Selectively disconnect active links on the local node while the network is
running and verify that the links have been disconnected, by displaying
information on the status of the links.

Logical link activity related to the Network Services Protocol (NSP) is
controlled by certain parameters that regulate the duration of NSP connect
sequences and inactivity intervals, and the frequency with which NSP
retransmits messages. The timers that affect this activity include
•

The incoming timer, which protects the local node against the overhead
caused by a local process that does not respond to an inbound connection
request within a specified interval

•

The outgoing timer, which protects the local node against the overhead
caused by a connection request to a remote node that does not complete
within a specified interval

•

The inactivity timer, which protects the user against a link that may be
permanently unusable, by setting the frequency with which DECnet tests
an inactive link

You should normally use default values for the parameters which regulate
the frequency of NSP message retransmission at the local node, unless you
need to change the operating characteristics of a particular logical link. The
retransmit time is affected by the estimated delay in round-trip transmission
between the local node and the node with which it is communicating. The
delay weight and delay factor parameters are used to calculate new values for
this estimated delay. The retransmit factor parameter governs the number of
times NSP will try to retransmit on a logical link.

2.6

Objects
Objects provide known general-purpose network services. An object is
identified by object type, which is a discrete numeric identifier for either a
user task or a DECnet program such as NML or FAL. The DECnet network
software uses object type numbers to enable logical link communication using
NSP. The system manager is responsible for supplying information for those
objects, both user-defined and network objects, that can be used over the
network.
For VAX PSI network operations, you are responsible for identifying objects
by name, and establishing command procedures to be initiated when
incoming X.25 calls to the objects arrive.

2-28

DECnet—VAX Components and Concepts

2.6.1

DECnet-VAX Objects
When setting up the network, you must supply information for two general
kinds of DECnet-VAX objects:
•

Objects with a 0 object type. These objects are usually user-defined
images for special-purpose applications. They are named when a user
requests a connection. Objects in this category are defined in the DECnetVAX configuration database as TASK (see Section 3.9.1). The object type
number for all of these objects is 0.

•

Nonzero objects. Nonzero objects are known objects that provide specific
network services such as FAL (file access) or NML (network management).
They may also be user-defined tasks; these objects should be for usersupplied known services. Object type numbers for all nonzero objects
range from 1 to 255. The number serves as a standard addressing
mechanism across a heterogeneous network. For a complete list of
network objects, refer to the VAX/VMS Network Control Program Reference
Manual.

The following DIGITAL-supplied objects are defined inside NETACP, by
default, in the configuration database. Note that MAIL and PHONE are
specific to VAX/VMS.
•

File access listener (FAL). FAL is an image that provides authorized access
to the file system of a DECnet node on behalf of processes executing on
any node in the network. FAL communicates with the initiating node by
means of the Data Access Protocol (DAP).

•

Network management listener (NML). NML is an image that provides
services such as gathering and reporting information about network status,
zeroing line and node counters, and loading a standalone system image to
a remote node.

•

Event logger (EVL). EVL is an image that logs significant events (locally or
remotely) for a given network component.

•

Loopback mirror (MIRROR). MIRROR is an image that is used for
particular forms of loopback testing.

•

DECnet Test Receiver (DTR). DTR is a DECnet test program that is
used with the DECnet Test Sender (DTS) to test logical links. The DTS
/DTR Utility is described in the DECnet Test Receiver/DECnet Test Sender
Reference Manual.

•

MAIL. MAIL is an image that provides personal mail service for
VAX/VMS nodes.

•

PHONE. PHONE is an image that allows you to have online
"conversations" with users on VAX/VMS.

•

Host loader (HLD). HLD is an image that provides downline task-loading
support for RSX-11S tasks.

For every object that can be started by an inbound connection request, you
must supply a command procedure unless either of the following conditions
exists:
•

The object is one of the following DIGITAL-supplied command
procedures: FAL, HLD, NML, EVL, DTR, MAIL, PHONE, MIRROR

2-29

DECnet-VAX Components and Concepts

•

The object is defined as an image, through specification of objectname.EXE
as the object file name.

Rules for establishing and identifying command files for objects are given in
Chapter 3.
You can also specify privileges a user must have in order to connect to the
object, and provide default access control information to be used for inbound
connections to the object when no access control is specified by the remote
node. Additionally, you can assign default proxy login access controls for the
object. Refer to Section 2.10 for a discussion of access control information
used for logical link connections and a description of proxy login access
control.

2.6.2

Objects Using the Cluster Alias Node Identifier
If your node is in a VAXcluster that is using an alias node identifier, you have
the option of specifying how the cluster alias node address is to be used in
relation to incoming and outgoing connections for specific network objects.
By default, all objects except PHONE are able to receive connect requests
directed to the alias node identifier. For outgoing connections, the default is
that only the MAIL object will be associated with the alias node address. If
you send mail from a cluster node that uses the alias, the sender's address on
the mail message will be the alias node identifier.
The alias node address should not be specified for objects that require
multiple incoming links, because an incoming link identified by the alias
node address may be assigned to any of the nodes participating in the cluster
alias node address. For example, PHONE should not use the alias node
address, because it requires that all incoming links be directed to the same
node in the cluster. Nontransparent tasks that have a mailbox and can receive
multiple inbound connection requests should not be accessed using the alias
node address (see Chapter 8). Also, objects whose resources are not available
clusterwide should not be allowed to receive incoming connect requests
addressed to the alias node address.

2.6.3

Creating DECnet—VAX Network Server Processes
On VAX/VMS, all DECnet objects run as processes. Unless a currently
running process has declared itself to be a numbered network object or a
named network object (with number 0), NETACP must invoke a process
to receive the connect request. When the logical link request comes in, a
standard procedure called NETSERVER.COM is run, which in turn causes
NETSERVER.EXE to be executed. This program works in concert with
NETACP to invoke the proper program for the requested object. Then,
when the logical link is disconnected, the "object" program (such as FAL)
terminates, but the process is not deleted. Instead, control returns to the
NETSERVER.EXE program, which asks NETACP for another incoming logical
link request to process. This cycle continues until NETSERVER is deleted
after a specified time limit. The default is 5 minutes. To use a different
default time limit, specify the logical name NETSERVER$TIMEOUT, using an
equivalence string in the standard VAX/VMS "delta time" format:
dddd hh:mm:ss.cc

2-30

DECnet—VAX Components and Concepts

The effect of NETSERVER is to reuse network server processes for more
than one logical link request, eliminating the overhead of process creation
for an often-used node. NETACP reuses a NETSERVER process only if the
access control on the connect request matches that used to start the process
originally.
When NETACP creates a process to receive the connect request, the process
runs like a batch job. The sequence is as follows:
1

The process is logged in according to information found in the UAF.
The key to this file is the username, which is part of the access control
information. The process is successfully logged in only if the password
from the access control string matches the password in the UAF record.
(Refer to Section 2.10 for a discussion of DECnet access control.)

2 DECnet-VAX automatically creates a log file in
SYS$LOGIN:NETSERVER.LOG. Unlike the log file for a batch job, this
log file is neither printed nor deleted. The log file is helpful for debugging
your own network tasks. If NETSERVER.LOG cannot be created for any
reason, the network job will continue running but will not produce any
log file.

3 The login command procedure indicated in the UAF for the process is
executed.

4 The process runs a command file to start the image that implements the
DECnet object. The rules for locating this command file differ depending
on whether or not the object has the number 0.
Because NETSERVER.LOG files are not required for network server processes,
you may explicitly inhibit all log files in your default nonprivileged DECnet
account by setting the default directory for the account to a nonexistent
directory. The effect of this action is to suppress all log files, while allowing
network jobs to be run.

2.6.4

Potential Causes of Network Process Failures
If a logical link fails and the status information displayed is "network partner
exited," this message indicates a problem in the remote network server
process. To determine the details of the failure, consult the NETSERVER.LOG
file at the remote node. Common reasons for failure are
•

Inability to log in because of failure to access the system login procedure,
or the account login procedure or any files that it accesses.

•

Protection set on network procedures and images in SYS$SYSTEM, such
as NETSERVER.COM or NETSERVER.EXE.

•

Attempted execution in your LOGIN.COM file of an interactive
command that does not apply to network/batch jobs (for example, a
SET TERMINAL/VT100 or SET TERMINAL/INQUIRE command). These
commands should not be specified in your LOGIN.COM file unless they
are preceded by IF F$MODE() .EQS. "INTERACTIVE".

For example, in your LOGIN.COM file, use the following to prevent a logical
link failure:
$ IF F$MODE() .EQS. "INTERACTIVE" THEN SET TERMINAL/VT100

2-31

DECnet-VAX Components and Concepts

Any failure to create NETSERVER.LOG will cause a network job to continue
running, but without a log file.

2.6.5

VAX PSI Objects
The object component of VAX PSI contains records that identify the object,
specify a command procedure that is initiated when the incoming call arrives,
and specify account information for the incoming call.
You must identify each VAX PSI object by a unique name. For each object,
you must create a command procedure for starting the object that will be
executed each time an incoming X.25 call to the object is received. Rules for
establishing and identifying the command procedures are given in Chapter 3.
For each object, you must also supply account information (consisting of
a user name, password, and, optionally, an account name) to be used by
incoming X.25 calls from remote DTEs.

2.7

X.25 and X.29 Server Modules
To handle calls coming in over a PSDN from remote DTEs and terminals,
configure the X.25 and X.29 server modules, referred to as the X.25 and X.29
call handlers, as required. The X.25 server module handles incoming calls
that originated at a remote DTE; the X.29 server module handles incoming
calls that originated at a remote terminal. Your local DECnet-VAX node can
receive X.25 and X.29 calls if it is configured as any of the following:

2.7.1

•

A DTE connected directly to a PSDN (to be a DTE, a DECnet-VAX node
must have VAX PSI software installed)

•

A multihost connector node that forwards calls between a PSDN and
host node (to serve as a connector node, a DECnet-VAX node must be
configured with VAX PSI software in multihost mode)

•

A host node that uses a connector node to send and receive X.25 and X.29
calls (to be a host node, a DECnet-VAX node must be configured with
VAX PSI Access software)

Destination of Calls from a Remote DTE
The configuration database for the server modules defines the processes that
are the destinations for calls, so that incoming calls from a PSDN can be
directed to the appropriate destination. If your node is serving as a DTE
connected directly to a PSDN or indirectly as a host node using an X.25
connector node, the destination is on the local node. If your node is serving
as an X.25 connector node, the destination may be on one of the host nodes
using the connector node.
The server database specifies the maximum number of circuits the server
module may have; that is, the maximum number of incoming and outgoing
calls that all destinations can handle.
When establishing the server configuration database, you must identify
each destination by a unique alphanumeric name. You must also name the
object activated when a particular destination accepts an incoming call, and
assign priorities to all destinations that could handle the same incoming call.

2-32

DECnet—VAX Components and Concepts

Optionally, you can restrict the incoming calls a destination will handle to
any combination of the following:
•

Calls to specified local DTE subaddresses

•

Calls from specified user groups (BCUGs and CUGs)

•

Calls from specified remote DTEs

•

Calls containing user data that matches a specified call value once a mask
has been applied

•

Calls that have been redirected from another DTE

•

Calls received from a particular network

•

Calls containing particular values in the called address extension after a
mask has been applied

If your local node is serving as an X.25 connector node, you must identify in
the X.25 server database the host node on which each destination is located.
Chapter 3 describes how to use NCP commands to specify call handling
parameters in the configuration database.

2.7.2

Handling Incoming Calls at the Local DTE
This section describes the process of handling incoming calls at the local DTE
as it relates to network management. The VAX PSI X.25 Programmer's Guide
describes the handling of incoming calls as it relates to programming PSI
network tasks.
Whenever a remote DTE attempts to communicate with your local DTE
(that is, attempts to set up a virtual circuit), the remote DTE, the PSDN, and
the local DTE provide information that identifies the user process that is
the destination of the call. Remote DTE information passed with the call is
optional; such information may include the remote DTE address, a local DTE
subaddress, a closed user group (CUG) or bilateral closed user group (BCUG)
name, and so on. VAX PSI at the local DTE uses this information, along with
destination information defined in the configuration database at the local DTE
for the server module and objects, to determine how to handle the incoming
call.
When an incoming call is received, VAX PSI constructs a network connect
block (NCB) using the remote DTE address and other information that may
be specified. VAX PSI then attempts to match the information in these fields
with the information specified for destinations in the configuration database.
If only one match is made, VAX PSI associates the incoming call with the
object specified in the configuration database for this destination. If more
than one match is made, VAX PSI chooses the destination with the highest
priority. Then it associates the incoming call with the object specified for this
destination (see Section 2.6.4).
The object names the task that is to run as a result of the incoming call.
(A command procedure associated with the object is activated when' the
incoming call arrives; this user-written command procedure may activate
a user program or an image.) Section 2.6 discusses objects and object
parameters specified in the configuration database.

2-33

DECnet-VAX Components and Concepts

VAX PSI rejects the incoming call if (1) no match is made, and (2) a lastchance destination has not been specified. A last-chance destination is a
destination with an associated object that handles all incoming calls for
which a match cannot be found. The simplest last-chance destination is
a destination that specifies the complete range of local DTE subaddresses,
handles calls from all DTEs and all user groups, and ignores any incoming
call-handling information in the user data field. It specifies no subaddress,
no CUGs, no remote DTEs, and no local subaddresses. The last-chance
destination must have the lowest priority of all the destinations.

2.8

X.25 Access Module
The X.25 access module provides a means for user processes on VAX/VMS
host nodes to access remote nodes or terminals connected to a PSDN through
a VAX/VMS node serving as a multihost connector node. The host node
must be configured with VAX PSI Access software. The connector node must
be configured with VAX PSI software in multihost mode.
The X.25 access module identifies the connector node to which the local
node is to be connected, the network the connector node can access, and,
optionally, access control information. The DECnet-VAX host system with
VAX PSI Access uses a DECnet link to connect to the connector node. VAX
PSI Access software uses the link to transmit X.25/X.29 messages between
the host and the connector node.

2.9

Logging
The network software logs significant events that occur during network
operation. 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
•

Circuit and node counter activity

•

Changes in circuit, line, and node states

•

Service requests (when a circuit or line is put in an automatic service state)

•

Passive loopback (when the executor is looping back test messages)

•

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

•

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

•

Lost event reporting (when some number of events are not logged)

This information can be useful for maintaining the network because it can
be recorded continuously by the event logger. As system manager, you are
responsible for controlling certain aspects of event logging. In particular, you
can control source-related parameters (actual events to be logged, the source
for these events, and the location at which these events will be logged) and
sink-related parameters (the name of the logging component at the local node
and its operational state).

2-34

DECnet—VAX Components and Concepts

For the most part, events are logged for the various DNA layers and for
system-specific resources. Events are defined by class and type, in the format
class.type. The class of an event identifies the layer or resource to which the
event applies, and the type is the particular form of event within the class.
For example, event 4.3 indicates oversized packet loss (type 3) for the Routing
layer (class 4). Event classes and types are summarized in the VAX/VMS
Network Control Program Reference Manual.
The logging component is the device or process that records logging events.
There are three logging components:
•

A logging console, which is generally a terminal or file that records
events in user-readable form. If no logging console name is specified, the
operator console (OPAO) will be used.

•

A logging file, in which events are recorded in binary format. Detailed
information regarding the format can be obtained from the DNA Phase IV
Network Management Functional Specification. There is no default logging
file name.

•

A logging monitor, which is a program supplied by the system or user
that receives and processes events. If a logging monitor is specified, events
formatted in user-readable form are sent to the Operator Communication
(OPCOM) facility; all network operator terminals (terminals enabled
through specification of the DCL command REPLY/ENABLE=NETWORK)
display these events. Also, if a logging monitor name is specified, events
encoded in binary format are sent to the DECnet object specified by that
name; detailed information regarding the format can be obtained from the
DNA Phase IV Network Management Functional Specification.

Both the logging console and the logging monitor can be used to display
events at the operator console; however, the inherent flexibility of OPCOM
and its ability to display messages at terminals being used for timesharing
may make the logging monitor a more suitable choice for many sites.
The source of an event can be an area, node, module, circuit, or line. Events
can be logged at either the local node or a remote node; this node is called
the sink node.
At the local node, you can control the operational state of the logging sink.
You must turn logging on before events can be logged to the sink, and off
before the logging parameters for the sink can be cleared from the database.
Specify the hold state to queue events for a specific logging sink.

2.10

Network Access Control
DECnet-VAX regulates access to the network on various levels, including
•

Routing initialization passwords for links connecting the local node to
remote nodes

•

System-level access control for inbound logical link connections that result
in a process being created

•

Node-level access control for inbound and outbound logical links

•

Proxy login access control for individual accounts

2-35

DECnet—VAX Components and Concepts

This section describes these levels of control as they relate to DECnet-VAX
software operation, from the perspective of the system manager's need to
establish control parameters through NCP. Use of specific NCP commands to
accomplish access control is described in Chapter 3.

2.10.1 Routing Initialization Passwords
Whenever you turn on a circuit, your local node attempts to initialize with
the DECnet software at the remote node connection for that circuit. As part
of this initialization process, the remote node may require a password to
complete the operation. The system manager can specify passwords when
setting up the configuration database.
In a Phase IV network, passwords are required when a Phase III node is
initialized (see Section A.5.2.2), but are optional when a Phase IV node is
initialized. Generally, passwords are used in initializing Phase IV nodes only
when a system has dialup telephone lines used by the network. When a
dialup node seeks a dynamic connection over a terminal line, the dialup node
must supply a password, but the node receiving the login request will not
send a password to the dialup node.
Figure 2-4 illustrates a routing initialization sequence for the network
example. When the circuit is turned on, nodes BOSTON and TRNTO
initialize. On the local node, BOSTON, DECnet-VAX software retrieves
the transmit password for remote node TRNTO and sends it to TRNTO upon
request. On node TRNTO, DECnet-VAX verifies this password with the
receive password specified for remote node BOSTON in its configuration
database. Once the passwords are verified, the link is operational; that is, the
circuit state makes the transition from ON-STARTING to ON.

Figure 2-4
TRNTO

Routing Initialization Passwords

NCP>SET LINE DMC-0 STATE ON

ZK-548-81

DECnet-VAX always solicits a receive password. However, if verification on
the circuit is disabled, or if no receive password is specified in the database

2-36

DECnet—VAX Components and Concepts

for the adjacent node, DECnet-VAX will accept anything the adjacent node
may send. The adjacent node is still required to send the verification message.

2.10.2 System-Level Access Control
DECnet-VAX provides system-level access control over logical link
connections. The network user on the initiating node may explicitly supply
an access control string to control which account is used on the remote
node. If, however, the initiating node does not supply explicit access control
information, DECnet optionally provides default access control when sending
the request to the remote node. It also optionally provides default access
control for incoming logical links if the initiating node has not supplied access
control information.

2.10.2.1

Setting Access Control Information for Outbound Connects
The system manager can specify default access control information for
outbound connections. This enables the local node to send outbound logical
link requests with default access control information when that information is
not explicitly provided. The remote node stores the access control information
in its configuration database. The default access control information can
include privileged and nonprivileged names and passwords to be used in
connecting to a particular remote node.
The system manager at a node can specify a list of privileges required for
connection to a particular object, such as NML. When the local node requests
connection to an object for which privileges have been specified, it sends
the default privileged access control string to the remote node. If the system
manager does not specify privileges for an object, such as FAL, the object is
accessible to all users. When the local node requests connection to this object,
it sends the nonprivileged access control string.

2.10.2.2

Sources of Access Control Information for Logical Link Connections
Whenever a local DECnet node attempts to connect to a remote DECnet-VAX
node by means of a logical link, system-level access control information is
sent to the LOGINOUT image running in the context of a process on the
remote node. Access control information can come from a number of sources:
•

The network user on the local node may explicitly supply an access
control string. If this is the case, the remote node uses the access control
information.

•

If the access control string is not explicitly supplied, the local node checks
its object database against the privileges of the initiating process. If the
object does not require privileges other than TMPMBX and NETMBX, the
local node sends the default nonprivileged access control string from its
node database to the remote node.

•

If the object requires privileges beyond TMPMBX and NETMBX, and the
user process has the required privileges, the local node sends the default
privileged access control string from its node database to the remote node.

•

If no access control string is supplied, the local node checks to see if proxy
access is enabled at the participating nodes. If so, LOGINOUT checks the
NETUAF.DAT file to determine whether a user should be logged in to a
designated account rather than the nonprivileged account. (Proxy login
access control is described in Section 2.10.5.)

2-37

DECnet-VAX Components and Concepts

•

If none of the cases above is valid, the local node sends a "no" access
control string.

•

When the remote node sees that no access control has been specified,
it checks its object database. If the object database contains a default
inbound access control string, the remote node uses that string.

•

If there is no default access control information in its object database,
the remote node checks its node database for nonprivileged account
information about the local node. If the information is there, the remote
node uses the nonprivileged access control string.

Finally, if none of these sources supplies the information, the connection fails.

Note: In DECnet-VAX usage, nonprivileged means NETMBX and TMPMBX
privileges only. NETMBX is the minimal requirement for any network
activity. Privileged means any privileges in addition to NETMBX or
TMPMBX.
Figure 2-5 illustrates the local node's access control options for inbound
connection requests.
Figure 2-5

Access Control for Inbound Connections

OUTBOUND CONNECTION
(from local node)

INBOUND CONNECTION
(from local node)

to remote
node

Regardless of the source, the remote node uses this information to determine
whether a logical link can be established. The way this validation process
works is important for both the system manager and network users. This
section discusses access control in terms of network management. Chapter 8

2-38

DECnet—VAX Components and Concepts

discusses access control as it relates to user-level operations such as remote
file access and task-to-task communication.
Access control information is not used where the connection is to a program
that has declared a name or object number and has started independently of
DECnet.
Access control information allows users on remote nodes to gain access to
resources on the local node. The system manager must establish access
control information in both the configuration database (for objects) and the
UAF (for default network accounts) on the local node. Chapter 1 briefly
describes the necessity for these default accounts. Chapter 5 explains how to
create a default nonprivileged DECnet account.
Whenever NETACP on the local node receives an inbound logical link
connection request, it creates a process and starts the LOGINOUT image,
which verifies the user's access rights by checking the UAF. When VAX/VMS
starts a user process as a result of an inbound connection request, the
privileges with which that process runs are determined by the UAF record
associated with the access control information passed in the connection
message. This function is almost identical to the one that occurs whenever a
local user starts a batch job; the difference is that the resulting LOG file will
be neither printed nor deleted. Section 2.6 discusses this process in detail.

2.10.2.3

Network Security and Passwords
You can maintain password security in a network environment by protecting
the network configuration files from unauthorized access. The most
convenient way to do this is to require SYSPRV to access these files.
NML must have access to network configuration files. NML on the remote
node accesses these files when it sees the NCP commands that access the
permanent database (DEFINE, PURGE, LIST, and SET "component" ALL).
Once you have set access control (as described in the previous section), users
must have the privileges necessary to perform the following operations:
•

To modify the volatile database, NML users must have OPER privilege.

•

To specify the permanent database (using the DEFINE command) or to
update the volatile database with all parameters from the permanent
database (using the SET "component" ALL command), the user must have
OPER privilege and WRITE access to all permanent database files.

•

To remove specific parameters from the permanent database (using the
PURGE command) or to reset or remove all parameters from the volatile
database (using the CLEAR "component" ALL command), the user must
have OPER privilege and write access to all permanent database files. To
clear counters, the user must have OPER privilege.

•

To start the network, a user must have ACNT, CMKRNL, SYSNAM, and
DETACH privileges.

To make these safeguards operational, you should avoid assigning privileges
beyond those normally used. In particular, you should not give the default
privileged account SYSPRV. These default accounts should be in their own
group to avoid extending group access to other directories on the local node.
Sensitive files and directories may be protected against world access by
requiring explicit access control to reach them.

2-39

DECnet-VAX Components and Concepts

2.10.2.4

Inbound Default Access Control for Objects
Another form of access control specific to network objects is default account
information that is used by inbound connects from remote nodes that send
no access control information. Because no access control information is
supplied, the default information you specify for the object is used to allow
the logical link connection to be made. One example of this is downline task
loading. When SLD connects to HLD on the host node, default access control
information specified for the HLD object is used. Refer to Chapter 4 for more
information on downline task loading.

2.10.3 Access Control for Remote Command Execution
If you are requesting that an NCP command be executed at a remote node,
you can supply an explicit access control string or default to access control
information in the configuration database. To supply an explicit access control
string, use either the standard VAX/VMS node specification (node"user
password account"::) or specify this access control information as parameters
in the NCP command to be executed at a remote node.

2.10.4 Node-Level Access Control
As system manager, you can regulate two forms of node-level access control
for incoming and outgoing logical links. One form involves specifying the
ACCESS parameter for a particular node in your volatile database, and the
other involves specifying the DEFAULT ACCESS parameter in your executor
database.
When an incoming or outgoing logical link connection is attempted, the
executor node first checks its volatile database for the ACCESS entry for the
target node. If the entry exists, the executor uses it.
Because it might not be feasible to include an ACCESS entry for every node
in a large network, DECnet-VAX provides the DEFAULT ACCESS alternative
If the logical link connection is attempted and there is no ACCESS entry for
the remote node in the volatile database, the executor uses the DEFAULT
ACCESS parameter value.
Both commands accept the same set of parameter values, which are listed
below.
INCOMING

Allows logical link connections from the remote node, but does
not allow the local node to initiate connections to the remote
node.

OUTGOING

Allows the local node to initiate connections to the remote node,
but does not allow connections from the remote node.

BOTH

Allows incoming and outgoing logical link connections. This is the
default.

NONE

Does not allow incoming or outgoing logical link connections to
this node.

If no entry is specified for the ACCESS or DEFAULT ACCESS parameters,
the DEFAULT ACCESS parameter defaults to BOTH.
Only those users with OPER privilege can bypass this access protection.

2-40

DECnet—VAX Components and Concepts

For each node, you can configure the privileged and nonprivileged accounts
and passwords that constitute default access control information. This default
access control information should match the system-level access control
information established for the node (see Section 2.10.2).
Another form of access control at the node level is the node checking that
is performed before a system can dial in and form a dynamic asynchronous
connection over a terminal line. For a description of security measures for
dynamic asynchronous connections, see Section 2.10.6.

2.10.5 Proxy Login Access Control
Proxy login permits a user who is logged in at a remote node to be logged
in automatically to a specific account at the local node, without having to
supply any access control information. The remote user must have a proxy
account on the local node that maps to a local user account. The remote user
assumes the same file access rights as the local account and also receives the
default privileges of the local account. The proxy login capability can be used
to increase security, by minimizing the need to specify explicit access control
strings in node specifications passed over the network or stored in command
procedures.
The procedure for establishing proxy accounts is summarized below, followed
by a description of the means of controlling proxy login access over the
network.

2.10.5.1

Proxy Accounts
Proxy accounts permit one or more users on a remote node to obtain access
privileges on a node without having a private account on that node. The
remote user can issue commands to access data that is accessible by the local
account to which he has proxy access.
The system manager controls the use of proxy accounts at the local
node, using the Authorize Utility to create and modify the network user
authorization file, NETUAF.DAT. NETUAF.DAT contains proxy login
records, each of which maps a remote node name and user name (in the
form NODE::USER) to the user name of a single local account. Each remote
user can access only one local user account. For a summary description of
proxy accounts and how to create them, see the VAX/VMS System Manager's
Reference Manual. The Authorize Utility is described in the VAX/VMS
Authorize Utility Reference Manual.

2.10.5.2

Controlling Proxy Login Access
If no access control string is supplied when the local node receives a request
for initiation of an inbound connection, the local system checks to see if
proxy access is enabled at the participating nodes. By default, both incoming
and outgoing proxy login access is enabled for each node. If proxy access
is enabled, LOGINOUT checks the NETUAF.DAT file to determine if the
user should be logged in to a designated account rather than the default
nonprivileged DECnet account.
Proxy login access for the local node is controlled by the setting of the
DEFAULT PROXY entry in the volatile database. DECnet-VAX has set
this entry to permit proxy logins to be initiated by the local node or by
the remote node; this is the recommended setting. The use of proxy logins
can be restricted, however, through specification of the executor parameter
DEFAULT PROXY in the configuration database. The possible proxy access
options for the local node are defined below.

2-41

DECnet-VAX Components and Concepts

INCOMING

Allows proxy login access from the remote node to the local
node.

OUTGOING

Allows the local node to initiate proxy login access to the remote
node, but does not allow proxy login access from the remote
node to the local node.

BOTH

Allows both incoming and outgoing proxy login access. This is
the default and the recommended option.

NONE

Does not allow incoming or outgoing proxy login access
connections to the local node.

Proxy login access to a specific network object is controlled by the value of
the object parameter PROXY set in the configuration database. Defaults for
each object are set in the database. Permitting proxy login access to an object
is recommended only if the proxy access serves some useful purpose. For
example, by default MAIL is set to prevent incoming proxy login, while FAL
is set to allow both incoming and outgoing proxy login.
Four options are available for the PROXY parameter for a network object:
INCOMING

Allows proxy login to the object.

OUTGOING

Allows the object to initiate proxy login.

BOTH

Allows both incoming and outgoing proxy login access. This is
the default option.

NONE

Does not allow incoming or outgoing proxy login access.

Note that there are advantages to disallowing incoming proxy access to an
object (such as MAIL) that does not require it. Whenever possible, incoming
connect requests are matched up with compatible existing NETSERVER
processes, to avoid the overhead of unnecessary process creation. If a user
on a remote node with outgoing proxy access sends a request to connect to
an object with incoming proxy enabled on the local node, the connect request
will only be matched with a NETSERVER process that was started by a
previous request from the same user on the same node. This matching occurs
because the proxy database is processed by LOGINOUT, not by NETACP. If
the object disallows incoming proxy access, incoming connect requests will
use default access control, with a higher probability of being matched with an
existing NETSERVER process.

2.10.6 Security for DDCMP Point-to-Point Connections
If a remote node requests a connection over a DDCMP point-to-point circuit,
the local node can avoid revealing its routing initialization password, while
requiring that the remote node supply its password. This security measure is
used to protect the password of the local node when a dialup node initiates
an asynchonous connection to the local node.
For example, a user at a system with a terminal line (such as a Micro VMS
system) can dial in to another system (such as a VAX/VMS system in a
VAXcluster) and initiate a dynamic connection, causing the terminal lines
to be converted to asynchronous DDCMP communications lines for the
duration of the telephone call. To prevent attempts at access by callers
at unauthorized nodes, certain checks have been included in the dynamic
configuration process. The dialup node must be the type of node (router or
end node) expected by the local VAX/VMS node. When the dialup node
attempts to initialize, it must supply a routing initialization password to
the local node, but the local node does not send its password to the dialup

2-42

DECnet—VAX Components and Concepts

node. This preserves the security of the local node in case the dialup node
is unauthorized. In addition, the connection has been configured to end
automatically when the telephone is hung up.

2-43

PART II: Network System Management

Managing and Monitoring the Network

This chapter explains how to use network management commands and
parameters to configure, manage, and monitor network software. The
management tools and components available to DECnet-VAX and VAX PSI
users fall into 13 broad categories:
•

The configuration database

•

The Network Control Program (NCP)

•

The executor node and remote nodes

•

X.25 protocol modules

•

Circuits

•

Lines

•

Routing

•

Links

•

Objects

•

X.25 and X.29 server modules

•

X.25 access modules

•

Logging

•

Access control

This chapter should provide enough information to build a network
configuration database for your VAX/VMS operating system. It will also
explain how to use most NCP commands at both the local node and remote
nodes to modify parameters for the running network. See Chapter 5 for
examples that use NCP commands to build databases for various network
configurations.
DECnet-VAX and VAX PSI network components and operating concepts are
described in Chapter 2. Reference information on the operation of the NCP
utility program and the complete syntax of NCP commands appear in the

VAX/VMS Network Control Program Reference Manual.

3.1

The DECnet—VAX Configuration Database
The DECnet-VAX configuration database contains files that provide
information about the local node, remote nodes, local physical lines, local
circuits, local logging, and local objects. Each DECnet node in the network
has a network database that supplies component and parameter information
of this kind. To ensure successful node-to-node communication, each node
has a configuration database that consists of the following databases:
•

A node database with a record for each node, including the local node

•

A circuit database with a record for each circuit known to the local node

3-1

Managing and Monitoring the Network

•

A line database with a record for each physical line known to the local
node

•

A logging database with a record for each sink (logged events are sent to
the sinks)

In addition, NETACP provides a default object database with a record for
each object known to the network, including objects (for example, FAL) that
are defined when you bring up the local node.
As system manager, you need to specify the nodes that can communicate
with your node, the physical lines that connect the nodes, and the circuits
associated with those lines. In some cases, this connection may include more
than one line and circuit to the remote node. You also need to establish a
variety of operational routing parameters for the local node to ensure proper
network operation.
To allow for communication between nodes, NETACP defines several network
objects including NML, FAL, and TASK.
To provide network management flexibility, the DECnet-VAX configuration
database consists of two distinct databases, one volatile and one permanent.
In addition, if VAX PSI is included in the network, a VAX PSI configuration
database, consisting of a volatile database and a permanent database, exists at
the local DTE (see Section 3.1.3).

3.1.1

The Volatile Database
The volatile copy of the DECnet-VAX configuration database is memory
resident; it allows you to control the running network without modifying
the permanent database. NCP provides commands for setting, clearing, and
showing network component parameters for the volatile database. NCP also
permits you to copy current information about remote nodes from the node
database of another node into your volatile database.
You can change parameters in the volatile database while the system is
running; these changes, however, will be in effect only until you modify them
again or until the network is shut down. NETACP uses parameters specified
only in the volatile database.

3.1.2

The Permanent Database
The permanent copy of the DECnet-VAX configuration database provides
the initial values for the volatile database. You access the permanent
database whenever you use the ALL parameter with the SET command,
as, for example, when you bring up the network. In effect, the permanent
database allows you to load network parameters into the volatile database
when you boot the system. You can also change parameters in the permanent
database.
You can use NCP commands to define, purge, and list network component
parameters in the permanent database. You can also use NCP to copy current
remote node entries into your permanent node database from the database of
another node to which you have access.
You can optionally use the NETCONFIG.COM procedure to configure
automatically the permanent database for your node (see Chapter 5).

3-2

Managing and Monitoring the Network

3.1.3

VAX PSI Configuration Database
The VAX PSI configuration database contains files that provide information
concerning the local DTE, local lines, virtual circuits, local modules, and
local objects. Each PSI DTE that is connected to a PSDN has a database that
supplies component and parameter information of this kind. For successful
DTE-to-DTE communication, each DTE has a minimum configuration
database that consists of the following databases:
•

A circuit database with a record for each permanent virtual circuit (PVC),
if PVCs are in use

•

An object database with a record for each object

•

A line database with a record for each physical line to a PSDN

•

A module database with records for the PSDN(s), the DTE(s), groups, and
destinations.

The VAX PSI configuration is also stored in the DECnet-VAX configuration
database.
Just as with the DECnet-VAX configuration database, the VAX PSI
configuration database consists of both a volatile and a permanent database.
You can use NCP commands to configure the VAX PSI software at any time.
STARTNET.COM sets the parameters in the volatile database every time you
load the VAX PSI software (see Chapter 6). You can change parameters in
the configuration database while VAX PSI is running.

3.2

The Network Control Program
The Network Control Program (NCP) is the vehicle for creating and
modifying component parameters in the configuration database. In addition
to the NCP command interface, DECnet-VAX users can write programs
that communicate with NML through the Network Information and Control
Exchange (NICE) protocol. For information concerning this interface, refer to
the Phase IV Network Management Functional Specification.
Most NCP commands allow you to modify either the volatile or the
permanent database. NCP will access either database, depending on which
command verb you use. For example, the following command accesses the
permanent database to create or modify the address of* a remote node:
NCP>DEFINE NODE 14 NAME DENVER

To change the parameter in the volatile database, issue the command
NCP>SET NODE 14 NAME DENVER

The following list distinguishes command verbs by function and the database
that they access.
Function

Volatile

Permanent

Creating/modifying parameters

SET

DEFINE

Clearing parameters

CLEAR

PURGE

Displaying parameters

SHOW

LIST

Because the commands to access the volatile and permanent databases are
similar, this chapter uses volatile database commands in all examples.

3-3

Managing and Monitoring the Network

When configuring your network, you can use NCP either to build upon
previously specified information or to change that information. Thus you
do not have to delete all existing parameters and start over. For example,
assume that you have identified a remote node address as 5. You can add
node parameters for this record in the volatile database by using the SET
NODE command. If you want to change the address of this node, you only
need to specify a new address in the ADDRESS parameter of the SET NODE
command. If you decide later that you want to remove any or all parameters
for this node, then you could use the CLEAR NODE command. Commands
to remove parameters exist for all network components.
NCP commands operate on network components and their parameters.
When issuing an NCP command, you must provide the command verb, the
component name, and one or more parameters and/or qualifiers, as shown in
the example below:
$ RUN SYS$SYSTEM:NCP
NCP>SET
NCP>SET

NODE 11
KNOWN LOGGING

NAME BOSTON COUNTER TIMER 30
STATE ON

NCP>SET

EXECUTOR^

STATION

command component

parameters

Note that components consist of two types: singular (as with NODE
BOSTON) and plural (as with KNOWN LOGGING). For example, you
can display information about an individual node or all nodes (including the
local node) in the network:
NCP>SH0W NODE BOSTON COUNTERS

NCP>SH0W KNOWN NODES COUNTERS

Most NCP commands support both singular and plural component names.
For a detailed description of NCP operation, the syntax of NCP commands,
and examples of NCP command prompting, refer to the VAX/VMS Network
Control Program Reference Manual

3.3

Node Commands
To establish your VAX/VMS operating system as a node in the DECnet
network, you must build the node database entries for the DECnet-VAX
configuration database. This section describes identification of the executor
node and remote nodes, and the node parameters required to build an
operational network node database. It also discusses updating your node
database by copying current information about remote nodes from another
node to which you have access.

3-4

Managing and Monitoring the Network

3.3.1

Executor Node Commands
NCP allows you to manage the operation and configuration of both your
local node and remote nodes in the network. Generally, the NCP commands
you will issue at your local node will be executed on that node. Occasionally,
however, you may want to issue commands from the local node to be
executed on adjacent or remote nodes. To this end, NCP incorporates the
concept of an executor node. The executor node is simply the node on
which NCP functions are actually performed, which in most cases will be the
local node. To perform NCP functions on remote nodes, NCP supports two
commands: SET EXECUTOR NODE and TELL.
Note: For command descriptions in this manual, the executor node on nonEthernet circuits is assumed to be the local node (BOSTON) unless
otherwise specified. On Ethernet circuits, the executor node is usually
ROBIN.

3.3.1.1

SET EXECUTOR NODE Command
The SET EXECUTOR NODE command sets the executor to the node at which
you want the commands to execute. One use of this feature is to display
information about the configuration database of the remote node. Figure 3-1
illustrates this use of a remote executor node.
As shown in Figure 3-1, you set the executor node by issuing the NCP
command
NCP>SET EXECUTOR NODE TRNTO

NCP executes commands that you enter at your local node, BOSTON, at the
remote executor node, TRNTO. The executor node interprets each command
with its own network management software, and then performs the NCP
function. Each command must be stated as if it were issued to NCP at the
executor node. In this example, any information output that results from the
execution of a command is displayed at node BOSTON. If the remote node
is not running DECnet-VAX software, refer to the appropriate documentation
for that node.
To reset the executor to the local node, use the NCP command
NCP>CLEAR EXECUTOR NODE

The executor is always the local node when NCP is activated. It is possible
for several users at one node to set their executor to different nodes.
When you issue a SET EXECUTOR NODE command, you can either
include specific access control information or use the default access control
information. The level of privilege allowed at the remote executor node
depends on the access control information specified. (Section 3.13 describes
the access control format.)
Note: When you clear the executor node, NCP communicates with NML as a
shared image in the same process. Hence, clearing the executor node
resets the executor's privileges to those of your current process—that is,
the process running NCP.

3-5

Managing and Monitoring the Network

Figure 3-1

Remote Command Execution

BANGOR

BOSTON

DENVER

(Local Node)

NYC

NCP>SET EXECUTOR NODE TRNTO
NCP>SHOW KNOWN LINES
\

FROM BOSTON
FROM TRNTO

NCP>CLEAREXECUTOR NODE
NCP>

FROM BOSTON
/K

3.3.1.2

18fir>-B4

TELL Prefix
As an alternative to using the SET EXECUTOR NODE command, you may
want to execute only a single command at a remote node or you may want
to temporarily override the current executor. In either case you can use the
TELL prefix with an NCP command. For example, if you issue the following
command at node BOSTON, NCP displays line information for all physical
lines connected to node TRNTO:
NCP>TELL TRNTO SHOW KNOWN LINES

3-6

Managing and Monitoring the Network

Remote execution in this case applies only to the one command entered
with the TELL prefix. Again, you can specify or default to access control
information.

3.3.2

Node Identification
When configuring the network, you must identify in the executor
configuration database the local node and all adjacent nodes connected to
it by circuits. Identifying all nodes by name as well as address will permit
you to reach any node by its name. This section describes node identification
and discusses NCP parameters relevant to identifying nodes.
Either the node address or the node name can serve as a node identifier
(node-id). 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, a decimal 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 area
1. In multiple-area networks, it is recommended that you always specify the
area number.
A node name is an optional, unique alphanumeric string that contains up
to six characters including at least one alphabetic character. It can be used
interchangeably with the node address to identify a node. In the single¬
area network example in Chapter 1, the node name BOSTON and the node
address 1.11 identify the same node.
When defining remote nodes in the volatile database, use the SET NODE
command to specify node names and node addresses. The command below
associates the node name TRNTO with the node whose address is 1.5.
NCP>SET NODE 5 NAME TRNTO

To specify a node address for the local node, use the SET EXECUTOR
command, as in the following example:
NCP>SET EXECUTOR ADDRESS 11

Then, use the following command to specify a node name for the local node:
NCP>SET NODE 11 NAME BOSTON

By issuing these commands, you have established a remote node (TRNTO)
whose address is 1.5 and the local node (BOSTON) whose address is 1.11.
You can then build upon this information to establish parameters for the
various nodes.
Before a node can be accessed by name, you must specify a node name to be
associated with a node address.

3-7

Managing and Monitoring the Network

Once you set the executor node's address in the volatile database, you cannot
change it unless you turn off and restart the network. However, you can
change any other node's address at any time. For example:
NCP>SET NODE TRNTO ADDRESS 6
NCP>SET NODE TRNTO ADDRESS 8

3.3.2.1

Maximum Address Parameter
The MAXIMUM ADDRESS parameter sets the highest address that the
local node will recognize. Setting this parameter allows you to group node
addresses in a predefined range, which minimizes the size of internal data
structures and control mechanisms for DECnet-VAX software. For example,
the command below sets the highest remote node address at 17.
NCP>SET EXECUTOR MAXIMUM ADDRESS 17

3.3.2.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. NCP
will display this string whenever you issue the SHOW EXECUTOR or LIST
EXECUTOR command. Use the IDENTIFICATION parameter with the SET
EXECUTOR command to specify this optional information, as shown in the
command below.
NCP>SET EXECUTOR IDENTIFICATION "VMS HOST SYSTEM"

This command provides information that NCP displays whenever you use the
SHOW EXECUTOR command to display executor node information, as in the
following example:
NCP>SH0W EXECUTOR CHARACTERISTICS
Node Volatile Characteristics as of 14-JAN-1986 11:27:07

3-8

Executor node

-1.11 (BOSTON)

Identification
Management version
Incoming timer
Outgoing timer

=
=
=
=

NSP version
Maximum links
Delay factor
Delay weight
Inactivity timer
Retransmit factor

=
=
=
=
=

Routing version
Type
Routing timer
Broadcast routing timer
Maximum address
Maximum circuits
Maximum cost
Maximum hops
Maximum visits
Maximum area
Max broadcast nonrouters
Max broadcast routers
Area maximum cost
Area maximum hops
Maximum buffers
Buffer size
Default access
Pipeline quota
Default proxy access
Alias incoming
Alias maximum links
Alias Node

= V2.0.0
= routing IV
= 600
= 40
= 255
= 16

VMS HOST SYSTEM
V4.0.0
45
45

V4.0
32
80
5
60
- 10

1022

=
=
=
=
=

15
63
63
64
32

1022

= 30
=

100

= 576
= incoming and outgoing
= 1200
= incoming and outgoing
= Enabled
= 32
-1.10 (CLUSTR)

Managing and Monitoring the Network

3.3.2.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. The local DECnetVAX software translates the node names into node addresses. In the single¬
area network example, the NCP commands below perform identical functions.
NCP>SH0W NODE 5 CHARACTERISTICS

NCP>SH0W NODE TRNTO CHARACTERISTICS

To remove a remote node name from the volatile database, use the CLEAR
NODE command. The following command removes the association between
TRNTO and node 5:
NCP>CLEAR NODE 5 NAME TRNTO

To remove a remote node address from the volatile database, you must
remove all parameters for the node. You can also remove addresses for all
known nodes other than the local node, as in the following example:
NCP>CLEAR NODE TRNTO ALL

NCP>CLEAR KNOWN NODES ALL

Once all parameters for a component are removed from the volatile database,
the component is no longer recognized by the network.
Note: To change the ADDRESS or BUFFER SIZE parameter for your node, you
must first turn off the executor. Refer to Section 3.3.5.2 and Chapter 6 for
information on changing the local node's operational state.

3.3.3

Identifying Cluster Nodes
For many network operations it is convenient to be able to treat nodes within
a homogeneous VAXcluster as though they were a single node in a DECnet
network. This can be accomplished by establishing an alias node identifier for
the cluster. The alias node identifier can be specified as either a unique node
address or a corresponding node name. Any member node can elect to use
this special node identifier as an alias while retaining its own unique node
identification. Use of the cluster alias node identifier is optional.
The management of a cluster alias node involves three primary decisions:
1

Will an individual node participate in the use of a cluster alias node
identifier?

2 If a node participates, does it want to receive inbound connect requests
targeted to the cluster alias address?

3 For any object defined on a participating node, should the object's logical
links appear to have originated from the cluster alias node and should the
object be able to receive incoming connect requests that are directed to the
cluster alias address?

3-9

Managing and Monitoring the Network

To establish an alias node identifier for a local node, use the SET EXECUTOR
or DEFINE EXECUTOR command with the ALIAS NODE parameter,
described in Section 3.3.3.1. To enable incoming requests to the cluster alias
node address, use the ALIAS INCOMING parameter of the SET EXECUTOR
or DEFINE EXECUTOR command, as described in Section 3.3.3.2.
The SET OBJECT command allows you to associate specific objects with
the cluster alias node identifier, by means of the ALIAS OUTGOING
parameter. You can also use the ALIAS INCOMING parameter to permit
specific objects to receive incoming connect requests sent to the cluster alias
address. Section 3.9.1 describes how to identify DECnet-VAX objects.

3.3.3.1

Setting an Alias Node Identifier for the Executor
You establish an alias node identifier for the local node using the SET
EXECUTOR command with the ALIAS NODE parameter. When the local
node includes an alias node identifier in its database, it can be accessed by
either the cluster alias or its individual node name or node address.
The alias node identifier can be either a node address or node name. Before
a node name can be established as a cluster alias, the node name must be
defined in the database, and associated with a node address representing the
whole VAXcluster, by means of the SET NODE or DEFINE NODE command.
For example, the following command associates the node name CLUSTR with
the address 2.13:
NCP>DEFINE NODE 2.13 NAME CLUSTR

The name CLUSTR can then be established as the alias node identifier for the
local node using the following command:
NCP>DEFINE EXECUTOR ALIAS NODE CLUSTR

By issuing these commands, you establish a node (CLUSTR) whose address
is 2.13. This is the cluster alias node. Its address and name appear in the
database like those of all other nodes. From the viewpoint of any node in the
network outside the cluster, address 2.13, which is named CLUSTR, appears
to be a real DECnet node that can participate in two-way communication.
This cluster alias acts as a single node identifier that all participating nodes in
the cluster can use to communicate with other nodes in the DECnet network.

3.3.3.2

Enabling Aliases for Nodes in a Cluster
When you manage the cluster alias node, you must decide whether
participating nodes will accept incoming connect requests directed toward
the cluster alias node identifier. You indicate this decision by specifying
the ALIAS INCOMING parameter of the SET EXECUTOR or DEFINE
EXECUTOR command. The ALIAS INCOMING parameter must be either
enabled or disabled. To permit the node to accept incoming connect requests
directed to the cluster alias node identifier, specify the ENABLED option.
Otherwise, specify the DISABLED option to avoid receiving incoming connect
requests directed to the cluster alias node identifier.
The following command prevents the local node from receiving incoming
connect requests directed to the alias node identifier.
NCP>DEFINE EXECUTOR ALIAS INCOMING DISABLED

By default, the ALIAS INCOMING parameter is enabled for a node if an alias
node identifier has been defined for the node.

3-10

Managing and Monitoring the Network

3.3.4

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. You do not
normally have to specify the Ethernet address of an individual node in order
to configure your network; the software at the node sets its own Ethernet
address. You need to know the Ethernet address of a node for service
functions (such as downline load, circuit loopback test, and configurator
operations) but not for normal network operations.

3.3.4.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, byte AA is transmitted first; byte FF is
transmitted last.
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 a read¬
only memory). This address is known as the Ethernet hardware address of
the interface.
DIGITAL's interface to Ethernet (for example, the DEUNA, DELUA, or
DEQNA controller) can set a different address to be used by the interface; this
address is known as the Ethernet physical address.
On powerup of the node, the Ethernet physical address is set to the hardware
address. When DECnet starts an Ethernet line (for example, UNA-0), it
causes the DEUNA connected to that line to set its physical address to be in
the range of DIGITAL Ethernet addresses. Specifically, the DEUNA constructs
the Ethernet physical address 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.

32 bits

Constant within
Ethernet block assigned
to DIGITAL

16 bits

DECnet node
address

ZK-1215-82

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-04.
Because the DEUNA at the node constructs its own physical address, users
normally do not need to manipulate Ethernet addresses directly.
Once the Ethernet physical address has been set to its new value, it is reset to
its original hardware address value only under the following circumstances:

3-11

Managing and Monitoring the Network

•

When a reset is issued to the DEUNA (for example, when the machine
power is shut off)

•

When the state of the Ethernet line is set to 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 16-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 (see Section 2.4.2). Therefore, changing the number of an area
involves changing the Ethernet physical address of each node in that area.
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 involve modification of the
area number in the executor node address. During the conversion process
(described in Section A.4), the network is shut down, the executor node
address in the configuration database is modified to include the new area
number, and the network is turned back on. When DECnet is restarted, it
causes the DEUNA at the executor node to reset its Ethernet physical address.
However, if a non-DECnet communications application (such as a LAT
terminal server) is connected to the same Ethernet as the executor node whose
area number is being modified, the Ethernet address of the executor used by
the application cannot be changed while the interface to the application
remains allocated. Thus the application should be stopped when DECnet is
shut down and restarted after DECnet is turned back on.

3.3.4.2

Determining the Ethernet Physical Address of a Node
You can determine the Ethernet physical address of a node as follows:
•

Convert the Phase IV node address (in the format area-number.nodenumber, as described in Section 3.7.2) to its decimal equivalent, using the
conversion algorithm
(area-number * 1024) + node-number

•
•

Convert the decimal node address to its hexadecimal equivalent, reversing
the order of the bytes to form the hexadecimal node address
Incorporate the hexadecimal node address in the format
AA--00--04--00--hexnodeaddress

For example, to determine the Ethernet physical address of a node whose
node address is 63.171, calculate the following:
(63 * 1024) + 171 = 64683 decimal = FCAB hexadecimal

Therefore the Ethernet physical address of the node is
AA-00-04-00-AB-FC

You can display the Ethernet physical address of a node by specifying the
following command:
NCP>SH0W EXECUTOR STATUS

The resulting display contains the Ethernet physical address of the executor,
as shown below.
Physical address

3-12

= AA-00-04-00-AB-FC

Managing and Monitoring the Network

3.3.4.3

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 1010 and the value of the
low-order bit is 0.)
The Ethernet multicast address is a multidestination address of one or more
nodes on a given Ethernet. The least significant bit of the first byte of a
multicast address is 1. (For example, in the multicast address AB-22-22-2222-22, byte AB in binary is 1010 1011 and the value of the low-order bit is
1.) A multicast address can be either of the following:

3.3.4.4

•

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-FFFF-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-00-00-00-00-00 through
AA-00-04-FF-FF-FF. Multicast addresses assigned for use in cross-company
communications are shown below.
Value

Meaning

FF-FF-FF-FF-FF-FF

Broadcast

CF-00-00-00-00-00

Loopback assistance

DIGITAL multicast addresses assigned to be received by other DIGITAL nodes
on the same Ethernet are shown below.
Value

Meaning

AB—00—00—01-00-00

Dump/load assistance

AB—00—00—02—00—00

Remote console

AB-00-00-03-00-00

All Phase IV routers

A B—00—00—04-00—00

All Phase IV end nodes

AB—00—00—05—00—00
through
AB—00—03—FF—FF—FF

Reserved for future use

A B—00—04—00—00—00
through
AB—00—04—FF—FF—FF

For use by DIGITAL customers for their own
applications

3-13

Managing and Monitoring the Network

DECnet always sets up the DEUNA at each node to receive messages sent to
any address in the above list of DIGITAL multicast addresses. For information
on sending messages to Ethernet multicast addresses, refer to the VAX/VMS
I/O User's Reference Manual: Part II.

3.3.5

Node Parameters
To establish information used to control various aspects of the local node's
operation within the network, you must specify the SET EXECUTOR
command parameter ADDRESS, and you should specify MAXIMUM
ADDRESS, BUFFER SIZE, and TYPE (you may be able to use a default
value for the node type). In addition, you may wish to specify names, access
control information, and node counter event logging information for any or
all of the nodes. If a remote node can be loaded downline, you can specify a
number of default parameters to be used locally to perform a downline load
or upline dump operation. Table 3-1 lists all node parameters by function
and indicates whether they apply to local or remote nodes or to both.
Table 3-1

Node Parameters and Their Functions

Parameters According to Function

Local
Node

Remote
Node

X
X
X
X

Node identification
ADDRESS node-address
ALIAS NODE
IDENTIFICATION id-string
NAME node-name

Loop node identification
CIRCUIT circuit-id

Counter timing for node counter logging events
COUNTER TIMER seconds

Local node state
STATE
ON
OFF
RESTRICTED
SHUT

Access control
ACCESS
INCOMING
OUTGOING
BOTH
NONE
DEFAULT ACCESS
INCOMING
OUTGOING
BOTH
NONE

3-14

Managing and Monitoring the Network

Table 3-1 (Cont.)

Node Parameters and Their Functions

Parameters According to Function

Local
Node

Remote
Node

DEFAULT PROXY
INCOMING
OUTGOING
BOTH
NONE

NONPRIVILEGED
ACCOUNT account
PASSWORD password
USER user-id

PRIVILEGED
ACCOUNT account
PASSWORD password
USER user-id

Downline loading
CPU cpu-type
DIAGNOSTIC FILE file-spec
HARDWARE ADDRESS E-address
HOST node-id
LOAD FILE file-spec
SECONDARY LOADER file-spec
SERVICE CIRCUIT circuit-id
SERVICE DEVICE device-type
SERVICE PASSWORD hex-password
SOFTWARE IDENTIFICATION software-id
SOFTWARE TYPE type
TERTIARY LOADER file-spec

X
X
X
X
X
X
X
X
X
X
X
X

Upline dumping
DUMP ADDRESS number
DUMP COUNT number
DUMP FILE number

X
X
X

Routing initialization passwords
RECEIVE PASSWORD password
TRANSMIT PASSWORD

X
X

DDCMP circuit connection control
INBOUND node-type

Data link control
BUFFER SIZE number
MAXIMUM ADDRESS number
MAXIMUM BUFFERS number
MAXIMUM CIRCUITS number

X
X
X
X

3-15

Managing and Monitoring the Network

Table 3—1 (Cont.)

Node Parameters and Their Functions

Parameters According to Function

Local
Node

Remote
Node

Logical link control
ALIAS MAXIMUM LINKS number
DELAY FACTOR number
DELAY WEIGHT number
INACTIVITY TIMER seconds
INCOMING TIMER number
MAXIMUM LINKS number
OUTGOING TIMER seconds
PIPELINE QUOTA quota
RETRANSMIT FACTOR number
SEGMENT BUFFER SIZE

X
X
X
X
X
X
X
X
X
X

Routing control
ALIAS INCOMING option
AREA MAXIMUM COST number
AREA MAXIMUM HOPS number
BROADCAST ROUTING TIMER seconds
MAXIMUM AREA number
MAXIMUM BROADCAST NONROUTERS number
MAXIMUM BROADCAST ROUTERS number
MAXIMUM COST number
MAXIMUM HOPS number
MAXIMUM VISITS number
ROUTING TIMER seconds
TYPE node-type

X
X
X
X
X
X
X
X
X
X
X
X

Incoming X.25 call control
SUBADDRESSES range

You can specify parameters common to both the local node and remote nodes
in one of two ways: use either the SET EXECUTOR or SET NODE command
with the local node name or address to establish or modify parameters for the
local node, or use the SET NODE command to establish or modify parameters
for a remote node.
When using either the SET EXECUTOR or SET NODE command to establish
or modify parameters for the local node, be sure to avoid using, in the same
command, parameters listed only under the Local Node column and those
listed under both the Local Node and Remote Node columns in Table 3-1. If
you mix these parameters in a single command, you will receive an "invalid
grouping error" message. For example, the following commands are valid:
NCP>SET EXECUTOR ADDRESS 11
NCP>SET NODE 11 NAME BOSTON
NCP>SET NODE 15 SERVICE CIRCUIT DMC-1 _ RECEIVE PASSWORD RSXNODE

The first command specifies a node address for the local node. The second
command specifies a node name for the node whose address is 1.11, which in
this case is the local node. The third command specifies parameters for node
1.15. Note that this command contains parameters for both remote and

3-16

Managing and Monitoring the Network

adjacent nodes. The command below, however, is invalid because it mixes
parameters.
NCP>SET EXECUTOR ADDRESS 11 NAME BOSTON
'/.NCP-I-NMLRSP, listener response - Invalid parameter grouping, Address

The CLEAR NODE command clears parameters for either the local or remote
nodes. The CLEAR EXECUTOR command clears local node parameters
common to both local and remote nodes. You cannot clear the local node
parameters BUFFER SIZE and STATE from the volatile database. You
can, however, purge them from the permanent database with the PURGE
EXECUTOR command. You can use this same command to remove local
node parameters common to both local and remote nodes from the permanent
database.
Once the local node's state is set to ON, you cannot change the ADDRESS or
BUFFER SIZE parameters for the local node.

3.3.5.1

Data Link Control
Several local node parameters regulate various aspects of physical line
operation. Specify 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-VAX
communication lines. NCP provides four parameters for this purpose:
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.
For X.25 data links, the node parameters do not directly affect physical line
operation.

Setting Buffer Sizes
To specify the maximum size (in bytes) of NSP receive buffers, use the
BUFFER SIZE parameter. For example, the following command sets the size
of all receive buffers for the executor node to 576 bytes:
NCP>SET EXECUTOR BUFFER SIZE 576

This parameter also controls the maximum segment size of all NSP messages
that the local node can receive and forward. The buffer size value that you
select will be used for all lines. You cannot use the BUFFER SIZE parameter
to select individual values for individual lines. You can, however, use the
BUFFER SIZE parameter in the SET LINE command to override the BUFFER
SIZE value set in the executor for specific logical links on a line, such as a
particular Ethernet line (see Section 3.6.2.2).
The default BUFFER SIZE value is equal to the SEGMENT BUFFER SIZE if
specified; otherwise the default size is 576 bytes. At a minimum, the buffer
size must be 192 bytes. Refer to Chapter 5 and to the Network Services
Functional Specification for more information in this area.
You should consider a number of things when selecting the buffer size value.
•

These buffers require nonpaged memory pool.

•

The SYSGEN parameter LRPSIZE should be set to the executor buffer
size. In addition, the parameter LRPCOUNT should be at least as large as
the total number of all receive buffers on all lines, plus twice the number
of circuits.

3-17

Managing and Monitoring the Network

•

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.

The procedure for changing buffer sizes is described below.
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.

Changing Buffer Sizes
You can change the size of the buffers on all nodes without bringing down
the entire network by performing a two-pass conversion process involving a
second parameter, the SEGMENT BUFFER SIZE, as well as the BUFFER SIZE
parameter. The conversion process requires only that you set the local node
to the OFF state while changing the buffer size.
The maximum size of the transmit buffer is specified in the SEGMENT
BUFFER SIZE parameter. For example, the following command sets the
maximum size of a transmit buffer to 576 bytes.
NCP>SET EXECUTOR SEGMENT BUFFER SIZE 576

The maximum size of the receive buffer is specified in the BUFFER SIZE
parameter. The command below sets the maximum size of the receive buffer
to 576 bytes.
NCP>SET EXECUTOR BUFFER SIZE 576

The SEGMENT BUFFER SIZE normally has the same value as the BUFFER
SIZE, but may be set to less in order to perform the buffer size conversion
process. The default value of the SEGMENT BUFFER SIZE is equal to the
BUFFER SIZE if specified; otherwise the default size is 576 bytes.
The steps in the conversion depend on whether you are increasing or
decreasing the size of the buffers. To increase the size of the buffers, perform
the following conversion:
1

As the first step, reset the value of the BUFFER SIZE parameter at each
node to the larger size, permitting each node to receive a larger message.

2 As the second step, reset the value of the SEGMENT BUFFER SIZE
parameter at each node to the larger size, permitting each node to transmit
a larger message.
This two-step process ensures that all nodes are able to receive and forward
larger messages before any node is able to transmit a larger message.
To decrease the size of the buffers, perform the following conversion:
1

In the first pass, reset the value of the SEGMENT BUFFER SIZE parameter
at each node to the smaller size, decreasing the size message that each
node can transmit.

2 In the second pass, reset the value of the BUFFER SIZE parameter at each
node to the smaller size, decreasing the size message all nodes can receive.

3-18

Managing and Monitoring the Network

This process ensures that the size of messages that can be transmitted across
the network is decreased before the size of the buffers that receive and
forward messages is decreased.
An example of the conversion process involves increasing the size of messages
that can be transmitted and received over the network from 576 bytes to 1000
bytes. First, cause the following command to be executed at each node in the
network:
NCP>SET EXECUTOR BUFFER SIZE 1000

Then cause the following command to be executed at each node in the
network:
NCP>SET EXECUTOR SEGMENT BUFFER SIZE 1000

Each node will first be able to receive and forward 1000-byte messages, and
then will be able to transmit them.

Maximum Number of Buffers
To specify the maximum number of buffers for the transmit buffer pool, use
the MAXIMUM BUFFERS parameter. The value that you assign determines
the size of internal data structures for DECnet-VAX software. For example,
this command sets the maximum number of buffers to 20:
NCP>SET EXECUTOR MAXIMUM BUFFERS 20

If you do not specify a value for this parameter, DECnet-VAX will provide
a default value of 100. Thus you do not have to specify a value unless
you want to limit the amount of nonpaged pool used by DECnet-VAX. For
most operations, DECnet-VAX 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.

Maximum Number of Circuits
To specify the maximum number of circuits that the user can identify in
the volatile database, use the MAXIMUM CIRCUITS parameter. This value
determines the size of internal data structures for DECnet-VAX software. For
example, the following command establishes an upper limit of 3 circuits that
the local node can use:
NCP>SET EXECUTOR MAXIMUM CIRCUITS 3

The default value for this parameter is 16.
If the local node is connected to an Ethernet circuit, the value of the
MAXIMUM CIRCUITS parameter cannot be changed while the executor
and the Ethernet circuit are in the ON state.

3-19

Managing and Monitoring the Network

3.3.5.2

Operational State of the Local Node
Use the STATE parameter in conjunction with the SET EXECUTOR command
to exercise control of the operational state of the local node. There are four
states associated with this parameter:
OFF

Allows no new logical links to be created, terminates existing
links, and stops route-through traffic. The NETACP process
exits.

Allows new logical links to be created. The ON state is the
normal operational state allowing route-through traffic.

RESTRICTED

Allows no new logical links from other nodes, yet does not
inhibit route-through.

SHUT

Similar to RESTRICTED. However, once all logical links are
terminated, the local node goes to the OFF state.

Any network user with the OPER privilege may initiate or confirm a logical
link connection even though the local node is in the RESTRICTED or SHUT
state. Thus a system manager can use NCP and NML when the network is in
either of these states.
Chapter 6 discusses local node states in terms of controlling the operation of
the local node, and thus the network as a whole.
Note: You should never use the DEFINE EXECUTOR STATE OFF command for
the permanent database because this command would cause the network
to shut down immediately after being started.

3.3.6

Copying Node Databases
You can update your node database by copying current information about
remote nodes from the configuration database of any node to which you
have access. Use the COPY KNOWN NODES command to copy the volatile
or permanent node database entries from a remote node to either or both
the volatile and permanent node databases on your node. If you specify the
WITH CLEAR or WITH PURGE qualifier on the COPY command, the local
node database to which the information is to be copied is cleared or purged
before the information is copied. Only the executor node characteristics and
the name and address of the remote node are retained when the database is
cleared or purged before a copy operation.
The COPY KNOWN NODES command permits you to update your existing
node database to reflect current data on remote nodes without having to shut
down your node. If your network is large, the COPY command provides you
with a means of keeping up with frequent changes in the composition of the
network. For example, one node on an Ethernet may serve as the master,
keeping in its node database current information on all remote nodes that can
be accessed over the network. Then, as other nodes come up on the same
Ethernet, they can obtain the latest version of the node database by copying
it from the master node.
If you did not specify any remote node entries when you configured your
node, you can use the COPY command at any time to obtain the remote
node entries that indicate the nodes to which you have access. If you want
to copy the node database from a remote node which is not defined in your
volatile database, you can specify the node's address in the COPY command;
execution of the copy operation will cause the name and address of the node
to be defined in your database.

3-20

Managing and Monitoring the Network

COPY KNOWN NODES cannot be used to copy a subset of a node database.

3.3.6.1

COPY Command Parameters and Qualifiers
The COPY KNOWN NODES command causes the names and addresses
of remote nodes to be copied from a remote database to the local node
database or databases you specify. The FROM node-id parameter in the
COPY command specifies the remote node from which the node database
information is to be copied.
You can include explicit access control information in the node-id field, or
default to a proxy or DECnet account on the remote node, as appropriate.
This command copies remote node data from node BOSTON on which user
BROWN has an account with the password PASS 123:
NCP>C0PY KNOWN NODES FROM B0ST0N"BR0WN PASS123"

To indicate which node database at the remote node is to be copied, specify
the USING VOLATILE or USING PERMANENT qualifier. If you do not
specify the USING qualifier, the default value is USING VOLATILE.
You can indicate the local node database to which the information is to be
copied by specifying the TO qualifier. The local node database can be the
volatile or permanent database, or both the volatile and permanent databases.
In the following command, the volatile database at node BANGOR is to be
copied to both the volatile and permanent databases at the local node:
NCP>C0PY KNOWN NODES FROM BANGOR USING VOLATILE TO BOTH

If you do not specify the TO qualifier, the local database defaults to
VOLATILE.
To clear or purge the local database before the copy operation is performed,
specify the WITH CLEAR or WITH PURGE qualifier in the COPY command.
The WITH CLEAR qualifier is appropriate if the local database is volatile;
the WITH PURGE qualifier, if it is permanent. Specify either WITH CLEAR
or WITH PURGE if both the volatile and permanent databases are to be
cleared. (In practice, you can specify either value of the WITH qualifier to
clear or purge either or both of the local databases.) The following command
indicates that the permanent node database at the local node is to be purged
before the remote node data from node BANGOR is copied to the local
database:
NCP>C0PY KNOWN NODES FROM BANGOR USING PERMANENT _T0 PERMANENT WITH PURGE

3.3.6.2

Clearing and Purging the Local Node Database
During a copy operation, if the volatile database is to be cleared, the entries
for the executor node and any loop nodes are not cleared. If the permanent
database is to be purged, however, the entry for the executor node is purged.
Therefore, before the purge occurs, the copy operation causes the executor
node characteristics to be saved: a LIST EXECUTOR CHARACTERISTICS
command is executed and the executor characteristics are stored. After the
purge is executed, the executor characteristics are reinserted in the local node
database.
In addition, the local node must retain the name and address of the remote
node from which it is to copy the data. Before the clear or purge operation
is performed, the name and address of the remote node are saved. This
information is reinserted in the local node database after the clear or purge
operation is completed. Thus, to purge your database without purging your
executor database, use the COPY KNOWN NODES command with the WITH
PURGE qualifier.

3-21

Managing and Monitoring the Network

Note that an error will result if the executor or remote node is not defined in
the local node database.
If an error occurs during execution of the LIST EXECUTOR
CHARACTERISTICS command, the purge will be aborted. After the LIST
operation has been performed, purging will continue even if errors are
encountered.
Clearing or purging the local database as part of a copy operation is
recommended. If a clear or purge operation is not performed before the
remote node data is copied, conflicts can occur between original node entries
in the local database and node entries being copied from the remote node
database. A node must be identified uniquely, by one name and one address.
A conflict exists when the entries being copied on an existing database would
cause one node address to be associated with two node names or two node
addresses with one node name. When such a conflict occurs during the
copy operation, the original node entry is not updated and an informational
message is displayed. For example, if the local node database identified node
A with address 3.1 and node B with address 3.3, an attempt to copy an
entry that defines node A with address 3.3 would fail, and an informational
message would be issued.

3.3.6.3

Copying the Node Database from a Remote Node
Entering a COPY KNOWN NODES command causes the following steps to
be performed:
•

If you indicate that the volatile node database at the remote node is to
be copied (by specifying the USING VOLATILE qualifier in the COPY
command), a SHOW KNOWN NODES command is executed at the
remote node. If you indicate the permanent node database is to be copied
(by specifying the USING PERMANENT qualifier), a LIST KNOWN
NODES command is executed at the remote node.

•

The COPY operation extracts remote node names and addresses from data
returned by the SHOW or LIST command.

•

For each node name and address extracted, a SET or DEFINE NODE
command is executed on the appropriate local node database. If you
indicate in the COPY command that the information is to be copied to the
volatile database, the following command is executed for each entry:
SET NODE ADDRESS address NAME name

If you indicate the information goes to both local node databases, both
SET NODE and DEFINE NODE commands are executed for each remote
node entry. When the COPY operation receives the name and address of
the local node, no SET or DEFINE command is performed.
When the name and address of the remote node from which the data is being
copied is returned, the entry will indicate that it is the executor node. When
the remote node is defined in the local database, however, it will not be listed
as an executor node. Loop node names listed in the node database at the
remote node will not be defined in the local database.
Once the COPY operation has begun defining the remote nodes, it continues
trying to define the nodes despite any errors it may encounter. It will issue
informational messages for errors in individual node entries.

3-22

Managing and Monitoring the Network

3.3.6.4

Example of Copying Remote Node Data
The following example illustrates the use of the COPY command to copy
remote node entries from the permanent node database at node ROBIN to
the permanent node database at node LARK without purging the local node
database. In this example, node LARK has not defined the executor node or
remote node ROBIN in its database; therefore, informational messages are
displayed. Note that the copy operation is not performed for nodes A and C,
because of a conflict between existing and updated addresses for these nodes.
Informational messages are issued for the entries for nodes A and C. (In the
example below, only the node entries resulting from the LIST commands are
displayed.)
To determine the node entries on the permanent node database at the local
node, enter the following command, which causes the node entries to be
displayed. Note that in this example the executor is not defined.
NCP>LIST KNOWN NODES
Remote node =2.1 (C)
Remote node =2.3 (A)

You can determine the node entries in the permanent node database at
remote node ROBIN (whose address is 2.20) by specifying the command
below, which causes the node entries to be displayed. You can reach node
ROBIN by specifying its address in the NCP command, even though the node
is not listed by name in the local node database.
NCP>TELL 2.20 LIST KNOWN NODES
Executor node =2.20 (ROBIN)
Remote node =2.1 (A)
Remote node = 2.2 (B)
Remote node = 2.3 (C)

To perform the copy operation, enter the following COPY command. The
informational messages generated during the copy operation will be displayed
on your screen directly under the COPY command. Note that remote node
entries successfully copied to the local node database (such as node B) are not
displayed under the COPY command.
NCP>C0PY KNOWN NODES FROM 2.20 USING PERMANENT
7.NCP-I-NMLRSP, listener response - Unrecognized component, Node
'/.NCP-I-EXEABO, Executor characteristics not defined.
'/.NCP-I-NMLRSP, listener response - Unrecognized component, Node
'/.NCP-I-REMABO, Remote node not defined.
y.NCP-I-NMLRSP, listener response - Invalid parameter value. Address
Remote node = 2.1 (C)
NODE

2.1

NAME A

'/,NCP-I-NMLRSP, listener response - Invalid parameter value, Address
Remote node = 2.3 (A)
NODE

2.3

NAME C

To determine the final results of the copy operation, enter the LIST KNOWN
NODES command at your node to obtain the following display of node
entries.
ncp>list known nodes
Remote
Remote
Remote
Remote

node
node
node
node

2.1 (C)
2.2 (B)
2.3 (A)
2.20 (ROBIN)

3-23

Managing and Monitoring the Network

3.3.7

Node Counters
DECnet software automatically collects certain statistics for nodes in the
network. These statistics are known as node counters. Such information may
include the number of connects sent and received, the number of messages
sent and received, and the number of packets lost. This information may be
useful either alone or in conjunction with logging information to evaluate
the performance of a given node. The network counter summary in the
VAX/VMS Network Control Program Reference Manual describes the complete
list of node counters. Refer to Section 2.9 for a discussion of logging.
You can use NCP to regulate how often counters are logged and when they
are zeroed. To do so, you can use the SET EXECUTOR or the SET NODE
command with the COUNTER TIMER parameter. For example, the following
command causes a node counter logging event to take place every 600
seconds for the local node:
NCP>SET EXECUTOR COUNTER TIMER 600

The counters are then zeroed. Similarly, the following command specifies
that counters for remote node TRNTO are to be logged at the local node
every 600 seconds:
NCP>SET NODE TRNTO COUNTER TIMER 600

Note that these counters are maintained on the local node. To clear the
COUNTER TIMER parameter, use the CLEAR EXECUTOR or CLEAR NODE
command along with this parameter.
You can display node counter statistics at any time while the network is
running by using the SHOW NODE COUNTERS command.
In addition, at any point when the network software is running, you can
zero node counters for a given remote node, the local node, or for all known
nodes. Use any of the following commands to zero node counters:
NCP>ZER0 EXECUTOR COUNTERS
NCP>ZER0 NODE BOSTON COUNTERS
NCP>ZER0 KNOWN NODES COUNTERS

3.4

X.25 Protocol Module Commands
The X25-PROTOCOL module implements the X.25 level 3 protocol, which
controls the transmission of data packets. This module structures control
and user data into packets, sequences these packets for transmission, and
establishes, maintains, and clears X.25 virtual circuits. This module also
associates PSDNs, local DTE addresses, and optionally group names, with
this controlling information.
Use separate SET MODULE X25-PROTOCOL commands to specify a
network, a DTE, and a group.

3—24

Managing and Monitoring the Network

3.4.1

Network Identification
Use the NETWORK qualifier to identify a network (that connects to a PSDN).
The network name must be unique both on this database and any VAX
X25-ACCESS databases.
You must specify a profile as a parameter to the NETWORK qualifier. The
profile is a file that gives maximum, minimum and default values for PSDN
parameters. The profile also gives the facilities of the PSDN, such as FAST
SELECT.
The network profile is set up as part of the FCNS (Field Configurable
Network Software) procedure, when VAX PSI is first matched with a
particular PSDN. For further details, refer to the VAX PSI documentation
set.
The following command associates with the X25-PROTOCOL module the
network TELENET 1, which has the profile TELENET:
NCP>SET MODULE X25-PR0T0C0L NETWORK TELENET1 PROFILE TELENET

3.4.2

Local DTE Identification
Use the DTE qualifier followed by a NETWORK parameter to identify a local
DTE and the network to which it is connected. For example,
NCP>SET MODULE X25-PR0T0C0L DTE 123789456 NETWORK TELENET1

...

specifies a DTE which has the address 123789456 in network TELENET1.
If you only have one network set up, you can omit the NETWORK parameter,
because this network will be taken as the default. If you have more than one
network set up, you must specify the network to which the DTE belongs.
Refer to the VAX PSI Public Network Information Cards for DTE address
formats.

3.4.2.1

Operational State of DTE
The STATE parameter specifies one of three operational states for each DTE.
OFF

Prevents use of the DTE and clears all existing virtual circuits.

Allows normal use of the DTE.

SHUT

Prevents use of the DTE for any new activity, but allows existing virtual
circuits to complete their operation. Once all circuits have been cleared,
the DTE returns to the OFF state.

The following command allows normal use of the DTE:
NCP>SET MODULE X25-PR0T0C0L DTE 123789456 STATE ON ...

The ON and SHUT states have substates; for a complete list of states,
substates, and their transitions, refer to the VAX/VMS Network Control
Program Reference Manual. The STATE parameter is optional. If it is not
specified, the state is set to ON.

3—25

Managing and Monitoring the Network

3.4.2.2

Line Identification
The LINE parameter identifies the line associated with each DTE. Each DTE
must have a unique line. Line identification takes the following format:
dev-c[-u]

dev

Is a device name

Is a decimal number designating the device's hardware controller

Is a decimal unit or line number included if the device is a multiple unit line
controller

(Section 3.6.1 describes line identification.)
Note that the unit number is optional for a DUP, DPV, or DMF. The
command below identifies the line KMX-0-0 associated with DTE 123789456:
NCP>SET MODULE X25-PR0T0C0L DTE 123789456 NET TELENET1 LINE KMX-0-0 ...

Use the SET LINE command to specify parameters for this line.
The LINE parameter is mandatory when you specify a DTE for the first time.

3.4.2.3

Channel Identification
The CHANNELS parameter associates a set of logical channels to be used
for outgoing calls with each DTE. Outgoing calls are all calls that originate
from your DTE. Specify one or more logical channel numbers (LCNs) as a
list. Separate multiple LCNs with hyphens to indicate ranges, and commas to
indicate individual numbers. For example, the following command indicates
that 20 is the first LCN, counting down from 20 to 10, then 3, and finally 9:
NCP>SET MODULE X25-PR0T0C0L DTE 123789456 _ CHANNELS 20-10,3,9 ...

Specify a value in the range 1 to 4095 for each number in the range.
The values you specify are those supplied by the PSDN authorities at
subscription time.

3.4.2.4

Maximum Circuits
The MAXIMUM CIRCUITS parameter specifies the maximum number of
circuits that each DTE can handle. For example, the following command
specifies that the DTE 123789456 can handle a maximum of 200 circuits:
NCP>SET MODULE X25-PR0T0C0L DTE 123789456 MAXIMUM CIRCUITS 200...

The MAXIMUM CIRCUITS parameter is optional and, by default, the
maximum is 255.
When you specify a DTE for the first time, this parameter indicates the size
of the control area allocated from nonpaged pool. Thus, you cannot increase
this value while the software is running. However, you can decrease the
value and increase it again, provided that you do not specify a value larger
than the original set. If this value is larger than required, nonpaged pool will
be wasted.

3-26

Managing and Monitoring the Network

3.4.2.5

INTERFACE Parameter
The INTERFACE parameter specifies whether VAX PSI operates as a DTE,
DCE, or automatically selects the correct interface (DTE or DCE).
For example, the following command specifies that VAX PSI will operate as a
DCE:
NCP>SET MODULE X25-PR0T0C0L DTE INTERFACE DCE

This parameter is of use only with the ISO8208 network profile. See also
Section 3.4.8.

3.4.3

Data Packet Control
The transmission of data packets over an X.25 virtual circuit is determined by
the size of the packet and the window.

3.4.3.1

Packet Size
The MAXIMUM DATA parameter specifies the maximum size of packets for
all X.25 virtual circuits. The following command sets the maximum packet
size to 128 bytes:
NCP>SET MODULE X25-PR0T0C0L DTE ... MAXIMUM DATA 128 ...

The packet size must always be at least 5 bytes smaller than the maximum
size of the frame on a line (see Section 3.6.5). If the value in the PSI$_
NCB_PKTSIZE field of the network connect block (NCB) is greater than
the value specified using the MAXIMUM DATA parameter, the MAXIMUM
DATA value is used.
The DEFAULT DATA parameter specifies a default packet size for all X.25
virtual circuits. For example, the command below sets the default packet size
to 64 bytes:
NCP>SET MODULE X25-PROTOCOL DTE ... DEFAULT DATA 64 ...

The default packet size must always be less than or equal to the maximum
packet size. If the PSI$_NCB_PKTSIZE field of the NCB is not specified, the
default packet size is used. The value must be a power of 2 in the range 16
to 4096.
The MAXIMUM DATA and DEFAULT DATA parameters are optional
and take the network value by default; otherwise they must be set to the
values specified in your PSDN subscription. See the VAX PSI Public Network
Information Cards for the network values of these parameters.

3.4.3.2

Window Size
The MAXIMUM WINDOW parameter specifies the maximum window size
for all X.25 virtual circuits. The value for this parameter will be the maximum
number of packets for which outstanding acknowledgments are allowed. The
command below sets the maximum window size to 3.
NCP>SET MODULE X25-PR0T0C0L DTE ... MAXIMUM WINDOW 3 ...

If the value in the PSI$_NCB_WINSIZE field of the NCB is greater than the
value specified using the MAXIMUM WINDOW parameter, the MAXIMUM
WINDOW value is used.

3-27

Managing and Monitoring the Network

The DEFAULT WINDOW parameter specifies a default window size for
all X.25 virtual circuits. For example, the command below sets the default
window size to 2.
NCP>SET MODULE X25-PR0T0C0L DTE ... DEFAULT WINDOW 2 ...

The default window size must always be less than or equal to the maximum
window size. If the PSI$_NCB_WINSIZE field of the NCB is not specified,
the default window size is used.
Specify values in the range 1 to 7 (unless extended sequence numbering is
used on the PSDN, in which case the range is 1 to 127). The values must
agree with your PSDN subscription.
The MAXIMUM WINDOW and DEFAULT WINDOW parameters are optional
and, by default, take the network value. See the VAX PSI Public Network
Information Cards for the network values of these parameters.

3.4.4

Call Request Packet Control
Use the CALL TIMER parameter to control call setup. This timer starts to run
when a request to set up a virtual circuit is transmitted; if it expires before
a response has been received, the request will be cleared. In the command
below, the request to set up a virtual circuit is cleared if no response has been
received within 10 seconds.
NCP>SET MODULE X25-PROTOCOL DTE ... CALL TIMER 10 ...

Specify a value in the range 1 to 255.
The CALL TIMER parameter is optional and, by default, takes the network
value. See the VAX PSI Public Network Information Cards for the network
value of this parameter.

3.4.5

Clear Request Packet Control
Two parameters control transmission of clear request packets over SVCs:
CLEAR TIMER and MAXIMUM CLEARS.
Use the CLEAR TIMER parameter to control how often clear request packets
are retransmitted if not acknowledged. The following command sets the
retransmission frequency to 20 seconds:
NCP>SET MODULE X25-PR0T0C0L DTE ... CLEAR TIMER 20 ...

Specify a value in the range 1 to 255.
Use the MAXIMUM CLEARS parameter to specify the maximum number of
times a clear request packet is retransmitted over the circuit. For example,
the following command indicates that if a clear request is not acknowledged
within 20 seconds, the request is retransmitted, and that this operation is to
be performed a maximum of 8 times:
NCP>SET MODULE X25-PR0T0C0L DTE ... CLEAR TIMER 20 _ MAXIMUM CLEARS 8 ...

The circuit is assumed to be cleared if the clear request is still not
acknowledged by this time.
Specify a value in the range 1 to 255.

3-28

Managing and Monitoring the Network

The CLEAR TIMER and MAXIMUM CLEARS parameters are optional
and take the network value by default. See the VAX PSI Public Network
Information Cards for the network values of these parameters.

3.4.6

Reset Control
Two parameters control transmission of reset packets over SVCs and PVCs:
RESET TIMER and MAXIMUM RESETS.
Use the RESET TIMER parameter to control how often reset packets are
retransmitted if not acknowledged. For example, the following command sets
the retransmission frequency to 10 seconds:
NCP>SET MODULE X25-PROTOCOL DTE ... RESET TIMER 10 ...

Specify a value in the range 1 to 255.
Use the MAXIMUM RESETS parameter to specify the maximum number of
times a reset is retransmitted to the DCE. The command below indicates that
if a reset is not acknowledged within 10 seconds, the reset is retransmitted,
and that this operation is to be performed a maximum of 8 times:
NCP>SET MODULE X25-PROTOCOL DTE ... RESET TIMER 10 _ MAXIMUM RESETS 8 ...

The circuit is cleared if the reset is still not acknowledged by this time.
Specify a value in the range 1 to 255.
The RESET TIMER and MAXIMUM RESETS parameters are optional and take
the network value by default. See the VAX PSI Public Network Information
Cards for the network values of these parameters.

3.4.7

Restart Control
Two parameters control transmission of restart packets over the data link to
the DCE: RESTART TIMER and MAXIMUM RESTARTS. Use the RESTART
TIMER to control how often restart packets are retransmitted. For example,
the command below sets the retransmission frequency to 20 seconds.
NCP>SET MODULE X25-PR0T0C0L DTE ... RESTART TIMER 20 ...

Specify a value in the range 1 to 255.
Use the MAXIMUM RESTARTS parameter to specify the maximum number
of times a restart is retransmitted to the DCE. The command below specifies
that a restart is to be retransmitted every 20 seconds, and that this operation
is to be performed a maximum number of 10 times.
NCP>SET MODULE X25-PROTOCOL DTE ... RESTART TIMER 20 _ MAXIMUM RESTARTS 10 ...

Specify a value in the range 1 to 255.
The RESTART TIMER and MAXIMUM RESTARTS parameters are optional
and take the network value by default. See the VAX PSI Public Network
Information Cards for the network values of these parameters.

3-29

Managing and Monitoring the Network

3.4.8

ISO Networks
There are two parameters provided for use with an IS 8208 packet switching
network. (IS 8208 is the International Standards Organization's definition of
the CCITT X.25 recommendations.)
The two parameters are INTERFACE and INTERRUPT TIMER. INTERFACE
allows you to specify that your VAX PSI system acts in one of three ways: as
a DTE, as a DCE, or automatically as either a DTE or DCE (parameter value
NEGOTIATED). Refer to Section 3.4.2.5 for an example of specifying the
INTERFACE parameter.
INTERRUPT TIMER controls how long an interrupt may remain unconfirmed.
If the interrupt is not confirmed within this time, the circuit is reset. The
following command sets the interrupt timer to 150 seconds.
NCP>SET MODULE X25-PR0T0C0L DTE ...

3.4.9

INTERRUPT TIMER 150

Group Identification
If you are a member of either a closed user group (CUG) or bilateral closed
user group (BCUG), always identify the group with the GROUP qualifier.
Each group should have a unique name, which is a string 2 to 16 characters
long. The following commands show a series of group specifications:
NCP> SET MODULE X25-PROTOCOL GROUP ESECUG ...
NCP> SET MODULE X25-PR0T0C0L GROUP DECCUG ...
NCP> SET MODULE X25-PR0T0C0L GROUP BASINGSTOKE ...

The local DTE, the group type, and the group number should be associated
with each group.

3.4.9.1

Local DTE Identification
Use the DTE parameter to specify the address of the DTE that is associated
with the group name, and the NETWORK parameter to identify the network
to which the DTE belongs. For example:
NCP>SET MODULE X25-PR0T0C0L GROUP ESECUG DTE 123789456 NETWORK PSS1 ...

The DTE parameter is mandatory when you specify a group for the first time.
Note that once you set parameters for a group, you cannot change them
except by clearing the group and setting it up again.

3.4.9.2

Group Number
Use the NUMBER parameter to specify the number that identifies your group.
These numbers are allocated by the PSDN at subscription time. For example:
NCP>SET MODULE X25-PR0T0C0L GROUP ESECUG NUMBER 12 ...

The NUMBER parameter is mandatory when you specify a group for the first
time.

3-30

Managing and Monitoring the Network

3.4.9.3

Group Type
If you are a member of a BCUG, use the TYPE BILATERAL parameter to
specify this group type. For example:
NCP>SET MODULE X25-PROTOCOL GROUP DECCUG TYPE BILATERAL ...

If the group is a CUG, omit this parameter.

3.4.10 X.25 Protocol Module Counters
VAX PSI automatically maintains certain statistics for the X25-PROTOCOL
module in the network. These statistics are known as protocol module
counters. They may include the number of bytes, data blocks, calls, and fast
selects sent and received; the number of active channels; the number of resets
sent, received, or initiated by the network; and the number of restarts. These
statistics are useful in monitoring the activity of the component. A complete
list of protocol module counters is given in the VAX/VMS Network Control
Program Reference Manual

3.5

Circuit Commands
The four classes of circuits that DECnet-VAX supports are DDCMP, Cl,
Ethernet, and X.25 circuits. Using NCP commands, you must identify all
DECnet circuits connected to the local node and all permanent virtual circuits
connected to local DTEs, and specify parameters that affect the operation of
the circuits. This section describes circuit identification and discusses using
NCP commands to specify circuit parameters.

3.5.1

Circuit Identification
As with nodes, circuits must also have unique identifiers. DECnet circuits and
X.25 circuits are not identified in the same way.

3.5.1.1

DDCMP Circuit Identification
For VAX/VMS, DDCMP circuit identification and line identification takes one
of the following formats:
dev-c
dev-c-u
dev-c.t
dev-c-u.t

dev

Is a device name. (Refer to the VAX/VMS Network Control Program
Reference Manual for a complete list of mnemonic device names.)

Is a decimal number (0 or a positive integer) that designates the hardware
controller for the device.

Is a decimal unit or circuit number (0 or a positive integer) that is included
only if there is more than one unit associated with the controller.

Is a decimal number (0 or a positive integer) that identifies a tributary on
a multipoint circuit. This is a logical tributary number, not to be confused
with the tributary address that is used to poll the tributary.

Note: Circuit devices that are similar in operation are referred to by the same
mnemonic.

3-31

Managing and Monitoring the Network

DDCMP Point-to-Point Addressing
The following command specifies a synchronous point-to-point circuit. The
command identifies the DMC (or DMR) circuit device and controller number

0.
NCP>SET CIRCUIT DMC-0 STATE ON

The following command specifies an asynchronous point-to-point circuit. The
command identifies the DZ11 asynchronous circuit device by the mnemonic
TT, and specifies controller number 0 and unit number 0 (that is, TTAO).
NCP>SET CIRCUIT TT-0-0 STATE ON

Dynamic asynchronous DDCMP circuit names are supplied automatically
when a dynamic connection is established. Note that you must load the
asynchronous driver NODRIVER before establishing a dynamic connection.
VAX/VMS maps network management circuit names to system-specific circuit
names (for example, DMC-4 maps to XMEO). Network management circuit
names provide network-wide circuit identification independent of individual
operating system conventions.

DDCMP Multipoint Tributary Addressing
The command below identifies the DMP circuit device, controller number 0,
and logical tributary 1.
NCP>SET CIRCUIT DMP-0.1 STATE ON

Use the SET CIRCUIT command to turn on the DMP circuit device as a
multipoint tributary device.
DECnet-VAX software uses a form of circuit identification called a tributary
address to poll a tributary for a specified circuit. Use the SET CIRCUIT
command to establish the tributary address. For example, the command
below specifies an address of 5 to tributary 1 on DMP controller 0.
NCP>SET CIRCUIT DMP-0.1 TRIBUTARY 5

Values in the range of 1 to 255 are valid for this parameter. The node at the
controlling end of this multipoint circuit will use this address to poll this line.
Correspondingly, you must set the tributary address on the remote node end
of the circuit that will respond to a polling address of 5. For example:
NCP>SET CIRCUIT DMP-1.0 TRIBUTARY 5

The logical tributary number (0 in this case) is not to be confused with the
tributary address. Refer to the description of logical tributary numbers in the
circuit identification at the beginning of this section.

3.5.1.2

Cl Circuit Identification
The TRIBUTARY parameter is also used to identify the Cl node on the other
end of a Cl circuit. In the following example, the tributary address 1 identifies
the Cl node on the other end of circuit CI-<> 1:
NCP>SET CIRCUIT Cl-0.1 TRIBUTARY 1

The tributary node address is the Cl port number of the remote Cl node, not
the DECnet node address.
Note that you must load the CNDRIVER before running DECnet over a Cl
(see Section 2.2.3).

3-32

Managing and Monitoring the Network

3.5.1.3

Ethernet Circuit Identification
For VAX/VMS, Ethernet circuit identification takes the following format:
dev-c

dev

Is a device name. (The device name for an Ethernet circuit is UNA for a
VAX/VMS system and QNA for a MicroVMS system.)

Is a decimal number (0 or a positive integer) that designates the hardware
controller for the device.

For example, the command below identifies the circuit device UNA and the
controller number 2 for an Ethernet circuit:
NCP>SET CIRCUIT UNA-2 STATE ON

3.5.1.4

X.25 Circuit Identification
Use the SET CIRCUIT command to identify X.25 circuits. The text following
the X25- prefix in the command string identifies all PVCs and DLM SVCs.
The text is an alphanumeric string not more than 12 characters in length.
The entire string, including the prefix X25-, should not be longer than 16
characters. An example of this command is shown below.
NCP>SET CIRCUIT X25-ANDIES ...

Specify unique circuit identifiers for each additional X.25 circuit. For example:
NCP>SET CIRCUIT X25-PVC0NE ...
NCP>SET CIRCUIT X25-PVCTW0 ...

Note that if there is more than one network available, you must specify the
network to which the circuit belongs.

3.5.2

Circuit Parameters
The configuration database contains circuit parameters for all circuits
connected to the local node or DTE. Table 3-2 lists the types of circuits
and the circuit parameters that apply to each type. The circuit parameters
supply information used to control various aspects of a circuit's operation.
Table 3-3 lists the circuit parameters by function.
Table 3-2

Types of Circuits and Applicable Circuit Parameters

Type of Circuit

All circuits

Applicable Circuit Parameter

COUNTER TIMER seconds
STATE ( 0N
l SERVICE

Circuits other than
X.25 native PVCs

)

COST cost
HELLO TIMER seconds

3-33

Managing and Monitoring the Network

Table 3-2 (Cont.)

Types of Circuits and Applicable Circuit
Parameters

Type of Circuit

Applicable Circuit Parameter

DDCMP circuits

ACTIVE BASE base
ACTIVE INCREMENT increment
BABBLE TIMER milliseconds
DEAD THRESHOLD count
DYING BASE base
DYING INCREMENT increment
DYING THRESHOLD count
INACTIVE BASE base
INACTIVE INCREMENT increment
INACTIVE THRESHOLD count
MAXIMUM BUFFERS count
MAXIMUM TRANSMITS count
POLLING STATE polling-state
SERVICE ( ENABLED }
l DISABLED /
TRANSMIT TIMER milliseconds
TRIBUTARY tributary-address

DDCMP circuits and X.25
DLM circuits (PVCs or SVCs)

f ENABLED
VERIFICATION } DISABLED
[ INBOUND

Ethernet circuits

MAXIMUM ROUTERS number
ROUTER PRIORITY number

X.25 native PVCs

CHANNEL number
DTE dte-address
MAXIMUM DATA count
MAXIMUM WINDOW count
NETWORK network-name
TYPE X25
USAGE PERMANENT

X.25 DLM circuits

BLOCKING ( ENABLED \
l DISABLED /
CHANNEL number
DTE dte-address
NETWORK network-name
MAXIMUM DATA count
MAXIMUM RECALLS count
MAXIMUM WINDOW count
NUMBER dte-address
OWNER EXECUTOR
RECALL TIMER seconds
TYPE X25
f INCOMING
)
USAGE 1 OUTGOING
>
PERMANENT

3-34

1
\

Managing and Monitoring the Network

Table 3-3

Circuit Parameters and Their Function

Parameter Function

Parameter

Indicates owner of circuit

OWNER EXECUTOR

Identifies circuit by address

TRIBUTARY tributary-address

Assigns circuit cost for routing purposes

COST number

Sets counter timer for circuit counter event
logging

COUNTER TIMER seconds

Sets circuit's operational state

Controls DDCMP multipoint operation

ACTIVE BASE base
DYING BASE base
INACTIVE BASE base
ACTIVE INCREMENT increment
DYING INCREMENT increment
INACTIVE INCREMENT increment
DEAD THRESHOLD count
DYING THRESHOLD count
INACTIVE THRESHOLD count
BABBLE TIMER milliseconds
TRANSMIT TIMER milliseconds
MAXIMUM BUFFERS count
MAXIMUM TRANSMITS count
POLLING STATE polling-state
TRIBUTARY

Sets timer to control Routing layer

HELLO TIMER seconds

Determines whether service operations
are allowed for circuit (initiated locally or
remotely)

SERVICE ( ENABLED
l DISABLED

Controls Routing layer initialization of
adjacent node

f DISABLED
VERIFICATION } ENABLED
INBOUND

Limits number of routers permitted on
Ethernet circuit

MAXIMUM ROUTERS number

Sets priority of router on Ethernet circuit for
selection of designated router

ROUTER PRIORITY number

Associates logical channel number with X.25
PVC

CHANNEL number

Specifies the network to which the local DTE
belongs

NETWORK network-name

Associates local DTE with X.25 PVC

DTE dte-address

Assigns remote DTE address used to
establishran outgoing DLM SVC to reserve
an incoming DLM SVC

NUMBER dte-address

Defines circuit type; if circuit is not X.25,
DDCMP is assumed

TYPE X25

Controls data packet parameters for X.25
circuits

MAXIMUM DATA count
MAXIMUM WINDOW count

1
J
1
\

3—35

Managing and Monitoring the Network

Table 3-3 (Cont.)

Circuit Parameters and Their Function

Parameter Function

Parameter

Determines whether message blocking over
DLM circuits occurs

BLOCKING ( CABLED
l ENABLED

Controls retransmission of DLM outgoing
SVCs

MAXIMUM RECALLS count
RECALL TIMER seconds

1
/

Use the SET CIRCUIT command to set and modify these parameters. Use
the CLEAR CIRCUIT command to reset them to their default values (if any)
or remove them from the volatile database. The circuit must be off before
you specify the ALL parameter in the CLEAR CIRCUIT command. The
circuit must also be off if you wish to modify any parameters except COST,
COUNTER TIMER, SERVICE, STATE, and VERIFICATION.
Note that not all circuit devices support all parameters listed in the above
tables. If a particular device does not support a parameter, an error message
may be displayed. Refer to the VAX/VMS I/O User's Reference Manual: Part
II for information on specific circuit devices.

3.5.2.1

Operational State of the Circuit
Just as you can control the operational state of the local node, you can also
control the operational state of circuits connected to it. There are three circuit
states:
OFF

Allows no traffic over a circuit. The circuit is unavailable for
network activity.

Allows traffic over the circuit. This is the normal operational
state allowing for complete route-through and downline loading
operations.

SERVICE

Restricts the circuit to service operations only. Only an Ethernet
circuit will allow logical link activity or route through at the same
time as service operations. Service operations include downline
system loading, upline dumping, and loopback testing.

Use the STATE parameter to specify the operational state of a circuit. For
example, this command allows normal traffic over circuit DMC-0:
NCP>SET CIRCUIT DMC-0 STATE ON

DECnet-VAX may automatically change the state of a DDCMP circuit for
certain functions. For example, assume that you have set a DDCMP circuit
to ON. Later, someone performs a circuit-level loopback test on that circuit
without first setting the circuit state to SERVICE. Network management
software automatically turns the circuit to the appropriate internal state (or
substate) for the test. If the circuit state were displayed at that point, it would
register as ON-LOOPING. When the circuit is in this state, it is in use for
an active circuit loop test. This test is termed active because it was initiated
on the local node. The local node enters the passive loopback state (ONREFLECTING) whenever a remote node initiates a loopback test with the
local node. When the test finishes, the circuit will return to the ON state. For
a complete list of circuit states, substates, and their transitions, refer to the
VAX/VMS Network Control Program Reference Manual.

3-36

Managing and Monitoring the Network

Several circuit substates have the prefix AUTO. These substates can occur
when an adjacent node is or is about to be in an automatic downline loading
or triggering stage. For example, if circuit DMC-2 is in the ON state and the
local node (BOSTON) receives a request for a downline load on that circuit,
the network software on the local node automatically sets the circuit to the
ON-AUTOSERVICE state.
Before performing service operations over a DDCMP circuit, you must enable
that circuit. To do so, set the SERVICE parameter, which enables or disables
service operations over a circuit. For example, the command below permits
the circuit DMC-0 to be put in the SERVICE state, allowing service functions.
NCP>SET CIRCUIT DMC-0 SERVICE ENABLED

To disable a DDCMP circuit, set the SERVICE parameter to DISABLED,
which allows you to restrict the operation of a circuit for network users. The
default for the SERVICE parameter is DISABLED.

3.5.2.2

Circuit Timers
Two timers exist for controlling message transmissions and checking the
status of adjacent nodes. The first is a hello timer, which defines the
frequency of Routing layer Hello ("I'm still here") messages sent to the
adjacent node on the circuit. The second is a listen timer, which controls the
maximum amount of time allowed to elapse before the Routing layer stops
waiting for either a Hello message or a user message from the adjacent node
on the circuit. You cannot set the listen timer with an NCP command; the
value of the listen timer is always twice the value of the hello timer at the
local node.
To set the hello timer, use the command
NCP>SET CIRCUIT DMP-0 HELLO TIMER 15

This command sets a limit of 15 seconds between Hello messages from the
executor node to the adjacent node on circuit DMP-0. The listen interval will
be 30 seconds between messages from the node on circuit DMP-0 adjacent
to the executor node. For the HELLO TIMER parameter, you must specify a
value between 1 and 8191 seconds. The default value for the HELLO TIMER
parameter is 15 seconds.
The value of the HELLO TIMER parameter should be the same on all adjacent
nodes over the same circuit.
It is recommended that you accept the default value for the HELLO TIMER
parameter, particularly if your node will communicate with nodes having
versions of Network Management software earlier than Version 3.0.

3.5.3

DDCMP Circuit Parameters
DDCMP circuit parameters include parameters related to verification and to
control of tributaries.

3-37

Managing and Monitoring the Network

3.5.3.1

DDCMP Circuit Level Verification
The VERIFICATION parameter applies to DDCMP circuits and to X.25 DLM
circuits (PVCs and SVCs).
The VERIFICATION parameter controls whether or not the local node will
check the Routing layer passwords (RECEIVE PASSWORD and TRANSMIT
PASSWORD) in the database entry for the remote node before it completes a
node initialization request from that node.
To turn on verification, issue the command
NCP>SET CIRCUIT DMP-0 VERIFICATION ENABLED

This command specifies that the Routing layer will perform initialization of
the remote node connected to circuit DMP-0. To turn verification off, use the
command
NCP>SET CIRCUIT DMP-0 VERIFICATION DISABLED

DISABLED is the default, which means that you need not specify a node in
the configuration database to complete Routing layer initialization. To include
a remote node in the configuration database, you must specify the NODE
NAME and ADDRESS parameters; you can optionally specify the RECEIVE
PASSWORD and TRANSMIT PASSWORD parameters.
The following rules apply when a remote node submits a node initialization
request to the local node:
•

Nodes not defined in the remote node database at the local node will not
be able to initialize over a circuit that has verification enabled.

•

Nodes defined in the remote node database for which receive and transmit
passwords are not specified will be allowed to initialize whether or not
verification is enabled on the circuit.

•

Nodes defined in the remote node database for which receive and transmit
passwords are specified will be allowed to initialize over a circuit with
verification enabled, provided the receive password in the local database
matches the transmit password sent by the remote node.

•

Any node will be allowed to initialize over a circuit for which verification
is disabled.

The VERIFICATION INBOUND parameter applies to any DDCMP point-topoint circuit. When VERIFICATION INBOUND is specified, the remote node
submitting an initialization request to the local node must supply a transmit
password that matches the receive password for that node in the local node
database. The local node, however, will not send its initialization password
to the requesting node. The VERIFICATION INBOUND parameter provides
added security for the local node, which can verify the password of a node
requesting a connection without revealing its own password.
For example, to require that a remote node supply a password before it can
initialize on circuit DMP-0 when the local node does not supply a password,
specify the command
NCP>SET CIRCUIT DMF-0 VERIFICATION INBOUND

The VERIFICATION INBOUND parameter is supplied automatically for
a dynamic asynchronous DDCMP circuit. When a dialup node requests a
dynamic connection to the local node and the VERIFICATION INBOUND
parameter is set for the circuit, you must specify the INBOUND parameter for
the dialup node in the node database. If VERIFICATION INBOUND is not
specified, the INBOUND parameter in the dialup node entry is ignored.

3-38

Managing and Monitoring the Network

3.5.3.2

DDCMP Tributary Control
Several circuit parameters enable you to regulate and control tributaries.
Some of these parameters apply to polling, others to timers. Note that you
specify these circuit parameters on the control station, not on the tributary
itself.

Polling Over DDCMP Circuits
To control the polling state of a tributary, use the DYING THRESHOLD,
DEAD THRESHOLD, or INACTIVE THRESHOLD parameters. There are four
polling states: ACTIVE, INACTIVE, DYING, and DEAD. These parameters
determine the number of times the control station will poll the active,
inactive, or dying tributary before changing its polling state. For example,
the command below sets the polling threshold for circuit DMP-0.3.
NCP>SET CIRCUIT DMP-0.3 DYING THRESHOLD 5

The control station will attempt to poll its tributary 5 times. If it gets receive
timeouts for five consecutive polls, the control station changes the tributary's
polling state from ACTIVE or INACTIVE to DYING. Values for the DYING
THRESHOLD parameter range from 0 to 255 and the default is 2. The
following command sets the polling threshold for circuit DMP-0.1:
NCP>SET CIRCUIT DMP-0.1 INACTIVE THRESHOLD 12

The control station will attempt to poll its active tributary 12 times. If it
receives only acknowledgments, but no data responses, the control station
changes the active tributary's polling state to INACTIVE. The values for the
INACTIVE THRESHOLD parameter range from 0 to 255 and the default is 8.
You can lock a tributary into one of the four states by using the POLLING
STATE parameter. Usually, the tributary's state is allowed to vary according
to the multipoint polling algorithm. This variance occurs when this parameter
is set to AUTOMATIC. Use this parameter to lock a tributary into the
ACTIVE, INACTIVE, DYING, or DEAD state. For example, this command
locks the tributary controlled by circuit DMP-0.1 into a DEAD state:
NCP>SET CIRCUIT DMP-0.1 POLLING STATE DEAD

The base priority of a tributary is the lowest value to which that tributary can
be set after a poll. A control station polls tributaries with high priorities first.
Note that a control station will not poll tributaries with priorities below 128.
To specify the base priority for a tributary, use the ACTIVE BASE, INACTIVE
BASE, or DYING BASE parameters. After polling the tributary, the control
station resets the base priority of the active, inactive, or dying tributary to
this value. You can set a separate base value for each of the polling states, as
shown in the following example:
NCP>SET CIRCUIT DMP-1.2 ACTIVE BASE 225

After a poll, the command above resets the base priority of the tributary on
circuit DMP-1.2 to 225. The values for all BASE parameters range from 0 to
255. The defaults are ACTIVE, 255; INACTIVE, 0; and DYING, 0.
You can also increment the priority of a tributary each time the line¬
scheduling timer expires. If, for instance, the polls pass over a tributary
with a low priority, you can raise the priority of that tributary by using the
ACTIVE INCREMENT, INACTIVE INCREMENT, or DYING INCREMENT
parameters. When the scheduling timer expires on an unpolled tributary, it
increases the priority according to the value you set. You can set a separate
increment value for each polling state, as shown in the following example:
NCP>SET CIRCUIT DMP-2.2 INACTIVE INCREMENT 200

3-39

Managing and Monitoring the Network

This command adds 200 to the base priority of the tributary on circuit DMP2.2. The increment values range from 0 to 255. The defaults are ACTIVE,
0; INACTIVE, 64; and DYING, 16. Note that if you set a 0 increment on
a tributary with a base priority lower than 128, the tributary will never be
polled. Active tributaries usually have a high base priority and, therefore, do
not need a high increment value.
The MAXIMUM BUFFERS and MAXIMUM TRANSMITS parameters give
you further control over the tributary. MAXIMUM BUFFERS specifies the
maximum number of buffers that a tributary can use from the common buffer
pool. If you do not set this parameter explicitly, the default is 4. Values
for this parameter can be either integers ranging from 1 to 254 or the word
UNLIMITED. For example, this command sets an upper limit of 10 buffers
that the tributary on this circuit can use from the common buffer pool:
NCP>SET CIRCUIT DMP-0.2 MAXIMUM BUFFERS 10

The MAXIMUM TRANSMITS parameter specifies the maximum number of
data messages that the tributary can transmit in a single poll interval. Values
range from 1 to 255; the default is 4. For example, the command below
sets an upper limit of two data message transmits from the tributary on this
circuit.
NCP>SET CIRCUIT DMP-0.2 MAXIMUM TRANSMITS 2

DDCMP Tributary Circuit Timers
Two timers exist for controlling message retransmission at the DDCMP
tributary circuit level. The babble timer controls the amount of time that a
tributary or remote half-duplex station can transmit; the transmit timer sets
the amount of time to delay between data message transmissions. To specify
these timers, use these commands:
NCP>SET CIRCUIT DMP-0.1 BABBLE TIMER 8000
NCP>SET CIRCUIT DMP-0.1 TRANSMIT TIMER 4000

The first command limits transmission time to 8 seconds (8000 milliseconds)
for the circuit's tributary. Values for the BABBLE TIMER parameter range
from 1 to 65,535; the default is 6000 (6 seconds).
The second command sets a delay of 4 seconds (4000 milliseconds) between
each transmission from the tributary. Values for the TRANSMIT TIMER
parameter range from 0 to 65,535; the default is 0.

3.5.4

Ethernet Circuit Parameters
Parameters that Ethernet circuits have in common with other DECnetVAX circuits are HELLO TIMER, COST, COUNTER TIMER and STATE.
Parameters unique to Ethernet circuits are ROUTER PRIORITY and
MAXIMUM ROUTERS, which you can specify in the SET CIRCUIT
command.
If there are two or more routers on the same Ethernet, the one with the
highest numerical priority (up to a maximum value of 127) is elected the
designated router. The designated router provides message routing services
for end nodes on the Ethernet (see Section 2.4.4.1). A designated router
is selected even if there are currently no end nodes on the Ethernet. Note
that routers are not required in order to route messages over the Ethernet
on behalf of end nodes; Ethernet end nodes are capable of communicating
directly. However, routers are required to route messages off of the Ethernet
over other circuits such as DDCMP circuits.

3-40

Managing and Monitoring the Network

Use the SET CIRCUIT command to set the ROUTER PRIORITY value in the
applicable circuit database at the executor node. For example, the following
command assigns a router priority of 70 to local node ROBIN on circuit
UNA-0:
NCP>SET CIRCUIT UNA-0 ROUTER PRIORITY 70

Each node on Ethernet circuit UNA-0 is assigned a router priority value in
the range 0 through 127; the default value is 64. DECnet software compares
the router priority values of the nodes and elects the router with the highest
priority the designated router. If two or more nodes on the Ethernet have the
same highest router priority value, the node with the highest node address is
selected as designated router. To learn which router is the designated router,
issue a SHOW ACTIVE CIRCUITS CHARACTERISTICS command. The
following information will be displayed for circuit UNA-0:
Designated router
Router priority

= 1.224 (ROBIN)
= 70

The recommended limit on the number of routers on an Ethernet circuit is
10, because of the control traffic overhead (composed of routing messages
and hello messages) involved. The maximum number of routers allowed is
33. The MAXIMUM ROUTERS parameter specifies the maximum number
of routers (other than the executor node) that the Routing layer is to allow
on a particular Ethernet circuit. Use the SET CIRCUIT command to assign
the MAXIMUM ROUTERS value for an Ethernet circuit. For example, the
following command sets a maximum value of 4 to the number of routers (in
addition to the executor node) that are permitted on circuit UNA-0:
NCP>SET CIRCUIT UNA-0 MAXIMUM ROUTERS 4

The default value is 33.

3.5.5

Ethernet Configurator Module Commands
Use the Ethernet configurator module to obtain a list of all systems on an
Ethernet circuit or circuits. Each DIGITAL-supported node on an Ethernet
circuit periodically transmits a system identification message to a multicast
address to which the Ethernet configurator listens. The configurator uses
these messages to build the configuration list.
Use NCP commands to access and control the configurator module. The
configurator runs as a separate process, available to all users on the system.
Once the configurator is started, it will continue to execute, maintaining and
updating its database of information on active nodes until a user causes it to
stop listening to system identification messages.
If several users of a particular system issue SET MODULE CONFIGURATOR
commands, they will all access the same configurator module. To determine
whether the configurator module is already running, issue the following
command:
NCP>SH0W MODULE CONFIGURATOR KNOWN CIRCUITS

3-41

Managing and Monitoring the Network

3.5.5.1

Enabling Surveillance by the Ethernet Configurator
To create or modify Ethernet configurator module parameters in the
volatile database, use the SET MODULE CONFIGURATOR command.
The SURVEILLANCE ENABLED parameter in this command causes the
configurator module to begin listening to system identification messages
transmitted by all systems on the circuit or circuits specified in the command.
The configurator collects this information and constructs a list of systems and
their capabilities in the volatile database.

3.5.5.2

Obtaining a List of Systems on Ethernet Circuits
To obtain information on the current configuration of nodes on Ethernet
circuits, use the SHOW MODULE CONFIGURATOR command. This
command permits you to access the configurator volatile database, which
contains the following information for each system:
•

The Ethernet physical and hardware addresses of the system

•

The device connecting the system to the Ethernet

•

The maintenance version number of the system

•

A list of maintenance functions that can be performed by the node

•

The last time a system identification message was received from that
system

The SHOW MODULE CONFIGURATOR command causes the configurator to
display this information along with the amount of time surveillance has been
enabled on the circuit. For example, for circuit UNA-0, the command
NCP>SH0W MODULE CONFIGURATOR CIRCUIT UNA-0 STATUS

will result in the following display:
Module Configurator Volatile Status as of 22-MAR-1986 09:15:25

3-42

Circuit name
Surveillance flag
Elapsed time
Physical address
Time of last report
Maintenance version
Function list
Hardware address

= UNA-0
= enabled
= 00:32:43
= AA-00-04-00-A3-04
= 22-Mar 9:14:8
= V3.0.0
= Loop, Primary loader
= AA-00-03-00-00-07

Device type

= UNA

Circuit name
Surveillance flag
Elapsed time
Physical address
Time of last report
Maintenance version
Function list
Hardware address
Device type

= UNA-0
= enabled
= 0:32:43
= AA-00-04-00-A1-04
= 22-Mar 9:11:29
= V3.0.0
= Loop, Primary loader
= AA-00-03-00-00-57
= UNA

Managing and Monitoring the Network

3.5.5.3

Disabling Surveillance by the Ethernet Configurator
To cause the configurator to stop listening to system identification messages
on specific Ethernet circuits, use the SURVEILLANCE DISABLED parameter
of the SET MODULE CONFIGURATOR command. If you specify the
KNOWN CIRCUITS parameter in this command, the configurator no longer
listens to system identification messages being broadcast on any Ethernet
circuit known to the local node. For example, this command causes the
configurator to cease surveillance of all Ethernet circuits known to local node
ROBIN:
NCP>SET MODULE CONFIGURATOR KNOWN CIRCUITS _ SURVEILLANCE DISABLED

Once the configurator ceases surveillance of all Ethernet circuits it has been
monitoring, the list of system information is deleted.

3.5.6

X.25 Circuit Parameters
The circuit parameters described below apply to permanent virtual circuits
(PVCs) used for X.25 operations.

3.5.6.1

Parameters Common to X.25 Circuits
The TYPE X25 and USAGE parameters are common to all X.25 circuits.
Use the TYPE parameter to specify an X.25 circuit as follows:
NCP>SET CIRCUIT X25-ANDIES

...

TYPE X25 ...

Note that, by default, when the name of the circuit starts with "X25," for
example, X25-ANDIES, the circuit type is X.25. The TYPE parameter is
optional.
Use the USAGE parameter to specify that the circuit is a PVC as follows:
NCP>SET CIRCUIT X25-ANDIES ...

USAGE PERMANENT ...

USAGE PERMANENT indicates that the circuit is permanently connected to
a remote DTE and does not need to be switched dynamically. The USAGE
parameter is mandatory for PVCs and takes no default.

3.5.6.2

Permanent Virtual Circuit Parameters
When PVCs are first specified, the CHANNEL and DTE parameters are
mandatory. In addition, the NETWORK parameter is mandatory if more than
one network is set up.
The CHANNEL parameter is used to associate a logical channel number with
each PVC. This number is allocated to you by the PSDN at subscription time
and will be in the range 1 to 4095. Each PVC different from those previously
specified for outgoing calls in the SET MODULE X25-PROTOCOL command
must have a unique channel number. The command below illustrates the use
of this CHANNEL parameter.
NCP>SET CIRCUIT X25-ANDIES ... CHANNEL 3 ...

The DTE parameter is used to associate the local DTE address with each PVC.
The command below illustrates the use of the DTE parameter.
NCP>SET CIRCUIT X25-ANDIES ...

DTE 123789456 ...

The DTE address is a decimal integer of 1 to 15 digits and must have been
specified previously in a SET MODULE X25-PROTOCOL command.

3-43

Managing and Monitoring the Network

The NETWORK parameter defines the network to which the DTE connects.
For example,
NCP>SET CIRCUIT X25-ANDIES ...NETWORK TELENET1

The network must have been defined previously with a SET MODULE
X25-PROTOCOL command.

3.5.6.3

Data Packet Control
Two parameters control the transmission of data packets over the PVC:
MAXIMUM DATA and MAXIMUM WINDOW.
The MAXIMUM DATA parameter specifies the maximum size of the packet
for a particular circuit. For example, the following command sets the
maximum size of the packet to 128 bytes for the circuit ANDIES:
NCP>SET CIRCUIT X25-ANDIES ...

MAXIMUM DATA 128 ...

The maximum packet size must always be at least 5 bytes smaller than the
maximum size of the frame on a line (see Section 3.6.5.1). Specify a value
that is a power of 2 in the range 16 to 4096 bytes.
The MAXIMUM DATA parameter is optional and, by default, takes the
network value. See the VAX PSI Public Network Information Cards for the
network value of this parameter.
The MAXIMUM WINDOW parameter specifies the window size for a
particular PVC. For example, the command that follows sets the window
size to 2 for the circuit X25-ANDIES:
NCP>SET CIRCUIT X25-ANDIES ...

MAXIMUM WINDOW 2 ...

Specify a value in the range 1 to 127.
The MAXIMUM WINDOW parameter is optional and, by default, takes the
network value. See the VAX PSI Public Network Information Cards for the
network value of this parameter.
Both parameters, if specified, must be set to values that agree with your
PSDN subscription.

3.5.7

DLM Circuit Parameters
A data link mapping (DLM) circuit allows an X.25 virtual circuit to be used as
a DECnet data link in communicating with other DECnet nodes over a PSDN.
Several circuit parameters are specific to the operation of DLM circuits: the
OWNER EXECUTOR parameter, the remote DTE address and the network
name used by DECnet to establish a DLM outgoing switched virtual circuit,
the USAGE parameter for a DLM circuit, and two parameters to regulate
recalls for DLM outgoing SVCs.
Parameters that DLM circuits have in common with other X.25 circuits are
CHANNEL, DTE, MAXIMUM DATA, and MAXIMUM WINDOW. The circuit
parameter VERIFICATION applies to DLM circuits and DDCMP circuits.

3-44

Managing and Monitoring the Network

3.5.7.1 DLM Circuit Owner
The OWNER EXECUTOR parameter is used to indicate that the Routing
layer has exclusive rights to use the circuit. To specify that the circuit X25DLMOUT should be used as a DLM circuit, use the following command:
NCP>SET CIRCUIT X25-DLM0UT OWNER EXECUTOR

The OWNER EXECUTOR parameter is required for a DLM circuit.

3.5.7.2 Remote DTE Addresses
To establish an SVC with a remote DTE, DECnet software requires the
address of the remote DTE. Use the NUMBER parameter in the SET CIRCUIT
command to specify the remote DTE address for incoming or outgoing DLM
SVCs.
For outgoing calls, the Routing layer uses this address (and the subaddresses
required at the remote DTE) to call on the circuit. For example:
NCP>SET CIRCUIT X25-DLM0UT NUMBER 31191234567842

Outgoing calls on circuit X25-DLMOUT use the DTE 311912345678 and a
subaddress of 42 to establish an SVC with a remote DTE associated with this
address.
For incoming calls, the NUMBER parameter is used to force them to a
particular circuit on the basis of the remote DTE address. If a NUMBER
parameter is specified for each incoming DLM circuit at the local DTE, an
incoming call from a remote DTE will be rejected if its address does not
match the number specified for any incoming circuit. If any incoming circuit
does not have a number specified, then the circuit can handle calls from any
DTE. The NUMBER parameter can also be used with an incoming circuit to
specify additional routing parameters for a selected DTE. For example:
NCP>SET CIRCUIT X25-INC USAGE INCOMING _ NUMBER 31191234567842 COST 15

Circuit X25-INC will receive calls only from the remote DTE with the DTE
311912345678 and subaddress 42. In this example, a cost of 15 is assigned to
the DLM connection to remote DTE 311912345678 to reflect a higher routing
cost for this configuration.
Note: If there is more than one network available, you must specify to which
network the circuit belongs.

3.5.7.3 Recalls for DLM Circuits
If previous attempts to establish a DLM SVC have been unsuccessful,
DECnet-VAX attempts to recall a number. The frequency of recalls and the
maximum number of recalls DECnet attempts can be set with two parameters.
The RECALL TIMER parameter sets the interval that DECnet should wait
before attempting to place a call to establish an SVC. The MAXIMUM
RECALLS parameter specifies the maximum number of times DECnet should
attempt to place a call to establish an SVC. The command below will cause
DECnet-VAX to place a call every 10 seconds for a maximum of 10 times to
establish an SVC for circuit X25-DLMOUT.
NCP>SET CIRCUIT X25-DLM0UT RECALL TIMER 10 _ MAXIMUM RECALLS 10

3-45

Managing and Monitoring the Network

The default value for the RECALL TIMER parameter is 3 seconds. Unless
you specify a value for the MAXIMUM RECALLS parameter, DECnet-VAX
places no limit on the number of recalls attempted. If an attempt to make
an outgoing call causes the system to exceed the MAXIMUM RECALLS
parameter, the circuit is placed in the OFF state, and the following command
is required before the outgoing call can be attempted again:
NCP>SET CIRCUIT X25-DLM0UT STATE ON

3.5.7.4

DLM Circuit Usage
DLM circuits operate according to the usage you define for them in the
volatile database. DLM SVCs may be used either for outgoing or incoming
calls. The usage of DLM PVCs is PERMANENT; that is, the circuit is
permanently connected to a remote DTE, and does not need to be switched
dynamically. The USAGE parameter specifies how DLM circuits are to be
used, as in the following example:
NCP>SET CIRCUIT X25-DLM0UT USAGE OUTGOING ...

3.5.7.5

Executor Node Subaddresses
When you are configuring the network, you can define a range of
subaddresses that the DECnet Routing layer will accept as incoming DLM
calls. VAX PSI will route all incoming calls within the specified subaddress
range to the Routing layer, to be handled as DLM circuits. You are
responsible for ensuring that the subaddress specified in the outgoing DLM
NUMBER parameter (see Section 3.5.7.2) matches the range of subaddresses
on the incoming side, as specified in the EXECUTOR SUBADDRESSES
parameter of the SET EXECUTOR command.
When the Routing layer receives an incoming call from a DTE, it scans the
incoming DLM circuits to find the address of the DTE sending the call that
matches the remote DTE address specified for the circuit (in the NUMBER
parameter of the SET CIRCUIT command). If an incoming circuit does not
have the NUMBER parameter specified, that circuit is selected to accept
any incoming call that has not yet been matched to a particular circuit. If all
incoming circuits have the NUMBER parameter specified and a call is received
from a DTE whose address does not match any circuit, that call is rejected.
Use the SUBADDRESSES parameter in the SET EXECUTOR command to
specify executor subaddresses (Section 3.3 describes the SET EXECUTOR
command). For example, use the SET EXECUTOR command to modify
subaddresses in the volatile database:
NCP>SET EXECUTOR SUBADDRESSES 42

The command above indicates that the Routing layer handles only incoming
X.25 calls that specify local DTE subaddress 42. All other calls are handled by
VAX PSI. A subaddress may consist of a range. For example, the command
below indicates that the Routing layer all incoming X.25 calls that specify a
local DTE subaddress in the range of 42 to 50:
NCP>SET EXECUTOR SUBADDRESSES 42-50

When specifying a subaddress range, use an integer in the range of 0 to 9999.
Separate two subaddresses with a hyphen to indicate a range, and be sure the
second subaddress is always greater than the first.

3-46

Managing and Monitoring the Network

3.5.7.6

Setting Up a DLM Circuit
The following example illustrates how to set up a DLM circuit between
DECnet node A (DTE address 123) and DECnet node B (DTE address 456),
which are to communicate over a PSDN.
On node A, the following command is used to specify the outgoing DLM
circuit in the volatile database:
NCP>SET CIRCUIT X25-0UTG0ING TYPE X25 OWNER EXECUTOR _ USAGE OUTGOING NUMBER 4561 STATE ON

The command must specify the DTE address and subaddress of the remote
node. The value in the NUMBER parameter represents DTE 456 subaddress

1.
On node B, the following command indicates that the DECnet Routing layer
will accept all incoming calls to this node (DTE) that have a subaddress in the
range 1 to 20:
NCP>SET EXECUTOR SUBADDRESSES 1-20

Note that this command must be issued at node B before node B can accept
calls from node A.
The following command at node B is then used to specify the incoming DLM
circuit in the volatile database:
NCP>SET CIRCUIT X25-INC0MING TYPE X25 OWNER EXECUTOR _ USAGE INCOMING STATE ON

3.5.8

Circuit Counters
DECnet-VAX automatically maintains certain statistics for circuits in the
network. These statistics are known as circuit counters. For all circuits,
counter information may include the number of data packets sent, received,
and lost over the circuit; timeouts; and the amount of time since the counters
were last zeroed. For DDCMP circuits, counters are maintained for timeouts
and data and buffer errors, and for both DDCMP and Ethernet circuits, the
number of bytes and data blocks sent and received. For X.25 circuits, the
following statistics are indicated in counters: the time since the counters
were zeroed; the number of bytes, data blocks and resets sent and received;
and the number of resets initiated by the network. Information obtained
from counters may be useful either alone or in conjunction with logging
information to measure the performance and throughput for a given circuit.
See the VAX/VMS Network Control Program Reference Manual for a complete
list of circuit counters. Refer to Section 2.9 for a discussion of logging.
You can use NCP to regulate the frequency with which circuit counters are
logged and when they are zeroed. At any point while the network is running,
you can also display circuit counter statistics using the SHOW CIRCUIT
COUNTERS command.

3-47

Managing and Monitoring the Network

To set a timer whose expiration automatically causes the circuit counters to be
logged at the logging sink and then zeroed, use the SET CIRCUIT command
with the COUNTER TIMER parameter. The following command causes a
circuit counter logging event to take place every 600 seconds:
NCP>SET CIRCUIT DMC-0 COUNTER TIMER 600

To clear this parameter, use the NCP command below.
NCP>CLEAR CIRCUIT DMC-0 COUNTER TIMER

At any point when the network is running, you can zero counters for a given
circuit or for all known circuits. Use the following commands to zero circuit
counters:
NCP>ZER0 CIRCUIT DMC-0 COUNTERS
NCP>ZER0 KNOWN CIRCUITS COUNTERS

3.6

Line Commands
DECnet-VAX supports four classes of lines: DDCMP, Cl, Ethernet, and X.25.
You must use NCP commands to identify all physical lines connected to the
local node and to specify parameters that affect operation of the lines. This
section describes line identification and discusses the line parameters you can
use.

3.6.1

Line Identification
As with nodes and circuits, lines must have unique identifiers. The line and
circuit names identify a logical connection. For VAX/VMS, line identification
takes one of the following formats:
dev-c
dev-c[-u]

dev

Device name. (Refer to the VAX/VMS Network Control Program Reference
Manual for a complete list of mnemonic device names.)

Decimal number (0 or a positive integer) designating the device's hardware
controller.

Decimal unit or line number (0 or a positive integer) included if the device is
a multiple unit line controller. For all non-multiplexed lines, the unit number
is optional and, if specified, is always zero (0).

Note: Devices which are similar in operation are referred to by the same
mnemonic.
VAX/VMS maps network management line names to system-specific line
names (for example, DMC-4 maps to XME0). Network management line
names provide networkwide line identification independent of individual
operating system conventions.
The following commands illustrate line identification. The command below
specifies a synchronous DDCMP point-to-point line, identifying the DMC (or
DMR) line device and controller number 0:
NCP>SET LINE DMC-0 STATE ON

3—48

Managing and Monitoring the Network

The command below specifies an asynchronous DDCMP point-to-point line.
It identifies the DMF32 asynchronous line unit by the mnemonic TX and
specifies controller number 0 and unit number 0 (that is, TXAO).
NCP>SET LINE TX-0-0 RECEIVE BUFFERS 4 STATE ON

When you turn on an asynchronous line, it is advisable to set the number of
receive buffers to a value of 4 or more (see Section 3.6.3.1).
Note that dynamic asynchronous DDCMP line names are supplied
automatically when a dynamic connection is established.
The following command specifies the Cl line CI-0:
NCP>SET LINE CI-0 STATE ON

The command below specifies the Ethernet line UNA-0:
NCP>SET LINE UNA-0 STATE ON

The command below specifies the X.25 line DUP-0:
NCP>SET LINE DUP-0 STATE ON

For each X.25 line, specify a unique device, for example:
DMF-0
DUP-0
KMX-0-0
KMX-0-1
KMV-0

3.6.1.1

Line Protocols
As part of the process of identifying lines, you must specify the line protocol.
To ensure that the data link protocol operates properly when information is
transferred over a line, use the SET LINE command with the PROTOCOL
parameter to specify a line protocol. The protocols are as follows:
DDCMP CONTROL

Specifies the line as a multipoint control station. You
can set multiple circuits for CONTROL lines. Each circuit
must have a unique physical tributary address.

DDCMP DMC

Specifies that the line is in DMC emulator mode. DMC is
similar to DDCMP POINT protocol, except that DMC uses
an older version of DDCMP (Version 3.2). This protocol
should be set for the local line when the remote line is a
DMC.

DDCMP POINT

Specifies the line as one end of a point-to-point DDCMP
connection. You may specify only one circuit per POINT
line.

DDCMP TRIBUTARY

Specifies that the line is a multipoint tributary end of a
DDCMP multipoint group. You may specify only one
circuit per TRIBUTARY line.

ETHERNET

Specifies that the line is a multiaccess line that uses the
Ethernet protocol.

LAPB

Specifies that the line uses the X.25 level 2 protocol.
The line must be used by the X25-PROTOCOL module.

LAPBE

Specifies that the line uses the X.25 level 2 protocol
with extended sequencing. The line must be used by
the X25—PROTOCOL module.

3-49

Managing and Monitoring the Network

Note that you do not specify any protocol for a Cl line. The Cl uses its own
private protocols for communication between nodes.
If you do not specify a line protocol, the default values below apply,
according to the device specified.
Device

Protocol

DMC/DMR

DDCMP POINT

DMP/DMV

DDCMP POINT

DMF

DDCMP POINT

TT/TX

DDCMP POINT

DUP/DPV

LAPB

KMX

LAPB

KMV

LAPB

KMY

LAPB

QNA

ETHERNET

UNA

ETHERNET

None (not specified)

The SET LINE PROTOCOL examples below specify line protocols in the
configuration database at the local node and on remote nodes other than
DECnet-VAX, such as DECnet-RSX. For example, the command below
identifies line DMP-0 as a multipoint control station:
NCP>SET LINE DMP-0 PROTOCOL DDCMP CONTROL

You set this parameter in the database of the local node at the controlling end
of this line. A tributary for this line could be specified as
NCP>SET LINE DMP-1 PROTOCOL DDCMP TRIBUTARY

You set this parameter in the database of the remote node connected to the
tributary end of the control station for that line.

3.6.2

Line Parameters
The configuration database should contain line parameters for all physical
lines connected to the local node or DTE. These parameters supply
information used to control various aspects of a line's operation. Table 3-4
lists the types of lines and the line parameters applicable to them. Table 3-5
lists all line parameters by function.
Table 3-4

Types of Lines and Applicable Line Parameters

Type of Line

Applicable Line Parameter

All lines

CONTROLLER controller-mode
COUNTER TIMER seconds
STATE { 0N
l OFF /

)

3-50

All lines except Cl

PROTOCOL protocol-name

All lines except X.25 lines

BUFFER SIZE number

Managing and Monitoring the Network

Table 3-4 (Cont.)

Types of Lines and Applicable Line
Parameters

Type of Line

Applicable Line Parameter

All lines except Ethernet lines

RETRANSMIT TIMER millisecond

DDCMP lines

CLOCK clock-mode
DEAD TIMER milliseconds
DELAY TIMER milliseconds
DUPLEX duplex-mode
RECEIVE BUFFERS count
SCHEDULING TIMER milliseconds
SERVICE TIMER milliseconds
STREAM TIMER milliseconds

DMR1 1 lines

TRANSMIT PIPELINE count

Asynchronous DDCMP lines

HANGUP ( DISABLED
l ENABLED
LINE SPEED number
SWITCH option

X.25 lines

MAXIMUM BLOCK count
INTERFACE interface-code
MAXIMUM RETRANSMITS count
MAXIMUM WINDOW count
MICROCODE DUMP file-spec
NETWORK network-name
PROTOCOL LAPB or LAPBE
STATE SERVICE

Table 3-5

1
/

Line Parameters and Their Functions

Parameter Function

Parameter

Defines line protocol

PROTOCOL

r DDCMP CONTROL
DDCMP POINT
DDCMP DMC
DDCMP TRIBUTARY
ETHERNET
LAPB
, LAPBE

Sets counter timer for line counter
event logging

COUNTER TIMER seconds

Selects clock type

n nrkr / INTERNAL
CLOCK ( EXTERNAL

Sets line's operational state

f OFF

STATE

\ ON

►

\
J
)
}

l SERVICE J

Sets maximum receive buffer size
for logical links over specific line

BUFFER SIZE number

Sets number of buffers in receive
queue

RECEIVE BUFFERS number

3-51

Managing and Monitoring the Network

Table 3-5 (Cont.)

Line Parameters and Their Functions

Parameter Function
Establishes physical line control
parameters for DDCMP protocol

Parameter
°UPLE>< { HALF }
DEAD TIMER milliseconds
DELAY TIMER milliseconds
RETRANSMIT TIMER milliseconds
SCHEDULING TIMER milliseconds
SERVICE TIMER milliseconds
STREAM TIMER milliseconds

Specifies asynchronous DDCMP
line characteristics

HANGUP ( DISABLED 1
l ENABLED J
LINE SPEED number
SWITCH ( DISABLED j
l ENABLED /

Establishes line-level loopback
control for controller operation

CONTROLLER ( LOOPBACK
l NORMAL

Establishes frame control
parameters for X.25 line

MAXIMUM BLOCK count
MAXIMUM WINDOW count

Controls retransmission of frames
for X.25 line

MAXIMUM RETRANSMITS count
RETRANSMIT TIMER

Controls packet transmission over
satellite link

TRANSMIT PIPELINE count

Defines the way in which the line
is used

INTERFACE ( DTE
X DCE

j
/

\
/

Use the SET LINE command to establish and modify these parameters.
The line must be set to OFF if you wish to modify any parameters except
COUNTER TIMER, SERVICE, SERVICE TIMER, and STATE. STATE is a
required parameter for all lines that you specify in the configuration database.
Use the CLEAR LINE command to reset parameters to their default values (if
any) in the volatile database. The line must be off before you specify the ALL
parameter in the CLEAR LINE command.
Note that not all circuit devices support all parameters listed in the above
tables. If a particular device does not support a parameter, an error message
may be displayed. Refer to the VAX/VMS I/O User's Reference Manual: Part
II for information on specific circuit devices.

3.6.2.1

Operational State of Lines
As with local node and circuit states, you can control the operational state of
lines connected to the local node or to the local DTE. There are three possible
line states:
OFF

Allows no traffic over a line. The line is unavailable for network
activity.

Allows traffic over the line. The ON state is the normal operational
state, which allows complete route-through and downline loading
operations.

SERVICE

Allows only restricted line service over the line. This traffic includes
loopback testing. (Used only for X.25 lines.)

The ON and SERVICE states have substates; see the VAX/VMS Network
Control Program Reference Manual for a complete list of line states, substates,
and their transitions.

3-52

Managing and Monitoring the Network

Use the STATE parameter to specify the operational state of a line. For
example, to allow normal traffic over line DMC-0, use the following
command:
NCP>SET LINE DMC-0 STATE ON

The command below specifies the operational state of an X.25 line, allowing
normal traffic over the DUP-0:
NCP>SET LINE DUP-0 STATE ON

The STATE parameter is optional and, by default, is set to OFF.

3.6.2.2

Buffer Size
You can increase the maximum size of receive buffers (and therefore the
size of NSP messages) that can be transmitted over a particular line by
specifying the BUFFER SIZE parameter in the SET LINE command. For
certain logical links established over the line to adjacent nodes, this BUFFER
SIZE value overrides the executor node BUFFER SIZE limit specified in the
SET EXECUTOR command (see Section 3.3.5.1).
If you specify the BUFFER SIZE parameter for a line, the adjacent node on
any new logical link initiated over that line can optionally accept an NSP
message segment size that is based on the BUFFER SIZE value. If the remote
node accepts the segment size, the logical link to that node is then tied to
that circuit. If the circuit fails, the logical link does not automatically route
the packet through an alternate circuit; that is, the logical link becomes
nonadaptive.
For example, the following command sets the maximum size of receive
buffers for line UNA-0 to 1400 bytes, but only for logical links to adjacent
nodes that accept 1400 bytes as the NSP segment size.
NCP>SET LINE UNA-0 BUFFER SIZE 1400

If the adjacent node does not accept a segment size based on the BUFFER
SIZE value, the default for any line except an Ethernet line is the executor
node's BUFFER SIZE value. The default for an Ethernet line is 1498 bytes.
This feature can be used to maximize performance over high-speed links,
such as Ethernet, by using a large value for the BUFFER SIZE parameter and
causing all logical links between adjacent nodes on the Ethernet to use that
larger message size.

3.6.3

DDCMP Line Parameters
Several parameters regulate various aspects of a DDCMP line's physical
protocol operation. You can specify the number of receive buffers, the duplex
mode, and the timers for both normal and service operations.
Parameters that apply specifically to asynchronous DDCMP lines indicate
the speed of the line, whether modem signals are dropped when a line is
shut down, and whether an asynchronous line is switched back to a terminal
line when disconnected from the network. For a dynamic asynchronous line,
DYNSWITCH supplies these parameters to NETACP automatically.
DDCMP line parameters are described below.

3-53

Managing and Monitoring the Network

3.6.3.1 Line Buffers
To allocate buffers for data reception by the device driver for a particular
DDCMP line, use the RECEIVE BUFFERS parameter. The following
command sets four buffers for this line:
NCP>SET LINE DMC-1 RECEIVE BUFFERS 4

Values for this parameter range from 1 to 32. The number of buffers you
set will depend 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.
For LAPB lines, see the description of X.25 line parameters in Section 3.6.5.

3.6.3.2

Duplex Mode
To set the duplex mode for a DDCMP line, use the DUPLEX parameter.
For example, the following command sets the mode of the DMC11 device
controller to full duplex for line DMC-1:
NCP>SET LINE DMC-1 DUPLEX FULL

Generally, you use full-duplex mode for local lines and permanently wired
telephone lines; you usually use half-duplex mode for dialup remote
telephone lines used with half-duplex synchronous modems. If you use a
modem, consult the manufacturer's documentation for full- or half-duplex
characteristics.

3.6.3.3

Line Timers
Line timers control the frequency of message retransmission at the DDCMP
level. There are six line timers.
•

Service timer. The service timer sets the maximum amount of time
allowed to elapse before a retransmission is necessary when service
operations are under way.

•

Retransmit timer. The retransmission timer sets the maximum amount of
time allowed to elapse before a retransmission is necessary on a multipoint
line. This is the amount of time a control station will wait for a tributary
to respond. For a DMF32 tributary, it is the maximum amount of time the
tributary will hold the line before returning control to the control station.
For an X.25 line, it is the maximum amount of time before a frame is
retransmitted (see Section 3.6.5.1).

•

Dead timer. The dead timer sets the amount of time between polls of the
dead tributaries.

•

Delay timer. The delay timer sets the amount of time to delay between
polls of active tributaries.

•

Scheduling timer. The scheduling timer sets the time limit between
recalculations of tributary polling priorities.

•

Stream timer. The stream timer sets the amount of time that a tributary or
half-duplex remote station is allowed to hold the line.

The DMP11 automatically handles message retransmission for normal
operations. However, when a DDCMP circuit is in the SERVICE state, a
line retransmission timer is necessary because the DMP11 does not handle
retransmission in maintenance operation protocol (MOP) mode.

3—54

Managing and Monitoring the Network

You can determine the optimum value to use for the retransmit timer for a
synchronous DDCMP line. The formula involves a constant obtained from
the calculation of the time required for transmission and reception of the
contents of a single executor buffer over the line. To derive the constant,
multiply the executor buffer size (in bytes) by 8 bits/byte, divide the result
by the line speed (in bits per second), and multiply by 2 (for transmission
and reception). To this result, add a factor representing the time allotted for
transmission delay and processing overhead (for DDCMP lines, a factor of
1/2 is used). Convert the final value to milliseconds by multiplying by 1000
ms/sec. When the constants are multiplied out, the remaining constant is
20,000, which applies to the following retransmit timer calculation.
In general, use this formula to calculate the best value for the retransmit timer
(in milliseconds):
RETRANSMIT TIMER = (20000 * buffer-size * number-of-buffers)/bps-of-line

The number of buffers is the value specified for the MAXIMUM TRANSMITS
parameter in the SET CIRCUIT command; it represents the maximum number
of data messages that the tributary can transmit in a single poll interval (see
Section 3.5.3.2).
Assume an example with an executor buffer size of 576, a line of 56K bits per
second (bps), and four buffers per selection interval. The formula would be
calculated as shown below.
RETRANSMIT TIMER = (20000 * 576 * 4)/56000 * 820 milliseconds

To set a retransmit timer for a DDCMP line, use the RETRANSMIT TIMER
parameter, as shown below.
NCP>SET LINE DMP-2 RETRANSMIT TIMER 820

This command sets the retransmission frequency for line DMP-2 to 820
milliseconds. If a message is not acknowledged in 820 milliseconds, it will be
retransmitted.
The above formula does not apply to the DMF32 tributary mode. The value
of the retransmit timer is the maximum time the tributary will hold the
line before returning control to the control station. For DMF32 tributary
mode, therefore, the more active the tributary, the higher the value to which
you should set the retransmit timer (a value of 2000 is recommended). For
inactive tributaries, set the timer value lower (a value of 500 milliseconds is
recommended).

3.6.3.4

Satellite Transmission Control
For a connection over a very long path, such as a satellite link, use the
TRANSMIT PIPELINE parameter to establish the maximum number of
DDCMP messages that may be transmitted over a DMR11 line without
waiting for a positive acknowledgment from the remote node. This parameter
is useful for satellite transmissions because of the long round-trip delay
between message transmission and acknowledgment. For example, the
following command sets a maximum of 10 DDCMP messages for the line
DMC-2:
NCP>SET LINE DMC-2 ... TRAMSMIT PIPELINE 10

The TRANSMIT PIPELINE parameter is optional and, by default, takes the
value 7.

3-55

Managing and Monitoring the Network

Because of the system memory overhead involved, you should avoid
arbitrarily setting this value higher than necessary. The optimum value
for the TRANSMIT PIPELINE parameter for the DMR11 is equal to the
number of DDCMP messages that can be transmitted before the first message
in the sequence is acknowledged. You can calculate the optimum TRANSMIT
PIPELINE value using the algorithm
messages = (delay*rate)/(size*8)

delay

The link's round trip delay time in seconds, which is the total
time required for a message to reach the remote receiver and
for the acknowledgment to be received by the transmitter.
You can determine the delay value from information supplied
by the carrier providing the leased circuit, or by observing
the delay on suitable line monitoring equipment.

rate

The line speed in bits per second.

size

The average DDCMP message size in bytes, which can be
calculated by dividing the number of bytes transmitted by
the number of messages transmitted. Use the SHOW LINE
command with the COUNTERS parameter to determine the
number of bytes and messages transmitted. Line counters
are described in Section 3.6.6.

For example, to determine the optimum TRANSMIT PIPELINE value of a
satellite link that has a round trip delay of 0.67 seconds, a line speed of 9.6K
bits per second, and an average DDCMP message size of 40 bytes, calculate
the following:
(0.67*9600)/(40*8) = 20

Therefore, for this example, the optimum value for TRANSMIT PIPELINE is
20 messages.
3.6.3.5

Asynchronous DDCMP Line Parameters
The LINE SPEED, HANGUP, and SWITCH parameters apply only to
asynchronous DDCMP lines. Values for these parameters are provided
automatically when a line is switched dynamically from a terminal line to
an asynchronous DDCMP line. When you initiate a dynamic connection
between two nodes over a telephone line, these parameters are included
in the line entries NETACP supplies to the NCP database. For static
asynchronous DDCMP lines, these parameters usually assume their default
values.
The LINE SPEED parameter specifies in baud the speed of an asynchronous
DDCMP line. The parameter defaults to the current speed of the line. If two
asynchronous lines are connected, both lines must have the same line speed.
If a dynamic connection is made, this value is supplied automatically for each
line. For a static asynchronous line, the default line speed value is the value
of the /SPEED qualifier in the DCL command SET TERMINAL you specified
to cause the terminal line to be converted to an asynchronous line.
The HANGUP parameter determines whether the modem signal is dropped
when the line is shut down. When you shut down a dynamically switched
asynchronous line, the modem carrier will be dropped if the value of the
parameter is HANGUP ENABLED. This value, supplied automatically,
corresponds to the /HANGUP qualifier in the SET TERMINAL command
you specified to cause the terminal line to be switched to an asynchronous
line. If the value supplied for the parameter is HANGUP DISABLED, the
modem signal will not be dropped when the line is shut down. For a static
asynchronous line, the parameter defaults to HANGUP ENABLED.

3-56

Managing and Monitoring the Network

The SWITCH parameter indicates whether an asynchronous DDCMP line
is to be switched back to a terminal line after it is disconnected from the
network (when the channel to the network is deassigned). The SWITCH
parameter is enabled automatically for a dynamic asynchronous line so
that the line can be switched back to a terminal line when the dynamic
connection is broken. The parameter defaults to SWITCH DISABLED for a
static asynchronous line, which remains available as a communications line
even when not assigned a channel to the network. Generally, the user does
not need to set the SWITCH parameter manually.

3.6.4

Ethernet Line Parameters
Ethernet lines do not support any service functions. Parameters the Ethernet
lines have in common with other DECnet lines are the COUNTER TIMER,
PROTOCOL, STATE, and BUFFER SIZE parameters. The BUFFER SIZE
parameter can be used to optimize performance over a high-speed data link
such as an Ethernet (see Section 3.6.2.2).
The Ethernet address associated with the Ethernet line device hardware is
displayed as a read-only parameter, HARDWARE ADDRESS, in response to
the SHOW LINE command. The command
NCP>SHOW LINE UNA-0 CHARACTERISTICS

will result in the following information being displayed for UNA-0:
Protocol
Hardware address

=
=

Ethernet
AA-00-03-00-00-0C

See the discussion of Ethernet physical addresses in Section 2.1.1, and the
general description of the format of Ethernet addresses in Section 3.3.4.

3.6.5

X.25 Line Parameters
All X.25 lines must specify the LAPB or LAPBE protocol. The line parameters
unique to X.25 lines include the MAXIMUM RETRANSMITS, MAXIMUM
BLOCK, and MAXIMUM WINDOW parameters.

3.6.5.1

Frame Control for X.25 Lines
The MAXIMUM BLOCK and MAXIMUM RETRANSMIT parameters control
the size and transmission of frames over an X.25 line; the RETRANSMIT
TIMER and MAXIMUM RETRANSMIT parameters control the retransmission
of frames. The MAXIMUM WINDOW parameter controls the number of
frames for which outstanding acknowledgments are allowed.
Use the RETRANSMIT TIMER parameter to control the frequency of frame
retransmission at X.25 level 2 on LAPB and LAPBE lines. For example, the
command below sets the retransmission frequency to 2000 milliseconds for
the line DUP-0:
NCP>SET LINE DUP-0 ...

RETRANSMIT TIMER 2000 ...

In other words, if a frame is not acknowledged in 2000 milliseconds, it is
retransmitted.
The value for this parameter depends on the size of the frame and the speed
of the X.25 line; refer to the VAX PS1 Public Network Information Cards for
recommended values. Specify a value in the range 1 to 65,535.

3-57

Managing and Monitoring the Network

The RETRANSMIT TIMER parameter is optional and, by default, takes the
network value. Refer to the VAX PSI Public Network Information Cards for the
network value of this parameter.
To specify the maximum number of times a frame is retransmitted over
a specified X.25 line, use the MAXIMUM RETRANSMITS parameter.
For example, the following command indicates that if a frame is not
acknowledged in 2000 milliseconds it is retransmitted and that this operation
is to be performed a maximum of 10 times:
NCP>SET LINE DUP-0 ... RETRANSMIT TIMER 2000 _ MAXIMUM RETRANSMITS 10 ...

Specify a value in the range 1 to 255.
The MAXIMUM RETRANSMITS parameter is optional and, by default, takes
the network value. Refer to the VAX PSI Public Network Information Cards for
the network value of this parameter.
To specify the maximum size of the frame for a particular X.25 line, use the
MAXIMUM BLOCK parameter. For example, the following command sets the
size of the frame to 133 bytes for the line DUP-0:
NCP>SET LINE DUP-0 ...

MAXIMUM BLOCK 133 ...

Produce a limit for the frame size as follows:
1

Calculate the maximum packet size and add five bytes.

2 If you subscribe to the LABPE protocol, add one byte to this total.
3 If you subscribe to extended sequence numbering at level 3, add another
byte to the total.
4

If you subscribe to the fast select facility and the current total is less than
213 bytes, replace the current total with 213 bytes.

The maximum frame size you specify should be greater than the total you
have calculated and less than or equal to 4103 bytes.
Note that some communications devices limit the frame size. This may cause
errors, even if you follow the preceding rules. For more details refer to the
VAX PSI documentation set.
The MAXIMUM BLOCK parameter is optional and, by default, takes the
network value. Refer to the VAX PSI Public Network Information Cards for the
network value of this parameter.
To specify the maximum number of frames for which there are outstanding
acknowledgments for a particular X.25 line, use the MAXIMUM WINDOW
parameter. For example, the command below sets the maximum to 2 for the
line DUP-0:
NCP>SET LINE DUP-0 ...

MAXIMUM WINDOW 2 ...

The MAXIMUM WINDOW parameter is optional and, by default, takes the
network value. Refer to the VAX PSI Public Network Information Cards for the
network value of this parameter.

3-58

Managing and Monitoring the Network

3.6.5.2 Receive Buffers for X.25 Lines
Optionally specify the number of buffers in the receive queue of any X.25
lines. Use the RECEIVE BUFFERS parameter, for example:
NCP>SET LINE DUP-0 ...

RECEIVE BUFFERS 4 ...

Specify a value in the range 2 to 32. By default, the number of buffers is 3.
This value is normally adequate for DUP, DPV, and DMF lines. For KMX,
KMY, and KMV lines, a value of 8 is recommended.
3.6.5.3 Interface of X.25 Lines
The INTERFACE parameter specifies whether the line will operate as a DTE
or as a DTE. It can take the values DTE or DCE. For example:
NCP>SET LINE DUP-0 ...

INTERFACE DCE

DTE is the default.
Note that you can only use the DCE interface in conjunction with the
ISO8208 network profile.
3.6.5.4

Network for X.25 Lines
The NETWORK parameter specifies the network to which the line will
connect. For example:
NCP>SET LINE DUP-0 ... NETWORK TELENET1

If more than one network is available, this parameter is mandatory.

3.6.6

Line Counters
DECnet software automatically maintains statistics for certain lines in the
network. These statistics are known as line counters. Line counters for
DDCMP lines include the number of bytes and data blocks sent and received;
local and remote process errors; and the amount of time since the counters
were last zeroed. DECnet-VAX currently maintains these counters only
for DMP11 and DMF32 lines. Line counters for Ethernet lines include the
number of bytes, multicast bytes, data blocks, and multicast blocks sent
and received; the number of blocks deferred or sent after collision; and the
number of send failures and discarded frames. This counter information
may be useful alone or in conjunction with logging information to measure
the performance and throughput for a given line. Refer to Section 2.9 for a
discussion of logging.
VAX PSI automatically maintains statistics for X.25 lines in the network.
These statistics are also called line counters, but are used for X.25 lines only.
Such information may include bytes and data blocks sent and received;
inbound and outbound data errors; and remote and local reply timeouts,
buffer errors, and process errors. These counters, together with component
characteristics, are useful in monitoring the activity of X.25 lines. The
counters may, for example, be employed to measure the performance and
throughput of a given X.25 line.
You can use NCP to affect the frequency with which counters are logged
and when the counters are zeroed. At any point while the network is
running, you can also display line counter statistics using the SHOW LINE
COUNTERS command.

3-59

Managing and Monitoring the Network

To set a timer whose expiration automatically causes the line counters to
be logged at the logging sink (location) and then zeroed, use the SET LINE
command with the COUNTER TIMER parameter. The command below
causes a line counter logging event to take place every 600 seconds.
NCP>SET LINE DMC-0 COUNTER TIMER 600

To clear this parameter, use the NCP command
NCP>CLEAR LINE DMC-0 COUNTER TIMER

At any point when the network is running, you can zero line counters for a
given line or for all known lines. Use the following commands to zero line
counters:
NCP>ZER0 LINE DMC-0 COUNTERS
NCP>ZER0 KNOWN LINES COUNTER

3.7

Routing Commands
As network or system manager, you can use certain NCP command
parameters to specify how the network is to be configured into routing and
nonrouting nodes and into areas. Other NCP parameters indirectly control
the path data takes through the network, and control the timing of routing
messages; these parameters have reasonable default values for most networks.
If the network is very large, it may be helpful to have a network manager,
rather than individual system managers, be responsible for controlling the
flow of data through the network.

3.7.1

Specifying the Node Type
The type of node is specified in the TYPE parameter of the DEFINE
EXECUTOR command. DECnet-VAX supports three values for the node¬
type: NONROUTING IV, ROUTING IV, and AREA. The type of a Phase
IV end node is NONROUTING IV, the type of a Phase IV level 1 router
is ROUTING IV, and the type of a Phase IV level 2 router is AREA. For
example, to designate the executor as a Phase IV nonrouting node (end node),
specify
NCP>DEFINE EXECUTOR TYPE NONROUTING IV

To specify the executor as a level 2 router in an area network configuration,
enter
NCP>DEFINE EXECUTOR TYPE AREA

The default value for node-type depends on the particular type of DECnetVAX license key installed (see Section 2.4.1.1). If the key is for a full function
license (supporting routers and end nodes), the default value of the TYPE
parameter is ROUTING IV; if the key is for an end node license, the default
(and only value possible) is NONROUTING IV.
Note that you cannot change the executor node type while DECnet is
running. You must shut down the network, use the DEFINE command to
change the executor node type, and then restart the network.
The SHOW EXECUTOR CHARACTERISTICS command displays the node
type of the executor node. The SHOW NODE STATUS command displays
the node type of a specified adjacent node. The possible values of node-type
are area, routing IV, nonrouting IV, routing III, nonrouting III, or phase II. A
Phase IV node can be a level 2 router (area), a level 1 router (routing IV), or

3-60

Managing and Monitoring the Network

an end node (nonrouting IV). A Phase III node can be either a router (routing
III) or an end node (nonrouting III).

3.7.2

Specifying the Area Number in a Node Address
To configure a network for area routing, assign each node to a specific area
which has a unique number. The area number is a decimal number, in the
range 1 through 63, which appears as a prefix on the decimal node number of
the individual node. The node number must be unique within the area. The
maximum value for node number is 1032. The area number and the node
number are separated by a period. The format of a node address in an area
network is
area-number.node-number

For example, node 300 in area 40 has an node address of 40.300.
To set the node address for the local node in an area configuration, use the
SET EXECUTOR command with the ADDRESS parameter, as below.
NCP>SET EXECUTOR ADDRESS 40.300

Configuration of a network requires that each node be assigned a node
address containing an appropriate area number. If you do not specify an area
number in a node address, the executor area number is used.
A Phase IV node address can be converted to a decimal equivalent for use
in DCL commands, such as COPY, and in sending messages using the Mail
Utility. The algorithm to convert the address to its decimal equivalent is
(area-number * 1024) + node-number

The address can also be converted to its hexadecimal equivalent for
incorporation in the Ethernet physical address of the node (see Section 3.3.4).
It is generally more convenient to refer to a node by name.

3.7.3

Setting Routing Configuration Limits
During configuration of the network, you can establish certain limits related
to routing over the network. You can limit the number of routers allowed
on a single Ethernet and the number of routing and end nodes permitted on
all Ethernet circuits to which the local node is attached. If the network is
grouped into areas, you can limit the number of areas allowed.

3.7.3.1

Maximum Number of Ethernet Routers and End Nodes Allowed
Certain NCP command parameters limit the number of routers and end
nodes that can be configured on Ethernet circuits. Use the SET CIRCUIT
command with the MAXIMUM ROUTERS parameter to set the maximum
number of routers permitted on a particular Ethernet circuit. The largest
number of routers allowed on an Ethernet is 33, which is the default value
of the MAXIMUM ROUTERS parameter. Note that the recommended limit
on the number of routers on a single Ethernet circuit is 10, because of the
control traffic overhead (routing messages and system identification messages)
involved. For example, the following command specifies that no more than
five routers can exist on Ethernet circuit UNA-0.
NCP>SET CIRCUIT UNA-0 MAXIMUM ROUTERS 5

3-61

Managing and Monitoring the Network

Use the SET EXECUTOR command with the MAXIMUM BROADCAST
ROUTERS parameter to specify the maximum number of routing nodes that
will be permitted on all Ethernet circuits to which the local node is attached.
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). For example, the following
command specifies that a maximum of 12 routers is allowed on Ethernet
circuits to which the executor node is connected:
NCP>SET EXECUTOR MAXIMUM BROADCAST ROUTERS 12

The default value of this parameter is 32.
Use the SET EXECUTOR command with the MAXIMUM BROADCAST
NONROUTERS parameter to set the maximum number of nonrouting nodes
(end nodes) permitted on all Ethernet circuits to which the local node is
attached. For example, the following command specifies that no more than
20 end nodes can exist on all Ethernet circuits to which the executor node is
connected.
NCP>SET EXECUTOR MAXIMUM BROADCAST NONROUTERS 20

The default value is 64.
3.7.3.2

Maximum Number of Areas Allowed
When configuring an area network, use the SET EXECUTOR command with
the MAXIMUM AREA parameter if you want to set a limit on the number of
areas that the executor node's Routing layer will recognize. For example, if
you want a maximum of 50 areas to be recognized, specify the command
NCP>SET EXECUTOR MAXIMUM AREA 50

If this parameter is not specified, the Routing layer will recognize up to 63
areas.

3.7.4

Routing Control Parameters
NCP supports routing parameters that provide for circuit cost control (COST),
control of the total path between any two nodes (MAXIMUM COST,
MAXIMUM HOPS), and route-through control (MAXIMUM VISITS). For
a network divided into areas, the routing parameters for maximum cost
and length of the paths between areas in the network (AREA MAXIMUM
COST, AREA MAXIMUM HOPS) also apply. These parameters are used to
control the path that data is likely to take when being transmitted through
the network, and to minimize congestion at particular nodes in the network.
For most networks, the default values of these parameters are reasonable.
3.7.4.1

Circuit Cost Control Parameter
Figure 3-2 illustrates sample circuit costs attributed to the network example.
The following paragraphs discuss routing control parameters as they relate to
Figure 3-2.
The COST parameter in the SET CIRCUIT command specifies the circuit cost.
For example, the following command sets a cost for the circuit connecting
node BOSTON to node NYC:
NCP>SET CIRCUIT DMC-2 COST 1

This command sets a low cost for the circuit. Numbers in the range of 1 to 25
are valid circuit costs. The default value is 10.

3-62

Managing and Monitoring the Network

Figure 3-2

Network Circuit Costs
BANGOR

BOSTON

DENVER

NYC
ZK-1866-84

It is recommended that you establish a circuit cost standard that is uniform
across the entire network. The following algorithm is used to determine
appropriate circuit costs. The algorithm is based on circuit delay. Delay is
based on circuit bandwidth.
1

where the bandwidth is greater than 100K bits per second

where x is approximately equal to 100,000 divided by the bandwidth, and
where the bandwidth is greater than 4K bits per second but less than 100K
bits per second

where the bandwidth is less than 4K bits per second or the circuit is an
X.25 circuit

3-63

Managing and Monitoring the Network

3.7.4.2

Maximum Path Control Parameters
Both the maximum cost for all circuits to the destination node (MAXIMUM
COST) and the maximum hops that a packet can make when routed to the
destination node (MAXIMUM HOPS) are set using the SET EXECUTOR
command. These parameters are used to ascertain whether a destination is
reachable. The value of the MAXIMUM HOPS parameter should always be
equal to or greater than the longest possible path within the network. For
the network example, a maximum hop parameter value of 6 is sufficient.
The maximum cost and hops values should be chosen carefully, with regard
to the intended use of the network, the actual network configuration, and
possible failures. The default values of these parameters are reasonable for
most networks.
The following example indicates the use of the SET EXECUTOR command to
specify the maximum cost and hops allowed for network routing.
NCP>SET EXECUTOR MAXIMUM COST 100 MAXIMUM HOPS 6

Values in the range 1 to 1022 are valid for the MAXIMUM COST parameter;
the default value is 1022. Values in the range 1 to 30 are valid for the
MAXIMUM HOPS parameter; the default value is 30. The value for the
MAXIMUM HOPS parameter must be less than or equal to the value for
MAXIMUM VISITS. Use as small a number as possible in these ranges.
Figure 3-2 illustrates the relationship between circuit costs and path costs.
To send a packet from TRNTO to DALLAS, the system can route it over
one of two paths, both of which require two hops; the first path is through
BOSTON, the second through DENVER. However, because the path through
BOSTON has a cost of 8 and the path through DENVER has a cost of 5, the
system will route the packet through DENVER.
Under normal conditions, a MAXIMUM HOPS value of 3 would be sufficient
for the network in Figure 3-2. However, if the MAXIMUM HOPS value
were set to 3, a failure of the TRNTO-BOSTON circuit would render TRNTO
unreachable from NYC, KANSAS, or BANGOR, even though a physical
path still exists (the four-hop path NYC-BOSTON-DALLAS-DENVERTRNTO). Consideration of possible failures is also important in establishing
the MAXIMUM COST parameter.
3.7.4.3

Route-Through Control Parameter
The MAXIMUM VISITS parameter in the SET EXECUTOR command specifies
the maximum number of nodes a packet can be routed through before
arriving at the destination node. For example, the following command sets
the number of visits to 12:
NCP>SET EXECUTOR MAXIMUM VISITS 12

If the number of nodes that the data packet visits exceeds the value of
MAXIMUM VISITS, the packet is discarded. Generally, use a value that
is two or three times the value for the MAXIMUM HOPS parameter. At a
minimum, the value for the MAXIMUM VISITS parameter must be equal to
or greater than the value for the MAXIMUM HOPS parameter. The maximum
value is 63, which is also the default value.

3-64

Managing and Monitoring the Network

3.7.4.4

Area Path Control Parameters
When a network is divided into areas, the MAXIMUM COST and MAXIMUM
HOPS parameters described above are used to control the path between each
pair of nodes within each area. A second set of routing parameters (AREA
MAXIMUM COST, AREA MAXIMUM HOPS) is used to control the total cost
and length of paths between level 2 routers within the whole network. In
effect, these parameters control the total possible path between areas in the
network.
The AREA MAXIMUM COST parameter in the SET EXECUTOR command
specifies the limit on the total path cost between the local level 2 router and
any level 2 router in the network. This value is the maximum cost of circuits
on the longest path between Level 2 routers. The AREA MAXIMUM HOPS
parameter in the SET EXECUTOR command specifies the maximum number
of hops that a packet can make between the local level 2 router and any
other level 2 router in the network. The AREA MAXIMUM COST and AREA
MAXIMUM HOPS parameters are used to determine whether an area is
reachable. The default values for these parameters are reasonable. Selection
of other values should be made carefully, with regard for the level 2 (area)
topology of the network.
The following example illustrates the use of the SET EXECUTOR command
to specify the maximum cost and hops permitted for routing between level 2
routers in the network:
NCP>SET EXECUTOR AREA MAXIMUM COST 500 AREA MAXIMUM HOPS 10

Values in the range 1 to 1022 are valid for the AREA MAXIMUM COST
parameter; the default value is 1022. Values in the range 1 to 30 are valid for
the AREA MAXIMUM HOPS parameter; the default value is 30.

3.7.5

Routing Message Timers
Routing messages exchanged between adjacent nodes contain information
about the cost and hops to each node in the network. Routing update
messages are sent automatically whenever there is a change in the
information (for example, when a line goes down). Nodes that detect the
change (for example, nodes at each end of a line that failed) are the first
to send routing update messages. The changed routing information then
propagates as far as necessary to update all routers.
Routing updates are also sent periodically under control of the routing timers.
These periodic transmissions ensure that routing tables are kept up to date
even in the unlikely event that a routing update message is lost.
The timer for transmission of routing messages is set using the SET
EXECUTOR command. For nodes on non-Ethernet circuits, the timer is
called the routing timer. Changing the setting of the routing timer will cause
additional routing messages to be transmitted to all adjacent nodes from
the local node, at a specified interval. For example, this command sets the
frequency of transmission of routing messages to 240 seconds:
NCP>SET EXECUTOR ROUTING TIMER 240

When this timer expires, the local node sends a routing message to all
adjacent nodes. Numbers in the range of 1 to 65,535 are valid for the
ROUTING TIMER parameter; the default value is 600. It is recommended
that you allow NETACP to supply the default.

3-65

Managing and Monitoring the Network

For a node on an Ethernet circuit, the timer is called the broadcast routing
timer. When the timer expires, the local node sends a multicast routing
configuration message to all nodes on the Ethernet. For example, this
command sets the frequency of routing message transmissions to 30 seconds:
NCP>SET EXECUTOR BROADCAST ROUTING TIMER 30

The broadcast routing timer for a node on an Ethernet circuit is set to a
much lower value (approximately 30 to 40 seconds) than the routing timer
for a node on a non-Ethernet circuit (every few minutes). Ethernet routing
messages are sent more often so that full routing messages can be exchanged
in case of datagram loss. The default value for this parameter is 40.

3.7.6

Cl End Node Circuit Failover
If a VAXcluster that uses the Cl as its DECnet datalink is configured to include
end nodes as well as routers, it is possible to define a backup circuit in each
end node that takes over should the primary circuit connecting the end node^
to its router fail.
An example is a three-node cluster comprised of one router (R) and two end
nodes (El and E2). Each end node should have a circuit defined to the router.
It is possible to define a second circuit in each end node which connects to
the other end node. The backup circuit is defined with a higher cost than the
primary circuit, and its state is set on. Under normal circumstances, with all
three nodes operational, the lower cost circuit (to the router) is used. Should
the router shut down, this circuit will be shut down. The backup circuit will
become the lowest cost circuit in the ON state, and will be used. The backup
circuit allows the end nodes to communicate while the router is absent from
the cluster.
If nodes El, E2, and R have Cl port addresses 1, 2, and 3, respectively, this
topology could be defined as follows in node El:
NCP>DEFINE CIRCUIT Cl-0.3 TRIBUTARY 3 COST 1 STATE ON
NCP>DEFINE CIRCUIT CI-0.2 TRIBUTARY 2 COST 10 STATE ON

The first circuit is the primary circuit; the second circuit is the backup circuit.
This technique can be extended to a larger cluster with two routers and
several end nodes; in each end node, two circuits of different cost are defined,
one to each router. The network could then survive the failure of one router,
but not both.

3.8

Logical Link Commands
Use the SET EXECUTOR command to set logical link parameters that define
the maximum number of active links permitted and set the timers that control
NSP operation. Use the DISCONNECT LINK command to disconnect links
while the network is running.

3—66

Managing and Monitoring the Network

3.8.1 Maximum Number of Links
When defining parameters for the local node, you may specify the maximum
number of logical links that can be active for that node. DECnet-VAX uses
this value to determine the size of internal data structures. The command
below sets the maximum number of links at 30:
NCP>SET EXECUTOR MAXIMUM LINKS 30

Note that this value includes both inbound and outbound logical links. In
the example above, you can have only 15 links if both ends of all links are
terminated locally.
If an alias node identifier has been established, you may also specify the
maximum number of logical links that can be active at the local node using
the alias node identifier. For example, the following command sets the alias
maximum links at 40.
NCP>SET EXECUTOR ALIAS MAXIMUM LINKS 40

When a VAXcluster uses an alias node identifier, two kinds of links (alias
node and local node) are possible. These links are controlled by the
appropriate parameter, MAXIMUM LINKS or ALIAS MAXIMUM LINKS.
When both of these parameters are specified, the upper limit on the number
of logical links that use the individual node identifier is reduced. Refer to the
VAX/VMS Network Control Program Reference Manual for information about
logical link restrictions.

3.8.2 Disconnecting Logical Links
You can selectively disconnect logical links active on the local node while
the network is running. The first command below disconnects link 1827; the
second disconnects all links active with all remote nodes.
NCP>DISCONNECT LINK 1827
NCP>DISCONNECT KNOWN LINKS

Use the SHOW KNOWN LINKS command to obtain link status information,
including link addresses, and to verify that links have been disconnected
upon issuing these commands (see Section 3.3). DECnet-VAX maintains and
uses link addresses.
Optionally, you can disconnect a single link or all known links to a particular
node. For example, the following NCP command disconnects all links to
node TRNTO:
NCP>DISCONNECT KNOWN LINKS WITH NODE TRNTO

3.8.3 Logical Link Protocol Parameters
A variety of parameters exists for controlling NSP-related logical link activity.
These parameters regulate the bounds for NSP connect sequences, inactivity
intervals, and message retransmission. Another parameter limits the amount
of nonpaged pool NSP will use for logical link transmission. You can change
these parameters at any time, without affecting existing logical links.

3-67

Managing and Monitoring the Network

3.8.3.1 Incoming and Outgoing Timers
There are two timers that regulate NSP connect sequences: an incoming timer
and an outgoing timer. Use the INCOMING TIMER parameter to specify
the maximum duration between the moment that a logical link connection
is received for a process on the local node and the moment that the process
accepts or rejects the connection. It is recommended that you use a value
between 30 and 60. To allow 30 seconds for connection confirmation, use the
following command:
NCP>SET EXECUTOR INCOMING TIMER 30

Expiration of this timer signals that a timeout has occurred. In effect, this
timer protects the local node against a process that never responds to an
inbound connection request.
The OUTGOING TIMER parameter specifies a timeout value for the duration
between the time a connection is requested and the time it is acknowledged
by the destination node. It is recommended that you use a value between
30 and 60. For example, this command allows 30 seconds to elapse before a
timeout is assumed to have occurred:
NCP>SET EXECUTOR OUTGOING TIMER 30

A typical value for this timer ranges from 10 to 90 seconds, depending on
line speed and network diameter. The network diameter is the maximum
diameter over the set of shortest paths between all pairs of nodes in the
network. In effect, this timer protects the user on the local node against a
connection request that never completes.

3.8.3.2

Inactivity Timer
A logical link is inactive when no data is transmitted in either direction for
a given interval of time. The inactivity timer regulates the frequency with
which local DECnet software tests the viability of an inactive link, thereby
protecting the user against a link that may be permanently unusable. Use
the INACTIVITY TIMER parameter to specify the maximum duration of
inactivity before the local node tests the viability of the link. For example,
this command sets the inactivity interval to 60 seconds:
NCP>SET EXECUTOR INACTIVITY TIMER 60

When this timer expires, DECnet-VAX generates artificial traffic to test
the link. The timer starts after an incoming message for the link has been
processed. The timer is reset if any messages are received on the link.

3.8.3.3

NSP Message Retransmission
A third group of parameters regulates the frequency of NSP message
retransmission. These are the DELAY WEIGHT, DELAY FACTOR, and
RETRANSMIT FACTOR parameters for the local node. Use of default values
for these parameters is recommended.
NSP estimates the current delay in the round-trip transmission to a node with
which it is communicating. The value of the DELAY WEIGHT parameter
is used to calculate a new value of the estimated round trip delay. The old
round trip delay is weighted by a function of this statistical factor to calculate
the new round trip delay. If the delay weight is set high, the retransmit time
changes slowly. If the weight is set low, the observed round trip time can
change quickly if the observed round trip delays vary widely, and thus the
retransmit time can change more rapidly.
The value of the DELAY FACTOR parameter is multiplied by one-sixteenth
of the estimated round trip delay time (derived as above) to determine the
appropriate value for the time to retransmit certain NSP messages.

3-68

Managing and Monitoring the Network

Values in the range of 1 to 255 are used in specifying values for the DELAY
FACTOR parameter, as in the following example:
NCP>SET EXECUTOR DELAY WEIGHT 3 DELAY FACTOR 48

The default value is 80. Refer to the Network Services Functional Specification
for a complete discussion of these concepts.
The value of the RETRANSMIT FACTOR parameter regulates the number of
times NSP will reattempt a transmission when its retransmission timer expires
for a logical link. This value must be a number in the range of 1 to 65,535;
the default value is 10. For example, the following command specifies that
NSP will reattempt a transmission no more than 10 times:
NCP>SET EXECUTOR RETRANSMIT FACTOR 10

If NSP tries to retransmit an eleventh time, the logical link will disconnect.
Note: Unless you have a special need to change the operating characteristics of
a logical link, you should use the default values for DELAY WEIGHT,
DELAY FACTOR, and RETRANSMIT FACTOR. In other words, do not
define these parameters in the permanent database.

3.8.3.4

Pipeline Quota
The PIPELINE QUOTA parameter in the SET EXECUTOR command specifies
the maximum number of bytes NCP will use from nonpaged pool to buffer
logical-link transmit requests. In effect, this quota determines the number of
packets NCP will transmit on a single logical link before waiting for a positive
acknowledgment from the remote end of the link. The number of packets
is determined by dividing the PIPELINE QUOTA value by the EXECUTOR
BUFFER SIZE value.
Unlike previous releases of DECnet-VAX, this PIPELINE QUOTA is not
deducted from the user process's byte count quota. This change allows the
system manager to set the process byte count quota to sensible values without
concern for the nonpaged pool requirements of DECnet. DECnet's nonpaged
pool usage with respect to the transmission over logical links is bounded by
the product of the values of the PIPELINE QUOTA and MAXIMUM LINKS
parameters.
The following command sets a pipeline quota of 6000 bytes for the local node
which is using a satellite link:
NCP>SET EXECUTOR PIPELINE QUOTA 6000

The default value for PIPELINE QUOTA is currently 3000. If satellite
communication is being used, it may be necessary to increase this value
to 6000 or more in order to improve DECnet performance.

Note: The SET EXECUTOR parameter PIPELINE QUOTA should not be
confused with the SET LINE parameter TRANSMIT PIPELINE. The
PIPELINE QUOTA parameter relates to transmission over logical links,
while TRANSMIT PIPELINE relates to data links. These parameters
address different levels of the Digital Network Architecture.

3—69

Managing and Monitoring the Network

3.9

Object Commands
Use the SET OBJECT command to establish and modify the object parameters
listed in Table 3-6. To remove any or all object parameters from the volatile
database, use the CLEAR OBJECT command.

Table 3-6

Object Parameters and Their Functions

Parameter Function

Parameter

Identifies object by number

NUMBER number

Identifies command procedure for
starting the object

FILE file-id

Specifies connect privileges for userlevel access control

PRIVILEGES privilege-list

Specifies optional default proxy login
access control for the object

f INCOMING

PROXY

J| OUTGOING
l
BOTH
^ NONE

Determines how the object will
respond to incoming connect requests
directed to the alias node identifier

3.9.1

'
DISABLED
ALIAS INCOMING j
ENABLED

Associates outgoing connect requests
for the object with the alias node
identifier

ALIAS OUTGOING f DISABLED
l ENABLED

Specifies optional default access
control for inbound connects

ACCOUNT account
PASSWORD password
USER user-id

\
J
\
J

DECnet-VAX Objects
Use the SET OBJECT command to establish and modify certain DECnet-VAX
objects and their command procedures.

3.9.1.1

DECnet-VAX Object Identification
When defining or modifying object parameters, you must identify the name
of the object. DECnet object names are descriptive alphanumeric strings of
up to twelve characters in length. DECnet software also uses object numbers
as unique object identifiers. Object numbers have a range of 1 to 255. Most
user-defined images will have a 0 object type. However, a user program
should have a nonzero number assigned when it provides a known service.
You may define an object name of TASK in the configuration database to
objects with a 0 object type if you provide additional required privileges or
default inbound access control to the object.
Generic objects such as FAL and NML have nonzero object numbers that are
recognized throughout the network. User-defined images may have unique
nonzero object numbers; numbers between 128 and 255 are reserved for this
purpose. For a list of object numbers and their associated names, refer to the
VAX/VMS Network Control Program Reference Manual. Unlike objects with a 0
object type, you must set each nonzero object in the configuration database.
Use the NUMBER parameter to specify a unique object number for nonzero
objects. For example:
NCP>SET OBJECT F00 NUMBER 129

3-70

Managing and Monitoring the Network

Note that the object name may not be unique to the generic services specified.
Only object numbers are unique across systems. For consistency, however, it
is recommended that you use object names as they are normally referenced
throughout the network.
When NETACP receives a logical-link connect request message from a remote
node, it translates the message into network connect block (NCB) format
and delivers it to the destination object running on the local node. (Refer to
Chapter 8 for a description of the NCB.)

3.9.1.2

Using the Cluster Alias Node Identifier for the Object
Command parameters for the SET OBJECT and DEFINE OBJECT commands
specify how certain objects treat incoming and outgoing connect requests
associated with the alias node.
By specifying the ALIAS OUTGOING parameter for a particular object, you
can indicate whether the object uses the alias node address in any outgoing
connect request.
This parameter makes it possible to direct an object such as MAIL to use the
alias node address rather than the executor address for outgoing connections.
For example, to direct the object FOX to use the alias node identifier for all
outgoing connect requests, use the following command:
NCP>SET OBJECT FOX ALIAS OUTGOING ENABLED

By default, only the object MAIL is so enabled. All other objects are disabled
unless specified.
Objects such as PHONE, which use a protocol that depends on multiple links,
should not have the ALIAS OUTGOING parameter enabled.
Use the ALIAS INCOMING parameter to specify how certain objects will
respond to incoming connect requests that are directed to the alias node.
Specific objects can be either enabled or disabled from receiving these
incoming connections.
This parameter allows you to restrict incoming connections to only those
objects that are appropriate. Any object which can receive multiple incoming
links or whose resources are not available clusterwide should not be enabled.
For example, to disallow the object FOO from receiving incoming connect
requests directed to the alias node address, use the following command:
NCP>SET OBJECT FOO ALIAS INCOMING DISABLED

By default, if an alias node identifier has been established for the node,
ALIAS INCOMING is enabled for all objects except PHONE. If an attempt is
made to use an alias node address to connect to an object for which ALIAS
INCOMING has been disabled, the status message NO SUCH OBJECT is
returned.

3-71

Managing and Monitoring the Network

3.9.1.3

Example of Using the Cluster Alias Node Identifier
The following scenario illustrates how use of an alias node identifier can
facilitate communication between a node within a cluster and a remote node.
A cluster includes nodes THRUSH and ROBIN. The network manager
establishes a node name CLUSTR in the database using the following DEFINE
NODE command:
NCP>DEFINE NODE 2.13 NAME CLUSTR

To establish the node name CLUSTR as the alias node identification for the
cluster, the network manager then issues the following command:
NCP>DEFINE EXECUTOR ALIAS NODE CLUSTR

Because an alias node identifier has been set, the ALIAS INCOMING
parameter is enabled by default. This means that all incoming connect
requests that are addressed to the alias node identifier will be routed to a
node that uses the alias.
The network manager also indicates that the MAIL object will use the alias
node identifier in its outgoing connect requests by specifying the command:
NCP>DEFINE OBJECT MAIL ALIAS OUTGOING ENABLED

After the network has been started, a user with the user name Jones logs
on to node THRUSH. He then sends a mail message to user Smith on node
BOSTON, which is outside the cluster. Since MAIL is enabled for outgoing
connect requests, it appears that Jones has sent mail from node CLUSTR. An
hour later, when user Smith reads her mail from Jones, it is preceded by the
node-identifier CLUSTR: JONES.
Smith decides to reply to Jones' mail. She sends the mail message to Jones
using the destination node CLUSTR.
Meanwhile, the node THRUSH has been taken down for maintenance, so
JONES has logged on to node ROBIN. Since ROBIN has also been enabled
for incoming connect requests addressed to the alias node identifier, JONES
receives his mail from SMITH. The mail is addressed to CLUSTR::JONES,
and is delivered to a node that uses the alias.

3.9.1.4

DECnet-VAX Command Procedure Identification
For non-zero-numbered objects, the default name of this command file is
SYS$SYSTEM:objectname.COM. Nonzero objects are identified in the logical
link connect message only by object number. Therefore, there must be an
entry in the object volatile database that enables NETACP to locate the
object name using the object number as a key. When you install DECnetVAX, nonzero object network-defined command procedures are entered by
default in the SYS$SYSTEM directory, and NETACP knows about these
command procedures. The supplied command files, named objectname.COM,
include FAL, HLD, NML, EVL, DTR, MAIL, PHONE, and MIRROR. Except
for those command procedures supplied by DIGITAL, you must create a
command procedure for every object that can be started by an inbound
connection request. You should name command procedures for nonzero
objects objectname.COM and place them in SYS$SYSTEM.
For zero-numbered objects, the default name of this command file is
SYS$LOGIN:objectname.COM. Zero objects are identified in the logical
link connect message by object name. Therefore, there is no need for an
entry in the object volatile database. You can, of course, specify an entry in
the object database at any time. You would be required to include a separate
entry if you desired special features such as default inbound access control
information.

3—72

Managing and Monitoring the Network

In either case, you can override the rules for locating the command file by
explicitly specifying a command procedure file in the SET OBJECT command.
This file is associated with the object in the object volatile database, as shown
in the following example:
NCP>SET OBJECT FAL NUMBER 17 FILE SYS$MANAGER:TRIALFAL.COM
NCP>SET OBJECT USERS NUMBER 0 FILE SYS$SYSTEM:USERS.COM

This technique can be particularly useful for zero-numbered objects. The
command file would then be found in the same place, regardless of which
access control information you use. If you do not specify the FILE parameter,
copies of the command file would have to exist in the SYS$LOGIN directory
of every account in which the object may possibly run.
Note: Because REMACP is started by a RUN command in RTTLOAD.COM,
there is no REMACP.COM procedure to start the object, and the software
does not create a REMACP.LOG file.
You can also invoke an image directly to serve as a network object, rather
than using a command procedure. To accomplish this, specify the object file
name as objectname.EXE, as in the following example:
NCP>SET OBJECT FAL NUMBER 17 FILE FAL. EXE

The image should be placed in SYS$SYSTEM. This approach causes the
object to be started up more quickly; it is useful in cases where no advantage
is gained by invoking the image from a command procedure. The session log
will appear as part of the NETSERVER.LOG file.

3.9.2

VAX PSI Objects
Use the SET OBJECT command to identify each VAX PSI object, its command
procedure, and the account information to be used by calls coming in to the
object from remote DTEs.

3.9.2.1

VAX PSI Object Identification
Each object must have a unique name. Object names are descriptive
alphanumeric strings up to 8 characters in length, for example, OBJONE.
Use the SET OBJECT command to identify the object. For example:
NCP>SET OBJECT OBJONE ...

3.9.2.2

VAX PSI Command Procedure Identification
The system manager must create a command procedure for every object
that can be accessed by a destination. Command procedures are named
filename.COM.
Use the FILE parameter to specify the command procedure for an object. For
example:
NCP>SET OBJECT OBJONE ...

FILE STARTUP.COM ...

The filename is associated with the object identification in the configuration
database. To allow connections to an object, you must first create a command
procedure in the default directory for the user account (either specified or
defaulted) that the incoming call will log in to. The command procedure must
also exist in the directory of every account in which the associated object
may run. VAX PSI automatically creates a log file (filename.LOG) every time
an incoming call causes an object's command file to be executed. This file

3-73

Managing and Monitoring the Network

is created in the default directory of the account. The log file is helpful for
debugging your own network tasks when an error occurs.
The command procedure will contain at least a RUN command for an
image. It may also contain terminal assignments for debugging purposes
(for example, DBG$INPUT and DBG$OUTPUT). There are no restrictions on
the type of commands that you can have in this file.

3.9.2.3

VAX PSI Object Account Information
The account information that is used by incoming calls from remote DTEs
should be specified for each object.
Use the ACCOUNT, PASSWORD, and USER parameters to specify the
account information. For example:
NCP>SET OBJECT OBJONE
_

...

USER NET -

PASSWORD NET ACCOUNT PAULS...

The PASSWORD and USER parameters are mandatory. The ACCOUNT
parameter is optional and, by default, no account is used.

3.10

X.25/X.29 Server Module Commands
The X25-SERVER and X29-SERVER module components handle incoming
X.25 and X.29 calls from a PSDN. The server components contain records that
identify destinations for incoming calls and associate with each destination
parameters that determine whether the destination can handle an incoming
call. The destination can be on a local DTE connected directly to a PSDN,
or on a host node to which an X.25 multihost connector node is forwarding
incoming calls. The server database also specifies the maximum number of
incoming and outgoing circuits that each module (that is, all destinations for
that particular module) can have, and specifies the state of the module.

3.10.1 X25—SERVER and X29—SERVER Module Identification
Use the SET MODULE X25-SERVER and SET MODULE X29-SERVER
commands to identify the modules that handle incoming calls. The
parameters for these two modules are the same. Use separate commands to
specify the destination qualifier (DESTINATION), and the module parameters
(MAXIMUM CIRCUITS, STATE, and COUNTER TIMER).

3.10.2 Destination Identification
Each destination must have a unique name. Destination names are
descriptive alphanumeric strings, from 1 to 16 characters in length. Use
the DESTINATION qualifier to specify the destination name. For example:
NCP>SET MODULE X25-SERVER DESTINATION JOE

...

Associate any of the following parameters with each destination:
SUBADDRESSES, GROUP, CALL MASK, CALL VALUE, CALLED
ADDRESS, INCOMING ADDRESS, RECEIVING DTE, REDIRECT REASON,
SENDING ADDRESS, NETWORK, EXTENSION MASK, EXTENSION
VALUE, PRIORITY, OBJECT, and NODE.

3-74

Managing and Monitoring the Network

The parameters from SUBADDRESSES through EXTENSION VALUE are
used to determine whether a call is handled. (If you do not specify a
parameter, the parameter is not used.) The PRIORITY parameter sets the
priority of the destination, and the OBJECT parameter names the object
activated when a destination accepts an incoming call. The NODE parameter
identifies the host node on which the destination is located, if the call is
received through a local X.25 multihost connector node.
The parameters are described in the following sections.

3.10.2.1 DTE Subaddress Range
Use the SUBADDRESSES parameter to specify a local DTE subaddress or
a range of subaddresses for each destination. The destination uses this
information to decide if it can handle incoming calls.
In the command below, destination JOE will handle only incoming X.25 calls
that specify local DTE subaddress 35:
NCP>SET MODULE X25-SERVER DESTINATION JOE SUBADDRESSES 35...

The following command, however, specifies that destination JOE will handle
all incoming X.25 calls that specify a local DTE subaddress in the range 12 to
24 inclusive:
NCP>SET MODULE X25-SERVER DESTINATION JOESUBADDRESSES 12-24...

A subaddress is a decimal integer in the range 0 to 9999. Separate two
subaddresses with a single hyphen to indicate a range. The second
subaddress must always be greater than the first.
The SUBADDRESSES parameter is optional, and, by default, no subaddress
range is used to determine if the destination can handle an incoming call.

3.10.2.2 Group Identification
Use the GROUP parameter to specify a closed user group (CUG) or bilateral
closed user group (BCUG) name for each destination. The destination uses
this information to decide if it can handle incoming calls. The following
command indicates that destination JOE will handle only incoming X.25 calls
that originate from a DTE that is a member of the closed user group ESECUG:
NCP>SET MODULE X25-SERVER DESTINATION JOE GROUP ESECUG ...

The GROUP parameter is optional, and, by default, no group name is used to
determine if the destination can handle an incoming call.

3.10.2.3 Remote DTE Identification
Use the SENDING ADDRESS parameter to specify the remote DTE address
that sent the call; that is, the address contained in the calling address field in
the call packet. The DTE address consists of 1 to 15 digits. The destination
uses this information to decide if it can handle incoming calls.
As an example, the following command specifies that the destination JOE will
handle only incoming X.25 calls that come from the remote DTE with address
987321654:
NCP>SET MODULE X25-SERVER DESTINATION JOE SENDING ADDRESS 987321654...

Managing and Monitoring the Network

The SENDING ADDRESS parameter is optional and, by default, no remote
DTE address is used to determine if the destination can handle an incoming
call.

3.10.2.4

User Data Field
Optionally use the CALL MASK and CALL VALUE parameters to specify
a call mask (to be applied to incoming call data before it is tested) and a
call value (the string used to test incoming call data). If you specify these
parameters, VAX PSI extracts the user data from the incoming call request
and performs a logical AND operation between this data and the call mask.
VAX PSI then compares the result of this operation with the call value; if the
fields match, the destination can accept the incoming call. Note that the call
mask and the call value you specify must be the same length. For example,
the command below indicates that destination JOE will handle only incoming
X.25 calls that contain value 11 in their user data fields:
NCP>SET MODULE X25-SERVER DESTINATION JOE CALL VALUE 11 _ CALL MASK FFFFFFFF ...

The CCITT (Comite Consultatif International Telegraphique et Telephonique)
recommends that you use a value of 01 for incoming X.29 calls. As an
example, the command below indicates that destination JIM will handle only
incoming X.29 calls that contain 01 in their user data fields:
NCP>SET MODULE X29-SERVER DESTINATION JIM CALL VALUE 01 _ CALL MASK FF ...

Specify strings of 2 to 32 hexadecimal digits for the two parameters.
You can use these two parameters to further identify X.29 calls when the
terminal user first connects to the PAD (Packet Assembly/Disassembly
Facility). To do so, specify a destination for the X29-SERVER that recognizes
a value entered as call data when connecting to the PAD. For example, the
following command indicates that the destination JANE will handle incoming
X.29 calls that specified a call data value of A (41 is the hexadecimal value for
A):
NCP>SET MODULE X29-SERVER JANE CALL VALUE 0000000041 _ CALL MASK 00000000FF ...

The CALL MASK and CALL VALUE parameters are optional and, by default,
no mask or value is used to determine if the destination can handle an
incoming call.

3.10.2.5

Address Extension
The address extension facility is intended to support end-to-end signaling,
as described in the VAX PSI Management Guide. Two parameters are used
for address extension: EXTENSION MASK and EXTENSION VALUE. These
are used like the CALL MASK and CALL VALUE parameters. The extension
mask is applied (by VAX PSI) to the called address extension in an incoming
call and the extension value is compared with the result. For example:
NCP>SET MODULE X25-SERVER DESTINATION JOE _ EXTENSION VALUE 12340000AA EXTENSION MASK FFFF0000FF

Here, the destination JOE will handle only incoming calls that have a
hexadecimal address extension value of 1234, followed by any four digits,
followed by AA.

3-76

Managing and Monitoring the Network

3.10.2.6 Call Redirection
The call redirection facility allows you to receive incoming calls that have
been redirected to your DTE from another DTE connected to the same PSDN.
Four parameters are used to match redirected calls: REDIRECT REASON,
CALLED ADDRESS, INCOMING ADDRESS and SENDING ADDRESS.
The REDIRECT REASON parameter takes one of the following values:
BUSY

Indicates that the called DTE was busy

OUT OF ORDER

Indicates that the called DTE was out of order

SYSTEMATIC

Indicates that calls to the called DTE are automatically
rerouted

The CALLED ADDRESS parameter should be matched against the originally
called address. This will be found in the call redirection notification facility
field of the call packet.
The INCOMING ADDRESS parameter should be matched against the address
in the called address field of the call packet.
The SENDING ADDRESS parameter (described in Section 3.10.2.3) should be
matched against the address in the calling address field of the call packet.
For example:
NCP>SET MODULE X25-SERVER DESTINATION JOE _ CALLED DTE 123999456 _ INCOMING ADDRESS 123789456 _ SENDING ADDRESS 123888456 _ REDIRECT REASON BUSY

Here, the destination JOE will handle Calls sent from 123888456 to 123999456
that have been redirected to 123789456 because 123999456 is busy.
3.10.2.7 Receiving DTE
Use the RECEIVING DTE parameter tQ specify the local DTE that has
received the call. For example:
NCP>SET MODULE X25-SERVER DESTINATION READINGS _ RECEIVING DTE 234295432 ...

creates the destination READING6 which matches any calls received on DTE
234295432.

3.10.2.8 Priority
Use the PRIORITY parameter to specify the priority of each destination. If an
incoming call can be accepted by more than one destination, the destination
with the highest priority is used. For example, the command below assigns a
priority of 3 to destination JOE:
NCP>SET MODULE X25-SERVER DESTINATION JOE PRIORITY 3...

Specify a priority value in the range 0 to 255, where 255 is the highest
priority.
The PRIORITY parameter is mandatory if you specify more than one
destination that could handle the same incoming call. Otherwise this
parameter defaults to 0.

3—77

Managing and Monitoring the Network

3.10.2.9

Object Identification
Use the OBJECT parameter to specify the name of the object that is activated
when an incoming call arrives and is accepted by the destination. Specify the
name as an id-string. If the object name is a string of digits, enclose the string
in quotation marks. You must specify the object itself, using the SET OBJECT
command (see Section 3.9.1).
The command below specifies the object OBJONE.
NCP>SET MODULE X25-SERVER DESTINATION JOE OBJECT OBJONE...

The OBJECT parameter is mandatory when you specify a destination for the
first time.

3.10.2.10

Host Node Identification
Use the NODE parameter with the DESTINATION qualifier to identify a host
node on which the destination is located. A host node receives X.25 calls
that have been forwarded by an X.25 connector node connected directly to a
PSDN. If your local DECnet-VAX node is configured with VAX PSI software
in multihost mode to serve as an X.25 connector node, you must specify the
NODE parameter for each host destination. For example, if your local node is
a connector node, use the command below to specify that incoming calls are
to be forwarded to the indicated destination on host node THRUSH on the
same Ethernet.
NCP>SET MODULE X25-SERVER DESTINATION THRUSH SUBADDRESSES 1-10 OBJECT 36 NODE THRUSH

Note that the host node THRUSH must be configured with VAX PSI Access
software to be associated with the X.25 connector node. The following
command must be entered at node THRUSH to specify the destination of
X.25 calls being forwarded by the X.25 connector node.
NCP>SET MODULE X25-SERVER DESTINATION JOE _ SUBADDRESSES 1-10 OBJECT OBJONE PRIORITY 1

3.10.3 Maximum Circuits
Use the MAXIMUM CIRCUITS parameter to specify the maximum number of
circuits that the module (that is, all destinations) can handle. The command
below enables the X.25 server module (the call handler for incoming X.25
calls) to handle a maximum of 32 circuits (incoming and outgoing calls) at
any one time.
NCP>SET MODULE X25-SERVER MAXIMUM CIRCUITS 32...

The MAXIMUM CIRCUITS parameter is optional and, by default, the
maximum is 255.

3-78

Managing and Monitoring the Network

3.10.4 Operational State of Server
Use the STATE parameter to specify the operational state of the server
module. There are three possible states:
OFF

Prevents use of the module and clears all existing virtual circuits

Allows normal use of the module

SHUT

Prevents use of the module for any new activity, but allows existing
virtual circuits to complete their operation

The command below allows normal use of the module.
NCP>SET MODULE X25-SERVER STATE ON ...

The STATE parameter is optional and, by default, the state is ON.
For a complete list of states and their transitions, refer to the VAX/VMS
Network Control Program Reference Manual

3.11

X.25 Access Module Commands
The X25-ACCESS module contains the database needed to connect the local
host node to a DECnet-VAX node serving as an X.25 multihost connector
node that can access specific PSDNs on behalf of the host nodes. Your local
host node must be a DECnet-VAX node on which VAX PSI Access software
is installed. The X.25 connector node must be a VAX/VMS node with VAX
PSI software in multihost mode installed (or a DECnet Router/X.25 Gateway
node). Refer to Chapter 5 for an example of the use of NCP commands to
configure the X.25 connector and host nodes.
Use the SET MODULE X25-ACCESS command to associate the name of
the X.25 network you want to access with the name of the node serving
as the connector to this network. You can optionally specify access control
information for the link between your host node and the connector node.

3.11.1 Network Identification in an X.25 Access Module
Use the NETWORK qualifier in the SET MODULE X25-ACCESS command to
identify the specific network you want to access through the X.25 connector
node. The network name you specify must be the same as the one defined in
the X. 25 protocol module database, at the X.25 connector node.
The command below identifies the network PSS1 to which the local DECnetVAX node with VAX PSI Access software wants access.
NCP>SET MODULE X25-ACCESS NETWORK PSS1

...

You must specify the NETWORK qualifier and must associate with it the
NODE parameter. You can optionally specify access control information to be
used by VAX PSI Access software in connecting to the X.25 connector node.

3-79

Managing and Monitoring the Network

3.11.2 X.25 Connector Node Identification
Use the NODE parameter to identify the node that will provide connector
or gateway services to the specified X.25 network. A DECnet-VAX node
serving as an X.25 connector node must be configured with VAX PSI software
in multihost mode. The connector node, also referred to as the target node,
is the one with which the VAX PSI Access software on your local node
establishes a DECnet link in order to transmit and receive X.25 and X.29
calls. The following command identifies the node ROBIN as the one which
will serve as the connector node to permit your local host node to access the
network PSS1:
NCP>SET MODULE X25-ACCESS NETWORK PSS1 NODE ROBIN ...

ROBIN must be a DECnet-VAX node configured with VAX PSI software in
multihost mode. ROBIN must be connected.by an X.25 line to the PSDN.
ROBIN must also contain an entry in its X.25 server module database
indicating that the destinations of specific incoming X.25 calls are located
on your host node (see Section 2.7).

3.11.3 Access Control Parameters in an X.25 Access Module
You have the option of specifying access control parameters to be used by
the VAX PSI Access software on your local host node in establishing a link
to the node serving as the X.25 connector. The access control parameters are
the standard DECnet-VAX parameters: USER, PASSWORD, and ACCOUNT,
The command below specifies the user identification PSI and password PSI
the local node can use for an inbound connect when establishing a DECnet
link with node ROBIN, the X.25 connector to the network PSS1.
NCP>SET MODULE X25-ACCESS NETWORK PSS1 NODE ROBIN _ USER PSI PASSWORD PSI

3.12

Logging Commands
In order to log events, you must turn logging on. (The DECnet-VAX default
has all events cleared.) 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 3-7 lists all logging parameters by function, and groups them according
to operational categories.

3-80

Managing and Monitoring the Network

Table 3-7

Logging Parameters and Their Function

Parameter Function

Source-Related Parameter

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 Parameter

NAME sink-name

Assigns name to logging
component
Sets state of logging component

Source-related and sink-related parameters are mutually exclusive. Therefore,
you cannot use parameters from both categories in a single command. Use
the SET LOGGING EVENTS command to specify source-related events, and
the SET LOGGING STATE command to specify sink-related events.
For a summary of event class and types and information about the specific
events that VAX/VMS will log, see the VAX/VMS Network Control Program
Reference Manual.
The logging component is defined by the device or process that records
the events released by the event logger. The logging component can be a
LOGGING CONSOLE, LOGGING FILE, or LOGGING MONITOR. The
LOGGING CONSOLE is a terminal or a file that receives events on the sink
node in a format the user can read. A LOGGING FILE is a user-specified file
on the sink node. The logging file component receives events in the standard
DNA binary format. (Refer to the Phase IV Network Management Functional
Specification for a description of this format.) Instead of specifying the console
and a file, you can specify a system- or user-supplied LOGGING MONITOR
program to receive and process DNA format-specific events/ This program
could possibly receive event data and adapt user application network activity
to reflect this data.
If the logging sink is the LOGGING MONITOR, DECnet-VAX uses
the Operator Communication (OPCOM) facility to display formatted
event messages on all terminals enabled as NETWORK (using REPLY
/ENABLE=NETWORK). This generally includes the operator console (OPAO).
The format of event messages OPCOM displays is similar to that used for
console logging; however, because of restrictions in the size of messages that
OPCOM can display, some messages may be truncated slightly, and node,
circuit, and line counters are not displayed at all.
To identify the name of the logging component on the local node, use the
NAME parameter. For example, if the component is a logging console file,
the command below creates the file EVENTS.LOG into which formatted
events will be logged.
NCP>SET LOGGING CONSOLE NAME SYS$MANAGER:EVENTS.LOG

3-81

Managing and Monitoring the Network

To identify a logging monitor program as the logging component, use the
NAME parameter followed by the program name. See Section 3.12.6.
Regardless of the logging component you use, parameter selection is the
same. If you want to modify parameters for all logging on the network,
then use the plural KNOWN LOGGING component when issuing the SET
LOGGING command.
Note: Because console logging uses normal VAX RMS file I/O, if a terminal is
specified as a sink name, the terminal should not be used or allocated
for any other purposes. For example, if a user should log in on such a
terminal, events will be lost until the user logs out.

3.12.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 layer to which the event pertains

type

Identifies a particular form of event, unique within an event class

For example, to specify an event in the Routing layer, you would use event
class 4. The event types for this class range from 0 to 14. Event type 0
indicates aged packet loss, event type 1 indicates unreachable node packet
loss, and so forth. Refer to the VAX/VMS Network Control Program Reference
Manual 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 illustrate 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 ascending, order.
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.*

3-82

Managing and Monitoring the Network

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.

3.12.2 Identifying the Source for Events
You can specify the particular source for which events apply, which can be
either a node, a module, a circuit, or a line. For example, to monitor network
activity for circuit DMC-0 connected to the local node, use the command
NCP>SET LOGGING CONSOLE CIRCUIT DMC-0 .

Events that pertain to activity over this circuit will be logged at the console by
the event logger. The same operation can be performed for any remote node.
If no source is specified for a component, the event logger logs events for all
circuits, lines, modules, and nodes known to the local node or DTE.
Note that you can set only one source (a circuit, module, node, or line) as the
source for events in a single command.
The command CLEAR LOGGING KNOWN EVENTS clears only events that
are not associated with any specific source. To remove an event associated
with a specific source, use the CLEAR LOGGING command that specifies that
source.

3.12.3 Identifying the Location for Logging Events
Events can be logged either at the local node or a remote node. Use the
SINK parameter to specify the location. For example, the following command
routes all event information to the logging monitor program running on node
DENVER:
NCP>SET LOGGING MONITOR SINK NODE DENVER .

If you do not specify a location, the local node is the default.

3.12.4 Controlling the Operational State of Logging
You can control the operational state of logging only for the local node. There
are three logging states:
HOLD

Indicates that the sink is temporarily unavailable. Events destined for
that location are queued.

OFF

Indicates that the sink is unavailable for receiving event information.
Events will not be logged for that sink.

Indicates that the sink is available for receiving event information. This
is the normal operational state.

3-83

Managing and Monitoring the Network

Use the STATE parameter to specify the operational state of logging on the
local node. The command below forces event information to be queued for
all instances of the logging component on the local node.
NCP>SET KNOWN LOGGING STATE HOLD

Note that this control over logging does not affect the operational state of
the node. It is recommended that you set the default state to ON in the
permanent database.
Note: The event logger object (number 26, name EVL) must be specified in the
object database. If you experience difficulty with event logging, examine
the event logger's own log file, SYS$MANAGER:EVL.LOG, for possible
problems.

3.12.5 Event Logging Example
The following example illustrates the use of NCP event logging commands.
You may want to log events normally to OPCOM for each node in the
network. In addition, you may want each node to transmit its events to a
single node to be stored in a file. For the three nodes—DENVER, TRNTO,
and BOSTON—you could issue the following commands at each node to
accomplish this task.
At nodes DENVER and BOSTON:
NCP>SET LOGGING MONITOR STATE ON
NCP>SET LOGGING MONITOR KNOWN EVENTS
NCP>SET LOGGING MONITOR SINK NODE TRNTO KNOWN EVENTS

At node TRNTO:
NCP>SET
NCP>SET
NCP>SET
NCP>SET
NCP>SET

LOGGING MONITOR
LOGGING MONITOR
LOGGING CONSOLE
LOGGING CONSOLE
LOGGING CONSOLE

STATE ON
KNOWN EVENTS
NAME SYS$MANAGER:NETEVENTS.LOG
STATE ON
KNOWN EVENTS

Events from all three nodes will be logged to all terminals enabled as
NETWORK (through the DCL command, REPLY/ENABLE=NETWORK)
on node TRNTO. In addition, all local events will be logged locally to the file
NETEVENTS.LOG on node TRNTO. Note that the transmitting node always
specifies the destination of the event logger output and causes its locally
generated events to be sent to the receiving sink node to be logged.

3.12.6 Using a Logging Monitor Program
Instead of using a logging console or a logging file, you can specify a logging
monitor program to receive and process events. The logging monitor is
a system- or user-supplied program. The advantage of using a logging
monitor program is that it can be tailored to the specific needs of the network
manager.
Logging monitor programs can be written in high-level languages and can
be designed by the programmer to perform specific functions desired by
the network manager. Thus, the logging monitor program can be simple or
complex, depending on its design and objective.

3-84

Managing and Monitoring the Network

The following logging monitor example is a BASIC program called
LOGGER.BAS. It records events released by the event logger and prints
them to a terminal. Detailed information about the format of the events can
be found in the Phase IV Network Management Functional Specification.
10

! TITLE LOGGER.BAS
I
! This is a sample logging monitor program.

MAP (EVENT)
BYTE
BYTE
WORD
STRING
WORD
STRING

FUNCTION.CODE,
SINK.FLAGS,
EVENT.CODE,
EVENT.TIME = 12,
SOURCE.NODE,
REST = 238

&
&
&
&
&
&

100 ! Record events released by the network event logger.
110 OPEN "SYS$NET" FOR INPUT AS FILE #17.. MAP EVENT
120 ON ERROR GOTO 998
200
! Begin loop to extract events and write them to the terminal.
300 WHILE 1=1
400
GET #17.
410
EVENT_CLASS7. = EVENT_CODE / 647.
420
EVENT_TYPE7. = EVENT.CODE - 327. * (EVENT.CODE / 327.)
430
EVENT_CLASS$ = NUM1$ (EVENT.CLASS7.)
440
EVENT_TYPE$ = NUM1$ (EVENT.TYPE7.)
450
EVENT$ = EVENT_CLASS$ +
+ EVENT_TYPE$
460
PRINT "Event " ; EVENT$ ; " Reported"
499 NEXT
998 RESUME 999
999 END

To use a logging monitor, you must add the name of the program to the
object database. For example, the following commands add the executable
image LOGGER to the database and set LOGGER as the name of the logging
monitor program.
NCP>SET
NCP>SET
NCP>SET
NCP>SET

OBJECT LOGGER NUMBER 0 FILE LOGGER.EXE
LOGGING MONITOR KNOWN EVENTS
LOGGING MONITOR STATE ON
LOGGING MONITOR NAME LOGGER

Sample output from logging monitor program (LOGGER.EXE) is as follows:
Event
Event
Event
Event
Event

3.13

0.9 Reported
0.9 Reported
4.7 Reported
4.10 Reported
4.15 Reported

Network Access Control Commands
The system manager can specify NCP commands to provide for access control
at the routing initialization level, at the system level during inbound logical
link connections, and at the node level during inbound and outbound logical
link connections. You can also use NCP commands to control proxy login
access to individual accounts and network objects at the local node. This
section indicates the NCP commands and parameters that can be specified for
access control. Refer to Section 2.10 for a description of DECnet-VAX access
control techniques.

3-85

Managing and Monitoring the Network

3.13.1 Specifying Passwords for Routing initialization
You can specify in your local configuration database transmit and receive
passwords for each adjacent node. The transmit password is the one you
send to the remote node and the receive password is the one you expect to
receive from the remote node during the routing initialization sequence. Use
the SET NODE command to specify these passwords. Each password can be
one to eight alphanumeric characters in length. For example, the command
below establishes transmit and receive passwords for the circuit or circuits
connecting the local node with node TRNTO.
NCP>SET NODE TRNTO TRANSMIT PASSWORD VAX.NODE_ RECEIVE PASSWORD VAX.NODE

If the password contains one or more space characters, you must delimit it
with quotation marks.
To remove transmit and receive passwords from the volatile database, use the
CLEAR NODE command, as shown in the example below.
NCP>CLEAR NODE TRNTO RECEIVE PASSWORD TRANSMIT PASSWORD

To provide for increased security when a remote node requests a
connection over a point-to-point circuit, you can use the circuit parameter
VERIFICATION INBOUND to prevent your node from revealing its routing
initialization password while requiring a password from the remote node.
When two nodes communicate over a point-to-point circuit, only one of the
nodes can have the VERIFICATION INBOUND parameter set. The primary
function of this parameter is to permit the system manager to restrict the
nodes that can initialize over a particular circuit, especially over a dialup
circuit.
When a dialup node attempts to establish a dynamic connection with your
node, the dynamic asynchronous circuit entry is supplied automatically
to your configuration database. This entry includes the circuit parameter
VERIFICATION INBOUND, which prevents your node from supplying
a password to the node requesting a dynamic connection, but requires a
password from the node dialing in.
Note that if VERIFICATION INBOUND is specified for a circuit, the node
parameter INBOUND ROUTER or INBOUND ENDNODE, as appropriate,
must be specified for the connecting node (see Section 3.13.3). This
requirement applies to both dynamic and static asynchronous connections.
If, on the other hand, you are a user on a node with a terminal line (such
as a Micro VMS system) and you expect to form a dynamic asynchronous
connection with another node, you should specify a transmit password in
your node database. For example, if you are at node MYNODE and expect
to form a dynamic connection with remote node VCLST1 on a VAXcluster,
specify the following command to establish the transmit password for the
dynamic circuit:
NCP>SET NODE VCLST1 TRANSMIT PASSWORD H0MEN0DE1

The remote node in a dynamic connection must specify the receive password
it expects to receive from the local node. In the example, the system manager
at remote node VCLST1 specifies the following command to indicate the
password expected from node MYNODE:
NCP>SET NODE MYNODE RECEIVE PASSWORD H0MEN0DE1

3-86

Managing and Monitoring the Network

3.13.2 System-Level Access Control Commands
You can use the SET NODE command to specify default privileged and
nonprivileged access control strings for outbound logical link requests.
Use the SET OBJECT command to specify privileges required to access
certain objects during inbound logical link requests. You can also use the
SET OBJECT command to specify a default access control string. For NCP
commands to be executed at remote nodes, you can either supply explicit
access control information in the node specification, as parameters in the
command, or by default.

3.13.2.1 Establishing Default Privileged and Nonprivileged Accounts
Use the SET NODE command to specify default access control information for
connecting to remote nodes. If you have not specified explicit access control
information in an outbound logical link request, this default information
is sent with the request. For example, the command below specifies both
privileged and nonprivileged user names and passwords for node DENVER:
NCP>SET NODE DENVER_ NONPRIVILEGED USER NETNONPRIV PASSWORD NONPRIV_ PRIVILEGED USER NETPRIV PASSWORD PRIV

You should specify default information for all remote nodes with which you
want to have the option of using default access control.

3.13.2.2 Specifying Privileges for Objects
Use the SET OBJECT command with the PRIVILEGE parameter to specify
those privileges that will cause the privileged user account to be used rather
than the nonprivileged user account. The privilege list accompanying the
parameter specifies those privileges required for all inbound connections to
that object. For example, you may want to make the FAL object accessible
to any network user, whereas you want to control access to the NML object.
The following command specifies privileges for the NML object in this
instance:
NCP>SET OBJECT NML PRIVILEGES OPER

You need not specify privileges for FAL because it requires only NETMBX
and TMPMBX privileges.

3.13.2.3 Setting Default Inbound Access Control Information
Use the SET OBJECT command with the USER, ACCOUNT, and
PASSWORD parameters to specify default inbound access control
information. For example, the following command specifies default
information that the local DECnet-VAX node can use for inbound connects
from SLD:
NCP>SET OBJECT HLD USER NETNONPRIV PASSWORD NONPRIV

3-87

Managing and Monitoring the Network

3.13.2.4

Indicating Access Controls for Remote Command Execution
Access control is used for remote NCP command execution. When you issue
the SET EXECUTOR NODE and TELL commands, you can explicitly specify
access control information, or you can default to information contained in the
configuration database.
Two formats exist to supply access control information explicitly for these
commands. You can use either a standard VAX/VMS node specification
(node"user password account"::) or the NCP parameters USER, ACCOUNT,
or PASSWORD. For example, the following commands perform the same
operation:
NCP>SET EXECUTOR NODE TRNTO"GRAY MARY"::
NCP>SET EXECUTOR NODE TRNTO USER GRAY PASSWORD MARY

The same formats exist for the TELL command. Use of the standard
VAX/VMS node specification format allows you to use a logical name as
the node-id for these commands. It is possible to override access control in a
logical name with explicit access control information in the command.
You can also use access control information to cause NML to run under an
account other than the default DECnet privileged account on the local node.
Issue the following command for this purpose:
NCP>SET EXECUTOR NODE TRNTO»user-id password"

3.13.3 Node-Level Access Control Commands
At the node level, you can specify access control commands that determine
what connections can be made. If your node expects to receive dialup
dynamic asynchronous connection requests, you can check the type of the
dialup node before permitting the connection.
The NCP commands SET NODE ACCESS and SET EXECUTOR DEFAULT
ACCESS, when used together, allow you to partition your network to allow
specific access for each node. For example, assume that there are 10 nodes
in your network, named A through J. The executor is node A. Because
most network traffic occurs between nodes A, B, and C, you could use the
following commands to allow unrestricted incoming and outgoing logical link
connections among those nodes:
NCP>SET NODE A ACCESS BOTH
NCP>SET NODE B ACCESS BOTH
NCP>SET NODE C ACCESS BOTH

Next, assume that you want to allow local users to initiate connections to
node D, but restrict connections from that node. Issue the command
NCP>SET NODE D ACCESS OUTGOING

Finally, assume that you want to allow incoming logical link connections from
all other remote nodes (E through J), but restrict outgoing connections from
the executor node. Issue the command
NCP>SET EXECUTOR DEFAULT ACCESS INCOMING

It is important to stress that the executor will check for a node ACCESS entry
before it checks for the DEFAULT ACCESS entry. You should also remember
that if the executor's state is set to OFF or SHUT, no logical links will be
allowed.

3-88

Managing and Monitoring the Network

You can indicate the type of node that can connect to your node over a pointto-point circuit by specifying the INBOUND parameter in the SET NODE
command. The INBOUND parameter permits you to check the type of a
connecting node before you form a dynamic connection with the node. For
example, if you expect the Micro VMS node MYNODE to initiate a dynamic
connection by dialing in over a specific terminal line, you can specify the
following in your node database:
NCP>SET NODE MYNODE INBOUND ENDNODE

If the node MYNODE dials in as a router, rather than as an end node, the
dynamic connection is not formed. If you specify INBOUND ROUTER for
the node and it dials in as an end node, the dynamic connection is permitted.
Note that when the node parameter INBOUND is specified, the circuit
parameter VERIFICATION INBOUND must also be set for the circuit over
which the connection is to be made (see Section 3.13.1). If VERIFICATION
INBOUND is not set for the circuit, the node parameter INBOUND is ignored.

3.13.4 Proxy Login Access Control Commands
Access to individual accounts on the local node by proxy login is enabled by
the DEFAULT PROXY setting in the executor database. The default setting of
DEFAULT PROXY for each node permits both incoming and outgoing proxy
access. This setting is the recommended option. You can, however, use the
SET EXECUTOR command to modify the DEFAULT PROXY value at the
local node.
The default value of the DEFAULT PROXY entry in the executor database is
equivalent to issuing the following command:
NCP>SET EXECUTOR DEFAULT PROXY BOTH

The system manager has the option of changing the default value, as in the
following command, which prohibits any proxy login to or from the local
node.
NCP>SET EXECUTOR DEFAULT PROXY NONE

To display the value of the DEFAULT PROXY entry for your node, use the
command
NCP>SHOW EXECUTOR CHARACTERISTICS

If proxy login access is enabled at your node, the resultant display is
Default proxy access = incoming and outgoing

When proxy login access is enabled, the remote user can access a file
accessible to the local account to which he has proxy access by using the
node specification NODE:: in the standard VAX/VMS file specification. For
example, a remote user can specify the following form of file specification to
access a file on an account on node TRNTO to which he has proxy access:
TRNTO::filename

To override proxy login, the remote user with a proxy account on a node can
specify NODE"":: in the file specification, causing the default nonprivileged
DECnet account to be used, since explicit access control will be passed to the
remote node.

3-89

Managing and Monitoring the Network

Access to a network object through a proxy account is controlled by the
PROXY parameter in the object database. By default, DECnet-VAX has set in
the configuration database PROXY values for some network objects. These
default values are the recommended values. To specify or modify the PROXY
parameter for an object, use the SET or DEFINE OBJECT command with
the PROXY parameter. In the following example, the outgoing proxy access
option is set for the object MAIL.
NCP>SET OBJECT MAIL PROXY OUTGOING

To display the setting for the PROXY parameter in the database, use the
SHOW OBJECT command with the CHARACTERISTICS parameter, as in the
following command:
NCP>SHOW KNOWN OBJECT CHARACTERISTICS

The resulting display lists the database entries for each known object,
indicating any proxy access that is enabled for the object. For object MAIL,
the display is shown below.
OBJECT = MAIL
Number
User id
Password
Proxy access

3.14

=
=
=
=

27
NETNONPRIV
TREWQ
outgoing

Monitoring the Network
You can monitor network activity in one of two ways: by using the NCP
command SHOW or by using the event logging facility and the SET
LOGGING command. This section discusses the use of the SHOW and
LIST commands. Refer to Section 2.9 for a discussion of events and event
logging, and Section 3.12 for a description of the SET LOGGING command.
NCP provides commands to display information about network components,
regardless of whether they are defined in the volatile or permanent database.
The NCP command SHOW displays information about components for the
running network. The NCP command LIST performs a similar function,
except that it lets you display and verify information in the permanent
database. In many cases, this information will be a subset of the information
displayed for the volatile database.
In general, the SHOW command allows you to monitor the operation of the
running network. For example, whenever someone changes the state of a
circuit, the configuration of the running network, in terms of reachable and
unreachable nodes, may be changed as well. A circuit failure could have the
same effect. NCP allows you to display the status of network circuits, lines,
modules, and nodes, and thereby to detect such conditions.
When you issue the SHOW and LIST commands, NCP allows you to select
components and display types. You can choose among several display
types, depending on the information you want. The display type determines
the format and type of information that NCP displays. Display types are

3-90

Managing and Monitoring the Network

described below.
CHARACTERISTICS

Includes static information that is usually specified in the
configuration database. Depending on the component,
this information may include the identification of a local
node and relevant routing parameters, the names
and numbers of known network objects, and the
identification and cost of circuits connected to the
local node. For VAX PSI, the information may include
identification of a local DTE and relevant parameters;
packet size, window size, and other network parameter
values; device identification; and timer values.

STATUS

Includes dynamic information that usually reflects
network operations for the running network. Depending
on the component, this information may include the
local node and its operational state, reachable and
unreachable nodes and their operational states, and
circuits with their operational states. For VAX PSI, the
information reflects the operation of the running VAX
PSI software. Depending on the component, this may
include identification of the line with its operational state.

SUMMARY

Includes only the most useful information derived from
both static and dynamic sources. This information
is usually an abbreviated list of information provided
for both the CHARACTERISTICS and STATUS display
types. For VAX PSI, it is usually an abbreviated list of
information provided for the STATUS display type.

EVENTS

Includes information about events currently being
logged for the logging component. This display type
is valid only for the SHOW LOGGING and LIST LOGGING
commands.

COUNTERS

Provides counter information for circuits, lines, modules,
and nodes, including the local node. Counters are
discussed in the sections of this chapter that describe
the circuit, line, module, and node commands.

If you do not specify a display type when issuing a SHOW or LIST command,
SUMMARY is the default. Examples of these display types and their formats
are given in the VAX/VMS Network Control Program Reference Manual.
When you display information about network components, you can use either
the singular or plural form of the component, as shown in the following
example:
NCP>SHOW NODE BOSTON CHARACTERISTICS

NCP>SH0W KNOWN NODES CHARACTERISTICS

For several components, there is a second form of the plural. This form
is the word ACTIVE. Whereas the word KNOWN displays information
for components available to the local node, the word ACTIVE displays
information for all active components—that is, components whose state is

3-91

Managing and Monitoring the Network

other than OFF. Use the word ACTIVE with circuit, line, node, and logging
components. For example, the following command displays the characteristics
for all active nodes in the network:
NCP>SHOW ACTIVE NODES CHARACTERISTICS

The word ADJACENT is also used as a plural in the SHOW NODE command,
as in the following
NCP>SHOW ADJACENT NODES STATUS

All NCP display commands optionally allow you to direct the information
displayed to a user-specified output file. For example:
NCP>SH0W KNOWN LOGGING SUMMARY TO SYS$MANAGER:NET.LOG

This command creates the file SYS$MANAGER:NET.LOG containing
summary information of all known logging for the running network. The
default file type is LIS. If the specified file already exists, NCP appends
the display information to that file. If you do not specify an output file,
SYS$OUTPUT is the default.
NML must have the BYPASS privilege to display passwords for the SHOW or
LIST commands; if it does not, no information will appear if you use SHOW,
and the "no access rights" message will appear if you use LIST.

3-92

DECnet—VAX Host Services

DECnet-VAX can act as the host node in performing the following services
for unattended systems:
•

Downline loading of an unattended system: transferring a copy of an
operating system file image from a VAX/VMS 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 VAX/VMS
node.

•

Downline loading of an RSX-11S task from a VAX/VMS node.

•

Connecting to a remote console: permitting a VAX/VMS terminal to act as
the console for certain unattended systems, such as the DIGITAL Ethernet
Communications Server running Router Server Software.

These operations are described in this chapter. Note that host services are not
available over asynchronous lines.

4.1

Loading Unattended Systems Downline
DECnet-VAX allows you to load an unattended system downline. Downline
loading involves transferring a copy of the file image of a remote node's
operating system from a VAX/VMS node to the unattended target node. For
example, DECnet-VAX permits you to load an RSX-11S operating system
file image from your VAX/VMS node downline to a target node. Downline
loading can be initiated by a VAX/VMS operator or by the target node. Both
procedures are discussed in this section.
To understand downline loading, it helps to distinguish the nodes involved
in the loading sequence. In the node descriptions below, the command node
and the executor node can be the same or different nodes, but cannot be the
target node.
•

Command node. An operator-initiated downline load request originates
at the command node. You use either the NCP command LOAD or
TRIGGER to initiate this request.

•

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

•

Target node. The target node receives the bootstrap loaders and the
system image file.

4-1

DECnet—VAX Host Services

4.1.1

Downline System Load Operation
Downline loading is initiated in one of two ways: either an operator initiates
the operation with the NCP command LOAD or TRIGGER, or the target
node initiates the operation by triggering its bootstrap ROM and sending
a program load request to the executor node. With an operator-initiated
load, the executor starts the operation by sending either a trigger message (if
necessary) or a load file to the target node. Essentially, the trigger message
provides the restart capability for an unattended target node. Once the target
node is triggered, it will then load itself in whatever manner its primary
loader is programmed to operate. This could include requesting a downline
load from either the executor that just triggered it or another adjacent node;
the target node could also load itself from its own mass storage device.
DECnet uses the maintenance operation protocol (MOP) to perform a
downline load operation. MOP is the protocol used by the network
management portion of DNA to perform maintenance functions such as
circuit testing, triggering, upline dumping, and downline loading. Once
triggered, the target node usually sends MOP program request messages
requesting a program to be loaded.
If the load is target initiated, DECnet-VAX detects MOP messages coming
over the circuit and sets the circuit's state to AUTOSERVICE. NML uses the
MOM subprocess named MOM_circuit-id_process-number (for example,
MOM_UNA-O_l) to perform the load. NML, through that subprocess,
searches the volatile database for a node entry with a service circuit that
matches the circuit over which the message was received, and, if it is an
Ethernet circuit, an Ethernet address that matches the Ethernet source
address from which the message was received. NML then performs the
load operation. In this manner, NML provides the control mechanism for the
loading process. Figure 4-1 illustrates this loading process.
If the target on an Ethernet circuit does not have a specific node from which
to request a program load (for example, if the target's loading 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-00-01-00-00 (described in
Section 3.3.4.4). This message is a request for any node on that Ethernet
to perform the load.

2 The nodes on the Ethernet whose circuits are enabled to perform service
functions check their own databases for a remote node entry whose
Ethernet hardware address matches that of the target node to determine
if they can load the target downline. 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).

3 The target choses 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.
Conversely, an operator-initiated load using NCP directly requests NML to
perform the load operation. The target node's primary bootstrap may or 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. Figure 4-2 illustrates the loading process.

4-2

DECnet—VAX Host Services

Figure 4-1

Target-Initiated Downline Load

BOSTON
(EXECUTOR NODE)

NYC
(TARGET NODE)
ZK-550-81

Use the NCP command LOAD or TRIGGER to perform an operator-initiated
downline load. The TRIGGER command allows you to directly trigger the
remote node's bootstrap ROM, which causes the target node to send its host
a request for a load operation. The programs to be loaded may come from a
local disk file on the target node, another adjacent node, or the executor node.
Note that the TRIGGER command may or 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 the local disk may result.
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 volatile
database. With this information, the executor is thereby able to control the
load sequence.
Section 4.1.2 describes the TRIGGER and LOAD commands, their parameters,
and examples of their use.

4-3

DECnet-VAX Host Services

Figure 4-2

Operator-Initiated Downline Load

NCP Commands:
TRNTO

(COMMAND NODE)

NCP>SET EXECUTOR NODE BOSTON

NYC

(TARGET NODE)
ZK-549-81

4.1.1.1

Load Sequence
The load sequence is the same, regardless of whether the request was initiated
by the operator or the target node. 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, UNA, or QNA). Once the target node's
primary loader is triggered, the target node sends a message to the executor
node requesting a program load. This program may come directly from the
executor or from a remote node. 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 system. In this sequence, each
program requests the next one until the operating system is loaded.

4—4

DECnet—VAX Host Services

The secondary loader is small and is always sent as a single message. The
tertiary loader and the operating system are larger and are sent in segments.
For both of these latter two, the last segment is 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.

4.1.1.2

Load Requirements
Prior to attempting a downline load operation, you must ensure that nodes,
lines, and circuits meet the following requirements:
•

The target node must be connected directly to the executor node. The
executor node provides the line- and circuit-level access.

•

The primary loader must either be a cooperating program in the target
or in the microcode of the target's device (DMC, DMR, DMP, DMV, or
UNA). The downline load operation usually involves loading a series of
bootstraps, each of which requests the next program until the operating
system itself is loaded.

•

The executor must have access to the load files. The location of the files
can be either specified in the load request or defaulted to in the volatile
database. Remote files are obtained through remote file access operations.
(Refer to the examples in Section 4.1.2.4.)

•

The target node must be able to recognize the trigger operation or must be
triggered manually.

•

The circuit involved in the load operation must be enabled to perform
service functions. It must also be in the ON or SERVICE state; a
multiaccess Ethernet circuit must be in the ON state. For example, the
following command readies circuit DMC-0 for downline loading node
BANGOR in our network example:
NCP>SET CIRCUIT DMC-0 SERVICE ENABLED STATE ON

•

You must turn the line to ON and specify a service timer for the line. This
timer sets the MOP timeout constant for retransmission if necessary. This
is the method by which MOP handles error recovery. The default for the
service timer is 4000 milliseconds. In the example below, the command
sets the retransmission frequency to 5000 milliseconds and turns on line
DMC-0.
NCP>SET LINE DMC-0 SERVICE TIMER 5000 STATE ON

Refer to the Maintenance Operation Protocol Functional Specification for a
complete description of MOP error recovery.

4.1.2

Operator-Initiated Downline Load Parameters
The most convenient method of downline loading involves setting default
information in the volatile database. The operator can use the NCP command
SET NODE to establish default information for the target node in the
volatile database. These default parameters are also used for target-initiated
downline loads, though the MOP program load message can override some
of the defaults. (This default method is discussed later in this chapter.)
Alternatively, you can override the default by specifying several parameters
for the NCP commands TRIGGER or LOAD. This section describes each
parameter and illustrates its use.

4-5

DECnet—VAX Host Services

4.1.2.1

TRIGGER Command
The TRIGGER command triggers 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 specific circuit. To bring up the system at the target
node, use either the TRIGGER NODE or TRIGGER VIA command. 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 volatile database. To identify
the target node in the volatile database, specify the SET NODE command
with the appropriate SERVICE CIRCUIT parameter, which establishes the
circuit to be used for loading.
The command below triggers node BANGOR in the network example.
NCP>TRIGGER NODE BANGOR VIA DMC-0

Note that this command specifies a DDCMP circuit over which the operation
is to take place. Figure 4-3 also illustrates the use of the TRIGGER command
for downline loading over a DDCMP circuit in the network example.
If downline loading is to occur over an Ethernet circuit, the executor node
uses the Ethernet physical address of the target node to distinguish it from
other adjacent nodes on the same Ethernet circuit. The PHYSICAL ADDRESS
parameter for the target node is required in the TRIGGER VIA command and
optional in the TRIGGER NODE command.
If you do not specify an Ethernet physical address in the TRIGGER NODE
command, DECnet-VAX derives one from the target's node number and
attempts to trigger the node. A target node that is running DECnet software
has set its own Ethernet physical address and recognizes the address;
otherwise, the target node recognizes only the Ethernet hardware address
set by the manufacturer. If unsuccessful in triggering the node, DECnetVAX attempts to use the Ethernet hardware address of the target node from
the volatile database to trigger it. You can set in the volatile database the
Ethernet hardware address originally assigned to the target node's DEUNA
or DEQNA controller by specifying the HARDWARE ADDRESS parameter in
the SET NODE command. (Refer to Section 3.3.4 for a description of Ethernet
addressing.)
Figure 4-4 illustrates the use of the TRIGGER NODE command for downline
loading a target node over Ethernet circuit UNA-0.
When you use the TRIGGER command, it may not always be obvious how
the system load is performed. Essentially, this command provides the trigger
message that controls the restart capability for an unattended target node.
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 that just triggered it or another
adjacent node, or the target node could load itself from its own mass storage
device.
One parameter that you can specify for the TRIGGER command is SERVICE
PASSWORD. This parameter supplies a boot password, which may be
required by the target node (see Section 4.1.2.9). If you do not specify this
parameter, a default value from the volatile database is used. Use the SET
NODE command to establish a default value for this parameter in the volatile
database. If no value is set in the volatile database, the value is 0.

4-6

DECnet—VAX Host Services

Figure 4—3

Operator-Initiated Downline Load over DDCMP
Circuit (TRIGGER Command)

BANGOR
(Target Node)

BOSTON
(Executor Node)

DENVER

NYC
NCP Commands:
NCP>SET EXECUTOR NODE BOSTON
NCP>SET LINE DMC-1 STATE ON
NCP>SET CIRCUIT DMC-1 STATE ON
NCP>TRIGGER NODE BANGOR SERVICE PASSWORD FEFEFEFE
/K 1887 84

4.1.2.2

LOAD Command
Use the LOAD NODE and LOAD VIA commands to load software downline
to a target node. For example, the following command loads node BANGOR:
NCP>LOAD NODE BANGOR

4-7

DECnet—VAX Host Services

Figure 4—4

Operator-Initiated Downline Load over Ethernet
Circuit (TRIGGER Command)

UNA-0

BOSTON
(EXECUTOR NODE)

TARGET
(TARGET NODE)

NCP Commands:
NCP>SET LINE UNA-0 STATE ON
NCP>SET CIRCUIT UNA-0 STATE ON
NCP>TRIGGER NODE TARGET PHYSICAL ADDRESS AA-00-04-00-CB-04 VIA UNA-0
ZK-1213-82

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 volatile database entry for the target node. You must use
the SET NODE command to include the SERVICE CIRCUIT entry in the
volatile database. Alternatively, you can explicitly include the circuit in the
command LOAD NODE BANGOR VIA DMC-0.
You could also use the LOAD VIA command to specify the circuit over
which to perform a downline load. For example, to load using circuit DMC-0
connected to the executor node, issue the command
NCP>L0AD VIA DMC-0

The executor node obtains the rest of the necessary information from its
volatile database. The LOAD NODE and LOAD VIA commands will work
only if the target node can be triggered by the executor or if the target has
been triggered locally.
If the loading circuit is a multiaccess Ethernet circuit, the executor node uses
the Ethernet physical address of the target node to differentiate the node
from other adjacent nodes on the same Ethernet. The PHYSICAL ADDRESS
parameter must be specified in the LOAD VIA command (which does not
identify the target node) and can optionally be specified in the LOAD NODE
command.
If you do not specify the PHYSICAL ADDRESS parameter in the LOAD
NODE command, DECnet-VAX derives the Ethernet physical address from
the target node number and attempts to load the target node. A target node
that is running DECnet software has set its own Ethernet physical address
and will recognize this address; otherwise, the target node will recognize
only the Ethernet hardware address set by the manufacturer. If unsuccessful
in loading the node, the executor node will attempt the load using the
Ethernet hardware address of the target node from the volatile database.
4-8

DECnet—VAX Host Services

You can set in the volatile database the Ethernet hardware address originally
assigned to the target node's DEUNA or DEQNA controller, by specifying the
HARDWARE ADDRESS parameter in the SET NODE command. (Refer to
Section 3.3.4 for a description of Ethernet addressing.)
Figure 4-5 illustrates the use of the LOAD command for downline loading
over Ethernet circuit UNA-0.
Figure 4-5

Operator-Initiated Downline Load over Ethernet
Circuit (LOAD Command)

UNA-0

r-1

BOSTON
(EXECUTOR NODE)

TARGET
(TARGET NODE)

NCP Commands:
NCP>SET NODE TARGET SERVICE CIRCUIT UNA-0
NCP>SET LINE UNA-0 STATE ON
NCP>SET CIRCUIT UNA-0 STATE ON
NCP>LOAD NODE TARGET PHYSICAL ADDRESS AA-00-04-00-CB-04

ZK-1214-82

If you choose to override the default parameters for the LOAD commands,
you can control the following aspects of the load sequence:
•

The host node that the target node is to use once the target comes up
HOST node-id

•

The identification of the load file
FROM file-id

•

The identification of the loader programs
SECONDARY LOADER file-id
TERTIARY LOADER file-id

•

The software type to be loaded downline first
SOFTWARE TYPE software-type
The software-type can be any of the following:
SECONDARY LOADER
TERTIARY LOADER
SYSTEM

4-9

DECnet—VAX Host Services

If the software-type is not specified in the first MOP program request,
the NCP command, or the volatile database, the default is SECONDARY
LOADER.
•

The identification of the CPU type and the corresponding software
identification
CPU cpu-type
SOFTWARE IDENTIFICATION software-id

•

The identification of the target node's line device type that is to handle
service operations
SERVICE DEVICE device-type

•

The identification of the service password for triggering the target node's
bootstrap mechanism
SERVICE PASSWORD hex-password

When issuing the LOAD NODE and LOAD VIA commands, you can specify
any or all of the parameters listed above. Any parameter not specified in
the command defaults to whatever information is specified in the volatile
database. Use the SET NODE command to establish default information for
the target node's parameters in the volatile database.

4.1.2.3

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-id 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 the host to node NYC once node BANGOR comes up as a network
node (if BANGOR has the necessary DECnet software):
NCP>SET NODE BANGOR HOST NYC

If the host is unspecified, the executor serves as the default host. You can
override any default information by using the HOST parameter for the LOAD
command.

4.1.2.4

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. You can specify default load file names in the
volatile database with the SET NODE command. Load files default to
SYS$SYSTEM:filename.SYS. If the files are on another node, specify node-id::
at the beginning of the file specification.
Figure 4-6 illustrates the use of the LOAD NODE command for loading a
target node over a DDCMP circuit.
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
files are selected according to the service device type on the target system, not
by the device type on the executor. The default secondary and tertiary loader
files are as listed in Table 4-1. The DECnet-llS kit includes the files listed in
Table 4-1.

4-10

DECnet—VAX Host Services

Figure 4-6

Operator-Initiated Downline Load over DDCMP
Circuit (LOAD Command)
BANGOR
(Target Node)

NYC
NCP Commands:
NCP>SET EXECUTOR NODE BOSTON
NCP>SET LINE DMC-1 STATE ON
NCP>SET CIRCUIT DMC-1 STATE ON
NCP>LOAD NODE BANGOR FROM NYC::SYS$SYSTEM:RSX11 S.SYS
ZK 1868-84

If load file names are not specified in the target's load request, the NCP
command LOAD or the volatile database, NML will provide them by
concatenating the service device with the prefix SEC or TER. For example,
if the service device is a DMC, NML uses the file names SECDMC.SYS and
TERDMC.SYS.

4-11

DECnet—VAX Host Services

Table 4-1

Default Loader Files by Target Device Type

Device Type

Secondary Loader

Tertiary Loader

DP11

SECDP.SYS

TERDP.SYS

DL1 1

SECDL.SYS

TERDL.SYS

DU 1 1

SECDU.SYS

TERDU.SYS

DQ1 1

SECDQ.SYS

TERDQ.SYS

DUP1 1

SECDUP.SYS

TERDUP.SYS

DMC1 1

SECDMC.SYS

TERDMC.SYS

DUV11

SECDUV.SYS

TERDUV.SYS

DPV

SECDPV.SYS

TERDPV.SYS

SECDA.SYS

TERDA.SYS

DMP

SECDMP.SYS

TERDMP.SYS

DMV1 1

SECDMV.SYS

TERDMV.SYS

QNA

SECQNA.SYS

TERQNA.SYS

UNA

SECUNA.SYS

TERUNA.SYS

If, however, 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.

4.1.2.5

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 a tertiary loader file, which in turn
would load the operating system image, you would use the command below.
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.

4.1.2.6

CPU and Software Identification
The software identification is the default program name of the operating
system to be loaded downline. Use the SOFTWARE IDENTIFICATION
parameter to specify a software-id of up to 16 alphanumeric characters. For
example, in the following command the CPU parameter specifies the default
processor type to be loaded downline:
NCP>SET NODE BANGOR SOFTWARE IDENTIFICATION RSX_11S_V3.2

4—12

DECnet—VAX Host Services

4.1.2.7

Service Device Identification
The service device is the controller on the target node end of a service circuit.
The service device handles downline loading in a variety of ways, depending
on the device used. In particular, this device influences the type of files
suitable for downline 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 downline
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 a DMC device controller.
NCP>SET NODE BANGOR SERVICE DEVICE DMC

By using the SERVICE DEVICE parameter for the LOAD command, you can
override the service device default information.

4.1.2.8 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 these 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.

4.1.2.9

Service Passwords
When defining nodes for downline 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 following ranges:
•

For DMC/DMR/DMP/DMV, the range is 0 to FFFFFFFF

•

For UNA/QNA, the range is 0 to FFFFFFFFFFFFFFFF

For example, to load node BANGOR on circuit DMC-1:
NCP>SET NODE BANGOR SERVICE PASSWORD FEFEFEFE
NCP>LOAD NODE BANGOR

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

4-13

DECnet—VAX Host Services

4.2

Dumping Memory Upline from an Unattended System
As a DECnet-VAX system manager, you can include certain SET NODE
parameters in the volatile database that will allow an adjacent unattended
node to dump its memory into a file on your VAX/VMS system. This
procedure is referred to as upline dumping. It is a valuable tool for crash
analysis; that is, programmers can analyze the dump file and determine why
the unattended system failed. When an unattended system that selected the
appropriate support at system generation detects an impending system failure,
that system will request an upline dump; for example, an RSX-11S system
may request an upline memory dump to a VAX/VMS system.
For upline dump operations, the local VAX/VMS node is referred to as the
executor and the adjacent unattended node as the slave.

4.2.1

Upline Dump Procedures
This section describes the procedures for an upline dump initiated by a
slave 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) that sends messages used for
circuit testing, triggering, downline loading, and upline dumping. Refer to the
Maintenance Operation Protocol Functional Specification for a more complete
discussion.
There are four steps involved in the upline dump process. The actual dump
takes place by repeating step 3.
1

When a slave node senses a system failure, it sends a memory dump
request to the VAX/VMS host node, or, on Ethernet, to a dump assistance
multicast address if an Ethernet host is not available (see below). The
request is a MOP request dump service message. This message might
contain information about the slave's memory size (DUMP COUNT) and
the upline dump device type at the slave.

2 If the message from the slave includes a DUMP COUNT value, the host
node uses it. Otherwise, the host node checks the slave 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 (DUMP FILE) for the slave. (If no entry exists for DUMP
ADDRESS, the value defaults to 0.) The host node, which can now be
considered the executor, sends a MOP request memory dump message to
the slave with the starting address and buffer size values.

3 Using the values it received from the executor, the slave 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 slave. 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.

4 Once the upline dump is completed, the executor node automatically
attempts to downline load the slave system. It initiates the downline load
by sending a TRIGGER message to the slave (see Section 4.1).
Figure 4-7 illustrates the upline dump procedure.

4-14

DECnet—VAX Host Services

Figure 4-7

Upline Dumping of RSX-11S Memory

BOSTON
(HOST NODE)
VAX/VMS

ZK-554-81

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:

4.2.2

The target node sends a memory dump request to the Ethernet dump
assistance multicast address AB-00-00-01-00-00 (described in Section
3.3.4.4). 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 choses 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. See the VAX/VMS Network Control Program
Reference Manual for a summary of all NCP events.

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

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

•

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

4-15

DECnet—VAX Host Services

•

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 DMC-0 for upline dumping node
BANGOR in the network example:
NCP>SET CIRCUIT DMC-0 SERVICE ENABLED STATE ON

•

If the slave does not supply the DUMP COUNT value, the executor must
have this value in its volatile database.

•

The executor must have a DUMP FILE entry in the volatile database. If
the file-id specifies a remote node, the executor transfers the data using
remote file access routines.

•

Upline dumping cannot occur unless you define a service timer for the
line. This timer sets the timeout constant for retransmission, enabling
MOP to handle error recovery. For example, to set the retransmission
frequency to 5000 milliseconds for line DMC-0, issue the command
NCP>SET LINE DMC-2 SERVICE TIMER 5000

4.3

Loading RSX-11S Tasks Downline
Downline task loading extends nonresident initial task load, checkpointing,
and overlay support to a DECnet RSX-1 IS node. You can load an RSX-1 IS
task downline by using the Satellite Loader (SLD) on the DECnet-llS node
and the host loader (HLD) on the DECnet-VAX node. SLD uses the intertask
communication facilities of RSX DECnet-llS to communicate with HLD.
Figure 4-8 illustrates one instance of this relationship.
By entering RUN TLK at the operator's console of the satellite system, SLD
requests HLD to load the task downline from a DECnet-VAX node on which
the file is located. Any request from the satellite or host node could also
initiate this operation by means of SLD and HLD.

4.3.1

Setting Up the Satellite System
You build the SLD task during the RSX-1 IS NETGEN procedure. (Refer
to the DECnet-RSX Network Generation and Installation Guide.) To allow
downline task loading, issue the appropriate commands to the RSX-1 IS
system image. Use VMR to install and fix SLD into the RSX-1 IS system, as
shown below.
>VMR
ENTER FILENAME:RSX1IS
VMR>INS SLD
VMR>FIX LDR...

This sequence of commands establishes SLD as the loading task (LDR...) for
the executive.
Note: The information in this section is specific to DECnet-RSX. Refer to the
related DECnet-RSX documentation.

DECnet—VAX Host Services

Figure 4-8

Downline Task Loading

BOSTON

Command:

(HOST NODE)

VAX/VMS

>RUN TLK

(HLD.DAT file containing HTASK$ TLK)

NYC
(SATELLITE NODE)

RSX-11S
ZK-553-81

If the RSX-11S system is to be loaded downline, any tasks to be downline
loaded to or checkpointed from the RSX-11S system must be installed, but
not fixed, using VMR. For example:
>VMR
ENTER FILENAME:RSX1IS
VMR>INS TLK

In this example, entering RUN TLK on a terminal of the RSX-11S remote
system initiates the downline task load of the file TLK.TSK.
If the RSX-11S system will not be loaded downline, you must specify the
node to which SLD will connect, using the VNP command SET EXECUTOR
HOST (see the DECnet-RSX System Manager's Guide). For example, you could

4-17

DECnet—VAX Host Services

use the command below, where 11 is the number of the node BOSTON on
which HLD resides:
>VNP RSX11S
VNP>SET EXECUTOR HOST 11

4.3.2

Host Loader Mapping Table
The Host Loader has a mapping table that is a special user-defined file
(HLD.DAT) that resides in the SYS$SYSTEM directory. The format of the
mapping table is as follows:
HLDTB$
HTASK$
HTASK$
HN0DE$
HTASK$
HTASK$
HN0DE$
HTASK$
.END

TLK,<TRNT0::SYS$DISK:[LOW]TLK>,UNM
TLK.<SYS$DISK:[LOW.EXT]TLK>,MAP
BANGOR
NCP,<SYS$DISK: [LOW]NCP11S>,LUN
...LOA,<SYS$DISK:[TEST]L0A>
NYC
...MCR,<LB:[RSX1IS.UNMAPPED]BASMCR>

The keywords for this table are defined below.
HLDTBS

Defines the file as the HLD mapping table.

HTASKS

Defines a task entry. The arguments for HTASK$ are
taskname, <file-spec> ,[opt-arg]

HNODES

taskname

Is the installed task name used to run the task on the
RSX-1 IS system.

file-spec

Is the task file specification on the host node. You
must use angle brackets ( <> ) to enclose the file
specification.

opt-arg

Are optional arguments—MAP^NIVLLUN

Defines the exclusive target node upon which the following HTASKS
can execute.

This table is almost identical in structure to a MACRO-11 source module used
by DECnet-RSX to define its downline task loading tables. Note, however,
that HLD.DAT is accessed directly as a text file and is neither assembled
nor task built. The organization of the mapping table and special features is
described below.

4-18

•

A task entry contains the name of the installed task, a file specification,
and an optional control argument. The file specification in the HTASK$
macro can omit the file type that defaults to TSK. A node entry contains
only the node name.

•

Any task entries that precede the first node entry are called generalpurpose tasks. You can load a general-purpose task into any RSX-1 IS
node in the network. Task entries that follow a node entry can only be
sent to that particular node.

•

The same task name can appear more than once in the general-purpose
task list. This allows both mapped and unmapped RSX-1 IS systems to
share installed task names. The control argument for a general-purpose
task is either MAP or UNM. The default is MAP.

DECnet—VAX Host Services

4.3.3

•

Tasks to be loaded downline must be installed in the RSX-11S system,
which initializes the task's logical unit number (LUN) assignments. LUNfixing is an SLD feature that reinitializes the LUNs after the task has
been loaded downline. This feature allows a single task to be loaded into
multiple RSX-11S systems that may have different system-wide device
assignments. SLD permits you to place a task in a general-purpose task
list. You can downline load either a general-purpose task or a task after a
node entry.

•

If you place a task in a general-purpose task list, you can add new nodes
to the network and can downline load general-purpose tasks to those
nodes without changing the mapping table. Nodes that are to receive
only general-purpose tasks need not be mentioned in HLD.DAT. Note,
however, that general-purpose tasks cannot be checkpointed.

HLD Operation and Error Reporting
When SLD attempts to connect to HLD, NETACP on the DECnet-VAX node
uses the default inbound access control information specified for the HLD
object by the system manager (see Section 3.13). You must make sure that
the files associated with the tasks to be loaded or checkpointed are accessible
from the resulting process created by this connection.
When the load operation completes, whether successfully or unsuccessfully,
the log file SYS$LOGIN:NETSERVER.LOG (described in Section 2.6.3)
contains information describing the operation, the node, and the task. This
information may consist of an error returned from RMS or certain HLDspecific messages that indicate either errors in HLD.DAT or inconsistencies in
the file to be loaded. Messages associated with these inconsistencies are listed
below.

4.3.3.1

HLD Error Messages
The following is a list of HLD error messages.

Format error in HLD.DAT
The format of the HLD mapping table is incorrect. For example, this error
could occur if HNODE$ was expected but not found in the table. Re-create
the table with the appropriate format.

Syntax error in HLD.DAT
The syntax of an element in the HLD mapping table is incorrect. For example,
you do not have angle brackets enclosing the file specification. Re-create the
table.

Task name not found
The task to be loaded downline is not specified in the HLD mapping table.
Re-create the table such that it contains this task name.

No header in task file
The file was built with the /-HD switch. Hence it is not a valid RSX-11S task
image. Rebuild the task.

Mapped task not on 4K boundary
The file was not built with the /MM switch. This error is for mapped
RSX-11S systems only. Rebuild the task.

4-19

DECnet-VAX Host Services

Unmapped partition mismatch
The TKB address does not correspond with the starting address of the
partition in the RSX-11S system. This error is for unmapped RSX-11S
systems only. Rebuild the task with a PAR= statement that specifies the
correct starting address.

File too big for partition
The initial load size of the file is larger than the partition size in the RSX-11S
system. Either make the partition larger or rebuild the file to use a smaller
partition size.

Partition too big for checkpoint space
The partition size in the RSX-11S system is larger than the checkpoint space
inside the file. Typically, this indicates that the partition size in your PAR=
statement is smaller than the actual size of the partition in the RSX-11S
system. Although the load size of a task may be much smaller than its
partition, the entire partition is transferred during checkpoint operations.
Rebuild the task with the exact partition size from the RSX-11S system.

4.3.4

Checkpointing RSX—11S Tasks
Checkpointing allows the execution of a task to be interrupted when a higher
priority task installed in the same partition becomes active. The software
writes the interrupted task from RSX-11S memory to a checkpoint file on the
host (Checkpoint Write) and then it loads the higher priority task into the
partition and activates it. When the priority task exits, the software restores
the interrupted task into main memory (Checkpoint Read), where it continues
executing.
Note that checkpointing implies that a job is already running in the partition.
Checkpoint space must be allocated inside the task being loaded downline
(through the /AL switch during RSX-11S task build).

4.3.5

Overlaying RSX—11S Tasks
Overlaying allows the execution of segments of a task in order to reduce the
memory or address space requirements for that task to run on an RSX-11S
system. SLD and HLD handle the reading of overlay segments by satellite
systems.

4.4

Connection to Remote Console
DECnet-VAX allows you to set up a logical connection between your
VAX/VMS 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 Router Server. The console carrier requester on the host connects to the
console carrier server on the server.

4-20

DECnet—VAX Host Services

You can set up the logical connection to the console using the remote console
facility (RCF). Both your host node and the target node (that is, the server
node) must be on the same Ethernet. You can use the RCF to force a crash
if the server node should become unresponsive. (To determine how to force
a crash, see the appropriate documentation for the particular server product.)
RCF also permits debugging under special circumstances.
To use the RCF, you must be sure the console carrier server image and its
loader file are present in the system directory on the host node. (The file
name of the console carrier server image is PLUTOCC.SYS and that of the
loader is PLUTOWL.SYS.) To invoke RCF, specify either the CONNECT
NODE or CONNECT VIA command. VAX/VMS then uses the loader
file to downline load the console carrier server image into the Ethernet
Communications Server hardware unit.
Use the CONNECT NODE command if the name of the target node is
known. If the target node's service password and service circuit are defined
in the host node's volatile database, you can use these default values. If the
Ethernet hardware address of the server node is not defined in the volatile
database, you must specify the PHYSICAL ADDRESS parameter in the
CONNECT NODE command. Should you specify the Ethernet physical
address of the target node, DECnet-VAX attempts to use it to load the image
file. If you do not supply an Ethernet address, DECnet-VAX derives an
Ethernet physical address from the target node number, first attempting to
use this address, and then attempting to use the Ethernet hardware address.
To define default information for the target node in the volatile database,
use the NCP command SET NODE to specify the SERVICE PASSWORD,
SERVICE CIRCUIT, and HARDWARE ADDRESS parameters for the target
node. You can override the target node parameter values currently defined in
the volatile database by specifying new values in the CONNECT command.
For example, to connect your VAX/VMS terminal to the console interface on
server node RTRDEV, whose Ethernet physical address on circuit UNA-0 is
AA-00-04-00-38-00, issue the command
NCP>CONNECT NODE RTRDEV SERVICE PASSWORD FEFEFEFEFEFEFEFE _ SERVICE CIRCUIT UNA-0 PHYSICAL ADDRESS AA-00-04-00-38-00

Use the CONNECT VIA command if the node name of the target node is not
known. In this command, you must specify the service circuit over which
the logical connection is to be made and the Ethernet physical address of the
target node.
If you have not defined the hardware address of the server node in the
volatile database and have not specified the Ethernet physical address of the
node in the CONNECT command, DECnet-VAX displays an error message
on your terminal as follows:
Hardware address required

The above message indicates that you must specify an Ethernet address for
the target node in your CONNECT command, since no hardware address is
available in the volatile database.
In addition to the messages DECnet-VAX NCP or MOM may issue during
downline loading of the console carrier server code, other messages described
below may be issued when you attempt to connect to a remote console:
Console in use

4-21

DECnet—VAX Host Services

The remote console has already been reserved for another purpose. Try to
make the connection later.
Console connected (press CTRL/D when finished)

The RCF is now ready for use. CTRL/B is used to pass a break character to
the remote console. CTRL/D terminates the console session and causes the
NCP prompt to be displayed.
Target does not respond

The remote console is supposed to respond quickly to inputs but is not doing
so, or no connection can be made.

4-22

PART III: Network Configuration,
Installation, and Testing

Configuration of a Network

This chapter explains how to set up your VAX/VMS system for use in a
DECnet-VAX network and provides sample configuration examples for
various types of networks.

5.1

Prerequisites for Establishing a Network
Before configuring your DECnet-VAX node, you need to satisfy certain
prerequisites for DECnet-VAX operation, such as setting up user accounts and
directories, defining user privileges, and installing the key to your DECnetVAX license. (Note that a DECnet-VAX license is required only if you are
planning to run DECnet in a multinode environment.)
If you are configuring VAX PSI, you must install it and define the privileges
required for VAX PSI operation. If you are configuring VAX PSI in multihost
mode (instead of native mode), you must install the VAX PSI multihost
software on the VAX/VMS connector node that will serve as an X.25
gateway, and the VAX PSI Access software on each host node that will
use the connector node.

5.1.1

User Accounts and Directories
In addition to creating normal user accounts in the user authorization file
(UAF), you should also create a default nonprivileged DECnet account that
can be used for activating network objects on the local node. DECnet-VAX
uses the access privileges of this account when access control information has
not been explicitly supplied by the network user. Section 3.13 discusses
access control and the use of default accounts. Refer to the VAX/VMS
System Manager's Reference Manual for a description of how to create and
use directories.
The following example illustrates commands to establish a default
nonprivileged DECnet account. If you use NETCONFIG.COM to configure
your node and request a default nonprivileged DECnet account, the account
will be created for you automatically (see Section 5.2.1.2).
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF>ADD NETN0NPRIV/PASSW0RD=N0NPRIV/DEVICE=DISK$USER1:_ /DIRECTORY=[NETUSER]/UIC=[200.200]/PRIVILEGE=(TMPMBX.NETMBX)_ /FLAGS=(CAPTIVE)/NOBATCH/NOINTERACTIVE/LGICMD=NL:
UAF>EXIT
$ CREATE/DIRECTORY DISK$USER1:[NETUSER]/0WNER_UIC=[200.200]

Note that you must substitute your own device name in place of DISK$USER1
when you set up the default nonprivileged DECnet account.
If you are configuring VAX PSI, ensure that you have the necessary PSI
accounts, and the required directories associated with these PSI accounts,
which will be used for incoming calls to your local DTE. You should also
specify account information to activate objects at the local DTE for use by
VAX PSI.
5-1

Configuration of a Network

5.1.2

Required Privileges
To perform any kind of network activity, a process must have the privileges
required to access the network processes involved in the activity requested.
As system manager, you define a user's privileges in the UAF. The privileges
listed in Table 5-1 are at times required by the Network Management Listener
(NML) and by those users of DECnet-VAX who are running NCP. The
privileges listed in Table 5-2 are those required at times by both network
users and system managers for VAX PSI operations.
Table 5-1

5—2

Required DECnet-VAX Privileges

Privilege

Description

ACNT

Allows you to create subprocesses or detached processes in
which accounting is disabled. ACNT is required to start the
network.

BYPASS

Allows you to view passwords that would not otherwise be
displayed by the NCP commands SHOW or LIST.

CMKRNL

Allows a process to change its access mode to kernel, execute
a specified routine, and then return to its original access mode.
Specifically, you need CMKRNL to start the network.

DETACH

Allows you to create detached processes by executing the
SCREPRC system service. DETACH is required to bring up the
network.

NETMBX

Allows you to assign a channel to the NET device. This privilege
is required to create a logical link or to perform any ACP control
QIO functions. NETMBX is the minimum requirement for all
accounts running network programs.

OPER

Allows you to perform certain operator functions such as
modifying the configuration database. (Refer to the VAX/VMS
System Manager's Reference Manual for a detailed explanation
of the functions available under this privilege.) NML requires
this privilege to modify any network parameters in the volatile
database.

TMPMBX

Allows you to create temporary mailboxes. If you have this
privilege, you can use the SCREMBX and SASSIGN system
services to create a temporary mailbox and assign an I/O
channel for task-to-task communication. Unlike a permanent
mailbox, which must be explicitly deleted, a temporary mailbox is
automatically deleted when no more channels are assigned to it.
TMPMBX is required for the default accounts and to run both NML
and NCP.

SYSNAM

Allows you to declare a name or object number in a user task (see
Chapter 8 for information on user tasks).

SYSPRV

Allows you to access the permanent database.

Configuration of a Network

Table 5-2

Required VAX PSI Privileges

Privilege

Description

SECURITY

Allows a system manager to access the VAX PSI security
databases.

DIAGNOSE

Allows a system manager to use diagnostic functions. You can
use it to run online diagnostic programs. DIAGNOSE is required if
you want to perform line loop tests.

NETMBX

Allows a network user to assign a channel to the NW device.
This channel is required to set up virtual circuits or to perform
any ACP control QIO functions. Either NETMBX privilege or the
PSI$X25_USER right is required for processes running network
programs.

OPER

Allows a system manager to use the NCP commands. A detailed
explanation of the NCP functions available under this privilege
is given in the VAX/VMS Network Control Program Reference
Manual.

TMPMBX

Allows a network user to create temporary mailboxes, that is, use
the $ASSIGN system service to create a temporary mailbox and
assign an I/O channel for DTE-to-DTE communication. Unlike a
permanent mailbox, which must be deleted explicitly, a temporary
mailbox is deleted automatically when no more channels are
assigned to it.

SYSPRV

Allows a system manager to create and display objects.

Refer to Section 3.13 for a further discussion of network user privileges and
their function in relation to overall network security.

5.2

Configuration Procedures
Before you install DECnet-VAX on your system, there are certain tasks
that you, as system manager, must complete to prepare for a networking
environment.
You must configure your DECnet-VAX permanent database. You can use
the interactive procedure NETCONFIG.COM provided by Phase IV DECnetVAX to do this. NETCONFIG.COM will prompt you for all the information
needed to configure the permanent database and set up an optional default
nonprivileged DECnet account on your system. If you choose not to use
NETCONFIG.COM, you must use NCP commands to build the permanent
database. Alternatively, you can use NCP commands to tailor the permanent
database created by NETCONFIG.COM to your own needs. Also, you can
use the NCP command COPY KNOWN NODES to build or update the
remote node entries in your node database. Special considerations that apply
to configuration of the permanent database for a VAXcluster node are given
in Section 5.4.5.
You may have to perform additional configuration tasks depending upon your
specific network requirements. If you plan to run DECnet-VAX over a Cl,
you must install the DECnet driver CNDRIVER. If you will be using some of
your terminal lines as DECnet-VAX lines, you must install the asynchronous
DDCMP driver NODRIVER and set up the static or dynamic asynchronous
lines. Section 5.2.2 describes these tasks in detail.
Refer to the MicroVMS User's Manual if you will be configuring one or more
MicroVMS systems as part of the network.

5—3

Configuration of a Network

If VAX PSI is to be run, the system manager is responsible for configuring
VAX PSI for the local DTEs. This involves supplying information about
various VAX PSI components, such as circuits, lines, modules, and objects.
The information is contained in the DECnet-VAX configuration database for
the local node (if both DECnet-VAX and PSI are configured) and in the PSI
configuration database for the local DTEs. You use NCP commands to supply
information to the configuration database.

5.2.1

Using NETCONFIG.COM
NETCONFIG.COM performs the following steps:
1

Prompts you for the name and address of your node and asks whether or
not you want a default nonprivileged DECnet account and whether you
want to operate as a router or an end node.

2 Determines which DECnet devices you have on your system.
3 Creates and displays the NCP and DCL commands required to configure
your DECnet-VAX node.

4 Executes the commands displayed, if they are accepted, setting the
appropriate parameters in the permanent configuration database at your
node. This procedure establishes all databases (executor, line, circuit,
object, logging) except for the remote node database.
Use of this optional procedure is recommended when you are bringing up a
new system as a DECnet-VAX node or when you wish to completely revise
the configuration database for a system that is already running DECnet-VAX.
Specifically, if you are bringing up a new system, follow the steps below.
1

Execute NETCONFIG.COM.

2 Use NCP commands to modify or add parameters once the initial database
is configured. To make changes in or add DECnet accounts, use the DCL
command AUTHORIZE.

3 Set up the remote node database using NCP DEFINE NODE commands.
4 Execute STARTNET.COM to bring up your DECnet-VAX node (see
Section 6.2).
If you are running DECnet-VAX on a node and wish to completely revise
all permanent configuration databases except the remote node database,
you should execute NETCONFIG.COM. To make any further alterations
in the databases and DECnet accounts, use NCP and the DCL command
AUTHORIZE.
If you are running DECnet-VAX and wish to preserve the existing permanent
database, do not use NETCONFIG.COM. Use NCP commands to make any
desired changes in the database.

5-4

Configuration of a Network

5.2.1.1

ExecutingNETCONFIG.COM
You must have system privilege (SYSPRV) to execute NETCONFIG.COM. To
invoke the command procedure, issue the command
$ <5SYS$MANAGER:NETCONFIG.COM

The only information you must supply to the procedure is the node name
and node address of your system. The node name is a string of up to six
alphanumeric characters, containing at least one alphabetic character. The
node address is a numeric value in the form
area-number.node-number

The number to the left of the period designates the area in which the node is
grouped (in the range from 1 to 63) and the number to the right of the period
designates the node's unique address within the area (in the range from 1 to
1023). If the network is not divided into two or more areas, you do not have
to provide the area number; the system will supply the default area number
1.
The procedure also asks whether you want a default nonprivileged DECnet
account to be established for you. If you indicate yes (or take the default YES
by pressing the RETURN key), the procedure displays the DCL AUTHORIZE
command that would create a default nonprivileged DECnet account with a
null password and a UIC of [376,376]. (Note that you can change this UIC
value or other account parameters by using the Authorize Utility once the
node is configured.)
NETCONFIG.COM then asks if you want the executor node to function as a
router. If you type NO (or take the default NO by pressing the RETURN key)
in response to this question, the executor node will be set up as a nonrouting
node.
NETCONFIG.COM automatically determines which DECnet devices exist
on your system for use in building the line and circuit permanent databases.
NETCONFIG.COM then uses the information you supply and the information
it obtains about the system to create all the commands necessary to configure
your system as a DECnet-VAX node, and displays these commands for your
approval (see example below). The commands define the permanent database
parameters for the executor; all lines, circuits, and objects; and all logging
monitor events. The commands do not define the database for any remote
node.
Inspect the displayed commands. NETCONFIG.COM will ask if you want to
configure using these commands. If you answer yes, the procedure establishes
the permanent configuration database and default nonprivileged DECnet
account (if you requested it). If you answer no, the procedure returns a
message indicating no changes have been made.
Once the permanent database is established, you have the option of using
NCP commands to alter the parameters to correspond more closely to your
configuration requirements.
If you use NETCONFIG.COM to establish the configuration database for
a system that will be using asynchronous lines (for example, a Micro VMS
system with a terminal line), NETCONFIG.COM will not configure
the asynchronous circuit and line parameters automatically. Instead,
NETCONFIG.COM will issue a message indicating that no circuits or lines
have been configured. You must set up the asynchronous lines separately
(see Section 5.2.2.2).

5—5

Configuration of a Network

If you have purchased a DECnet-VAX license and have not yet installed the
key for that license, do so now.
After configuring your DECnet-VAX system, start up the network by issuing
the command
$ QSYS$MANAGER:STARTNET

To ensure that the installation is successful, you can use the User
Environment Test Package (UETP) to test DECnet. The test procedure is
described in the Guide to VAX/VMS Software Installation.

5.2.1.2

NETCONFIG.COM Example
The following example shows the interactive dialog that is displayed when
you execute NETCONFIG.COM to configure node CHCAGO
DECnet-VAX network configuration procedure
This procedure will help you define the parameters needed to get
DECnet running on this machine.
You will be shown the changes before
they are actually executed, in case you wish to perform them manually.
What do you
What do you
Do you want
Do you want

want your DECnet node name to be?
want your DECnet address to be?
a default DECnet account?
[YES]
to operate as a router?
[NO (nonrouting)]

CHCAGO
2.37
RET
RET

Here are the commands necessary to set up your system.

$ RUN SYS$SYSTEM:NCP
PURGE EXECUTOR ALL
PURGE KNOWN LINES ALL
PURGE KNOWN CIRCUITS ALL
PURGE KNOWN LOGGING ALL
PURGE KNOWN OBJECTS ALL
PURGE MODULE CONFIGURATOR KNOWN CIRCUITS ALL
$ DEFINE/USER SYS$OUTPUT NL:
$ DEFINE/USER SYS$ERROR NL:
$ RUN SYS$SYSTEM:NCP
PURGE NODE 2.37 ALL
PURGE NODE CHCAGO ALL
$ RUN SYS$SYSTEM:NCP
DEFINE EXECUTOR ADDRESS 2.37 STATE ON
DEFINE EXECUTOR NAME CHCAGO
DEFINE EXECUTOR MAXIMUM ADDRESS 255
DEFINE EXECUTOR ROUTING TYPE NONROUTING IV
DEFINE EXECUTOR NONPRIVILEGED USER DECNET
$ DEFINE/USER SYSUAF SYS$SYSTEM:SYSUAF.DAT
$ RUN SYS$SYSTEM:AUTHORIZE
ADD DECNET /OWNER="DECNET DEFAULT" /PASSWORD3"" /UIC=[376,376] /ACCOUNT=DECNET /DEVICE=SYS$SYSDEVICE: /DIRECTORY3[DECNET] /PRIVILEGE3(TMPMBX,NETMBX)
/FLAGS3(CAPTIVE)/NOBATCH/NOINTERACTIVE /LGICMD=NL:
/NOBATCH /NOINTERACTIVE
$ CREATE/DIRECTORY SYS$SYSDEVICE:[DECNET] /OWNER3[376,376]

5-6

Configuration of a Network

$ RUN SYS$SYSTEM:NCP
DEFINE LINE
CI-0 STATE ON
DEFINE LINE
UNA-0 STATE ON
DEFINE CIRCUIT UNA-0 STATE ON COST 3
DEFINE LINE
DMC-0 STATE ON
DEFINE CIRCUIT DMC-0 STATE ON COST 5
DEFINE LINE
DMC-1 STATE ON
DEFINE CIRCUIT DMC-1 STATE ON COST 5
DEFINE LOGGING MONITOR STATE ON
DEFINE LOGGING MONITOR EVENTS 0.0-9
DEFINE LOGGING MONITOR EVENTS 2.0-1
DEFINE LOGGING MONITOR EVENTS 4.2-13,15-16,18-19
DEFINE LOGGING MONITOR EVENTS 5.0-18
DEFINE LOGGING MONITOR EVENTS 128.0-4

Do you want to go ahead and do it?
No changes have been made.

5.2.2

[YES]:

Tailoring the Configuration Database
If you do not choose to use NETCONFIG.COM to build the network
configuration in the permanent database, you may instead configure the
network using individual NCP commands. Examples of various configuration
procedures are given in Section 5.3. NCP can also be used to add or delete
entries in an existing permanent database.
Following are two examples of changes made to the network configuration
that require corresponding modification of the permanent database.
•

Running DECnet over the CL The driver CNDRIVER must be loaded
on the system and all Cl lines and circuits must be defined in the
configuration database.

•

Running DECnet over terminal lines. The terminal driver NODRIVER
must be loaded on the system, terminal lines must be converted to
DDCMP lines, and all DDCMP lines and circuits must be defined in the
configuration database.

The procedures for handling these changes are described in detail in the
following sections.

5.2.2.1

Running DECnet over the Cl
To use the CI750 or CI780 as a DECnet device on your VAX/VMS system,
you must first install CNDRIVER, the DECnet driver associated with the CL
To load CNDRIVER, add the following commands to the LOADNET.COM
command procedure in the SYS$MANAGER directory.
$ RUN SYS$SYSTEM:SYSGEN
CONNECT CNAO/NOADAPTER

You are now ready to run DECnet over the CI. The following example
illustrates how to use NCP commands to define the CI line and one or more
CI circuits in the permanent database.
$ RUN SYS$SYSTEM:NCP
NCP>DEFINE LINE CI-0 STATE ON
NCP>DEFINE CIRCUIT CI-0.0 TRIBUTARY 0 STATE ON
NCP>DEFINE CIRCUIT CI-0.1 TRIBUTARY 1 STATE ON

NCP> EXIT
$

5-7

Configuration of a Network

5.2.2.2

Running DECnet over Terminal Lines
To use lines connected to terminal ports as DECnet communications lines,
you must load the asynchronous DDCMP driver NODRIVER, set up the
terminal lines to be converted to asynchronous DDCMP lines, and specify the
appropriate lines and circuits in the NCP configuration database. The steps
in converting terminal lines to asynchronous lines depend on the type of line
you want to set up:
•

Static asynchronous DDCMP line: a line permanently configured as a
DECnet line

•

Dynamic asynchronous DDCMP line: a line that is switched from terminal
to DECnet use for the duration of a dialup call

Procedures for installing and shutting down each of these types of lines are
described below.
Because dialup lines are more prone to noise problems than dedicated
synchronous lines that do not use modems, it is recommended that the
executor buffer size and segment buffer size be set to a value of 192 for any
end node that is connected to its router by a dialup line. Use of a relatively
small buffer size will reduce the effect of buffer retransmission on overall
throughput.
5.2.2.3

Installing Static Asynchronous Lines
The following procedures illustrate the steps in setting up and shutting down
static asynchronous lines on your system.
Setting Up Static Asynchronous DDCMP Lines
The steps necessary to set up lines connected to terminal ports on your
system for use as static asynchronous DECnet lines are as follows:
1

Load the asynchronous DDCMP driver NODRIVER by adding the
following commands to the LOADNET.COM command procedure in
the SYS$MANAGER directory or specifying the commands after the
system is booted.
$ RUN SYSISYSTEM:SYSGEN
SYSGEN> CONNECT NOAO/NOADAPTER

Choose the terminal lines on your system that you will use as DECnet
lines. To convert a line to a static asynchronous DDCMP line,
add the DCL command SET TERMINAL/PROTOCOL=DDCMP to
LOADNET.COM in your SYS$MANAGER directory for each terminal
line that will run DECnet.
For example, to convert the terminal lines connected to ports TTAO and
TXB7 on your system into DECnet lines with no modem control, add the
following to LOADNET.COM:
$ SET TERMINAL/PROTOCOL=DDCMP

TTAO:

$ SET TERMINAL/PROTOCOL=DDCMP

TXB7:

To convert the line connected to terminal port TXA1 (which can be used
as a dialup line) to a DECnet line with modem control, add the following
command to LOADNET.COM:
$ SET TERMINAL/PERMANENT/MODEM/NOHANGUP/NOAUTOBAUD _$ /NOTYPEAHEAD/PROTOCOL=DDCMP TXA1:

Note that the line speed cannot be changed while the terminal line is in
use as a DECnet communications line.
5-8

Configuration of a Network

3 Use NCP commands to define all terminal lines and circuits in the
configuration permanent database, as illustrated in the following example:
$ RUN SYS$SYSTEM:NCP
NCP> DEFINE LINE TT-0-0 STATE ON
_ LINE SPEED 9600
NCP> DEFINE CIRCUIT TT-0-0 STATE
NCP> DEFINE LINE TX-1-7 STATE ON
_ LINE SPEED 9600
NCP> DEFINE CIRCUIT TX-1-7 STATE

RECEIVE BUFFERS 4 ON
RECEIVE BUFFERS 4 ON

NCP> DEFINE LINE TX-1-1 STATE ON RECEIVE BUFFERS 4 _ LINE SPEED 1200
NCP> DEFINE CIRCUIT TX-1-1 STATE ON
NCP> EXIT
$

The lines are then turned on to the network.

Reasons for Failure of Static Asynchronous Connections
If static asynchronous DECnet lines are started but are left in the "ON STARTING" state, check the following:
•

The line speeds or both ends of the connection must be set to the same
value.

•

If you are using a dialup line, the modem characteristic must be set on the
terminal before the line is switched to asynchronous DDCMP use.

•

If the network is divided into areas, the two nodes being connected must
be in the same area or must be area routers.

•

Asynchronous DECnet requires that the parity on the asynchronous line
be set to NONE and the terminal line be set up to use 8-bit characters. If
you are using a non-VAX/VMS system, you must check that the terminal
line is set to the correct parity.

If your terminal line cannot be set up as a static asynchronous DDCMP line,
check whether the following condition exists:
•

If data is stored in a type-ahead buffer associated with your terminal
line, the line will come up as a terminal line even if a startup command
procedure attempts to set it up as a DDCMP line. This generally occurs
when the remote node is running and its asynchronous DDCMP line is
on. The DDCMP start messages being transmitted will be stored in the
type-ahead buffer for your line. Before you can start up your terminal line
in DDCMP mode, you must terminate the process that has started and
that owns your terminal line.

Shutting Down Static Asynchronous DDCMP Lines
To shut down a DECnet line and return it to a terminal line, specify the
following commands:
$ RUN SYS$SYSTEM:NCP
NCP> SET LINE TT-0-0 STATE OFF
NCP> CLEAR LINE TT-0-0 ALL
NCP> SET CIRCUIT TT-0-0 STATE OFF
NCP> CLEAR CIRCUIT TT-0-0 ALL

To switch a line for which modem control was not enabled back to a terminal
line, specify
$

SET TERMINAL/PR0T0C0L=N0NE TTAO:

5-9

Configuration of a Network

To switch a line for which modem control was enabled back to a terminal
line, specify
$ SET TERMINAL/PERMANENT/AUTOBAUD _$ TYPEAHEAD/PROTOCOL=NONE TXA1:

5.2.2.4

Installing Dynamic Asynchronous Lines
To make a temporary connection to another node over an asynchronous
connection (for example, a telephone line), the terminal lines at each node
may be switched to dynamic asynchronous DDCMP lines for the duration of
the connection. The procedure for establishing a dynamic connection, reasons
why the connection might fail, and the actions that shut down the lines are
described below. Dynamic switching is described in detail in Chapter 2.

Setting Up Dynamic Asynchronous DDCMP Lines
The steps necessary to set up a dynamic connection, switching lines connected
to terminal ports to dynamic asynchronous DECnet lines, are outlined below.
This procedure illustrates commands used if a local Micro VMS system
(MYNODE) is establishing a dynamic connection with a remote VAX/VMS
system (BIGVAX).
1

The system manager at each node must load the asynchronous
DDCMP driver NODRIVER by adding the following commands to the
LOADNET.COM command procedure in the SYS$MANAGER directory or
specifying the commands after the system is booted.
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> CONNECT NOAO/NOADAPTER

2 The system manager at each node must install the shareable image
DYNSWITCH as follows:
$ INSTALL:=$SYS$SYSTEM:INSTALL
$ INSTALL/COMMAND
INSTALL> CREATE SYS$LIBRARY:DYNSWITCH/SHARE _ /PROTECT/HEADER/OPEN
INSTALL> EXIT

Note that if the image DYNSWITCH is not installed on the system,
dynamic switching of lines is implicitly disabled.

3 The system manager at the remote node, BIGVAX, must enable the use of
virtual terminals with these commands:
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> CONNECT VTAO/NOADAPTER/DRIVER-TTDRIVER

The system manager must also enable the disconnect option for the
terminal by specifying the following for the terminal:
$ SET TERMINAL/PERMANENT/DISCONNECT TTB1:

(For further information on using virtual terminals, refer to the VAX/VMS
System Manager's Reference Manual.)

4 The user at the local system, MYVAX, performs the following steps:
a

Specify the following to establish the system as a terminal emulator
(TTA1 identifies the terminal port on the local system through which
the dynamic connection will be made):
$ SET HOST/DTE TTA1:

5-10

Configuration of a Network

(You can optionally include the /DIAL qualifier in the SET HOST
command to cause automatic dialing of the modem to the remote
node).

Dial in to the remote system.

If your local terminal emulator supports automatic dynamic switching
of terminal lines to asynchronous DDCMP lines, specify the following
to initiate automatic dynamic switching at both ends of the connection:
$ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET

You will receive the following message when DECnet is started at the
local node:
7, REM-S-END - control returns to local-node-name:
$

Use the line for network operations when you see the local system
prompt ($).

If your local terminal emulator does not support automatic switching,
specify the /MANUAL qualifier in the SET TERMINAL command:
$ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET/MANUAL

You will receive the following message from the remote system:
7. SET-I-SWINPRG

The line you are currently logged
over is becoming a DECnet line

Exit the terminal emulator and specify the following to switch your
terminal line manually:
$ SET TERMINAL/PROTOCOL=DDCMP TTA1:

Enter the following NCP commands to turn on your line and circuit.
DECnet is then started at the local node.
$ RUN SYS$SYSTEM:NCP
NCP>SET LINE TT-0-1 RECEIVE BUFFERS 4 STATE ON
NCP>SET CIRCUIT TT-0-1 RECEIVE BUFFERS 4 STATE ON
NCP>EXIT

Note that the SET TERMINAL command is a VAX/VMS DCL command.
If you are on a non-VAX/VMS node, you should specify the equivalent
function for your system.

Reasons for Failure of Dynamic Asynchronous Connections
If dynamic switching is being performed and the asynchronous DECnet
connection is not made, first check that the following conditions exist:
•

DECnet must be started on both nodes.

•

The asynchronous DDCMP class driver (NODRIVER) must be loaded by
means of SYS$SYSTEM:SYSGEN at each node.

•

The dynamic switch image (DYNSWITCH) must be installed by means of
SYS$SYSTEM:INSTALL at each VAX/VMS node.

•

Virtual terminals must be enabled both on the remote node and, in
particular, for the terminal over which you are logged in. The terminal
line at the remote node must have the attribute DISCONNECT set.

5-11

Configuration of a Network

•

After you issue a SET TERMINAL command with the /MANUAL
qualifier, you must specify NCP commands to turn on the DECnet line
within approximately four minutes or the line will return to terminal
mode.

If the dynamic asynchronous lines are started but are left in the "ON STARTING" state, check the following:
•

If the network is divided into areas, the two nodes being connected must
be in the same area or must be area routers.

•

The routing initialization passwords on each node must be set correctly
(see Section 3.13.1).

•

The INBOUND parameter for the local node entry must be set correctly in
the node database at the remote node (see Section 3.13.3).

•

Shutting Down Dynamic Asynchronous Lines
You have two options for ending a dynamic connection:
•

Break the telephone connection.

•

Specify one of the following NCP commands (either command will cause
both line and circuit entries to be cleared in the database):
NCP> SET LINE TT-0-0 STATE OFF
NCP> SET CIRCUIT TT-0-0 STATE OFF

The results of these commands are different depending on the side of the
connection from which they are entered. On the side where the commands
are executed (the local node), the port will be immediately switched to the
terminal driver. On the other side (the remote node), the line will remain in
the ON-STARTING state for approximately three minutes and then will be
switched to the terminal port.
Note that if you specified the /NOHANGUP qualifier in the SET TERMINAL
command with which you initiated dynamic switching, the modem carrier
signal will not be dropped when you shut down the DECnet line or circuit.
The carrier signal will be broken when you hang up the telephone.
If you specify the SET TERMINAL command with the /MANUAL qualifier
to switch the terminal line manually, you can abort the switch by pressing
CTRL/C or CTRL/Y.

5.3

Network Configuration Examples
This section illustrates how you can use NCP commands to build your
network configuration in the permanent database. Included are examples
of the NCP commands you would use to obtain the following network
configurations:

5-12

•

Synchronous DDCMP point-to-point configuration

•

DDCMP multipoint configuration

•

Static asynchronous DDCMP point-to-point configuration

Configuration of a Network

•

Dynamic asynchronous DDCMP point-to-point configuration

•

Ethernet configuration

•

X.25 DLM configuration

•

X.25 native mode configuration

•

X.25 multihost mode configuration

•

X.25 multinetwork configuration

Note that the configuration examples in this section assume single-area
networks using the default area 1. For an example of the NCP commands
used to configure a multiple-area network, see Section A.3.
Combine the appropriate NCP commands in a command file that reflects
your network configuration; then edit and run this procedure as many times
as necessary to properly build the permanent database corresponding to your
configuration and needs. Once you have configured the permanent database,
invoke SYS$MANAGER:STARTNET.COM to load these parameters into the
volatile database and bring up the network.

5.3.1

Synchronous DDCMP Point-to-Point Network Example
The example below builds a database for a network configuration of four
nodes, connected by a DMC11, DMP11 or DMF32 line and circuit.

Figure 5-1

A Synchronous DDCMP Point-to-Point Network
Configuration

CHCAGO

NEWARK

ATLNTA

TAMPA
ZK-1852-84

Use the following NCP commands to configure the DDCMP point-to-point
network. Note that node NEWARK is a nonrouting RSX-11S system to which
node CHCAGO will perform a downline load.
Define executor-specific parameters for local node CHCAGO.
The TYPE parameter for the executor node defaults to
ROUTING IV.
DEFINE EXECUTOR

ADDRESS 1
BUFFER SIZE 576 MAXIMUM HOPS 6 MAXIMUM VISITS 12
STATE ON

5-13

USER NETNONPRIV PASSWORD NONPRIV
Define parameters for remote node NEWARK
(a nonrouting
RSX-11S system).
CHCAGO will be the load host for NEWARK.
DEFINE

NODE

NAME NEWARK HOST NODE CHCAGO LOAD FILE NODIIS.SYS NONPRIVILEGED USER NETNONPRIV PASSWORD NONPRIV SERVICE CIRCUIT DMC-0 SERVICE PASSWORD FE SECONDARY LOADER SECDMC.SYS
TERTIARY LOADER TERDMC.SYS

Define the remaining nodes.
Note that no default outbound
access control information is specified.
This assumes that
the default access control information will be supplied by
each remote node when it receives an inbound connect request.
DEFINE NODE 3
DEFINE NODE 4

NAME ATLNTA
NAME TAMPA

Define parameters for line/circuit DMC-0 to node NEWARK.
Because this node will be loaded downline, the service
parameters must be set up.
DEFINE

LINE

DMC-0

DEFINE CIRCUIT DMC-0

PROTOCOL DDCMP POINT SERVICE TIMER 4000 STATE ON
SERVICE ENABLED
STATE ON

Define parameters for line/circuit DMF-0 to node ATLNTA.
(Give this line more receive buffers because it has a faster
connection.)
DEFINE

LINE

DMF-0

DEFINE CIRCUIT DMF-0

PROTOCOL DDCMP POINT
RECEIVE BUFFERS 8 STATE ON

STATE ON

Define parameters for line/circuit DMP-0 to node TAMPA.
DEFINE

LINE

DMP-0

DEFINE CIRCUIT DMP-0

5-14

PROTOCOL DDCMP POINT
STATE ON
STATE ON

DEFINE LOGGING MONITOR KNOWN EVENTS
Define receiver-related logging parameters.
DEFINE LOGGING MONITOR STATE ON

5.3.2

DDCMP Multipoint Network Example

This example builds a database for a network config
connected by a combination of DMC, DMF, and DM
Figure 5-2

A DDCMP Multipoint Network

PHILA

CHCAGO

ATLNTA

TAMPA

MIAMI
ZK-1853-84

Use the following NCP commands to configure the
network:

Define executor-specific parameters for local node CH
The TYPE parameter for the executor node defaults to
ROUTING IV since a full function license is installed
DEFINE EXECUTOR

ADDRESS 1
BUFFER SIZE 576 MAXIMUM HOPS 6 MAXIMUM VISITS 12 STATE ON

USER NETNONPRIV PASSWORD NONPRIV
Define the remaining nodes.
Note that no default outbound
access control information is specified.
This assumes that
the default access control information will be supplied by
each remote node when it receives an inbound connect request.
DEFINE
DEFINE
DEFINE
DEFINE

NAME PHILA
NAME ATLNTA
NAME TAMPA
NAME MIAMI

NODE 2
NODE 3
NODE 4
NODE 5

Define parameters for line/circuit DMC-0 to node PHILA.
DEFINE

LINE

DMC-0

DEFINE CIRCUIT DMC-0

PROTOCOL DDCMP POINT
STATE ON -

STATE ON

Define parameters for line/circuit DMF-0 to node ATLNTA.
DEFINE

LINE

DMF-0

DEFINE CIRCUIT DMF-0

PROTOCOL DDCMP POINT
STATE ON

STATE ON

Define parameters for line DMP-0 and circuits to nodes
and MIAMI.

TAMPA

TAMPA is connected as tributary 3, DMP-O.0
MIAMI is connected as tributary 4, DMP-O.1
The DMP line runs at 56,000 bits per second,
setting for the retransmit timer is

The proper

20,000 * buffer_size
retransmit timer
bps
Thus, with a buffer size of 576, the retransmit timer should
be 210 milliseconds.
The dead timer is set to 30 seconds to avoid excessive delays
when polling dead tributaries.
The timer is set when a node
goes down.
DEFINE

5-16

LINE

DMP-O

PROTOCOL DDCMP CONTROL
DEAD TIMER 30000 RECEIVE BUFFERS 6 RETRANSMIT TIMER 210 STATE ON

DEFINE CIRCUIT DMP-O.0

COST 4 STATE ON TRIBUTARY 3

DEFINE CIRCUIT DMP-O.1

COST 4 STATE ON TRIBUTARY 4

Configuration of a Network

The object database does not need to be defined because it
defaults to the standard list of objects known to VAX/VMS.

Define transmitter-related logging parameters.
DEFINE LOGGING MONITOR KNOWN EVENTS

!
!
j

Define receiver-related logging parameters.
DEFINE LOGGING MONITOR STATE ON

5.3.3

Static Asynchronous DDCMP Network Example
The example below builds a database for a network configuration of four
nodes, connected by a DMR11 line and two terminal lines converted to static
asynchronous DECnet lines.
Figure 5-3

A Static Asynchronous DDCMP Network
Configuration

CHCAGO

ST PAUL

YELLOW

BLUE
ZK-1854-84

Use the following NCP commands to configure the DDCMP point-to-point
network that includes static asynchronous lines. To establish the static
asynchronous connections, nodes YELLOW and BLUE must also specify in
their configuration databases the circuits and lines connecting them to node
CHCAGO. Before issuing these commands, you should set up the terminal
line with the appropriate characteristics. (See Section 5.2.2.3.)
Define executor-specific parameters for local node
CHCAGO.
The TYPE parameter for the executor node defaults to
ROUTING IV.
DEFINE EXECUTOR

ADDRESS 1
BUFFER SIZE 576 MAXIMUM HOPS 6 MAXIMUM VISITS 12 STATE ON

5-17

USER NETNONPRIV PASSWORD NONPRIV
Define the remaining nodes.
Note that no default
outbound access control information is specified.
This assumes that the default access control
information will be supplied by each remote node
when it receives an inbound connect request.
DEFINE NODE 2
DEFINE NODE 3
DEFINE NODE 4

NAME STPAUL
NAME YELLOW
NAME BLUE

Define parameters for line/circuit DMR-0 to node
STPAUL.
DEFINE

LINE

DMR-0

DEFINE CIRCUIT DMR-0

PROTOCOL DDCMP POINT
STATE ON
STATE ON

Define parameters for line/circuit TT-0-0 to node
YELLOW.
DEFINE

LINE

TT-0-0

DEFINE CIRCUIT TT-0-0

RECEIVE BUFFERS 4
STATE ON LINE SPEED 9600

STATE ON

Define parameters for line/circuit TX-1-7 to node
BLUE.
DEFINE

LINE

TX-1-7

DEFINE CIRCUIT TX-1-7

RECEIVER BUFFERS 4
STATE ON LINE SPEED 1200

STATE ON

The object database does not need to be defined
because it defaults to the standard list of objects
known to VAX/VMS.

Define transmitter-related logging parameters.
DEFINE LOGGING MONITOR KNOWN EVENTS
Define receiver-related logging parameters.
DEFINE LOGGING MONITOR STATE ON

5.3.4

Dynamic Asynchronous DDCMP Network Example

The example below indicates the NCP commands to configure
connected by a terminal line converted to a dynamic asynchron
line. Before issuing these commands, refer to the procedure fo
dynamic asynchronous lines in Section 5.2.2.4.

5-18

5.3.4.1

Node BIGVAX Database

Use the following NCP commands to configure the
DDCMP connection from node BIGVAX to node MY
assumes BIGVAX is a router.
Define executor-specific parameters for local node
BIGVAX.
DEFINE EXECUTOR

ADDRESS 1
BUFFER SIZE 576 MAXIMUM HOPS 6 MAXIMUM VISITS 12 STATE ON

Define common node parameters for the local node.
Be
sure to add the NETNONPRIV user to your system
authorization file by using the Authorize Utility.
DEFINE

EXECUTOR

NAME BIGVAX NONPRIVILEGED USER NETNONPRIV PASSWORD NONPRIV

Define the remote node.
You must use the INBOUND
parameter to check whether dialup node MYNODE will
operate as an end node or as a router.
As an added
security feature for a node using a dynamic asynchron
communications line, you must also specify a receive
password for node MYNODE.
This will be compared with
the transmit password supplied by MYNODE when it
issues the connect request.

DEFINE NODE 2

NAME MYNODE INBOUND ENDNODE RECEIVE PASSWORD 10101010

You do not need to define parameters for a
line/circuit to node MYNODE.
These parameters are
provided automatically by the system when the dynamic
connection is initiated.

DEFINE LOGGING MONITOR KNOWN EVENTS
Define receiver-related logging parameters.
DEFINE LOGGING MONITOR STATE ON

5.3.4.2

Node MYNODE Database

Use the following NCP commands to configure the dynamic as
DDCMP connection from node MYNODE to node BIGVAX. Th
assumes that MYNODE is an end node and that the dynamic l
(1200 baud) modem line.
Define executor-specific parameters for local node
MYNODE.
DEFINE EXECUTOR

ADDRESS 2 BUFFER SIZE 192 SEGMENT BUFFER SIZE 192 STATE ON TYPE NONROUTING

Define common node parameters for the local node.
Be sure to add the NETNONPRIV user to your system
authorization file by using the Authorize Utility.
DEFINE

EXECUTOR

NAME MYNODE NONPRIVILEGED USER NETNONPRIV PASSWORD NONPRIV

Define the remote node.
You must specify a transmit
password which matches the receive password in the
remote node database on node BIGVAX.
DEFINE NODE 1

NAME BIGVAX TRANSMIT PASSWORD 10101010

You do not need to define parameters for a
line/circuit to node BIGVAX.
These parameters are
provided automatically by the system when the dynamic
connection is initiated.

The object database does not need to be defined
because it defaults to the standard list of objects
known to VAX/VMS.

5-20

UNA-0

ROBIN

THRUSH

LAR

ZK-1855

* Use the following NCP commands to configure the
Repeat the procedure to configure the databases for
LARK.

Define executor-specific parameters for local node
Note that the TYPE parameter for the executor node de
to a node type that corresponds to the type of n
license (router or end node) you have installed.
DEFINE EXECUTOR

ADDRESS 20 BUFFER SIZE 576
STATE ON

Define common node parameters for the local node.
Be
to add the NETNONPRIV user to your system authorizati
file by using the Authorize Utility.
DEFINE

EXECUTOR

NAME ROBIN NONPRIVILEGED USER NETNONPRIV PASSWORD NONPRIV

Define the remaining nodes.
Note that no default out
access control information is specified.
This assume
the default access control information will be suppli
each remote node when it receives an inbound connect
DEFINE NODE 21
DEFINE NODE 22

NAME THRUSH
NAME LARK

Define parameters for line/circuit UNA-0.

Define transmitter-related logging parameters.
DEFINE LOGGING MONITOR KNOWN EVENTS
Define receiver-related logging parameters.
DEFINE LOGGING MONITOR STATE ON

5.3.6

X.25 Data Link Mapping Example

This example builds a database for a network configuration of
connected by a DMC11 line and circuit and an X.25 packet sw
network (PSDN).
Figure 5-6

An X.25 Data Link Mapping Network C

BUFFLO

CHCAGO

X25-OUT

I
DTE 311111222333

X25-INC

SDIEGO
ZK-1856-84

5-22

NETWORK TELENET PROFILE TELENET

Define the line used to communicate with the X.25 net
DEFINE LINE DUP-0

NETWORK TELENET STATE ON

Define the local DTE for node CHCAGO.
DEFINE MODULE X25-PR0T0C0L DTE 311111222333 NETWORK TELENET CHANNELS 2018-1546 LINE DUP-0 STATE ON

Define executor specific parameters for local node CH
The TYPE parameter for the executor node defaults to
ROUTING IV.
DEFINE EXECUTOR

ADDRESS 1
BUFFER SIZE 576 MAXIMUM HOPS 6 MAXIMUM VISITS 12
STATE ON

Define common node parameters for the local node.
Be
to add the NETNONPRIV user to your system authorizatio
file by using the Authorize Utility.
DEFINE

EXECUTOR

NAME CHCAGO
NONPRIVILEGED USER NETNONPRIV PASSWORD NONPRIV

NAME BUFFLO
NAME SDIEGO

Define parameters for line/circuit DMC-0 to node BUFF
DEFINE

LINE

DMC-0

DEFINE CIRCUIT DMC-0

PROTOCOL DDCMP POINT
STATE ON -

STATE ON

Define parameters for the outgoing DLM circuit X25-0U
SDIEGO (node SDIEGO is addressed as DTE 311444555666
X.25 network; subaddress 1 is defined on node SDIEGO
DECnet DLM subaddress).
DEFINE CIRCUIT X25-0UT NETWORK TELENET NUMBER 3114445556661 OWNER EXECUTOR USAGE OUTGOING STATE ON

DEFINE LOGGING MONITOR KNOWN EVENTS
Define receiver-related logging parameters.
DEFINE LOGGING MONITOR STATE ON

5.3.62

Node SDIEGO Database

Use the following NCP commands to configure the node SDIE
Set up the X.25 protocol module.
DEFINE MODULE X25-PR0T0C0L NETWORK TELENET PROFILE TELENET
Define the line used to communicate with the X.25 network.
DEFINE LINE DUP-0

NETWORK TELENET

STATE ON

Define the local DTE for node SDIEGO.
DEFINE MODULE X25-PROTOCOL DTE 311444555666 NETWORK TELENET CHANNELS 2490-2452 LINE DUP-0 STATE ON
Define executor-specific parameters for local node SDIEGO.
Note that the X.25 subaddress range is given as 1 to 5 so
that this node can accept all X.25 calls with a subaddress
from 1 to 5.
Because CHCAGO is sending X.25 calls said does
not intend to receive any, you need not specify the
subaddress parameter for this DTE.
The system manager must
coordinate the subaddress values used to designate DECnet
data link calls among the DECnet nodes.
DEFINE EXECUTOR

ADDRESS 3 BUFFER SIZE 576 MAXIMUM HOPS 6 MAXIMUM VISITS 12 SUBADDRESSES 1-5 STATE ON

Define common node parameters for the local node.
Be sure
to add the NETNONPRIV user to your system authorization
file by using the Authorize Utility.
DEFINE

5-24

EXECUTOR

NAME SDIEGO NONPRIVILEGED USER NETNONPRIV PASSWORD NONPRIV

DEFINE NODE 1
DEFINE NODE 2

NAME CHCAGO
NAME BUFFLO

Define parameters for the incoming DLM circuit X25-IN
node CHCAGO).
DEFINE CIRCUIT X25-INC

NETWORK TELENET OWNER EXECUTOR
USAGE INCOMING STATE ON

The object database does not need to be defined becau
defaults to the standard list of objects known to VA

Define transmitter-related logging parameters.
DEFINE LOGGING MONITOR KNOWN EVENTS
Define receiver-related logging parameters.
DEFINE LOGGING MONITOR STATE ON

5.3.7

X.25 Native Mode Network Example

This example builds a database for a network config
DTE with a packet switching data network (the Uni
PSS) by a DUP line. The example builds server and
incoming calls.
Figure 5-7

An X.25 Native-Mode Network

DTE 234123456789

ZK-1857-84

Use the following NCP commands to configure the
the X.25 native-mode network.
Set up the X.25 protocol module.
DEFINE MODULE X25-PR0T0C0L NETWORK PSS PROFILE PSS

DEFINE LINE DUP-0

NETWORK PSS STATE ON

Define the local DTE.
DEFINE MODULE X25-PR0T0C0L DTE 234123456789 NETWORK PSS CHANNELS 2018-1546 LINE DUP-0 STATE ON

Define the destinations.
DEFINE MODULE X25-SERVER DESTINATION JOE SUBADDRESS 1-10 OBJECT OBJONE PRIORITY 1
DEFINE MODULE X25-SERVER DESTINATION JIM SUBADDRESS 11-15 OBJECT OBJTWO PRIORITY 2
DEFINE MODULE X25-SERVER DESTINATION DEFDEST OBJECT DEFOBJ PRIORITY 0
Define the X.29 call handler.
DEFINE MODULE X29-SERVER STATE ON
Define the objects used for incoming calls.
DEFINE OBJECT OBJONE FILE OBJSTUP.COM USER PSIUSER PASSWORD PSIUSER
DEFINE OBJECT OBJTWO FILE OBJECTTWO.COM USER JIM PASSWORD JIM
DEFINE OBJECT DEFOBJ FILE LSTCHNCE.COM USER NET PASSWORD NET

5.3.8

X.25 Multihost Mode Network Example

The following example illustrates the NCP commands used to conf
VAX/VMS nodes connected by an Ethernet UNA line and circuit,
node set up as an X.25 multihost connector node to the PSDN calle
the other two nodes set up as host nodes to use the connector nod

In this example, node ROBIN, with VAX PSI multihost software in
is configured as the connector node, and nodes THRUSH and LAR
with VAX PSI Access software installed, are configured as host nod
communicate with the X.25 network through ROBIN.

5-26

Configuration of a Network

Figure 5—8

An X.25 Multihost Mode Network Configuration

ZK-1858-84

You must complete the following tasks in order to configure this network:

5.3.8.1

•

Build the Ethernet network.

•

Build the appropriate databases on ROBIN to configure this node as the
X.25 connector node.

•

Configure THRUSH and LARK as host nodes capable of accessing the
X.25 network through the connector node ROBIN.

Building the Ethernet Network
Use the following NCP commands to configure the node ROBIN database.
Repeat the procedure to configure the databases for nodes THRUSH and
LARK.
Define executor-specific
parameters
for local node
ROBIN.
The TYPE parameter for the executor node defaults
to ROUTING IV.
DEFINE EXECUTOR

ADDRESS 20 BUFFER SIZE 576
STATE ON

Define common node parameters for the local node.
Be sure
to add the NETNONPRIV user to your system authorization
file by using the Authorize Utility.
DEFINE

EXECUTOR

NAME ROBIN NONPRIVILEGED USER NETNONPRIV PASSWORD NONPRIV

Define the remaining nodes.
DEFINE NODE 21
DEFINE NODE 22

NAME THRUSH
NAME LARK

5-27

The object database does not need to be defined because it
defaults to the standard list of objects known to VAX/VMS.

Define transmitter-related logging parameters.
DEFINE LOGGING MONITOR KNOWN EVENTS
Define receiver-related logging parameters.
DEFINE LOGGING MONITOR STATE ON

5.3.8.2

Configuring the X.25 Connector Node

The following NCP commands build the X25-PROTOCOL and
databases for a multihost PSI node. Node ROBIN is configure
PSI multihost node connected to the PSDN named PSS.
Set up the X.25 protocol module.
DEFINE MODULE X25-PR0T0C0L NETWORK PUBLIC PROFILE PSS
Define the line used to communicate with the X.25 network.
DEFINE LINE DUP-0 NETWORK PUBLIC STATE ON
Define the local DTE.
DEFINE MODULE X25-PR0T0C0L DTE 311111222333 NETWORK PUBLIC CHANNELS 2018-1546 LINE DUP-0 STATE ON
Define host destinations for incoming calls.
DEFINE MODULE X25-SERVER DESTINATION THRUSH SUBADDRESSES 1-10 OBJECT 36 NODE THRUSH
DEFINE MODULE X25-SERVER DESTINATION LARK SUBADDRESSES 11-20 OBJECT 36 NODE LARK

5-28

Node THRUSH database
Set up the X.25 access module.
DEFINE MODULE X25-ACCESS NETWORK PUBLIC NODE ROBIN
Define the destination on THRUSH.
DEFINE MODULE X25-SERVER DESTINATION JOE SUBADDRESS 1-10 OBJECT 0BJ0NE
Define the X.29 call handler.
DEFINE MODULE X29-SERVER STATE ON
Define the destination objects for incoming calls.
DEFINE OBJECT 0BJ0NE FILE OBJSTUP.COM USER PSIUSER PASSWORD PSIUSER

Node LARK database
Set up the X.25 access module.
DEFINE MODULE X25-ACCESS NETWORK PUBLIC NODE ROBIN
Define the destination on LARK.
DEFINE MODULE X25-SERVER DESTINATION JOE SUBADDRESS 11-20 OBJECT OBJTWO
!
!
j

Define the X.29 call handler.
DEFINE MODULE X29-SERVER STATE ON

j
!

Define the destination object for incoming calls.

DEFINE OBJECT OBJTWO FILE OBJTWO.COM USER JIM PASSWORD JIM

Configuration of a Network

5.3.9

X.25 Multinetwork Example
This example builds a database for a network configuration where a
VAX/VMS system is connected to a PSDN (the United Kingdom PSDN
called PSS) and also to a non-DIGITAL machine which behaves like an X.25
DTE. The non-DIGITAL connection uses the profile ISO8208. VAX PSI is
running in native mode.
Figure 5-9

A Multinetwork Configuration

ZK-4771 -85

Use the following NCP commands to configure the permanent database for
the multinetwork configuration.
Set up the networks.
The PSS connection will be called network PUBLIC
and the other network will be called NONDEC (using the profile IS08208).
DEFINE MODULE X25-PR0T0C0L NETWORK PUBLIC PROFILE PSS
DEFINE MODULE X25-PR0T0C0L NETWORK NONDEC PROFILE IS08208
Define the line used to connect to PSS.
DEFINE LINE KMY-0 NETWORK PUBLIC STATE ON
Define the line used to connect to the non-DIGITAL machine.
DEFINE LINE DMF-0 NETWORK NONDEC INTERFACE DCE STATE ON
Define the DTE addresses.

5-30

NETWORK NONDEC LINE DMF-0 CHANNELS 100-1 INTERFACE DCE
Define the destinations.
from PUBLIC only.

The

destination, JOE, rece

DEFINE MODULE X25-SERVER DESTINATION JOE SUBADDRESS 1-10 NETWORK PUBLIC OBJECT OBJONE PRIORITY 1
The

destination, JIM, receives calls from either net

DEFINE MODULE X25-SERVER DESTINATION JIM SUBADDRESS 11-16 OBJECT OBJTWO PRIORITY 2

The destination, DEFDEST, provides a general destinat
that do not match the other destinations.
DEFINE MODULE X25-SERVER DESTINATION DEFDEST
OBJECT DEFOBJ PRIORITY 0
Define the X.29 call handler.
DEFINE MODULE X29-SERVER STATE ON
Define the objects used for incoming calls.
DEFINE OBJECT OBJONE FILE OBJSTUP.COM USER PSIUSER PASSWORD PSIUSER
DEFINE OBJECT OBJTWO FILE OBJECTTWO.COM USER JIM PASSWORD JIM
DEFINE OBJECT DEFOBJ FILE LSTCHNCE.COM USER NET PASSWORD NET

5.4

System Configuration Guidelines

Proper network operation, particularly in a routing
that you properly configure the system software run
network. Memory and processor time are two princ
need to define.

Configuration of a Network

5.4.1

Normal Memory Requirements
Most of the memory required by the network software is allocated from the
VAX/VMS nonpaged dynamic memory pool. This pool is configured by
setting the NPAGEDYN, IRPCOUNT, LRPCOUNT, and LRPSIZE system
parameters.
These SYSGEN parameters are set by the AUTOGEN facility when the
operating system is first booted and do not normally require modification. If,
however, you find that the SYSGEN parameters must be reset to properly
tune the system, run SYS$SYSTEM:SYSGEN, as shown in the following
example, and change the parameter values.
$ RUN SYSISYSTEM:SYSGEN
SYSGEN>USE CURRENT
SY SGEN > SHOW/MAJ OR

SYSGEN>SET NPAGEDYN number
SYSGEN>SET IRPCOUNT number
SYSGEN>SET LRPCOUNT number
SYSGEN>SET LRPSIZE number
SYSGEN > SHOW/MAJ OR

SYSGEN>WRITE CURRENT
SYSGEN>EXIT
$

5.4.1.1

NPAGEDYN Parameter
To increase the nonpaged dynamic pool space, calculate the value for the
SYSGEN parameter NPAGEDYN using the following equation:
number = current value + total driver value +a+b+c+d

current value

The current byte count without any version of DECnetVAX installed (derived from the SYSGEN command SHOW
/MAJOR).

total driver value

The total number of bytes required to load the driver plus
NETDRIVER (see Table 5-3 for driver sizes).

The total number of bytes required for all lines used by
DECnet-VAX. Use the following formula to determine the
approximate space required.
a = (number of lines) * (number of buffers) * (buffer size)

The buffer size and the number of buffers are determined
by the values you give to the executor BUFFER SIZE and
individual line RECEIVE BUFFERS parameters.
b

The total number of bytes required for the DECnet-VAX
data structure that handles logical links. Use the following
equation to determine the approximate space required,
b * 512 * number of links

The number of links is determined by the value you give to
the executor MAXIMUM LINKS parameter.

5-32

Configuration of a Network

The total number of bytes required for the DECnet data
structure that handles circuits. Use the following equation to
determine the approximate space required.
c = 60 * number of circuits

The number of circuits is the number of circuits you intend
to use.
d

A multiple of the additional IRPCOUNT count. Use the
following equation to determine this value.
d = (new IRPCOUNT - current IRPCOUNT) * 200

The new IRPCOUNT is computed as in Section 5.4.1.2; the
current IRPCOUNT is the current count without any version
of DECnet-VAX installed.
Use the NCP SHOW EXECUTOR and SHOW CIRCUITS commands to
display parameter values that you have set for the local node.
The number of bytes required to load NETDRIVER and the individual drivers
is given in Table 5-3.
Table 5-3

5.4.1.2

Driver Sizes

Driver Software

Number of Bytes

NETDRIVER

14,500

CNDRIVER (Cl)

3,000

NODRIVER (asynchronous)

13,000

XDDRIVER (DMP)

9,800

XEDRIVER (UNA)

13,000

XGDRIVER (DMF)

15,000

XMDRIVER (DMC)

9,800

IRPCOUNT Parameter
With the SYSGEN command SET IRPCOUNT, increase the number of
preallocated I/O request packets to reflect the increase of nonpaged dynamic
pool space using the following formula.
number

5.4.1.3

current value + number of buffers + maximum circuits + 2

current value

The current count without any version of DECnet-VAX
installed.

number of buffers

The number of buffers that may be used by DECnet-VAX
in peak periods (see Section 5.4.1.1).

number of circuits

The number of circuits that you intend to use.

LRPCOUNT and LRPSIZE Parameters
Calculate the value for the SYSGEN parameter LRPCOUNT according to the
following formula:
number of buffers = number of lines + number of receive buffers

The number is the total number of receive buffers specified for all lines plus
the total number of lines.
The value for LRPSIZE should match that of the BUFFER SIZE parameter in
the executor database.

5-33

Configuration of a Network

Refer to the VAX/VMS System Generation Utility Reference Manual for a
complete discussion of the System Generation Utility (SYSGEN). Note that
the new settings for LRPCOUNT and LRPSIZE will not take effect until the
next time the operating system is booted.

5.4.2

Critical Routing Node Requirements
For some critical routing nodes in large networks, it may be necessary to
guarantee that user processes running on the node never interfere with the
memory requirements of the network software. In this case, you may want to
configure the system for worst-case use of the nonpaged dynamic pool.
The use of nonpaged pool is controlled by the quota values that you specify
for each user when you create the user's authorization record. For worst-case
configuration, the sum of the quotas of all the simultaneously active processes
must provide the required free pool for the network software.
To configure a system for such a worst case, adhere to the following four
rules:
•

The sum of the ASTLM (asynchronous system trap limit), BIOLM
(buffered I/O limit), DIOLM (direct I/O limit), and TQELM (timer queue
limit) quotas for each process must be added to the IRPCOUNT parameter.

•

The FILLM (file and logical link limit) quota for each process must be
doubled and added to the IRPCOUNT parameter.

•

The ENQLM (enqueue limit) quota for each process must be doubled and
added to the IRPCOUNT parameter. ENQLM is the number of locks each
process can own.

•

The BYTLM (buffered I/O byte count limit) quota for each process must
be added to the NPAGEDYN parameter.

Given these guidelines, the result of the calculation below should be less than
the total free pool after the network has initialized:
USERPROCESSES * (((ASTLM + BIOLM + DIOLM + TQELM + (FILLM * 2)) * 96) + BYTLM)

For example, if for a critical routing node you also want to provide for 16
users' processes, the calculation might be
16 * (((10 + 6 + 6 + 5 + (8 * 2)) * 96) + 4096) = 16 * 8224 = 131584 bytes

This calculation indicates that there should be at least 131,584 bytes
of nonpaged dynamic pool remaining after the network has initialized.
However, because it is extremely unlikely that all users will require their
quota of pool at the same time, then, except for a worst-case configuration,
the quotas and pool could be configured minimally so that no one user's
quota would completely deplete the free pool. Use the SHOW MEMORY
operator command or the dynamically updated POOL display for the Monitor
Utility to configure the nonpaged dynamic memory pool for normal use.
The consequences of running almost or completely out of pool are fairly
obvious to system users: System performance will be very sluggish; processes
will continually enter the MWAIT scheduling state while they wait for an
available free pool; and the free pool SHOW MEMORY display will indicate
almost none.

5-34

Configuration of a Network

If the lack of pool causes the network software on the node to be unable
to allocate a buffer fast enough to receive data from a communications
line, the line may be considered unusable by another node in the network.
When this happens, the network will attempt to adaptively reconfigure
itself, thereby resulting in network traffic consisting of configuration update
messages. If the node with pool problems should be close to failing, without
failing completely, it may alternate between working and not working,
thereby causing the network to repeatedly reconfigure itself. Ultimately, these
reconfigurations will degrade the performance of the entire network.

5.4.3

CPU Time Requirements
Proper system configuration to provide adequate processor time for the
network software is somewhat more straightforward. Most of the procedures
that control network routing are located in NETDRIVER. Because most of
NETDRIVER runs at elevated interrupt priority level (IPL), normal user
programs cannot preempt its execution. However, user-written drivers and
privileged programs running at elevated IPL can affect the proper operation
of NETDRIVER.
Writing a Device Driver for VAX/VMS provides guidelines for elevated IPL
execution programming. In general, a program should run at elevated IPL
only as long as necessary to synchronize correctly with other processes and
devices. In particular, running at IPL IPL$_SYNCH for more than a few
hundred milliseconds or running at any IPL at or above IPL$_MAILBOX
for more than a few hundred milliseconds may adversely affect the network
software. The effect of improper elevated IPL programming on the whole
network is the same as having insufficient free nonpaged dynamic pool.
The procedure that handles the automatic network reconfiguration for a
network node is contained in the NETACP process. Therefore, for proper
network operation, the NETACP process must also be assured of sufficient
processor time. It runs at base priority of 9, which is well above the
recommended base priority of 4 for normal users. However, real-time
processes running at priorities 10 through 31 can preempt the execution
of NETACP.
Just as for user-written drivers, the programming of real-time processes must
account for the needs of the network software and other system software.
A rule of thumb for real-time processes is that they should not normally
preempt the execution of NETACP for more than a few hundred milliseconds
at a time, and they should never preempt its execution for more than 5 to 10
seconds. This restriction allows NETACP sufficient processor time to run its
routing algorithms properly.
If NETACP is unable to perform all of its functions, the effects on the whole
network will be the same as having insufficient free pool or incorrect elevated
IPL programming. If the above guidelines cannot be met for a particular
real-time application, the application should probably not be used on a node
that is also doing network routing.
The NETACP process, like all system processes, can be swapped and
paged. However, because its base priority is 9, it will be one of the last
processes swapped when it is running and swapping becomes necessary.
Also, NETACP receives high priority for paged disk I/O requests. Again,
improper considerations for the disk I/O needs of NETACP can adversely
affect the network as a whole. If the NETACP process continually enters the
PFW or COMO scheduling state, it is probably not receiving sufficient priority

5-35

Configuration of a Network

for paging or swapping; other real-time or system programs should probably
be modified to relieve the problem.

5.4.4

UNIBUS Adapter Map Register Considerations
The UNIBUS adapter on VAX processors provides a mechanism called
UNIBUS map registers (UMRs) that allows UNIBUS peripherals to access
VAX main memory. These map registers are required because the UNIBUS
allows only 18 bits of address space while the VAX processors provide 24
or 30 bits (depending on processor type). The 18 bits of address space are
divided into 496 pages of 512 bytes each. Therefore, there are 496 map
registers that allow up to 496 pages of memory to be mapped for direct
memory access (DMA) by UNIBUS devices.
Because UNIBUS map registers are a limited resource needed for correct
operation of the network software, some consideration should be given to
their use.
VAX/VMS provides a service for device drivers to allocate and deallocate
map registers. Most drivers allocate map registers only for the time it takes
for the device to perform a transfer, after which they deallocate them for use
by another I/O request to the same device or by other drivers for different
devices. This type of allocation is referred to as dynamic allocation.
Other drivers, however, permanently allocate map registers all the time the
system is running. This is either because certain memory tables must be
accessible to the device (TS11, DMC11, and DMP11) all the time the device
is initialized or because of certain throughput requirements of the device (1
megabaud DMC11/DMR11, DMP11, DEUNA, and LPA11). This type of
allocation is referred to as permanent allocation.
If a device driver process attempts to allocate UMRs and there are not enough
free to satisfy the allocation, the driver process is put into a FIFO wait queue
to wait for UMRs to become available.
The following list presents the UNIBUS map register requirements of the
various supported UNIBUS devices.

5-36

•

The TS11 driver permanently allocates a maximum of three map registers
in its command table for each TS11 on the UNIBUS when it initializes.
The TS11 supports one DMA I/O request at a time, and because an I/O
can be up to 65,536 bytes in size, the TS11 driver requires a maximum of
128 map registers that can be allocated dynamically.

•

The RL02, RK06, RK07, and RX02 disk drives support one DMA I/O
request at a time. Because the maximum I/O request size can be 65,536
bytes, these drivers require a maximum of 128 map registers that can be
allocated dynamically.

•

The LPA11-K laboratory data acquisition device driver can be configured
to permanently or dynamically allocate up to 496 map registers. The
SYSGEN parameter LAMAPREGS allows you to specify how many map
registers are to be permanently allocated; if this parameter is 0, map
registers will be dynamically allocated as needed when the device is used
for I/O.

•

The DMC11/DMR11 driver permanently allocates a maximum of three
map registers for its base table when it initializes. It also permanently
allocates enough map registers for all of its receive buffers, which are set
with the RECEIVE BUFFERS line parameter and BUFFER SIZE executor

Configuration of a Network

parameter. However, if more than seven receive buffers are specified per
line, only seven sets of map registers per line will be allocated.
The DMC11/DMR11 driver supports one DMA transmit at a time and
because each transmit can be a maximum of 16,383 bytes in size, the
DMC11/DMR11 driver requires a maximum of 32 map registers that can
be allocated dynamically.
•

The DMP11 driver allocates map registers in the same way that the
DMC11/DMR11 driver does with the exception that the DMP11 driver,
which does not have a base table, requires three fewer map registers.

•

The DEUNA device driver assigns eight receive buffers with a length of
1500 bytes per buffer. Enough map registers are permanently allocated for
all receive buffers.

The following example details how one might determine whether sufficient
map registers will be available. Assume the example system consists of a
VAX-11/780 with a single UNIBUS adapter, two RK07 disk drives on a
single controller, a TS11 tape drive, and three DMRlls. The BUFFER SIZE
executor parameter is set to 576 and each line has its RECEIVE BUFFERS
parameter set to 4. Because each buffer can potentially cover three pages
(two pages to contain the 576-byte buffer and one page for an offset page)
and because the VAX/VMS map register allocator always allocates an extra
invalid map register for protection, each buffer will require four map registers.
Device

Permanent Map Registers

TS11

Three permanent map registers would be required for the TS1 1.

DMR11 (3)

Fifty-seven map registers would be required for the three
DMRlls. (Each DMR permanently allocates 19 map registers;
three UMRs for the base table and four UMRs for each of the
four receive buffers.

Therefore, 496 minus 60, or 436 map registers are available for dynamic use
by all devices.
Because the TS11 and RK07s can each be using 128 map registers, there will
always be at least 436 minus 256, or 180 map registers available to map
DMR11 transmit buffers. This amount is more than sufficient as the DMRlls
will each have only one transmit of 576 bytes outstanding at a time, which
will require a maximum of 3 times 4, or 12 map registers.
In general, because VAX/VMS has dynamic map register allocation and
waiting when UNIBUS map registers run out, they are not a resource
problem. However, if a system has a large number of DMC11/DMR11,
DMP11, and DEUNA devices, it is prudent to calculate map register use to
ensure that the configuration works.

5-37

Configuration of a Network

5.4.5

Permanent Database Considerations in VAXclusters
The permanent configuration database, usually resident on disk, consists of a
number of files. These files are listed in Table 5-4.
Table 5-4

Permanent Configuration Database Files

File Name

Usage

SYS$SYSTEM:NETNODE—REMOTE. DAT

Remote node

SYS$SYSTEM:NETNODE_LOCAL.DAT

Executor and loop node

SYS$SYSTEM:NETLINE.DAT

Line

SYS$SYSTEM:NETLOGING.DAT

Logging

SYS$SYSTEM:NETOBJECT.DAT

Object

SYS$SYSTEM:NETCIRC.DAT

Circuit

SYS$SYSTEM:NETX25.DAT

X.25 module

SYS$SYSTEM:NETX29.DAT

X.29 module

SYS$SYSTEM:NETCONF.DAT

Configurator module

In a homogeneous VAXcluster, it may be desirable to allow some of these files
to be shared by members of the VAXcluster; shared files should be moved to
SYS$COMMON:[SYSEXE] and files that are not to be shared should reside
in SYS$SPECIFIC:[SYSEXE] (where they are normally created). Neither
NETNODE_LOCAL.DAT nor NETX25.DAT should be shared as they contain
executor information that is unique for each node in a VAXcluster. Other
files such as NETLINE.DAT and NETCIRC.DAT should not be shared if
the communications hardware configurations within the VAXcluster are not
identical on every node.
As an example, if the permanent object database is identical on every node in
a VAXcluster, it can be shared by using the following steps:
1

Rename (or move) the permanent object database on one node to the
common system root, for example:
$ RENAME SYS$SPECIFIC:[SYSEXE]NETOBJECT.DAT _$ SYSICOMMON:[SYSEXE]NETOBJECT.DAT

or
$ COPY SYS$SPECIFIC:[SYSEXE]NETOBJECT.DAT _$ SYSICOMMON:[SYSEXE]NETOBJECT.DAT

2 Delete (or rename) the permanent object database from the private system
root on each node in the VAXcluster, for example:
$ DELETE SYSISPECIFIC:[SYSEXE]NETOBJECT.DAT;*

or
$ RENAME SYSlSPECIFIC:[SYSEXE]NETOBJECT.DAT;* _$ SYSISPECIFIC:[SYSEXE]NETOBJECT.OLD;*

The files SYS$SYSTEM:NETNODE.DAT and SYS$SYSTEM:NETNODE_
OLD.DAT are obsolete versions of the permanent node database that may be
deleted.

5-38

Installation of a Network

This chapter describes how to start DECnet-VAX and how to install and start
VAX PSI.

6.1

Installing a DECnet-VAX Key
If you have purchased a license for either a DECnet-VAX full function kit
or a DECnet-VAX end node kit, you must install the key for the license.
The procedure for installing the appropriate license key is described in the
DECnet-VAX Key Installation Guide, which is distributed with the key.
The DECnet-VAX end node kit allows the node to be configured only as an
end node. The DECnet-VAX full function kit allows the node on which it has
been installed to be configured as either a routing node or an end node. To
upgrade an end node license to a full function license, install the key for the
full function kit.

6.2

Bringing Up Your Network Node Using STARTNET.COM
After you satisfy the prerequisites for establishing a network and define the
necessary parameters in the configuration database (see Chapter 5), you are
ready to bring up your DECnet-VAX node. To do so, you must have defined
the local node (using the DEFINE EXECUTOR command) in the permanent
database. This information is the minimum requirement for the initial control
of the operational state of the node.
After you build the permanent database using either NCP or the
NETCONFIG.COM interactive configuration procedure (see Chapter 5),
issue the following command to bring up your network:
$ <QSYS$MANAGER: STARTNET. COM

This command starts NCP and NML, and configures the volatile database
with the parameters that you have defined in the permanent database. This
procedure also turns on the local node and all lines and circuits connected to
it. In addition, STARTNET.COM starts the network command terminal ACP
by executing SYS$MANAGER:RTTLOAD.COM. At this point, the local node
is ready for network operations with itself and with adjacent nodes.
DECnet-VAX uses OPCOM to display certain network-related messages on
the network operator's console. When you turn on the local node, OPCOM
will display the following message:
Opcom, hh:mm:88:cc, SYSTEM Acct=
Opcom, DECnet starting

Once you have brought up your DECnet-VAX node, you use NCP commands
to control the operational states of network components. You can control
both local components and remote executions of NCP commands. This
control allows you to dynamically reconfigure your network to control the use
of the network and its resources. Use the NCP commands CLEAR and SET
for the volatile database to control the network.

6-1

Installation of a Network

Parameters in the permanent database define network components each time
you use the word ALL with the SET command. Typically, you will use the
SET "component" ALL command if you choose not to use STARTNET.COM
to bring up the network. Section 6.5 discusses how you can shut down your
network in an orderly manner.
Note that if you are going to run VAX PSI, you must install the VAX PSI
software before invoking STARTNET.COM. This also applies to VAX PSI
Access software.

6.3 Bringing Up Your VAX PSI DTE
Bringing up VAX PSI DTE is similar to bringing up a node on the DECnetVAX network. First, install VAX PSI, following the procedure described
in the VAX PSI Installation Procedures. Make sure you configure VAX PSI
in multihost mode (instead of native mode) if you are building a DECnet
network that allows some or all of its nodes to access the PSDNs connected.
The multihost installation will set up the commands necessary to bring up
the connector node (the node connected to the PSDNs) as a DTE. (Section 5.3
includes examples of both native mode and multihost mode configurations.)
Invoking the STARTNET.COM procedure will bring up both DECnet-VAX
and VAX PSI software. Once you are satisfied that VAX PSI is installed
properly, you can use VAX PSI to communicate with a remote DTE over a
packet switching data network (PSDN).
Note that if you make changes to your PSI system while it is running and you
wish to include these changes in your PSI system the next time the system is
started, you must also make similar changes to the permanent database using
NCP commands (DEFINE and PURGE).

6.4 Testing the Installation with UETP Test Procedure
To ensure that the DECnet-VAX installation is successful, you can use the
User Environment Test Package (UETP) to test DECnet. The test procedure is
described in the Guide to VAX/VMS Software Installation.

6.5 Shutting Down Your DECnet—VAX Node
Bringing down your operating system will automatically bring down your
DECnet-VAX node as well. The next time you reboot the operating system,
your network will come up automatically if SYSTARTUP.COM invokes
STARTNET.COM (see Section 6.2). However, if the network is running and
you want to shut down your network node in an orderly manner or otherwise
restrict its use, you can use NCP to control the operational state of the local
node. NCP offers three options for shutting down the executor node.
•

To shut down your local node without destroying active logical links, use
the command
NCP>SET EXECUTOR STATE SHUT

This command closes the node in an orderly fashion; new links are not
allowed, and existing links are not destroyed. When all logical links are
disconnected, this command turns off the node, and NCP logs an event
message.

6-2

Installation of a Network

Once the last link terminates and is disconnected, the executor node in
the SHUT state enters the OFF state. This action occurs whether or not
the node is currently in use for route-through traffic. Consequently, the
communication path between nodes using the local node for route-through
may be broken.
•

Instead of shutting down your local node, you can restrict network
operations on that node. This restriction does not affect current logical
link activity; however, no new inbound logical links can be created unless
they originate locally or unless a process with the OPER privilege confirms
them. Use the following command to restrict local node operations:
NCP>SET EXECUTOR STATE RESTRICTED

•

To shut down the local node regardless of current logical link activity, use
the command
NCP>SET EXECUTOR STATE OFF

This state allows no new logical links to be created, terminates existing
links, and stops route-through traffic.
Note: Programs that have declared names or object numbers and that are
started independently of DECnet-VAX should be programmed to
terminate when their mailboxes receive a MSG$__NETSHUT message.
This message appears when the node is shutting down.
Whenever the local node's state goes to OFF, DECnet-VAX uses the OPCOM
facility to display the following message on the console:
Opcom, hh:mm:as:cc, SYSTEM Acct=
Opcom, DECnet shutting down

Table 6-1 summarizes local node states and basic network operation
restrictions for them. These operations include network routing, confirming
inbound connections from a remote node, and initiating outbound
connections to a remote node.
If your network configuration includes VAX PSI, shutting down a DECnetVAX node will also shut down VAX PSI and clear the PSI volatile database.
Bringing up the DECnet-VAX node subsequently will restart VAX PSI and
recreate the volatile database from the permanent database.
Table 6-1

Local Node States and Network Operations

State

Route-Through
Traffic

Connect Confirm
Operations

Connect Initiate
Operations

Unrestricted

RESTRICTED

Unrestricted

Unrestricted only if the partner node
is the local node or if the confirming
process has the OPER privilege

Unrestricted

SHUT

Unrestricted

Unrestricted only if the confirming
process has the OPER privilege

Unrestricted only if the
initiating process has the
OPER privilege

OFF

Restricted

6-3

Testing the Network

NCP provides several kinds of tests to help you determine whether the
network is operating properly. Specifically, 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-VAX software, you may want to run some of these tests.
In general, problems that you encounter with the DECnet-VAX network will
probably arise from misconfigured VAX/VMS and DECnet parameters that
can easily be fixed using SYSGEN or NCP. DIGITAL supplies variations of
these tests to exercise separate layers of the network. User-written processes
or DECnet-supplied processes may also initiate the tests.
DECnet-VAX tests fall into two categories: node-level loopback tests and
circuit-level loopback tests. Use node-level tests to evaluate the operation
of logical links, routing, and other network-related software. Use circuitlevel tests to evaluate the operation of circuits. It is suggested that you use
node-level tests first; then, if necessary, use circuit-level tests. This chapter
describes these variations as they relate to DECnet loopback capabilities and
the NCP command LOOP, and provides a practical approach to their use.
Note that LOOP commands cannot be used on asynchronous lines or circuits.
VAX PSI provides various ways to analyze software and hardware operation
and to diagnose problems in PSI operations. Use line-level loopback tests
to evaluate the operation of the X.25 physical lines and communications
hardware. VAX PSI provides an additional facility for the KMS11 and KMV11
line interfaces, allowing you to dump the microcode to a specified file for
analysis. This chapter describes these VAX PSI test facilities and how to use
them. For additional details about the VAX PSI test facilities, refer to the VAX
PSI Problem Solving Guide.

7.1

Node-Level Tests
Node-level loopback tests will test the logical link capabilities of a node by
exchanging test data between DECnet processes on two different nodes or
between DECnet processes on the same node. These tests consist of two
types:
•

Loopback tests for logical link operation regardless of the circuit

•

Loopback tests for operation over a specified circuit

The second test sends test messages over a specified circuit associated with a
loop node name (see Section 7.1.2). This test directs test messages regardless
of the Routing layer function.
Both types of node-level loopback tests allow you to test the functions of your
DECnet-VAX software. To test various aspects of this software, you may
want to perform a series of operations, as described below.
1

In the first test, loop information to a remote loopback mirror process
using a remote loopback test. This tests all local and remote network
software up to the DNA user layer on the remote node.
7-1

Testing the Network

2 If the first test fails, use a loop node name and loop information to the
local node and to a remote node. The loop node name allows you to
direct traffic over a specified circuit, which tests local and remote Routing
software.

3 If the second test fails, set the circuit's line to "controller loopback" and
repeat step 2.
Regardless of the type of test you choose, use the NCP command LOOP
NODE to send test messages. This NCP function uses a cooperating process
called the Loopback Mirror to facilitate the transmission and reception of test
messages. When you issue this command, you have the option of controlling
the type of binary information (MIXED, ONES, ZEROS); the number of
blocks of information, which ranges from 1 to 65,535; and the length in
bytes of each block to be looped, which also ranges from 1 to 65,535. (It is
recommended that you use a maximum block length of 4096 bytes to reduce
the system load.) Refer to the VAX/VMS Network Control Program Reference
Manual for the complete syntax of the LOOP NODE command.
If your message returns with an error, the test stops and NCP prints a
message that indicates a test failure, specifies the reason for the failure, and
provides a count of the messages that were not returned. For a summary of
NCP error messages, refer to the VAX/VMS System Messages and Recovery
Procedures Reference Manual.
In the example below, the test attempted to send 10 messages, each 50 bytes
long. The first two messages were sent successfully, and an error occurred on
the third.
ncp>loop node boston count 10
'/.NCP-I-NMLRSP, listener response- line communication error
Messages not looped = 8

7.1.1

Remote Loopback Test
Use the LOOP NODE command to test for a logical link connection between
two nodes. When using this command, you must identify the node to which
you want to loop test messages. Figure 7-1 illustrates a remote loopback test.
For this test, you first turn the selected remote node line and circuit to the ON
state to allow for logical link activity. Then use the LOOP NODE command.
For example, the set of commands below tests both local and remote DECnet
software on nodes BOSTON and TRNTO.
NCP>SET LINE DMC-0 STATE ON
NCP>SET CIRCUIT DMC-0 STATE ON
NCP>L00P NODE TRNTO COUNT 10

7.1.2

Local and Remote Loopback Tests Using a Loop Node Name
If the remote loopback test failed, then use the LOOP NODE command with
a loop node name to test a logical link path over a specified circuit. You
can loop test messages either over a logical link path and circuit within the
local node or between two different nodes with a loop node/bold specified
for the circuit to be used. Use the latter method first in order to test remote
Routing layer software. In each case, use the SET NODE command with
the CIRCUIT parameter to establish a loop node name. For example, the
following command establishes circuit DMC-0 as the circuit over which loop
testing will take place:

7—2

Testing the Network

Figure 7-1

Remote Loopback Test

NCP Commands:
NCP>SET LINE DMC-0 STATE ON
NCP>SET CIRCUIT DMC-0 STATE ON
NCP>LOOP NODE TRNTO COUNT 10

BOSTON (executor)

TRNTO

NCP

Loopback
Mirror
NML

_J
(logical link)
ZK-555-81

NCP>SET NODE TESTER CIRCUIT DMC-0

No other parameters are valid for loop nodes. This circuit must be turned on
when performing these tests.
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
DMC-0, you must issue a CLEAR NODE TESTER CIRCUIT command before
assigning another loop node name to DMC-0.
When a logical link connection request is made to the loop node name, all
subsequent logical link traffic will be 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.
7.1.2.1

Local-to-Remote Testing
To test a logical link path over a circuit between the local node and a remote
node, you must specify a loop node name for the given circuit and issue the
LOOP NODE command. Figure 7-2 illustrates a local-to-remote loopback test
using a loop node name.

7-3

Testing the Network

Figure 7-2

Local-to-Remote Loopback Test Using a Loop Node
Name

NCP Commands:
NCP>SET LINE DMC-0 STATE ON
NCP>SET NODE TESTER CIRCUIT DMC-0
NCP>SET CIRCUIT DMC-0 STATE ON
NCP>LOOP NODE TESTER COUNT 10

BOSTON (loop node TESTER)

Remote Node

ZK-556-81

For this test, you first turn on the line and set a loop node name for the
given circuit to the remote node. Next, turn on the circuit. Finally, issue the
LOOP NODE command using the loop node name, as shown in the following
example:
NCP>SET LINE DMC-0 STATE ON
NCP>SET NODE TESTER CIRCUIT DMC-0
NCP>SET CIRCUIT DMC-0 STATE ON
NCP>L00P NODE TESTER COUNT 10

This set of commands tests both local and remote Routing layer software
operation. The test messages are looped over the loopback circuit. Because
the test actually tests the operation of the Routing layer on the remote node,
the message may not come back on the circuit over which it was sent.

7.1.2.2

Local-to-Local Testing
If the local-to-remote test fails, try a local loopback test with the local node to
test local Routing layer software exclusively. To test a logical link path over a
specified line on the local node, specify a loop node name and set the device
controller to loopback mode. Figure 7-3 illustrates a local-to-local loopback
test using a loop node name.
For this test, you first turn off the line, set the controller to loopback mode,
and turn on the line and circuit. Finally, set a loop node name for the given
line and issue the LOOP NODE command using the loop node name. The
set of commands below tests the Routing layer software and the controller on
the local node.
NCP>SET LINE DMC-0 STATE OFF
NCP>SET LINE DMC-0 CONTROLLER LOOPBACK
NCP>SET LINE DMC-0 STATE ON
NCP>SET CIRCUIT DMC-0 STATE ON
NCP>SET NODE TESTER CIRCUIT DMC-0
NCP>L00P NODE TESTER COUNT 10 LENGTH 32

7-4

Testing the Network

Figure 7-3

Local-to-Local Loopback Test Using a Loop Node
Name

NCP Commands:
NCP> SET LINE DMC-0 STATE OFF
NCP>SET LINE DMC-0 CONTROLLER LOOPBACK
NCP> SET LINE DMC-0 STATE ON
NCP>SET CIRCUIT DMC-0 STATE ON
NCP>SET NODE TESTER CIRCUIT DMC-0
NCP> LOOP NODE TESTER COUNT 10 LENGTH 32

BOSTON (loop node TESTER)

ZK-557-81

Because the device is set to loopback mode, the test messages are looped over
the circuit and back to the local node. If this test fails, try a local loopback
test to test local DECnet software.
Note: Because of restrictions in the operation of the DMC controller, you must
use a block length of fewer than 50 bytes for controller loopback tests.

7.1.3

Local Loopback Test
If the loopback tests described in Section 7.1.2.2 should fail, then use either
the LOOP NODE command with the local node-id or the LOOP EXECUTOR
command to test local DECnet software. This type of test uses DECnetVAX software to loop messages to the loopback mirror on the local node.
Figure 7-4 illustrates a local loopback test.
For this test, you simply issue the following command at the local node:
NCP>L00P EXECUTOR COUNT 10

This test evaluates the local DECnet software using an internal logical link
path. If this test succeeds and the other node-level tests fail, then try the
circuit-level tests. If these tests fail, the executor's default nonprivileged
DECnet account is probably set up incorrectly.

7-5

Testing the Network

Figure 7-4

Local Loopback Test

NCP Commands:
NCP>LOOP EXECUTOR COUNT 10

BOSTON (executor)

NCP

Loopback
Mirror

NML
(logical link)

7.2

Circuit-Level Tests
Circuit-level loopback tests will test a DECnet circuit by looping test data
through a hardware loopback device on the circuit, either through a modem
(or loopback connector) or through a remote node. The tests that use a
hardware loopback device are referred to as controller loopback tests; the
tests that use a loopback connector or a modem are referred to as circuit
loopback tests; the tests that use the software capabilities of the system are
referred to as software loopback tests.
You may want to perform a series of operations to test various aspects of a
circuit. These operations are described below.
1

In the first test, perform a software loopback test to another node to
determine whether the circuit is operational up to the remote circuit unit
and controller.

If the first test fails, set the controller to loopback mode and use a
controller loopback test to determine whether the controller works.

If the second test succeeds, then attach a modem (or loopback connector)
to the controller and use a circuit loopback test to determine whether the
unit is functional.

Regardless of the test type, you must use the NCP command LOOP CIRCUIT
to perform a circuit-level loopback test. When you issue this command, you
have the option of controlling the type of binary information (MIXED, ONES,
ZEROS); the number of blocks of information, which ranges from 1 to 65,535;
and the length in bytes of each block to be looped, which also ranges from 1
to 65,535. (It is recommended that you use a maximum block length of 4096
bytes.) For the complete syntax of the LOOP CIRCUIT command, refer to the
VAX/VMS Network Control Program Reference Manual.

7-6

Testing the Network

If your message returns with an error, the test stops and NCP prints a
message indicating a test failure, the reason for the failure, and a count of
the messages that were not returned. For a summary of NCP error messages,
refer to the VAX/VMS System Messages and Recovery Procedures Reference
Manual. In the example below, the test attempted to send 10 messages, each
50 bytes long. The first two messages were sent successfully, and an error
occurred on the third.
NCP>SET LINE DMC-0 CONTROLLER NORMAL STATE ON
NCP>L00P CIRCUIT DMC-0 COUNT 10
V.NCP-1 -NMLRSP, listener response- line protocol error
Messages not looped = 8

7.2.1

Software Loopback Test
Use the LOOP CIRCUIT command to perform a software loopback test of
a circuit connected to the local node. This type of test uses DECnet-VAX
software to loop through the circuit to circuit service software in the adjacent
node and back to the local node. Figure 7-5 illustrates a software loopback
test to test whether the circuit is operational up to the remote unit and
controller on the adjacent node.
Figure 7-5

Software Loopback Test

NCP Commands:
NCP>SET LINE DMC-0 STATE OFF
NCP>SET LINE DMC-0 CONTROLLER NORMAL
NCP>SET LINE DMC-0 STATE ON
NCP>SET CIRCUIT DMC-0 STATE ON
NCP>LOOP CIRCUIT DMC-0 COUNT 10

BOSTON (executor)

Remote Node

ZK-559-81

In the first step of this test, you turn the line off. Next, you set the controller
to its normal operational mode and put the line and the circuit in the ON
state. Finally, you issue the LOOP CIRCUIT command. This sequence is
shown below.
NCP>SET LINE DMC-0 STATE OFF
NCP>SET LINE DMC-0 CONTROLLER NORMAL
NCP>SET LINE DMC-0 STATE ON
NCP>SET CIRCUIT DMC-0 STATE ON
NCP>L00P CIRCUIT DMC-0 COUNT 10

This set of commands tests the circuit DMC-0 up to the adjacent node. If this
test fails, try a circuit loopback test to verify that the circuit is functional.

7-7

Testing the Network

7.2.2

Controller Loopback Test
Use the LOOP CIRCUIT command to perform a controller loopback test of
a physical line on the local node while the controller is in loopback mode.
This type of test verifies whether or not the circuit up to the controller and
the controller itself are functional. Figure 7-6 illustrates a controller loopback
test.
Figure 7-6

Controller Loopback Testing

NCP Commands:
NCP>SET LINE DMC-0 STATE OFF
NCP>SET LINE DMC-0 CONTROLLER LOOPBACK
NCP>SET LINE DMC-0 STATE ON
NCP>SET CIRCUIT DMC-0 STATE ON
NCP> LOOP CIRCUIT DMC-0 COUNT 10 LENGTH 32

BOSTON (executor)

For this test, you first turn the line off. Next, you set the controller to
loopback mode and put the line and circuit in the ON state. Finally, you
issue the LOOP CIRCUIT command. For example:
NCP>SET LINE DMC-0 STATE OFF
NCP>SET LINE DMC-0 CONTROLLER LOOPBACK
NCP>SET LINE DMC-0 STATE ON
NCP>SET CIRCUIT DMC-0 STATE ON
NCP>L00P CIRCUIT DMC-0 COUNT 10 LENGTH 32

This set of commands tests the circuit up to the controller for physical line
DMC-0 connected to the local node by circuit DMC-0.
Note: Because of restrictions in the operation of the DMC controller, you must
use a block length of fewer than 50 bytes for controller loopback tests.

7-8

Testing the Network

7.2.3

Circuit-Level Loopback Testing
Circuit-level loopback testing is also supported for Ethernet circuits. One
major difference between loopback testing on point-to-point and multipoint
circuits (DMCs and DMPs) and on an Ethernet circuit is that the former
requires two separate processors (one at each end), but the latter requires
only one processor. In Ethernet circuit loopback testing, it is the target node's
Ethernet interface rather than its processor that loops the messages.
In Ethernet circuit-level loopback testing (as in the case of point-to-point
circuit loopback testing), network management accesses the Data Link layer
directly, thus bypassing intermediate layers. One advantage of the Ethernet
loopback test is that it can be performed concurrently with other DECnet
operations on the circuit.

7.2.3.1

Testing with the PHYSICAL ADDRESS and NODE Parameters
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. As indicated in Chapter 2,
DECnet supports the UNA, which provides for multiaccess connections
between many nodes on the same Ethernet circuit. In the example below, the
command identifies the circuit device UNA and the controller number 0 for
an Ethernet circuit.
NCP>SET CIRCUIT UNA-0 STATE ON SERVICE ENABLED

The UNA is used to loop messages on the Ethernet circuit. If desired, it can
be used to loop messages to itself in order to test its own state. To do this,
enter the following commands:
NCP>SET LINE UNA-0 STATE OFF
NCP>SET LINE UNA-0 CONTROLLER LOOPBACK STATE ON
NCP>SET NODE TEST CIRCUIT UNA-0
NCP>LOOP NODE TEST

In this case you were able to test the status of the UNA in controller loopback,
but not the capacity of the node to transmit and receive messages. For
more information on the node's capacity to send and receive messages, see
Section 7.1.2.2.
More typical cases of loopback testing of Ethernet circuits involve looping
messages to remote systems over the Ethernet; this tests the capability of both
the local and the remote UNAs to send and receive messages. In those cases,
you are required to supply such information as the Ethernet physical address
or the node name or address of the circuit at the remote node that you wish
to test.
Nodes on Ethernet circuits are identified by unique Ethernet addresses.
An Ethernet address is 48 bits in length and is represented by six pairs of
hexadecimal digits (6 bytes), separated by hyphens (for example, AA-01-2345-67-89). For more detail on Ethernet addresses, see Section 3.3.4.
Each UNA on the Ethernet circuit has a hardware address (in read-only
memory) that has been assigned to it by the manufacturer. Typically, DECnet
will set an Ethernet physical address for the UNA, thereby replacing the
hardware address as the address to which the UNA currently responds. The
UNA's physical address will continue to be the address to which it responds,
unless it is reset to the hardware address value (for example, if the Ethernet
circuit is set to OFF).

7-9

Testing the Network

It is helpful to know the Ethernet physical address of the UNA on the remote
node that you wish to test. Since this is not always possible, it is a good
practice if you plan to perform loopback tests to include the hardware address
of each of the UNAs on your Ethernet circuit in the permanent database,
thus ensuring that the address will be retrievable from the volatile database.
You can then use the node-id in the LOOP command. When node-id is
specified, network management software retrieves the hardware address from
the volatile database and attempts to transmit the loop message to the remote
UNA by alternately using the hardware address and the physical address that
DECnet would normally use.
The following example contains an Ethernet physical address:
NCP>L00P CIRCUIT UNA-0 PHYSICAL ADDRESS AA-00-04-00-FF-04

Since in this case you know the physical address of the remote node that you
wish to test, you merely include the PHYSICAL ADDRESS parameter with its
value. If, however, that physical address had changed (for example, if it had
been reset to the hardware address value), the loopback would have failed.
You would have received the following message:
7.NCP-I-NMLRSP, listener response line protocol error
Messages not looped = 1

If you also know the name or address of the remote node, you could test
the UNA on that node even though its Ethernet physical address may
have changed. The Ethernet hardware address of the node to be tested
must already have been entered in the database on the executor node. If
the hardware address is included in the volatile database, and you test by
supplying the node name or address, the loop test will be attempted by the
network management software to both the hardware address and the DECnet
address.
An example of a loopback test that specifies the NODE parameter is the
following:
NCP>L00P CIRCUIT UNA-0 NODE TEST

Assume that TEST'S physical address, which was AA-00-04-00-F7-04, is
changed. Thus any attempt to test TEST using the old physical address
would not succeed. If, however, TEST'S hardware address (which was
AA-00-03-00-01-31) is included in the volatile database on the executor
node, the loopback test with the NODE parameter in its specification would
succeed.
In the above example, you could alternatively supply the node address value
(such as 226) for the NODE parameter. For example, if you know the node-id
but not the name of the node, you could specify
NCP>L00P CIRCUIT UNA-0 NODE 226

In this case, the node address is used to construct the DECnet physical
address and the Ethernet hardware address (assuming that it is included
in the volatile database) is used to access the circuit on the remote node
and complete the loopback test. Thus it is important to enter the hardware
address in the volatile database.
If you want to examine the Ethernet hardware address of your own UNA
(in this case UNA-0), you can use the NCP command SHOW LINE
CHARACTERISTICS. When you enter the command
NCP>SH0W LINE UNA-0 CHARACTERISTICS

7-10

Testing the Network

you will receive a display such as the following:
Line Volatile Characteristics as of 15-APR-1986 15:33:25
Line = UNA-0
Receive buffers
Controller
Protocol
Service timer
Hardware address
Buffer size

7.2.3.2

=
=
=
=
=

0
normal
Ethernet
4000
AA-00-03-00-12-00
1498

Loopback Assistance
DECnet supports the use of an assistant physical address and an assistant
node to aid you in interrogating a remote node. To use this feature, you
specify either the ASSISTANT PHYSICAL ADDRESS parameter or the
ASSISTANT NODE parameter as an additional parameter to the LOOP
CIRCUIT command.
You can use the "assistant" in three distinct ways. First, you can use it to
assist you in receiving loop messages from a remote node. Second, you can
use it in transmitting loop messages to a remote node. Third, you can use it
in both transmitting messages to and receiving messages from a remote node.
There are various reasons why you might choose one form of assistance over
another. For example, it is possible that the target node to which you wish
to transmit a message is located at a point where the signals are too weak to
send a message. In this case, you could request assistance in transmitting the
message to the target node. Similarly, you may be able to transmit messages
to the target node, but not be able to receive messages from it. In such a case
you can send a message directly to the target node and request an "assistant"
to aid you in receiving a message from the target node. When you encounter
difficulties in both sending and receiving messages, you can request an
assistant node to help you to both transmit messages to and receive messages
from the target node.
The commands below illustrate the use of the ASSISTANT PHYSICAL
ADDRESS and ASSISTANT NODE parameters.
NCP>L00P CIRCUIT UNA-0 PHYSICAL ADDRESS AA-00-04-00-18-04_ ASSISTANT PHYSICAL ADDRESS AA-00-04-00-15-04
NCP>L00P CIRCUIT UNA-0 NODE LOON ASSISTANT NODE THRUSH

In the first command, you are requesting the node described by the Ethernet
physical address AA-00-04-00-15-04 to assist you in testing the node
described by the Ethernet physical address AA-00-04-00-18-04. In the
second command, you are requesting the node THRUSH to assist you in
testing node LOON.
If you specify either the ASSISTANT PHYSICAL ADDRESS or ASSISTANT
NODE parameter and you do not specify the HELP parameter, you will
receive FULL assistance; that is, you will be assisted both in receiving and
transmitting loop messages. Note that in the above examples, because the
ASSISTANT PHYSICAL ADDRESS and ASSISTANT NODE parameters were
specified without the HELP parameter, the default is FULL assistance.
If you wish to use an assistant node only to receive messages from the remote
node, you could issue the following command:
NCP>L00P CIRCUIT UNA-0 NODE LOON ASSISTANT NODE THRUSH HELP RECEIVE

7-11

Testing the Network

In this example you are requesting the node THRUSH to assist you in
receiving messages from node LOON. When you wish to be assisted only in
sending or transmitting loop messages, you could issue a command such as
the following:
NCP>L00P CIRCUIT UNA-0 NODE LOON ASSISTANT NODE 21 HELP TRANSMIT

Note that in this case the ASSISTANT NODE parameter contains the node
address, rather than the name of the node as in the previous example. In
each of the last two examples, the HELP parameter was included to specify
the type of assistance desired.

7.3

X.25 Line-Level Loopback Tests
There are three types of line-level loopback tests that you can use to test an
X.25 physical line:
•

External loopback tests that loop data back through the modem

•

Internal loopback tests that loop data back through the device

•

External loopback tests that loop data back through a loopback device on
the line

You may want to perform the series of operations below to test various
aspects of the physical line.
1

First, using the loop switch on the modem, perform an external loopback
test through the modem. This test checks the logic of the device
transmitter and receiver, the line driver, the modem cable, and part of
the modem. If this test is successful and you still have errors, contact your
network manager.

If the first test fails, perform an internal loopback to test only the logic of
the device transmitter and receiver.

If the second test succeeds, attach a hardware loopback device to the
modem cable. Then perform an external loopback to test the logic of the
device transmitter and receiver, the line driver, and the modem cable.

Regardless of the test type, use the NCP command SET LINE to specify the
type of loopback test and the NCP command LOOP LINE to initiate the
line-level loopback test.
Specify values for two parameters of the SET LINE command, as follows:
Internal Loopback

External Loopback

STATE SERVICE

CONTROLLER LOOPBACK

CONTROLLER NORMAL

Note that the line state must be set to OFF before the CONTROLLER
parameter can be changed.
To initiate a test, use the LOOP LINE command with the same line identifier
you specified with the SET LINE command. For example, the commands
below initiate an external loopback test for the line DUP-0:
NCP>SET LINE DUP-0 ... STATE SERVICE CONTROLLER NORMAL
NCP>L00P LINE DUP-0 ...

Associate parameters with the LOOP LINE command to control the type of
test information and the size and number of blocks sent during testing.
7-12

Testing the Network

Use the COUNT and LENGTH parameters to specify the number of blocks
sent over the line during a test and the length (in bytes) of each block sent.
The command line below sends 2000 blocks 100 bytes long over the line.
NCP>L00P LINE DUP-0 COUNT 2000 LENGTH 100 ...

Specify decimal integers in the range 1 to 65,535 for both these parameters.
Note that this test will take approximately 5 minutes, as calculated below.
2000 * (100+4)*8
- seconds
5000

= 5 minutes

A DUP runs at 5000 bps when looped back.
Use the WITH parameter to specify the type of binary information sent during
loopback testing. You can specify three types of binary information:
ONES

All binary Is

ZEROES

All binary 0s

MIXED

A random combination of Is and Os

For example, the command below sends 2000 blocks 100 bytes long, each
containing all binary Is, over the line:
NCP>L00P LINE DUP-0 COUNT 2000 LENGTH 100 WITH ONES

If you omit the WITH parameter, a combination of Is and Os (MIXED) is
sent. If you omit the COUNT and LENGTH parameters, one block of 128
bytes is sent. For example, the command below sends one block of 128 bytes,
containing mixed binary information, over the line:
NCP>L00P LINE DUP-0

Further details on loopback testing are given in the VAX PSI Problem Solving
Guide.

7.4

Dumping KMS11 and KMV11 Microcode
This section describes how to dump the KMS11 or KMV11 microcode to a file
and how to analyze the dump file. The KMS11 and KMV11 are synchronous
line devices that interpret the X.25 level 2 protocol. They are supported by
VAX PSI (see the table of DECnet circuit and line devices in the VAX/VMS
Network Control Program Reference Manual).
Use the MICROCODE DUMP parameter of the NCP command SET LINE to
dump the microcode of the specified device to the file indicated. By default,
the output file takes the format below, where filename is the file that you
specify.
filename.DMP

For example, the command below dumps the microcode of the file
BARRY.DMP in your current default directory:
NCP>SET LINE KMX-0-0 MICROCODE DUMP BARRY

Use the DUMP parameter only if you believe there is an error in the
microcode of the KMX, KMY, or KMV.
The KMS/KMV dump analyzer can be used to process the dump file.
For a description of the dump analyzer, refer to the VAX PSI Problem Solving
Guide.

7-13

PART IV: Network User Operations

Performing Network User Operations

DECnet-VAX allows you to perform a variety of operations over the network.
For example:
•

Retrieving information about the status of the nodes in your network

•

Establishing communication with a remote DECnet node through the
heterogeneous command terminal facility

•

Accessing files on remote nodes

•

Performing task-to-task operations

This chapter describes each of these operations. The primary focus of this
chapter, however, is on the use of task-to-task communication in network
operations.
For VAX PSI user operations, refer to the VAX PSI documentation set.

8.1

Retrieving Network Status Information
Before you perform a specific type of operation over the network, you may
want to check the status or availability of a particular node or nodes in your
network. To retrieve such information, you can use the DCL command
SHOW NETWORK.
Note that the SHOW NETWORK command can be used to retrieve
information about your network only if your local node is a routing node.
If your local node is a nonrouting (end) node, you will not receive any
network information; instead, you will be directed to a designated routing
node.
The SHOW NETWORK command displays the availability of the local node
as a member of the network and the addresses and names of all nodes that
are currently accessible to the local node.
The SHOW NETWORK command also displays link and cost relationships
between the local node and other nodes in the network. It displays the
current network in terms of five characteristics: node, links, cost, hops, and
next hop to node.
Node

Identifies each available node in the network by its node
address and node name.

Links

Shows the number of logical links between the local
node and each available remote node.

Cost

Shows the total line cost of the path to a remote node.
The cost for each line in the network is assigned by the
system manager.

Hops

Shows the number of intervening nodes plus the target
node.

8-1

Performing Network User Operations

Next hop to node

Shows the outgoing physical line used to reach the
remote node. (The local node is identified by the term
LOCAL.)

When you enter the SHOW NETWORK command, you will receive a display
on your terminal similar in format to the following:
VAX/VMS Network Status for local node 2.161 ARAKIS on 15-APR-1986
The next hop to nearest area router is node 2.62 ZEUS.
Node
2.161 ARAKIS
2.1 RAEL
2.2 PANGEA
2.3 TWDEE
2.4 TWDUM
2.11 NEONV
2.63 AURORA

Links
0
0
0
0
0
0
0

Cost

Hops

Next Hop to Node

0
8
8
10
8
8
8

0
1
1
2
1
1
1

Local
UNA-0
UNA-0
UNA-0
UNA-0
UNA-0
UNA-0

->
->
->
->
->
->
->

2.161 ARAKIS
2.1 RAEL
2.2 PANGEA
2.63 AURORA
2.4 TWDUM
2.11 NEONV
2.63 AURORA

Total of 7 nodes.

If your local node is an end node, and you enter the SHOW NETWORK
command, you will receive the following message on your terminal:
This is a nonrouting node, and does not have any network
information. The designated router for node ARAKIS is
node 2.62 ZEUS.

If you enter the SHOW NETWORK command, but the network is unavailable
at that time, you will receive the following display:
Network unavailable

For more detailed information on the DCL command SHOW NETWORK, see
the description in the VAX/VMS DCL Dictionary.

8.2

Establishing Communication with a Remote Node
DECnet-VAX supports a command terminal facility that permits a single user
to establish communication with a remote node and to use the facilities of
that system while physically connected to the local node. By means of this
link, you can temporarily become a local user of the remote node and thereby
perform functions that the remote node allows its local users to perform.
Note that in addition to communicating with remote VAX/VMS nodes, you
can also communicate with non-VAX/VMS nodes that support the DNA
heterogeneous remote command terminal protocol facility. Consult the
Software Product Description for non-VMS operating systems and their
DECnet implementations.
If you wish to use the command terminal facility to establish communication
with a remote node, enter the DCL command SET HOST. The format for this
command is
$ SET HOST nodename

The nodename is a 1- to 6-character name or number specifying the remote
node at which you want to log in. The SET HOST command does not
recognize the area prefix in a node number. Therefore, to specify by number
a node in another area, you must convert the node number to its decimal
equivalent (as described in Section 3.7.2).

8-2

Performing Network User Operations

The remote node system will prompt for a username and password. If the
information you supply is valid, you will be logged in to the remote node. To
return control to your local node, type LOGOUT.
You will receive the following message at your terminal:
'/.REM-S-END, Control returned to node _nodename: :

This message indicates that control has been returned to your local node.
The only special control character used for remote command terminal
operations is CTRL/Y. Except for CTRL/Y, all control characters are handled
as if they were issued at the local node.
Repeated, rapid pressing of CTRL/Y will generate a prompt asking if the
remote connection should be broken. If you answer "Yes" to the prompt,
control will return to the local node. This technique is useful if for some
reason you cannot return to the local node normally.
The following command sequence illustrates the operation of remote
command terminals for our network topology example. The name of the
local node is BOSTON.
$ SET HOST TRNTO
Username: SMITH
Password:
Welcome to VAX/VMS Version 4.0 on node TRNTO

$ LOGOUT
SMITH logged out at 8-APR-1986 12:31:55:49
‘/.REM-S-END, Control returned to node .BOSTON::
$

Once you are logged in at a remote node, you can use the SET HOST
command to establish communication with another node. After logging in to
node TRNTO, you could type SET HOST DENVER.
You would again be prompted for a username and password. If you then
supply a valid username and password, you will be logged in at node
DENVER.
Note that when you log out at node DENVER, control is returned to node
TRNTO. You must log out from node TRNTO to return to your local node,
BOSTON.
For more detailed information on the SET HOST command, see the
description in the VAX/VMS DCL Dictionary.

8.3

Accessing Files on Remote Nodes
DECnet-VAX allows you to access files on remote nodes in your network as
though these files were on your local node. You can use the DECnet-VAX
facilities to access remote files by means of DCL commands and command
procedures, higher-level language programs, and MACRO programs using
VAX RMS or VAX/VMS system services.

8-3

Performing Network User Operations

8.3.1

Using DCL Commands and Command Procedures
Most DCL commands used to perform file operations at a local node can
also be used to perform these operations on remote nodes. For example, you
can use the same DCL commands to obtain directory listings, manipulate
files, and execute command procedures on remote nodes. You need only
prefix a node name followed by two colons to the standard VAX/VMS file
specification to access the remote file.
For example:
$ TYPE TRNTO::WORKS:[DOE]LOGIN.COM

In this example, the TYPE command requests that the file LOGIN.COM in
the directory DOE at the remote node TRNTO be displayed on your local
terminal.
As with DCL, remote file accessing by higher-level languages is accomplished
in a way that is transparent to the user. All that you need to specify is the
name of the remote node containing the file or files that you wish to access.
Like DCL, higher-level language programs also employ the VAX RMS services
to perform file access operations.
Other examples of the use of DCL commands to access remote files can be
found in the VAX/VMS DCL Concepts Manual. Command descriptions in that
document also include restrictions that apply to individual commands and
command qualifiers used over the network. Unless otherwise stated, you can
assume that a particular DCL command is supported for network operations.

8.3.2

Using Higher-Level Language Programs
You can use various higher-level languages to write programs that access
remote files. Regardless of the programming language used, you access
remote files exactly as you would access local files.
For example, assume you want to design a FORTRAN program to transfer
files from a local node to a remote node. Also assume that the two nodes
are identified by the logical names SRC and DST, respectively. You can use
two DCL commands to define the logical names for the files involved in the
transfer, by entering the following commands:
$ DEFINE SRC TRNTO::USER:[STOCKROOM.PAPER]INVENTORY.DAT
$ DEFINE DST BOSTON::LPAO:

Once you have made the logical name assignments, the FORTRAN program
can open the files by way of those logical names. You can use the following
FORTRAN open calls:
OPEN (UNIT=1.NAME=•SRC'.TYPE='OLD'.ACCESS*'SEQUENTIAL',
FORM*'FORMATTED')
OPEN (UNIT*2,NAME*'DST',TYPE*'NEW',ACCESS*'SEQUENTIAL'.
FORM*'FORMATTED',CARRIAGECONTROL*'LIST',
RECORDTYPE*'VARIABLE')

This FORTRAN program uses standard I/O statements to transfer records
from one file to another. In this example, the access mode is sequential.
Examples of complete higher-level language programs designed to access
remote files are included in the appropriate sections of each VAX language's
programming manuals.

8-4

Performing Network User Operations

8.3.3

Using MACRO Programs
The VAX/VMS system provides a programming interface for remote file
accessing using VAX MACRO. The MACRO programs can use VAX Record
Management Services (RMS) calls or VAX/VMS system service calls.
This section describes how RMS can be used to access remote files. The
VAX/VMS system services, which can also be used for remote file accessing,
are described more thoroughly in Section 8.5.4.
For remote file processing, RMS integrates the network software necessary to
translate standard RMS calls, which provides a transparent user interface to
the network.
Using the RMS facilities, you can perform remote file-handling operations on
entire files or access individual records, through programmed RMS service
calls in a VAX/VMS MACRO application. All you need to do is supply the
name of the remote node in your file specification.
As in the FORTRAN example above, you can use DCL commands to make
logical name assignments to the source and destination files that you wish to
manipulate.
$ DEFINE SRC TRNTO::USER:[STOCKROOM.PAPER]INVENTORY.DAT
$ DEFINE DST BOSTON::TEMP:[ARCHIVE]INVENTORY.DAT

Before you can open either the source (SRC) or destination (DST) files with
the RMS $OPEN statement, however, you must allocate the appropriate file
access blocks (FABs) and record access blocks (RABs) in your program. To do
this you can use the RMS structures shown below.

SRC.FAB:
$FAB

FAC=GET,F0P=SQ0.FNM=SRC

$RAB

FAB=SRC_FAB,RAC=SEQ,-

These statements define the source file FAB and RAB control blocks. You
must also define the destination file FAB and RAB control blocks.

DST.FAB
$FAB

FAC=PUT,F0P=SQ0.FNM=DST.0RG=SEQ,RFM=VAR,RAT=CR

$RAB

FAB=DST_FAB,RAC=SEQ,-

DST.RAB

8-5

Performing Network User Operations

After defining the source and destination FABs and RABs, you can now open
the files for remote file processing. Note that if your program accesses files
sequentially, you can specify the sequential-only (SQO) option of the file
options (FOP) field of the FAB. Specifying FOP=SQO enables RMS and the
remote File Access Listener (FAL) to enter into file-transfer mode, which
significantly increases file-transfer performance.
Examples of complete MACRO programs using RMS to access remote files
are contained in the Guide to VAX/VMS File Applications. Examples in this
document also illustrate the network-specific features provided by VAX RMS.
RMS fields and options that must be specified for DECnet-VAX applications
are described in the VAX Record Management Services Reference Manual of
the VAX/VMS System Routines Reference Volume. This manual also describes
restrictions that apply to using RMS over the network. See Chapter 9 for
a list of restrictions on VAX/VMS operations involving other systems in a
heterogeneous network.
Note that DECnet-VAX does not support the use of RMS for operations on a
remote magnetic tape volume.

8.4

Performing Task-to-Task Operations
Task-to-task communication, a feature common to all DECnet
implementations, allows two programs running under the same or different
operating systems to communicate with each other regardless of the
programming languages used. For example, a FORTRAN program running
on the VAX/VMS system at node BOSTON could exchange messages with
a MACRO program running on the RSX-11M system at node DALLAS.
Although these programs use different programming languages and run
under different operating systems, the DECnet software translates systemdependent language calls into a common set of network protocol messages.
Note that in the context of task-to-task communication, the terms "task" and
"program" are used synonymously.

8.4.1

Transparent and Nontransparent Task-to-Task Communication
DECnet-VAX supports both transparent and nontransparent task-to-task
communication. Transparent communication provides all the basic functions
necessary for a DCL command procedure or a user program (written in either
VAX/VMS MACRO or in a higher-level language) to communicate with other
command procedures or user programs over the network. Nontransparent
communication allows the MACRO programmer to use more network-specific
functions.
A simple analogy illustrates the differences between these two forms of
communication. Transparent communication is similar to device-independent
I/O in VAX/VMS in which you move data with little concern for the way the
operation is accomplished. Likewise, transparent communication allows you
to move data across the network without necessarily knowing that you are
using DECnet software. Nontransparent communication, on the other hand,
is analogous to device-dependent I/O, in that you are interested in specific
characteristics of the device that you want to access. A nontransparent task,
in turn, can use network-specific features to monitor the communication
process.

8-6

Performing Network User Operations

8.4.1.1

Transparent Communication
Transparent communication provides the basic functions necessary for a
task to communicate with another task over the network. These functions
include the initiation and completion of a logical link connection, the orderly
exchange of messages between both tasks, and the controlled termination of
the communication process. To perform these functions, you can program
your transparent task in any of the higher-level languages supported over the
network, in VAX MACRO (using RMS service calls or system service calls) or
even using DCL commands.
One way to view transparent communication is to look at the programming
required to develop such an application. Transparent access provides the
minimum functions necessary to communicate over the network using
standard I/O operations. When accessing the network transparently, you
use no DECnet-specific calls to perform these functions; rather, you use
standard RMS I/O service calls or the normal I/O statements provided by
the applicable language to access a sequential record-oriented device. (The
remote task is modeled as two VAX/VMS mailboxes in which two processes
can perform read and write operations.) You can also use system service calls
to perform transparent communication, as described in Section 8.5.

8.4.1.2

Nontransparent Communication
Nontransparent communication provides the same basic functions as
transparent communication plus additional system service and I/O functions
supported by DECnet-VAX. In particular, a nontransparent task can create
and use a VAX/VMS mailbox to receive information that would otherwise
remain inaccessible to a transparent task. Thus you can make use of networkspecific features such as optional user data on connects and disconnects, and
interrupt messages. Also, certain nontransparent tasks that have a mailbox
can receive and process multiple inbound connection requests.
Note that on a VAXcluster node, nontransparent tasks that can receive
multiple inbound connection requests should not use the cluster alias node
address for outgoing connections, and should not be enabled to receive
incoming connections directed to the cluster alias node. Incoming links
directed to a cluster alias node address can be assigned to any of the nodes
in the cluster that accept that alias node address, without knowledge of the
nodes on which a declared task may be running (see Section 2.6.2).
In general, nontransparent tasks can use a mailbox to receive information
about particular network operations. Mailbox messages are of four types:
•

Messages that result from the use of certain system service calls (including
optional user data carried on logical link creation or termination)

•

Interrupt messages

•

Logical link status messages

•

Network system messages

Nontransparent functions that indirectly cause mailbox messages to be
placed in the receiver's mailbox include calls for initiating and completing
logical links, and calls for terminating links. Figure 8-1 illustrates the use of
mailboxes by nontransparent tasks.
A list of mailbox messages and their meanings is given in the VAX/VMS
System Services Reference Manual.

8-7

Performing Network User Operations

Figure 8-1

Mailbox

Mailbox Messages

Synchronous Disconnect (opt. user data)
Disconnect Abort (opt. user data)

Mailbox

MSGS_DISCON
MSGS_ABORT

Z3C
DECnet-VAX Software

Network Status Notifications:

MSGS_EXIT
MSGS_PATH LOST
MSGS_PROTOCOL
MSGS_TIMEOUT
MSGS_THIRDPARTY

ZK-840-82

MSGS_NETSHUT

A nontransparent task can also receive network status notifications in the
mailbox. These notifications apply to physical and logical link conditions over
the network. For example, DECnet-VAX software can notify a nontransparent
task of the following conditions:
•

Third-party disconnections

•

Network software- and hardware-related problems

•

Processes exiting before I/O completion

•

Connection request timeouts

Regardless of whether you are performing a transparent or nontransparent
task-to-task operation, you must use a task specification string to identify
the remote task with which you wish to communicate.

8-8

Performing Network User Operations

8.4.2

Task Specification Strings in Task-to-Task Applications
A task specification string is a quoted string that identifies the remote task to
which you attempt a logical link connection.
To establish a logical link connection with a remote task addressed as object
type 0, use either of the following forms of task specification string:
•

"TASK=taskname"

•

"(Maskname"

Note that "0" and "TASK" are equivalent. The taskname can be from 1 to 12
characters.
If the remote node is a VAX/VMS system, the taskname represents the
file name of a command procedure to be executed at the remote node. (If
the remote node is not a VAX/VMS system, the maximum length of the
taskname may be different.) The command procedure can complete the
logical link itself (using a DCL OPEN command), or it can include a DCL
RUN command to execute a program that completes the logical link.
The examples that follow illustrate two uses of the task specification string.
The specification below identifies the task TEST2 by using the TASK= form
for specifying remote tasks. The second example is the same as the first,
except that access control information is provided and the alternative 0= form
for specifying a task is used.
BOSTON::»TASK=TEST2»
BOSTON"SMITH JOHN"::»0=TEST2"

In this example, TEST2 refers to SYS$LOGIN:TEST2.COM at the remote
VAX/VMS node. Note that only the file name component of the command
file specification is used in the task name string.

8.4.3

Functions Required for Performing Task-to-Task Operations
Several functions are necessary for performing a task-to-task operation. The
number of functions will, of course, depend on whether you intend to access
the network transparently or nontransparently.
Even a transparent task-to-task application requires a minimum number
of operations to initiate and complete a logical link connection, to
exchange messages, and to terminate the logical link. These operations
are actually a subset of a larger group of functions defined for nontransparent
communication. The entire set of functions is as follows:
•

Initiating a logical link connection
— Requesting a logical link to a remote task1
— Declaring a network name and processing multiple connection requests

•

Completing a logical link connection
— Rejecting a logical link connection request
— Accepting a logical link connection request1

l Minimum subset for transparent task-to-task communication.

8-9

Performing Network User Operations

•

Exchanging messages
— Sending and receiving data messages1
— Sending and receiving interrupt messages

•

Terminating a logical link
— Synchronously disconnecting the logical link
— Aborting the logical link1

Nontransparent tasks can use any or all of these functions to extend the basic
capabilities offered under transparent communication.

8.4.3.1

Initiating a Logical Link Connection
Regardless of whether you access the network transparently or
nontransparently, you must establish a communication link to the remote
node on which the target task runs before any message exchange can take
place. You establish the link by issuing a source task call that requests a
logical link connection. (The source task is the task that initiates a logical
link connection request; the target task is the task with which you want to
communicate).
The interaction between the source task and the target task that takes place
before the logical link is established is called a handshaking sequence. Upon
receiving a call that requests a logical link connection, the local DECnet-VAX
node initiates a handshaking sequence with the target task. The following
information is supplied in a connection request:
•

An I/O channel. The I/O channel serves as the path over which messages
are sent and received by the source program.

•

The identification of the target node. Every node in a network has an
identifier that distinguishes it from all other nodes in the network.
Transparent communication uses a task specification string to indicate
the name of the target node. Nontransparent communication requires a
user-generated data structure called the network connect block (NCB),
which includes a task specification string.

•

An object type descriptor.

•

Access control information (optional).

•

Optional user data. Nontransparent tasks have the option of sending up
to 16 bytes of data to the target program (see the information below on
NCBs).

It is important to be aware that once you issue a call that uses either a task
specification string or an NCB, you access the network and, by definition,
DECnet-VAX software.

1 Minimum subset for transparent task-to-task communication.
8-10

Performing Network User Operations

8.4.3.2

Completing the Logical Link Connection
As part of the handshaking sequence, the target task completes the logical
link connection in two steps. First, the DECnet software at the remote node
processes the inbound logical link connection request. Second, the target
task either accepts or rejects the link. These steps are performed differently,
depending on whether the target task uses transparent or nontransparent I/O.
When a logical link request is received, a procedure called NETSERVER.COM
is executed, which in turn invokes the image NETSERVER.EXE. This program
works in conjunction with the network ACP (NETACP) and uses DCL to
invoke the image or command procedure defined for the requested object (the
specified task for object 0 or FAL for object 17).
When the logical link is terminated, the "object" program (for example, FAL)
also terminates. However, the process is not deleted. Instead, control is
returned to NETSERVER.EXE, which communicates with NETACP to inquire
for another incoming logical link request. This inquiry process continues until
NETSERVER encounters a timeout condition (the default is 5 minutes).
The time that NETSERVER waits for another logical link request can be
specified by the system manager. The logical name NETSERVER$TIMEOUT,
when defined, determines the amount of time NETSERVER will wait before
reaching the timeout condition. Note that the equivalence name must be in
the standard VAX/VMS delta time format.
In the following discussion, it is assumed that the remote node is a VAX/VMS
system. If the remote node on which your target task runs is not a VAX/VMS
system, you should refer to the DECnet documentation for that system.
Completing the Connection Transparently
If the target task is transparent, the DECnet software at the remote node
checks the access control information supplied in the connection request call.
Before you access the remote node, the system manager must have created the
appropriate account in the UAF (refer to the information on access control). In
addition, the command procedure file (taskname.COM) for starting the remote
task must exist in the directory associated with the account identified by the
access control information. For a description of the command procedure
taskname.COM, see Section 8.7.1, which contains examples of command
procedures designed for task-to-task communication.
Command procedures for objects existing in the OBJECT database (which is
created using NCP commands) are located in the SYS$SYSTEM directory.
The DIGITAL-supplied FAL.COM procedure is an example of such a
command procedure.
Completing the Connection Nontransparently
If the target task is nontransparent, then one of several things may occur.
If the task has not declared itself a network task (and is therefore eligible
to accept only one connection request at a time), then the DECnet software
at the remote node performs the access checking procedure. After it starts,
the target task retrieves the connection information by translating the logical
name SYS$NET using the $TRNLNM system service call (see Section 8.6).
If the target task declares itself as an active network task, then
DECnet-VAX software places all connection requests addressed to the task
in the mailbox associated with the channel being used. The first message
in the mailbox is the NCB from the original connection request that started
the task. This message appears in the mailbox after channel assignment and

8-11

Performing Network User Operations

name declaration occur. Once the task declares a network name or number,
subsequent inbound connection requests are not checked by the remote node
to verify access control. (Note that if the task is started without being part of
a DECnet operation, access control is never checked.) Section 8.6 describes
in more detail the nontransparent process of completing the logical link
connection.
After examining the incoming connection request, the target task either
accepts or rejects the request, and optionally can send 1 to 16 bytes of data
back to the source task at the same time that it responds to the logical link
connection request. Furthermore, a library routine, LIB$ASN_WTH_MBX,
which assigns a channel and associates a unique mailbox, can be used when
accepting the connection if no optional data is returned.

8.4.3.3

Exchanging Messages
You access the network transparently or nontransparently, DECnet-VAX
sends data messages over a logical link in response to a set of send and
receive calls issued by the source and target tasks. For higher-level language
tasks, use standard READ and WRITE statements to send and receive data
messages. (In Example 8-2, the two FORTRAN tasks use read and write
statements to exchange information. The equivalent RMS service calls are
$GET and $PUT.)
After DECnet-VAX creates a logical link, the two tasks are ready to exchange
messages. This exchange can take place only if the two tasks "cooperate" in
the transmission process. In other words, for each message sent by a task, the
receiving task must issue a corresponding call to receive the message. Also,
you must decide which task will disconnect the link. In addition, if the tasks
are nontransparent, they must agree on whether or not the optional data will
be passed. In the context of an established logical link, the task sending a
message is the transmitter and the task receiving it is the receiver.
DECnet-VAX distinguishes between two types of messages: data messages
and mailbox messages. Data messages are the normal mode of information
exchange for both transparent and nontransparent communication. Mailbox
messages such as interrupt messages, messages resulting from some DECnet
operation (including optional user data), and network status notifications, can
be used only in nontransparent communication.
Nontransparent communication frequently involves using a mailbox to obtain
network-specific information. A task may receive three types of messages in
its mailbox:
•

Messages that DECnet generates when the task initiates certain network
operations. A VAX/VMS task issues system service calls to initiate these
operations.
— When one task requests a logical link connection, a notification
message (and optional user data) may be placed in the mailbox of
the target task.
— When a target task accepts or rejects the logical link connection request,
a notification message (and optional user data) is placed in the mailbox
of the source task.
— When one task synchronously disconnects or aborts a logical link, a
notification message (and optional user data) is placed in the mailbox
of the task from which it is disconnecting.

•

8-12

Network status notification messages that inform a task of some unusual
network occurrence (such as a third-party disconnect).

Performing Network User Operations

•

84.3.4

Interrupt messages sent by the other task.

Terminating the Communication Process
The termination of a logical link signals the end of the communication
between tasks.
In transparent communication using higher-level language statements, RMS
service calls, or system service calls, either task can break the link. To
terminate the link properly, it is recommended that the receiver, and not
the transmitter, of the final message issue the close call to break the link.
The link termination process is complete when the other task issues a link
termination request. In transparent communication using system service calls,
the $DASSGN system service call causes the link to be terminated.
In nontransparent communication using system service calls, you can
terminate I/O operations over a channel in one of three ways:
•

Synchronous Disconnect ($QIO)—Indicates to the remote receiver that all
messages sent by the local transmitter have been acknowledged at the
end-communication layer. This does not guarantee, however, that the
user of NSP received the data.

•

Disconnect Abort ($QIO)—Indicates to the remote receiver that all messages
sent have not necessarily been received. To ensure that all messages are
received before the link is disconnected, the sender must cancel I/O on
the channel before issuing the abort call.

•

Deassign Channel and Terminate Link ($DASSGN)—Deassigns the
channel and immediately breaks the link.

Note that after either a synchronous disconnect or a disconnect abort, you
can issue a new connection request because you did not deassign the I/O
channel but merely deaccessed the link. For further information on these
system service calls, see Section 8.6.
When a nontransparent task terminates the communication process, a
notification message indicating that the link is disconnected is placed in
the mailbox of the affected task. A nontransparent task can send up to 16
bytes of optional user data, which is also placed in the mailbox.
By their nature, disconnect operations are of little value in guaranteeing to
both partners that communication is complete. Therefore, it is recommended
that the communicating tasks agree on a protocol for terminating
communication. In general, the receiver, not the transmitter, of the final
message should disconnect the logical link.
In general, transparent communication allows you to create a logical link
between tasks, send and receive data messages, and terminate the logical link
at the end of the message dialog. The discussion covers general concepts
implicit in DECnet-VAX task-to-task communication and assumes familiarity
with the QlO-related material in the VAX/VMS System Services Reference
Manual. The use of higher-level language statements and RMS service calls
in transparent task-to-task communication is described in Section 8.5.

8-13

Performing Network User Operations

8.5

Performing Transparent Task-to-Task Operations
This section describes the system service calls and functions that you can use
to perform transparent task-to-task communication over the network. You
can perform these operations using any of the following methods:
•

DCL commands and command procedures

•

Higher-level language programs using appropriate language calls

•

MACRO programs using VAX RMS calls or VAX/VMS system service calls

See Section 8.7 for examples of transparent task-to-task operations.

8.5.1

Using DCL Commands and Command Procedures
To perform transparent task-to-task operations, you can use DCL commands
to construct and execute command procedures.
For example, to display information about another system, you can design
a command procedure that can be invoked as a remote task. Assume that a
procedure called SHOWBQ.COM is designed to return status information
about jobs entered in batch queues on the system where it executes.
Assume also that SHOWBQ.COM resides on node TRNTO. You can
use SHOWBQ.COM for task-to-task communication by entering a task
specification string in a TYPE command. For example:
$ TYPE TRNTO"BROWN JUNE"::"TASK=SHOWBQ"

See Section 8.7.1 for an example of a command procedure used for taskto-task communication. For additional information concerning the design,
construction, and execution of command procedures, see the Guide to Using
DCL and Command Procedures on VAX/VMS.

8.5.2

Using Higher-Level Language Programs
This section contains examples of higher-level language calls that can be used
for transparent task-to-task communication. Each higher-level language call
contains a task specification string as part of its statement.
Higher-level language tasks can use standard file opening statements to
request a logical link connection to a remote task. The following examples
show how to specify a target task, TEST4, running on node TRNTO, in six
languages supported on VAX/VMS.
FORTRAN

OPEN (UNIT=7,NAME=TRNTO::"TASK=TEST4''',TYPE='NEW/)

BASIC

OPEN TRNTO: :"TASK=TEST4/" AS FILE #7

PL/I

OPEN FILE(OUTPUT) TITLE (TRNTO: :"TASK=TEST4'");

PASCAL

OPEN (PARTNER#'TRNT0::"TASK=TEST4,",NEW);

COBOL

SELECT PARTNER ASSIGN TO "TRNTO::,,,/TASK=TEST4/,,///. OPEN OUTPUT PARTNER.

F 1=0PEN ("TRNTO::\"TASK=TEST4\ "",2);
To complete the logical link, the target task performs a file opening operation
using the logical name SYS$NET to establish a communications path back to
the source task. The following examples show how to specify SYS$NET.

8-14

Performing Network User Operations

FORTRAN

OPEN (UNIT=2,NAME=/SYS$NET,,TYPE=/OLD/)

BASIC

OPEN "SYS$NET" AS FILE #2

PL/I

OPEN FILE(INPUT) TITLE ('SYS$NET');

PASCAL

OPEN (PARTNER/SYSSNET^LD);

COBOL

SELECT PARTNER ASSIGN TO "SYS$NET". OPEN INPUT PARTNER.

F2=OPEN ("SYS$NET",2);
An example of a FORTRAN program designed for transparent task-to-task
communication is in Section 8.7.2.

8.5.3

Using RMS Service calls in MACRO Programs
You can write a MACRO program or a higher-level program to perform
transparent task-to-task communications, using RMS service calls. This
section describes how to use RMS service calls in a MACRO program.
Note that the RMS $OPEN statement is equivalent to the higher-level
language statements described in the previous section.
Once the appropriate FAB and RAB control blocks have been defined, you
can use the $OPEN statement to specify the target task, TEST4, running on
node TRNTO. You can initiate the link by specifying the following call, in
your MACRO program.
TARGET:
$FAB

$OPEN

FAC=<GET,PUT>,0RG=SEQ,FNM=<N0DE: :"TASK=TEST4”>
FAB=TARGET

To complete the logical link, the target task performs a file-opening operation
using the logical name SYS$NET to establish a communications path back to
the source task. For example:
REQUESTER:
$FAB

$0PEN

FAC=<GET,PUT>,0RG=SEQ,FNM=<SYS$NET>
FAB=REQUESTER

As in the case of the target task, the appropriate FABs and RABs must already
be declared, if the RMS OPEN call is to succeed. On inbound connections,
DECnet-VAX automatically makes the logical name assignment to SYS$NET.

8.5.4

Using System Service Calls in MACRO Programs
You can write MACRO programs or higher-level language programs to
perform transparent task-to-task communications, using system service calls.
This section focuses on MACRO programs using system service calls for
performing these operations.
Table 8-1 summarizes these calls and their network-related functions.
Section 8.5.5 presents the format of these calls in more detail.

8-15

Performing Network User Operations

Table 8-1

System Service Calls for Transparent
Communication

Call

Function

SASSIGN

Request a logical link connection

SDASSGN

Terminate a logical link

$QIO (IO$_READVBLK)

Receive a message

$QIO (IOS—WRITEVBLK)

Send a message

These calls allow you to perform task-to-task communication in much the
same way as you would perform normal I/O operations. Use the $ ASSIGN
call to assign a logical link I/O channel to a device, which in this case
is a task that behaves like a full-duplex record-oriented device. You can
perform read and write operations with this task in either a synchronous or
asynchronous manner. To exchange messages, use the Queue I/O (QIO)
requests supported by DECnet-VAX. When all communication completes,
use the $DASSGN system service call to deassign the channel and thereby
disconnect the logical link.

8.5.4.1

Requesting a Logical Link
To request a logical link and assign an I/O channel, use the $ ASSIGN system
service. When you issue this call, you must include a task specifier for the
remote node on which the cooperating task runs. The task specifier identifies
the remote node and the target task to which you want to establish a logical
link.
For example, for the network model described in Chapter 1, you could
establish a logical link to target task TEST2 on node TRNTO to perform taskto-task communication. To create this link, code the following VAX MACRO
statements in your source program.
TARGET:
NETCHAN:

.ASCID
.BLKW

/TRNTO::"TASK=TEST2"/
1
; Channel number returned here

$ASSIGN_S

DEVNAM=TARGET,CHAN=NETCHAN

For debugging or for symmetry, you can develop and run the target task on
the local node. Use the local node name (or node number 0) plus two colons
to connect to the local node.
Once you establish a logical link, you refer to the assigned channel in any
succeeding call in the MACRO program, either to send or receive messages,
or to deassign the channel and terminate the logical link.
Until the connection operation completes, the process is in local event flag
wait (LEF) state in kernel mode. Therefore, pressing CTRL/Y will not return
the process to DCL status. The maximum amount of time that the process
will wait in this state is specified by the NCP command SET EXECUTOR
with the OUTGOING TIMER parameter. If this timer cannot be set to an
acceptable value, tasks that accept commands from the terminal should use
$QIO (IO$_ACCESS) instead of the transparent $ASSIGN call to initiate
logical links.

8-16

Performing Network User Operations

8.5.4.2

Completing the Logical Link Connection
The target task completes the logical link by specifying the logical name
SYS$NET as the devnam argument for the $ASSIGN system service. For
example:
LOGNAM:
NETCHAN:

.ASCID
.BLKW

/SYS$NET/
1
; Channel number returned here

$ASSIGN_S

DEVNAM=LOGNAM,CHAN=NETCHAN

Issue these calls in the target task to complete the logical link connection. The
target task also specifies a channel to be used in subsequent system service
calls.
It is assumed that the remote node is a VAX/VMS system. If the remote node
on which the target task runs is other than VAX/VMS, you should refer to
the related DECnet documentation.

8.5.4.3

Exchanging Messages
After DECnet-VAX software establishes a logical link with the target task,
either task can then send or receive messages. However, they must cooperate
with each other: for each message sent with the $QIO (IO$_WRITEVBLK),
the other task must issue a corresponding $QIO (IO$_READVBLK) to receive
the message.
You must ensure that the tasks allocate enough buffer space for receiving the
messages; if they do not, a DATAOVERUN error will occur. You must also
ensure that the end of the dialog can be determined. Finally, one of the two
tasks must disconnect the logical link. To terminate a logical link properly,
the receiver, and not the transmitter, of the final message should break the
link.

8.5.4.4

Terminating the Logical Link
Use the $DASSGN system service call to deassign the channel and break off
the logical link with the cooperating task. This call terminates all pending
calls for sending and receiving messages, aborts the link immediately, and
frees the channel associated with that logical link.

8.5.4.5

Status and Error Reporting
When a system service completes execution, a status value is always returned.
The $ASSIGN, $DASSGN, and $QIO system services place the return status
information in register 0 (RO). For the $QIO system service, a successful
status return indicates only that the request was queued successfully. All I/O
completion status information is placed in the I/O status block (IOSB). For
example, a $QIO system service read request to a task might be successful
(status return is SS$_NORMAL) yet fail because the link was disconnected.
(I/O status return is SS$_LINKABORT.) The return status codes shown in
the following sections may be returned both in RO and in the IOSB.
The VAX/VMS System Services Reference Manual and the Guide to Programming
on VAX/VMS both describe the use of asynchronous system traps (ASTs),
IOSBs, and event flags.

8-17

Performing Network User Operations

8.5.5

Summary of System Service Calls for Transparent Operations
The following sections describe the VAX/VMS system services you can use
for transparent intertask communication. Each description covers the use of
the call, its format, the arguments associated with the call, and the return
status information. The VAX/VMS System Messages and Recovery Procedures
Reference Manual lists the entire set of network system service error messages.

8.5.5.1

SASSIGN
The $ASSIGN system service assigns a channel to refer to the logical
link. You can then use the channel returned in the chan argument in any
succeeding call to send or receive a message, or to deassign the channel and
thereby terminate the logical link.

Format
$ASSIGN devnam ,chan , [acmode]

Arguments
devnam

Address of a quadword descriptor of a character string that identifies
the remote task. The string will contain either of the following:
•

A task specification string if the call is by the source task. Both
the string and its descriptor must be in read/write storage.

•

SYSSNET if the call is by the target task. (SYSSNET is a logical
name.)

chan

Address of a word that will receive the assigned channel number. You
use this channel number to send a message to a remote task, receive
a message from a remote task, or to abort the logical link.

acmode

Access mode to be associated with this channel. The most privileged
access mode used is the access mode of the caller. You can perform
I/O operations on the channel only from equal or more privileged
access modes.

Return Status

8-18

SS$_REMOTE

The service completed successfully. (A logical link was
established with the target task.)

SS$_CONNECFAIL

The connection to a network object timed out or failed.

SS$_DEVOFFLINE

The physical link is shutting down.

SS$_FILALRACC

A logical link already exists on the channel.

SS$_INSFMEM

There is not enough system dynamic memory to
complete the request.

SS$_INVLOGIN

The access control information was found to be invalid
at the remote node.

S$_IVDEVNAM

The task specifier has an invalid format or content.

SS$_LINKEXIT

The network partner task was started, but exited
before confirming the logical link (that is, SASSIGN to
SYSSNET).

Performing Network User Operations

8.5.5.2

SS$_NOLINKS

No logical links are available. The maximum number
of logical links as set for the NCP executor MAXIMUM
LINKS parameter was exceeded.

SSS—NOPRIV

The issuing task does not have the required privilege to
perform network operations or to confirm the specified
logical link.

SS$_NOSUCHNODE

The specified node is unknown.

SS$_NOSUCHOBJ

The network object number is unknown at the remote
node; or for a TASK= connect, the named DCL
command procedure file cannot be found at the remote
node.

SS$_NOSUCHUSER

The remote node could not recognize the login
information supplied with the connection request.

SS$_PROT OCOL

A network protocol error occurred, most likely because
of a network software error.

SS$_REJECT

The network object rejected the connection.

SS$_REMRSRC

The link could not be established because system
resources at the remote node were insufficient.

SS$_SHUT

The local or remote node is no longer accepting
connections.

SS$_THIRDPARTY

The logical link connection was terminated by a third
party (for example, the system manager).

SS$_TOOMUCHDATA

The task specified too much optional or interrupt data.

SS$_UNREACHABLE

The remote node is currently unreachable.

$QIO (Sending a Message to a Target Task)
The $QIO system service with a function code of IO$_WRITEVBLK sends
a message to a target task. The $QIO call initiates an output operation
by queuing a request to the channel associated with the logical link.
Alternatively, you could use the $QIOW system service to perform the
same operation but wait for I/O completion.

Format
)$QI0 i [efn]
($QI0W(

.chan ,func , [iosb]

,[astadr]

, [astprm]

,pl

,p2

Arguments
efn

Number of the event flag to be set at request completion.

chan

A word containing the channel number associated with the logical link.
Use the same channel number returned previously in the $ASSIGN call.

func

IO$_WRITEVBLK

iosb

Address of a quadword I/O status block that is to receive the
completion status.

astadr

Entry point address of an AST routine that executes when the I/O
operation completes. If specified, the AST routine executes at the
access mode from which the $QIO service was requested.

8—19

Performing Network User Operations

astprm

AST parameter to be passed to the AST completion routine,

Buffer address.

Buffer length in bytes.

Return Status

8.5.5.3

SSS—NORMAL

The service completed successfully.

SS$_ABORT

The I/O request has been aborted by a $DASSGN or
$CANCEL.

SS$_CANCEL

The I/O on this channel has been canceled.

SS$_FILNOT ACC

No logical link is associated with the channel.

SS$_INSFMEM

Enough memory to buffer the message could not be
allocated.

SS$_LINK ABORT

The network partner task aborted the logical link.

SS$_LINKDISCON

The network partner task disconnected the logical link.

SS$_LINKEXIT

The network partner task exited.

SS$_PATHLOST

The path to the network partner task node was lost.

SS$_PROT OCOL

A network protocol error occurred. This is most likely
due to a network software error.

SS$_THIRDPARTY

The logical link connection was terminated by a third
party (for example, the system manager).

$QIO (Receiving a Message from a Target Task)
The $QIO system service with a function code of IO$_READVBLK receives
a message from a target task. The $QIO call initiates an input operation
by queuing a request to the channel associated with the logical link.
Alternatively, you could use the $QIOW system service to perform the
same operation but wait for I/O completion.

Format
$QI0
$QI0W

[efn]

.chan ,func ,[iosb]

,[astadr]

.[astprm]

,pl

,p2

Arguments

8-20

efn

Number of the event flag to be set at request completion.

chan

A word containing the channel number associated with the logical link.
Use the same channel number returned previously in the SASSIGN call.

func

IO$_READVBLK

iosb

Address of a quadword I/O status block that is to receive the
completion status.

astadr

Entry point address of an AST routine that executes when the I/O
operation completes. If specified, the AST routine executes at the
access mode from which the $QIO service was requested.

astprm

AST parameter to be passed to the AST completion routine.

Performing Network User Operations

Buffer address.

Buffer length in bytes.

Return Status

8.5.54

SS$_NORMAL

The service completed successfully.

SS$_ABORT

The I/O request has been aborted by a $DASSGN or
SCANCEL.

SS$_CANCEL

The I/O on this channel has been canceled.

SS$_DAT AOVERUN

More bytes were sent than could be received in the
supplied buffer.

SS$_FILNOT ACC

No logical link is associated with the channel.

SS$_INSFMEM

Enough memory to buffer the message could not be
allocated.

SS$_LINK ABORT

The network partner task aborted the logical link.

SS$_LINKDISCON

The network partner task disconnected the logical link.

SS$_LINKEXIT

The network partner task exited.

SS$_PATHLOST

The path to the network partner task node was lost.

SS$_PROT OCOL

A network protocol error occurred. This is most likely
due to a network software error.

SS$_THIRDPARTY

The logical link connection was terminated by a third
party (for example, the system manager).

$DASSGN (Terminating a Logical Link)
The $DASSGN system service terminates all pending operations to send and
receive data, disconnects the logical link immediately, and frees the channel
associated with that link. Either task can terminate the logical link by calling
$DASSGN.

Format
$DASSGN chan

Arguments
chan

A word containing the channel number to the logical link you want
disconnected. Use the same channel number returned previously in the
SASSIGN call.

Return Status

8.6

SS$_NORMAL

The service completed successfully.

SS$_IVCHAN

An invalid channel number was specified.

SS$_NOPRIV

The specified channel was not assigned or was assigned from
a more privileged access mode.

Performing Nontransparent Task-to-Task Operations
This section describes the system service calls and functions that you use
for nontransparent task-to-task communication. In general, the principles of
nontransparent task-to-task communication are similar to those of transparent
communication.

8-21

Performing Network User Operations

If you wish to perform nontransparent communication operations, you can
write VAX MACRO programs using VAX/VMS system services designed
specifically for DECnet-VAX. You can also write programs in one of the
higher-level languages, provided that the language supports the DECnet-VAX
services. These DECnet-VAX services are described in detail throughout this
section.
DECnet-VAX also provides additional services with extensions that allow you
to use network-specific features for nontransparent network operations such
as the following:
•

Creating and using mailboxes for receiving messages, including network
status notifications

•

Declaring a task as a network task, thus enabling it to process multiple
inbound logical link connection requests

•

Sending connection requests, optionally with user data

•

Accepting or rejecting a connection request, optionally with user data

•

Communicating between a transparent and a nontransparent task

•

Sending or receiving an interrupt message

•

Aborting or synchronously disconnecting a logical link, optionally with
user data

The general concepts implicit in DECnet-VAX task-to-task communication
are covered in Section 8.5. You should also be familiar with the material
contained in the VAX/VMS System Routines Reference Volume and the
VAX/VMS I/O Reference Volume.

8.6.1

Using System Services for Nontransparent Operations
Nontransparent task-to-task communication over the network uses a set of
system service calls available under the VAX/VMS operating system. Table
8-2 summarizes these calls and their network-related functions. The $QIO
calls are distinguished by function code.
Table 8-2

8-22

System Service Calls for Nontransparent
Communication

Call

Function

SASSIGN

Assign an I/O channel

$CANCEL

Cancel I/O on a channel

SCREMBX

Create a mailbox

$DASSGN

Abort the logical link connection
(deassigning an I/O channel)

$GETDVI

Get information on device or
volume

$QIO (IO$_ACCESS)

Request a logical link connection

$QIO (IO$_ACCESS)

Accept a logical link connection
request

Performing Network User Operations

Table 8-2 (Cont.)

8.6.1.1

System Service Calls for Nontransparent
Communication

Call

Function

$QIO (IO$_ACCESS!IO$M_ABORT)

Reject a logical link connection
request

$QIO (IO$_ACPCONTROL)

Assign a network name to a
task eligible to accept multiple
inbound connection requests

$QIO (IO$_DEACCESS!IO$M_ABORT)

Abort the logical link connection

$QIO (IO$_DEACCESS!IO$M_SYNCH)

Synchronously disconnect a
logical link

$QIO (IO$_READVBLK)

Receive a message

$QIO (IO$_WRITEVBLK)

Send a message

$QIO (IO$_WRITEVBLK!IO$M_INTERRUPT)

Send an interrupt message

STRNLNM

Translate logical names

Assigning a Channel to _NET: and Creating a Mailbox
To prepare for nontransparent task-to-task communication, you need to assign
a channel just as you would for transparent communication. In addition, you
can create a mailbox to take advantage of optional network protocol features.
You must assign a channel to a pseudodevice called _NET:; use the $ ASSIGN
system service call for this purpose. This call normally contains a reference
to a mailbox, thereby associating it with the channel assigned to _NET:. If
you use a mailbox, you must create the mailbox before assigning a channel to
_NET:. It is important to note that this use of the $ ASSIGN system service
differs from its use for transparent communication. Assigning a channel to
—NET: does not transmit a logical link connection request to the remote
node. Instead, the channel to —NET: provides a communication path to
DECnet software. A separate $QIO call (IO$_ACCESS function using the
same channel) must be used to request a logical link to the remote task.
To take advantage of optional network protocol features, you can create a
mailbox to receive messages on behalf of logical link operations. For example,
the mailbox receives a message indicating whether the cooperating task
accepted or rejected a connection request issued by the source task. Use the
$CREMBX system service to create a mailbox for these purposes. In the event
that your application does not use mailbox messages, you need not create a
mailbox.
For convenience, the Run-Time Library routine LIB$ASN_WTH_MBX can
be used to create a temporary mailbox, assign a channel to it, and assign a
channel to —NET:. This routine creates a unique mailbox in that multiple
copies of the task using it will in effect use different mailboxes. If you were
to create a mailbox with a logical name, all tasks would use the same mailbox
and thereby interfere with each other's mailbox messages. For a complete
description of this routine, see the VAX/VMS Run-Time Library Routines
Reference Manual.

8-23

Performing Network User Operations

8.6.1.2

Mailbox Message Format
The mailbox receives information specific to nontransparent communication
with a remote task. Figure 8-2 illustrates the general format of the mailbox
message.
Figure 8-2

Mailbox Message Format

MSGTYPE

UNIT

COUNT
NAME

COUNT
INFO

ZK-841-82

Notes to Figure 8—2
MSGTYPE

Contains a code that identifies the message type.

UNIT

Contains the binary unit number of the device for which the
message applies.

COUNT NAME

Contains a counted ASCII string that gives the name of the
device for which the message applies. The SASSIGN system
service creates devices having names of "NET".

COUNT INFO

Contains a counted ASCII string of information which depends
on the message type.

The VAX/VMS System Services Reference Manual summarizes the mailbox
messages that pertain to nontransparent task-to-task communication.

8.6.1.3

Requesting a Logical Link Connection
Once you assign the I/O channel, you can request a logical link connection
to the target task. Use the $QIO system service with a function code of
IO$_ACCESS. You must identify the target task in the $QIO call. Use a
network connect block (NCB) to specify the target task identification string.
In addition, you can optionally send 1 to 16 bytes of data in the NCB. The
NCB must be in read/write storage. The format of the NCB is discussed in
Section 8.6.1.4.
Once the source task issues the connection request, it can then issue a $QIO
call with a function code of IO$_READVBLK to read its mailbox. Checking
the contents of the mailbox is one way to determine whether the target task
accepted or rejected the connection request. The mailbox will contain either
MSG$_CONFIRM or MSG$_REJECT, possibly with optional data in the
mailbox buffer.
If specified, the IOSB argument of the $QIO (IO$_ACCESS) call will also
contain the result of the connection request operation. Section 8.6.2.2
provides a complete list of I/O status messages for this call.

8-24

Performing Network User Operations

Note that you must read the mailbox to inspect any optional data sent from
the target task upon accepting or rejecting the connection request.

8.6.1.4

Using the Network Connect Block
The network connect block is a user-generated data structure that contains
the information necessary to request a logical link connection or to accept or
reject a logical link connection request.
Example 8-1 is an example of an NCB you could use when issuing a
connection request call.
The significance of the information contained in the NCB block varies,
depending on the type of call in which it is used. If the call is an outbound
connection request with no optional data, items 2, 3, 4, and 5 of the block are
not required. If the call is a connect accept operation and no optional data is
sent, then items 4 and 5 are not required. Item 5 is meaningful only to the
receiver of a connection request.

Example 8-1
1.

Network Connect Block Format

With optional data (outbound connect):

o
NCB:

.ASCII
. WORD

?TRNT0::"TASK=TEST2/?
0©

OPTDATA:
.ASCIC /USERINFO/
. BLKB 17-< . -0PTDATA>©
.ASCII /"/

0
2.

Without optional data (outbound connect):

.ASCII

7TRNT0::"TASK=TEST2"?

Item

Function

A valid task specification string. For an inbound call with an NCB, the
task name portion of the task specification string is a process ID if the
remote node is a VAX/VMS system; if not, then the task name portion
is a system-specific string that identifies an executable unit (for example,
job or task). The task specification string must be a quoted string. Note
that the final quotation mark of the task specification string follows the
last item within the NCB.

The slash character (/).

One word. This word must be 0 for a connection request operation.
For a connect accept or reject operation, this word contains an internal
DECnet link identifier.

Up to 16 bytes of optional data sent as a counted string. This string
is stored in a fixed-length field that is 17 bytes long. DECnet-VAX
software ignores unused bytes.

8-25

Performing Network User Operations

8.6.1.5

A destination descriptor. This descriptor indicates how the connection
was issued and is meaningful only to the task or object to which the
connection is made. This information is useful where one program
serves many functions and needs to know how it was invoked. The
maximum length for the destination descriptor is 19 bytes. The format is
as follows:

If byte 0 contains 0, then byte 1 is the binary value of the object
number.

If byte 0 contains 1, then byte 1 is the binary object number, and
bytes 2 through 18 contain a counted task name.

If byte 0 contains 2, then byte 1 is the binary object number, bytes 2
through 5 contain a UIC, the first two bytes of which contain a binary
group code and the second two bytes contain a binary user code, and
bytes 6 through 18 contain a counted task name.

Completing the Logical Link
A nontransparent target task completes the logical link connection in one of
several ways, depending upon whether the task can process multiple inbound
connection requests or just a single request. Furthermore, a nontransparent
target task has the option of accepting or explicitly rejecting a logical link
request.

Receiving Connection Requests
This section describes what happens when you receive single and multiple
connection requests. It is assumed that the remote node is VAX/VMS. If the
remote node on which your target task runs is other than VAX/VMS, you
should refer to the related DECnet documentation.
When a remote node receives a call requesting a logical link, the DECnetVAX software constructs an NCB from the information contained in the call.
At this point, one of two things occurs. If a process already running on the
remote node has declared a network name or object number the same as the
one identified in the NCB, then the software puts the NCB into that process's
mailbox. If not, DECnet-VAX software either uses a compatible netserver
process (if one exists) or creates a netserver process (if one does not already
exist) to execute NETSERVER.COM, which in turn will run NETSERVER.EXE.
SYS$NET is equated to the NCB, and LOGIN.COM (if it exists) is invoked,
which in turn starts the taskname.COM command file. The name of this
command file is determined as follows:
•

If the connection request identifies a numbered (nonzero) object, then
the appropriate record is located in the configuration database and the
name of the file is found in this record. (The file is assumed to reside in
SYS$SYSTEM.)

•

If the connection request identifies a named object with type 0 (TASK),
then the file name is assumed to be the name of the task connected to
(with a file type of COM) and is assumed to reside in the default directory
associated with the access control information.

Once executing, the target task can then determine whether to accept or
explicitly reject the connection request. You can program the target task to
base this assessment on the information contained in the NCB.

8-26

Performing Network User Operations

A nontransparent target task can accept only one connection request at a
time, unless it declares itself as a network task. The target task may retrieve
the connection information by translating the logical name SYS$NET using
the $TRNLNM system service. Once the task retrieves the logical name, it
may then decide whether to accept or explicitly reject the connection request.
Note that you need to translate SYS$NET only if you require the following
information:
•

The optional data in the network connect block

•

The identity of the connector

•

The descriptor by which the connection was made

A target task can accept multiple inbound connection requests only if it
declares itself a known network task. To make this declaration, you must
first use the $ ASSIGN call to assign an I/O channel to _NET:. Then, use
the $QIO system service with a function code of IO$_ACPCONTROL to
assign a network name or object number to the task, making it eligible to
process multiple inbound connection requests. This system service requires
SYSNAM privilege. You must associate a mailbox with the channel if a name
or number is to be declared.
Programs that have declared names or object numbers should be programmed
to terminate when their mailboxes receive a MSG$_NETSHUT message.
Such programs must be restarted when the network comes back up.
Once you declare the target task as an active network task, DECnet places
all connection requests addressed to the task in the mailbox associated with
the channel over which the ACP control function was issued. The target task
retrieves connection requests from the mailbox by issuing the $QIO system
service call with a function code of IO$_READVBLK. Note that the first
message in the mailbox is the NCB from the original connection request that
put the task into a state of execution. Once the task declares a network name
or object number, subsequent inbound connection requests are not checked
for their access control information. (However, if the network task is started
separately from a DECnet operation, access control is never checked.)
Note that you can start programs that declare names or object numbers apart
from the first inbound connection (that is, by a RUN command).

Accepting or Rejecting a Connection Request
The target task can either accept or explicitly reject a connection request. To
accept a connection request, thus completing the logical link connection, use
the $QIO system service with a function code of IO$_ACCESS. To reject
the connection request, use the $QIO system service with the function code
IO$_ACCESS!IO$M_ABORT. When it either accepts or rejects the connection
request, the target task can also send 1 to 16 bytes of optional data within a
modified NCB back to the source task.

Exchanging Data Messages and Receiving Interrupt Messages
The exchange of data messages between the two cooperating tasks is
performed in the same way for both nontransparent and transparent
communication. (Refer to Section 8.5.5 for information on using the system
service calls $QIO (IO$_WRITEVBLK) and $QIO (IO$_READVBLK) to send
and receive messages.)

8—27

Performing Network User Operations

The receiving of information applies only to nontransparent communication.
Either task can send a 1- to 16-byte interrupt message. You can use this
method to send a message to a target task outside the normal flow of data
messages. DECnet-VAX places the received interrupt message in the target
task's mailbox. Use the $QIO system service with a function code of
IO$_WRITEVBLK!IO$M—INTERRUPT to send the interrupt message. To
notify the target task that an interrupt message has been placed in its mailbox,
the task should issue a $QIO system service call with a function code of
IO$_READVBLK to the mailbox. Specifying an AST routine in the $QIO
system service call will cause the routine to be executed on receiving the
interrupt message. (AST routines are described in the VAX/VMS System
Services Reference Manual.

8.6.1.6

Disconnecting or Aborting the Logical Link
A nontransparent task can terminate communication with a remote task
either by disconnecting the link (synchronous disconnect or disconnect abort)
or by deassigning the channel. In the first instance, you can issue a new
connection request on the same channel because you do not deassign it.
If you specifically use the IO$_DEACCESS, as opposed to the SDASSGN
method of terminating a link, you can send an optional message of 1 to 16
bytes of data with the $QIO call.
To disconnect a logical link synchronously, issue the $QIO system service
with a function code of IO$_DEACCESS!IO$M_SYNCH. The channel is then
free for subsequent communication with either the same or a different remote
task.
A synchronous disconnect may be useful for master/slave communication, in
which one task always sends data and its partner task always receives data. If
the receiving task is notified of a synchronous disconnection, then all the data
that was sent has been received. (The sending task, on the other hand, is not
guaranteed that its partner received the data.) Because this notification is the
only guarantee provided by this operation, using this operation is discouraged
in favor of a user-defined protocol to ensure completion of communication.
In general, the receiver of the final message should break the logical link.
To abort the logical link, issue the $QIO system service with a function code
of IO$_DEACCESS!IO$M_ABORT. This form of disconnection indicates to
the receiver that not all messages sent have necessarily been received. To
ensure that all transmitted messages have been received, the task itself must
terminate I/O operations on the link before instituting the DEACCESS
function because this function never completes before all pending I/O
operations complete. To do so, first issue the $CANCEL system service to
terminate I/O operations over the link; then, issue the $QIO system service
to terminate the link.
Note that after either a synchronous disconnect or a disconnect abort, you can
issue a new connection request if you did not deassign the I/O channel.
If you issue the $CANCEL system service to a channel over which a network
name or object has been declared, the declaration will be removed from the
network database.

8-28

Performing Network User Operations

8.6.1.7

Terminating the Logical Link
You can issue the $DASSGN system service call to deassign the channel
and terminate the logical link immediately. You issue the call only after all
communication between the tasks is complete. The call releases the I/O
channel, disassociates the mailbox from the channel, and terminates the
logical link immediately. This operation is equivalent to using $CANCEL
followed by $QIO IO$_DEACCESS!IO$M_ABORT.
The same status and error reporting considerations apply to nontransparent
as to transparent task-to-task communication. Refer to Section 8.5.4.5 for
information on status and error reporting.

8.6.2

System Service Calls for Nontransparent Operations
The following sections describe the VAX/VMS system services you can use for
nontransparent intertask communication over the network. Each description
covers the use of the call, its format, the arguments associated with the
call, and the return status information. The VAX/VMS System Messages and
Recovery Procedures Reference Manual lists the entire set of network system
service error messages.
The following system services are not described in detail below, because
their use does not change in a networking context. For a description of these
system services, see the VAX/VMS System Services Reference Manual.
•

$CANCEL (Cancel I/O on Channel)

•

$CREMBX (Create Mailbox and Assign Channel)

•

$GETDVI (Get Device/Volume Information)

Note that $GETDVI performs the same function as the Get I/O Channel
Information ($GETCHN) system service. However, DIGITAL recommends
that you use the $GETDVI system service.

8.6.2.1

$ASSIGN (I/O Channel Assignment)
The $ASSIGN system service assigns a channel to refer to a logical link. You
use this channel in all $QIO calls that communicate with a remote task. In
addition, you can use the $ASSIGN system service call to associate a mailbox
with the channel.

Format
$ASSIGN devnam .chan , [acmode]

.[mbxnam]

Arguments
devnam

Address of a quadword descriptor of a character string containing the
string _NET: or a logical name for _NET:.

chan

Address of a word that will receive the assigned channel number.

8-29

Performing Network User Operations

acmode

mbxnam

Address of a character string descriptor for the physical name
of the mailbox to be associated with the channel. This mailbox
remains associated with the channel until the channel is deassigned
($DASSGN).

Return Status

8.6.2.2

SSS—NORMAL

The service completed successfully.

SS$_INSFMEM

There is not enough system dynamic memory to complete
the request.

SS$_NOPRIV

The issuing task does not have the required privileges to
create the channel.

SS$_NOSUCHDEV

The network device driver is not loaded (for example, the
DECnet-VAX software is not running currently on the local
node).

$QIO (Requesting a Logical Link Connection)
The $QIO system service with a function code of IO$__ACCESS requests
a logical link connection to a target task. You can send 1 to 16 bytes of
optional data to the target task at the same time that you issue the $QIO
system service.

Format
$QIO [efn]

.chan ,func ,[iosb]

,[astadr]

, [astprm]

, [pi]

,p2

Arguments
efn

Number of the event flag to be set at request completion.

chan

The channel number associated with the logical link. Use the same
channel number returned previously in the $ASSIGN call.

func

IO$_ACCESS

iosb

Address of a quadword I/O status block that is to receive the
completion status.

astadr

Entry point address of an AST routine that executes when the I/O
operation completes. If specified, the AST routine executes at the
access mode from which the $QIO service was requested.

astprm

AST parameter to be passed to the AST completion routine.

Not used (omit the argument).

address of a quadword descriptor of the NCB (see Section 8.6.1.4).
Both the descriptor and the NCB must be in read/write storage.

Return Status

8—30

SS$_NORMAL

The

SS$_CONNECFAIL

The

SS$_DEVOFFLINE

The

Performing Network User Operations

8.6.2.3

SSS—FILALRACC

A logical link is already accessed on the channel (that
is, a previous connection is active on the channel).

SS$_INSFMEM

There is not enough system dynamic memory to
complete the request.

SS$_INVLOGIN

The access control information was found to be invalid
at the remote node.

SS$_IVDEVNAM

The NCB has an invalid format or content.

SS$_LINKEXIT

The network partner task was started, but exited
before confirming the logical link (that is, SASSIGN to
SYS$NET).

SS$_NOLINKS

No logical links are available. The maximum number of
logical links as set for the executor MAXIMUM LINKS
parameter was exceeded.

SSS—NOPRIV

The issuing task does not have the required privileges
to create a logical link to the designated target.

SS$_NOSUCHNODE

The specified node is unknown.

SS$_NOSUCHOBJ

The network object number is unknown at the remote
node; or for a TASK= connect, the named DCL
command procedure file cannot be found at the remote
node.

SS$_NOSUCHUSER

The remote node could not recognize the login
information supplied with the connection request.

SS$_PROT OCOL

A network protocol error occurred. This error is most
likely due to a network software error.

SS$_REJECT

The network object rejected the connection.

SS$_REMRSRC

The link could not be established because system
resources at the remote node were insufficient.

SS$_SHUT

The local or remote node is no longer accepting
connections.

SS$_THIRDPARTY

The logical link was terminated by a third party (for
example, the system manager).

SS$_T OOMUCHD AT A

The task specified too much optional or interrupt data.

SS$_UNREACHABLE

The remote node is currently unreachable.

$QIO (Accepting Logical Link Connection Request)
The $QIO system service with a function code of IO$_ACCESS accepts a
logical link connection request from a source task. You can send 1 to 16 bytes
of optional data to the source task at the same time that you issue the $QIO
system service.

Format
$QI0 [efn]

.chan ,func , [iosb]

,[astadr]

,[astprm]

, [pi]

,p2

Arguments
efn

Number of the event flag to be set at request completion.

chan

The channel number associated with the logical link. Use the same
channel number returned previously in the SASSIGN call.

func

IO$_ACCESS

8-31

Performing Network User Operations

iosb

Address of a quadword I/O status block that is to receive the
completion status.

astadr

Entry point address of an AST routine that executes when the I/O
operation completes. If specified, the AST routine executes at the
access mode from which the $QIO service was requested.

astprm

AST parameter to be passed to the AST completion routine.

Not used (omit the argument).

Address of a quadword descriptor of the NCB (see Section 8.6.1.4).
Both the descriptor and the NCB must be in read/write storage.

Return Status

8.62.4

SS$_NORMAL

The service completed successfully.

SS$_DEV ALLOC

The process cannot access the logical link specified
in the NCB because that link is intended for another
process.

SS$_EXQUOT A

The process does not have sufficient quota to
complete the request.

SS$_INSFMEM

There is not enough system dynamic memory to
complete the request.

SS$_IVDEVNAM

The NCB has an invalid format or content.

SS$_LINKABORT

The network partner task aborted the logical link.

SS$__LINKDISCON

The network partner task disconnected the logical link.

SS$_LINKEXIT

The network partner task exited.

SS$_NOSUCHNODE

The specified node is unknown.

SS$_PATHLOST

The path to the network partner task node was lost.

SS$_PROTOCOL

A network protocol error occurred. This error is most
likely due to a network software error.

SS$_THIRDPARTY

The logical link connection was terminated by a third
party (for example, the system manager).

SS$_TIMEOUT

The connection request did not complete within the
required time.

SS$_UNREACHABLE

The remote node is currently unreachable.

$QIO (Rejecting a Logical Link Connection Request)
The $QIO system service with a function code of IO$_ACCESS!IO$M_
ABORT rejects a logical link connection request. You can send 1 to 16 bytes
of optional data to the target task at the same time that you issue the $QIO
system service.

Format
$QI0 [efn]

,chan .rune

,[iosb]

, [astadr]

.[astprm]

,[pi]

,p2

Arguments

8-32

efn

Number of the event flag to be set at request completion.

chan

The channel number associated with the logical link. Use the same
channel number returned previously in the $ASSIGN call.

func

IO$_ACCESS!IO$M _ABORT

Performing Network User Operations

iosb

Address of a quadword I/O status block that is to receive the
completion status.

astadr

Entry point address of an AST routine that executes when the I/O
operation completes. If specified, the AST routine executes at the
access mode from which the $QIO service was requested.

astprm

AST parameter to be passed to the AST completion routine.

Not used (omit the argument).

Address of a quadword descriptor of the NCB (see Section 8.6.1.4).
Both the descriptor and the NCB must be in read/write storage.

Return Status

8.62.5

SS$_NORMAL

The service completed successfully.

SS$_DEV ALLOC

The process cannot access the logical link specified
in the NCB because that link is intended for another
process.

SS$_EXQUOT A

The process does not have sufficient quota to complete
the request.

SS$_IVDEVNAM

The NCB has an invalid format or content.

SSS—LINK ABORT

The network partner task aborted the logical link.

SS$_LINKDISCON

The network partner task disconnected the logical link.

SS$_LINKEXIT

The network partner task exited.

SS$_NOSUCHNODE

The specified node is unknown.

SS$_TIMEOUT

The connection request did not complete within the
required time.

SS$_PATHLOST

The path to the network partner task node was lost.

SS$_PROT OCOL

A network protocol error occurred. This error is most
likely due to a network software error.

SS$_THIRDPARTY

The logical link connection was terminated by a third
party (for example, the system manager).

SS$_UNREACHABLE

The remote node is currently unreachable.

$QIO (Sending a Message To a Target Task)
The $QIO system service with a function code of IO$_WRITEVBLK sends a
message to a target task. Refer to Section 8.6.2.7 for the format of this call,
its arguments, and possible return status codes. Note that you must substitute
IO$_WRITEVBLK for IO$_WRITEVBLK!IO$M_INTERRUPT as the function
code.

8.6.2.6

$QIO (Receiving a Message From a Target Task)
The $QIO system service with a function code of IO$_READVBLK receives a
message from a target task. Refer to Section 8.6.2.7 for the format of this call,
its arguments, and possible return status codes.

8-33

Performing Network User Operations

8.6.2.7

$QIO (Sending an Interrupt Message To a Target Task)
The $QIO system service with a function code of IO$_WRITEVBLK!IO$M_
INTERRUPT sends a 1- to 16-byte interrupt message to a target task. If the
remote node is a VAX/VMS system, the message is placed in the mailbox
associated with the target task.

Format
$QI0 [efn]

.chan ,func

, [iosb]

, [astadr]

,[astprm]

,pl ,p2

Arguments
efn

Number of the event flag to be set at event completion.

chan

The channel number associated with the logical link. Use the same
channel number returned previously in the $ASSIGN call.

func

IO$_WRITEVBLK!IO$M_INTERRUPT

iosb

Address of a quadword I/O status block that will receive the
completion status.

astadr

Entry point address of the AST routine that executes when the I/O
operation completes. If specified, the AST routine executes at the
access mode from which the $QIO service was requested.

astprm

The AST parameter to be passed to the AST completion routine.

Buffer address.

Buffer length (1 to 16 bytes).

Return Status

8.6.2.8

SS$_NORMAL

The service completed successfully.

SS$_ABORT

The I/O request has been aborted by a $DASSGN or
SCANCEL call.

SS$_FILNOT ACC

No logical link is associated with the channel.

SS$_INSFMEM

Enough memory to buffer the message could not be
allocated.

SS$_LINK ABORT

The network partner task aborted the logical link.

SS$_LINKDISCON

The network partner task disconnected the logical link.

SS$_LINKEXIT

The network partner task exited.

SS$_NOSOLICIT

DECnet could not accept an interrupt message at this
time.

SS$_TOOMUCHDAT A

The task specified too much interrupt data.

SS$_PATHLOST

The path to the network partner task node was lost.

SS$_PROT OCOL

A network protocol error occurred. This error is most
likely due to a network software error.

SS$_THIRDPARTY

The logical link connection was terminated by a third
party (for example, the system manager).

$QIO (Synchronously Disconnecting a Logical Link)
The $QIO system service with a function code of IO$_DEACCESS!IO$M_
SYNCH synchronously disconnects the logical link. All pending messages are
transmitted to the remote node before the link is disconnected.
You can send 1 to 16 bytes of optional data to the task from which you are
disconnecting at the same time you issue this $QIO system service.

8-34

Performing Network User Operations

Format
$QI0 [efn]

.chan ,func , [iosb]

,[astadr]

, [astprm]

, [pi]

, [p2]

Arguments
efn

Number of the event flag to be set at event completion.

chan

The channel number associated with the logical link. Use the same
channel number returned previously in the SASSIGN call.

func

IO$_DEACCESS!IO$M—SYNCH

iosb

Address of a quadword I/O status block that will receive the
completion status.

astadr

Entry point address of the AST routine that executes when the I/O
operation completes. If specified, the AST routine executes at the
access mode from which the $QIO service was requested.

astprm

The AST parameter to be passed to the AST completion routine,

Not used (omit the argument).

Address of a descriptor of a counted ASCII string of optional user
data. Both the string and its descriptor must be in read/write storage.

Return Status

8.6.2.9

SS$_NORMAL

The service completed successfully.

SS$_FILNOTACC

No logical link is associated with the channel.

$QIO (Aborting a Logical Link)
The $QIO system service with a function code of IO$_DEACCESS!IO$_
ABORT terminates the logical link. Note, however, that the DEACCESS
function completes only after all pending I/O operations complete, even
though you specify IO$_ABORT. First, issue the $CANCEL system service
call to cancel I/O operations on the logical link and then issue this call to
terminate the logical link.
You can send 1 to 16 bytes of optional data to the task from which you are
disconnecting at the same time that you issue this $QIO system service call.

Format
$QI0 [efn]

.chan ,func .[iosb]

.[astadr]

.[astprm]

,[pi]

, [p2]

Arguments
efn

Number of the event flag to be set at event completion.

chan

The channel number associated with the logical link. Use the same
channel number returned previously in the SASSIGN call.

func

IO$_DE ACCESS! IO$M_ABORT

iosb

Address of a quadword I/O status block that will receive the
completion status.

astadr

Entry point address of the AST routine that executes when the I/O
operation completes. If specified, the AST routine executes at the
access mode from which the $QIO service was requested.

8-35

Performing Network User Operations

astprm

The AST parameter to be passed to the AST completion routine,

Not used (omit the argument).

Address of a quadword descriptor of a counted string of optional user
data. Both the string and its descriptor must be in read/write storage.

Return Status

8.6.2.10

SS$_N0RMAL

The service completed successfully.

SS$_FILNOTACC

No logical link is associated with the channel.

$QIO (Declaring a Network Name Or Object Number)
The $QIO system service with a function code of IO$__ACPCONTROL assigns
a network name or object number to the task, thereby making it eligible to
process multiple inbound connection requests. You must associate a mailbox
with the I/O channel. All inbound connection requests are placed in the
mailbox associated with the channel over which this I/O function is issued.
The SYSNAM privilege is required to declare a name or object number.
MACRO programmers should be aware that whenever a logical link is
established, its device unit number (for example, 18 from _NET18:) should
be obtained by using the $GETDVI system service, because unit numbers and
not channel numbers appear in mailbox messages. Use this system service
call where a single mailbox is being used for many logical links. The unit
number could be used as a key into a database that keeps track of multiple
links.

Format
$QI0 [efn]

,chan ,func ,[iosb]

,[astadr]

.[astprm]

,pl

,p2

Arguments

8—36

efn

Number of the event flag to be set at event completion.

chan

A word containing the channel number associated with the logical link.
Use the same channel number assigned previously in the SASSIGN
call.

func

I0$_ACPC0NTR0L

iosb

Address of a quadword I/O status block that will receive the
completion status.

astadr

Entry point address of the AST routine that executes when the I/O
operation completes. If specified, the AST routine executes at the
access mode from which the $QI0 service was requested.

astprm

The AST parameter to be passed to the AST completion routine.

Performing Network User Operations

Address of a quadword descriptor of a 5-byte block consisting of a
function type (one byte) and a longword parameter. The function type
is a symbol defined by the SNFBDEF macro in SYS$LIBRARY:LIB.MLB.
The format of the 5-byte block for declaring a name is
.BYTE NFB$C_DECLNAME
.LONG 0

The format of the 5-byte block for declaring an object number is
.BYTE NFB$C_DECLOBJ
.LONG object-number

The object number is a number reserved for customer use in the range
of 128 to 255. This 5-byte buffer and its descriptor should be in
read/write storage.
p2

Address of a quadword descriptor of the network name (maximum of
12 characters). This argument is ignored for the DECLOBJ function.
Both the name and its descriptor must be in read/write storage.

Return Status

8.6.2.11

SS$_NORMAL

The service completed successfully.

SS$_BADPARAM

One of the QIO parameters has an invalid value.

SS$_ILLCNTRFUNC

The control function is invalid.

SSS—NOMBX

A name or object number is being declared using a
channel without an associated mailbox.

SS$_NOPRIV

The issuing process does not have the SYSNAM
privilege.

$DASSGN (Terminating a Logical Link)
The $DASSGN system service terminates all pending operations to send
and receive data, aborts the logical link immediately, and frees the channel
associated with that link. Refer to Section 8.5.5.4 for the format of this call,
its arguments, and possible return status codes.

8.7

Designing Tasks
This section contains a command procedure and three user program examples
designed to perform task-to-task communications over the network.
The command procedure and the first two user program examples illustrate
transparent operations. The third user program example illustrates a
nontransparent operation.

8.7.1

DCL Command Procedure for Task-to-Task Communication
As described in Section 8.5, you can write command procedures in DCL
to execute transparent task-to-task operations. The command procedure
below, called SHOWBQ.COM, can be used to perform such an operation.
You can use SHOWBQ.COM for task-to-task communication by entering a
task-spec-string in a TYPE command. For example:
$ TYPE TRNTO"BROWN JUNE"::"TASK=SHOWBQ"

8—37

Performing Network User Operations

In this command procedure, SYS$OUTPUT is equated to SYS$NET in user
mode to allow the SHOW QUEUE image to communicate over the logical
link by opening SYS$OUTPUT. When the SHOW QUEUE image exits,
the temporary definition of SYS$OUTPUT is deleted. In other words, only
one DCL image can use the logical link as the communication path to the
requester at the other node.
SHOWBQ.COM
$
$
$
$
$
$
$
$
$
$
$
$
$

!
!
!
!
!
!
!
!
!
!
!
!
•

This command procedure returns status information about
jobs entered in batch queues on the system where it
executes.
It may be
run interactively as a command
procedure,
submitted as a local or remote batch job, or
invoked as a "remote task"
to display information about
another system.
For example:
$
$
$
$

(OSHOWBQ
SUBMIT SHOWBQ
SUBMIT/REMOTE node::SHOWBQ
TYPE node::»TASK=SHOWBQ"

$ IF F$M0DE() .EQS. "NETWORK" THEN GOTO NET
$ SHOW QUEUE/BATCH/BRIEF/ALL
$ EXIT
$NET:
$ DEFINE/USER SYS$OUTPUT SYS$NET
$ SHOW QUEUE/BATCH/BRIEF/ALL
$ EXIT

8.7.2

FORTRAN Program for Task-to-Task Communication
Example 8-2 is a simple example of VAX FORTRAN transparent
communication. In the FORTRAN source task that initiates the logical
link request, you use a standard open statement to specify the remote task to
which you want to connect. In turn, the remote task issues an open statement
to complete the logical link connection. A coordinated set of read and write
operations enable the exchange of information over the link. To terminate
the connection, the source task executes a close statement to break the logical
link. When the remote task receives this close statement, it issues a close
statement, which completes the link termination process. The remainder of
this section discusses the statements that you would use to develop such an
application.

8-38

C
C
C
C
C
C
C
C
C

The information is obtained by communicating wi
(TEST4) on another node that has access to the i

Before running this program, the logical name TA
defined to refer to the target program. For exam
$ DEFINE TASK "TRNTO::H"TASK=TEST4"""
$ RUN TEST3
CHARACTER PARTN0*5
INTEGER PARTCOUNT

C
100
200
300
400
C
C
C

FORMAT
FORMAT
FORMAT
FORMAT

C
C
C
20
$
$
$
$
$

Establish a logical link with the target task.

O
1

C
C
C
C
C
C
10

(/,'$Enter part number: ')
(A)
(14)
('OInventory for part number ',A,' is:

OPEN (UNIT=1,NAME='TASK',ACCESS='SEQUENTIAL',
F0RM='FORMATTED',CARRIAGECONTROL='NONE1.TY

Prompt the user for a part number, send it to th
read reply of quantity on hand, and finally disp
for the user. Repeat the cycle until the user e
a part number.
TYPE 100
ACCEPT 200, PARTNO
IF (PARTNO .EQ. 'EXIT') GOTO 20
O WRITE (1,200) PARTNO
READ (1,300) PARTCOUNT
TYPE 400, PARTNO, PARTCOUNT
GOTO 10
Disconnect the logical link.

© CLOSE (UNIT=1)
END
!
TEST4.COM
!
!
This command procedure executes the program TEST
!
being started by a task-to-task connection requ
!
by TEST3.

$ !

Test4 is the target program that communicates w
For each part number received from the source ta
number of units in stock is determined, and this
returned.

Performing Network User Operations

Example 8-2

(Cont.)

FORTRAN Task-to-Task Communication

c
C
C
C
C

To complete the logical link with its initiator, this program
uses the logical name SYS$NET as the file specification in an
open statement.
CHARACTER PARTN0*5
INTEGER PARTCOUNT

C
100
200
C
C
C

FORMAT (A)
FORMAT (14)
Complete the logical link connection.
© OPEN (UNIT=1.NAME='SYS$NET',ACCESS^'SEQUENTIAL',
1
F0RM=■FORMATTED',CARRIAGECONTROL-1 NONE',TYPE=•OLD•)

C
C
C
C
C
10
C
C
C
C

Process requests until end-of-file is reached. (This is the
error condition returned when the source task breaks the
logical link connection.)
© READ

(1,100,END=20) PARTNO

Perform appropriate processing to obtain the part count value
and transmit this back to the source task.
CALL INSTOCK (PARTNO.PARTCOUNT)
© WRITE (1,200) PARTCOUNT
GOTO 10

C
C
C
20

(UNIT=1)

Notes on Example 8-2
© The source task, TEST3, requests a logical link connection to the target
task, TEST4.
© When the remote node receives a connection request, the command
procedure TEST4.COM is executed. This command procedure must reside
in the default directory associated with the account being accessed.
TEST4.COM contains a RUN statement that causes the program
TEST4.EXE to be executed.
© TEST4 completes the logical link connection through SYS$NET. Note that
the unit numbers in the source and target programs need not be the same.
© TEST3 and TEST4 send and receive data messages.
© TEST3 disconnects the logical link and thereby terminates the
communication process.
Because DECnet-VAX translates system-dependent language calls into the
same set of messages that permit task-to-task communication, any task
programmed in VAX MACRO or one of the higher-level languages can
communicate with a remote task programmed in the same or a different
language. More specifically, for communication between tasks that run on
VAX/VMS nodes, the language in which you access the network has no
effect on the communication process. The VAX FORTRAN source task in
Example 8-2 could just as easily communicate with a MACRO task on node
TRNTO.

8-40

communication. TRANA is a MACRO source task on th
communicates with a target task, TRANB, on node TRNT
sends a connection request to the remote node whereupo
started by the command file TRANB.COM. Once the log
is made, the source task sends a message to the target ta
responds with a message and then waits for additional m
source task drives the communication process. Once the
a response from the target task, it disconnects the link an
the target task to exit also, thereby terminating the comm

Example 8-3

.TITLE
.IDENT
.SBTTL
.PSECT
NETCHAN:.BLKW
IOSBUF: .BLKQ
TARGET: .ASCID

Transparent Communication Usi
Services

TRANA
- SOURCE TASK USING TRANSPARENT I/O
/VI.0/
WRITABLE.DATA
TRANA$DATA
SHR,NOEXE,RD,WRT,BYTE
1
1
/TRNTO"MALIK KARL"::"TASK=TRANB"/

SENDMSG:.ASCII /SEND THIS STRING TO TRANB/
SENDMSG_SIZ=.-SENDMSG
RECVMSG:.BLKB
512
RECVMSG_SIZ=.-RECVMSG
.SBTTL
.PSECT
.ENTRY

MAIN
TRANA$CODE
START,~M<>

Network
I/O sta
Task-sp

Output
Output
Input b
Input b

NOSHR,EXE,RD,NOWRT,BYTE
;Entry point from exe

Request a logical link to the target task and assign an I/O
$ASSIGN_S DEVNAM=VT TARGET,CHAN=VT NETCHAN
BLBC
RO,EXIT

;
;
;
;

Assign a channel to
Address of device n
Address to receive
Branch on failure

Send a message to the target task.
$QIOW_S EFN=#1,CHAN=W~NETCHAN,FUNC=S“#IO$_WRITEVBLK,IOSB=VT IOSBUF.P1=VTSENDMSG,P2=S~#SENDMSG_SIZ
BLBC
RO,EXIT
MOVZWL vr IOSBUF.RO
BLBC
RO,EXIT

Issue transmit requ
Use local event fla
Use assigned chann
Write virtual block
Address of I/O stat
Address of output b
Size of output buff
Branch on failure
Get completion stat
Branch on failure

(Con

$QI0W_S EFN=#1,CHAN=VTNETCHAN, FUNC=S~#IO$_READVBLK,I0SB=W~I0SBUF,P1=W~RECVMSG,P2=#RECVMSG_SIZ
BLBC
RO.EXIT
MOVZWL W~IOSBUF.RO
BLBC
RO.EXIT

;
;
;
;
;
;
;
;
;
;

Issue receive request
Use local event flag numb
Use assigned channel
Read virtual block
Address of I/O status bloc
Address of input buffer
Size of input buffer
Branch on failure
Get completion status
Branch on failure

; Abort the logical link.
$DASSGN_S CHAN=W~NETCHAN

; Deassign the channel
; Address of word containing

; Exit with status (in R0).
EXIT:

$EXIT_S R0

; Exit with status to be dis
on error condition

.END

START

;

.TITLE
.IDENT
.SBTTL
.PSECT

TRANB - TARGET TASK USING TRANSPARENT I/O
/VI.0/
WRITABLE.DATA
TRANB$DATA
SHR.NOEXE.RD.WRT.BYTE

NETCHAN:.BLKW
1
IOSBUF: .BLKQ
1
RECVMSG:.BLKB
512
RECVMSG_SIZ=.-RECVMSG
LOGNAM: .ASCID /SYS$NET/
SENDMSG:.ASCII /REPLY TO TRANA/
SENDMSG_SIZ=.-SENDMSG
.SBTTL
.PSECT
.ENTRY

MAINLINE
TRANB$CODE
START,~M<>

Image transfer address

Network channel
I/O status block
Input buffer
Input buffer size
Logical name and descripto
Output buffer
Output buffer size
NOSHR.EXE.RD.NOWRT.BYTE
;Entry point from exec

Complete the logical link connection (that TRANA requested).
$ASSIGN_S DEVNAM=W~LOGNAM,CHAN=VT NETCHAN
BLBC
RO.EXIT

Assign channel to SYS$NET
Descriptor of SYS$NET
Store channel number
Branch on failure

LOOP:
Receive message from source task.
$QI0W_S EFN=#1,CHAN =VT NETCHAN , FUNC=S~#IO$_READVBLK,I0SB=W“IOSBUF,P1=W~RECVMSG,P2=#RECVMSG_SIZ
BLBC
RO.EXIT
MOVZWL W~I0SBUF.R0
CMPW
S~#SS$_ABORT,RO
BEQL
DONE
BLBC
RO.EXIT

(Continued

8-42

Performing Network User Operations

Example 8-3

(Cont.)

Transparent Communication Using
System Services

Send message to source task.
$QI0W_S EFN=#1,CHAN=VTNETCHAN,FUNC=S“#IO$_WRITEVBLK,I0SB=W“I0SBUF,P1=W“SENDMSG,P2=S“#SENDMSG_SIZ
BLBC
RO,EXIT
MOVZWL VTIOSBUF.RO
BLBC
RO.EXIT
BRB
LOOP

Issue transmit request
Use local event flag number 1
Use assigned channel
Write virtual block
Address of I/O status block
Address of output buffer
Size of output buffer
Branch on failure
Get completion status
Branch on failure
Reissue the read

; Logical link was aborted.
DONE:

$DASSGN_S CHAN=W“NETCHAN

Deassign the channel
Address of channel number

; Exit with status (in RO).
EXIT:

8.7.4

$EXIT_S RO

Exit with status to be displayed
on error condition

.END

Image transfer address

START

MACRO Program for Nontransparent Task-to-Task Communication
Example 8-4 illustrates the use of several of these system service calls for
nontransparent task-to-task communication. CONNECT is a nontransparent
MACRO source task on the local node that communicates with a
nontransparent target task, DECLARNAM, on node DENVER. This example
is similar to Example 8-2, except that the source task here uses an NCB
and performs a nontransparent assign operation to establish communication
with the target task. DECLARNAM is a nontransparent target task that has
declared a name (that is, it is eligible to receive multiple inbound connection
requests). In addition, it also uses a mailbox to receive network status
notifications. Neither task performs useful functions. They are presented
here only to illustrate various nontransparent functions.

8-43

.SBTTL
.PSECT
INFBDEF
IDIBDEF
DEVDESC:.ASCID
MAXMSG: .LONG
BUFQUO: .LONG
MBXDESC:.ASCID
MAXLINKS=128
BUFFER.SIZE=64

READONLY.DATA
DECLARNAM$RDDATA

/.NET:/
128
128
/DECLARMBX/

.SBTTL
.PSECT

SHR,NOEXE,RD,NOWRT.BYTE

Pseudo-device and descriptor
Maximum message size
Buffer quota
Mailbox lognam and descriptor
Maximum number of logical links allowed
Size of input buffer to accept
;
messages

READWRITE.DATA
DECLARN AM$RWDATA

NAMEDESC:
.ASCID /DECLARNAM/
DCL.CHAN:
.BLKW
1
DEV.CHAN:
.BLKW
1
MBX.CHAN:
.BLKW
1
MBXMSG: .BLKB
128
IOSB:
.BLKQ
1
AST.IOSB:
.BLKQ
1
100
NCBDESC:.LONG
NCB
.LONG
NCB:
.BLKB
100
NFBDESC:.LONG
5
NFB
.LONG
NFB:
.BYTE
NFB$C_DECLNAME
.LONG
0
PRILEN: .WORD
0
PRIBUF: .LONG
128
PBUF
.LONG
PBUF:
.BLKB
128
COUNT:
.BLKL
1
CHAN.LIST:
.BLKW
MAXLINKS
UNIT.LIST:
.BLKW
MAXLINKS
IOSB.LIST:
.BLKQ
MAXLINKS
MAXLINKS * BUFFER.SIZE
BUFFERS:.BLKB
LIST:
OFFSET = 0
.REPT
MAXLINKS
.ADDRESS BUFFERS + OFFSET
OFFSET = OFFSET + BUFFER.SIZE
.ENDR
.SBTTL MAIN

SHR,NOEXE,RD,WRT,BYTE
Declared name & descriptor

Word to receive declared name channel number
Word to receive device channel number
Word to receive mailbox channel number
Mailbox buffer
I/O status block
I/O status block for AST
Network control block descriptor
Network control block
Network function block descriptor
Network function block
Length of buffer for $GETCHAN info
Descriptor of $GETCHAN buffer
Buffer to receive $GETCHAN info
Number of table entries
Channel number list
Unit number

list

Read message I/O status block list
Input buffers to put message
List of pointers to input buffers

(Continued

8-44

inbound connection requests. It is included for illustrative purposes
and is not intended to perform any useful work. In particular, nonnetwork
code is kept to a minimum (note for example, that all errors result in
program termination, which is an inappropriate procedure for most applications).

.PSECT

DECLARNAM$CODE

NOSHR,EXE.RD.NOWRT,BYTE

.ENTRY

START,~M<>

; Main entry point

Create a temporary mailbox with the logical name DECLARMBX.
$CREMBX_S CHAN=VT MBX_CHAN,MAXMSG=W~MAXMSG, BUFQU0=W~BUFQU0,LOGNAM=VTMBXDESC

Address
Address
Address
Address

BLBC

Error if LBC

RO,EXITS

of
of
of
of

word to put mailbox channel
longword with maximum message
longword with buffer quota
descriptor of mailbox lognam

Assign a channel to a NET device and associate the mailbox with it.
$ASSIGN_S DEVNAM=VT DEVDESC,CHAN=VTDCL_CHAN, MBXNAM=VTMBXDESC

Issue $ASSIGN system service request
Address of descriptor of NET device
Address of word to put channel number
Address of descriptor of mailbox logical

BLBC

Error if LBC

RO,EXITS

Declare a network name.
$QI0W_S CHAN=VT DCL.CHAN,FUNC=#IO$_ACPCONTROL,I0SB=VTI0SB,P1=W~NFBDESC,P2=#NAMEDESC

Issue declare name request
Use assigned channel
ACP QIO
Address of I/O status block
Address of NFB descriptor
Address of declared name descriptor

BLBC
MOVZWL
BLBC

Error if LBC
Get the I/O status
Error if LBC

RO.EXITS
W~IOSB.RO
RO.EXITS

; Issue an asynchronous read to the mailbox.
BSBW

READ_MBX

; Set up mailbox read AST

; Now, go to sleep until someone writes to our mailbox.
$HIBER_S
EXITS:

; zzzzzzz.

$EXIT_S RO

; Exit with status

.SBTTL
.ENTRY

MAILBOX.AST
MAILBOX.AST,'‘MO

MOVZWL
BLBC

W~AST_I0SB,R0
RO,EXITS

CASEB

W~MBXMSG,#MSG$_ABORT,#MSG$_NETSHUT-MSG$_ABORT

; Entry point for AST routine
;+
; AST routine to examine the mailbox message code
; and determine the appropriate action.
; Get asynchronous I/O completion status
; Branch on failure

.WORD
.WORD
.WORD
.WORD
.WORD
.WORD
.WORD
.WORD
.WORD
.WORD

CONNECT-DISP.TAB
DISCON-DISP.TAB
EXIT-DISP.TAB
INTMSG-DISP.TAB
PATHLOST-DISP.TAB
PROTOCOL-DISP.TAB
REJECT-DISP.TAB
THIRDPARTY-DISP.TAB
TIMEOUT-DISP.TAB
NETSHUT-DISP.TAB

BRB

EXITS

BSBW
CMPW
BEQL

CONNECT.ACCEPT
#I0$_ACCESS!IO$M_ABORT,R4
10$

BSBW

READ.CHAN

BSBB
RET

READ.MBX

Fall through on mailbox message out of range
Unknown mailbox message encountered

CONNECT:

10$:

DISCON:
ABORT:
EXIT:
PATHLOST:
PROTOCOL:
THIRDPARTY:
TIMEOUT:
BSBW
DISCONNECT
BSBB
READ.MBX
RET
NETSHUT:
$WAKE_S
RET
INTMSG:

Go accept the connect request
Was the connect request rejected?
If rejected then do not issue the
read
Issue a read on the channel we
just confirmed
Requeue the mailbox read AST
Return control to main program

Go disconnect the link
Requeue the mailbox read AST
Return control to main
The network is shutting down
Wake the main program so that
it will exit
Ignore interrupt messages for
this example

REJECT:
CONFIRM:
BSBB
RET

READ.MBX

.SBTTL
.ENTRY

READ.AST
READ.AST,“M<>

Requeue the mailbox read AST
Return control to main
Entry point for AST routine

; AST routine to check the completion status of the read and to process
; the message received.
MOVL
MOVQ
CMPW
BEQL
CMPW
BEQL
BLBC

4(AP),R8
W~I0SB_LIST[R8],R0
#SS$_LINKAB0RT,R0
10$
##SS$LINKDISCON,RO
10$
RO,EXITS

Get the index to the lists
Get the I/O completion status
Did the link go away?
If EQL then ignore
Did the partner disconnect the link?
If EQL then ignore
If LBC then error

(Continued

8-46

; the message. When complete, reissue the read on the channel and
; then go back to point where interruption occurred.

10$:

MOVW
BSBB
RET

W~CHAN_LIST[R8],R3
READ_CHAN

.SBTTL

SUBROUTINES

; Get the channel number
; Reissue the read
; Return from AST routine

Subroutine to issue an asynchronous read to the mailbox with an AST.
READ.MBX:
$QI0_S -

10$:

BLBS
BRW
RSB

CHAN=W~MBX_CHAN,FUNC=#IO$_READVBLK,I0SB=W~AST_I0SB,ASTADR=W~MAILBOX_AST,Pi=W~MBXMSG,P2=W~MAXMSG
R0,10$
EXITS

Issue read with AST
Use assigned mailbox channel
Read virtual block
Address of I/O status block
Address of AST routine
Address of input buffer
Length of input buffer
Error if LBC
Branch (failure)
Return from subroutine

Subroutine to issue an asynchronous read to the channel with an AST.
READ_CHAN:
$QI0_S

10$:

BLBS
BRW
RSB

CHAN=R3,FUNC=#IO$_READVBLK,I0SB=W~I0SB_LIST[R8]
ASTADR=W~READ_AST,ASTPRM=R8,P1=W~®BUF_ADR_LIST[R8]
P2=#BUFFER_SIZE
RO,10$
EXITS

Issue read with AST
Use channel we just confirmed
Read virtual block
Address of 1/0 status block
Address of AST routine
Store index as AST parameter
Address of input buffer
Length of input buffer
Error if LBC
Branch (failure)
Return from subroutine

.PAGE
; Subroutine to accept the connect request and add the channel and unit
; numbers to the lists
CONNECT.ACCEPT:
MOVAB
MOVZBL
ADDL2
MOVZBL
M0VC3
MOVL

W~MBXMSG+4,R9
(R9)+,R8
R8.R9
(R9)+,R8
R8.(R9),W~NCB
R8,W~NCBDESC

Get address of device name count
Get byte count of device name string
Skip over the string
Get byte count of info string
Put the NCB in address NCB
Update the NCB descriptor

Make sure we haven't reached maximum links.
CMPL
BGTR
MOVW
MOVZWL
BRB

#MAXLINKS,W~COUNT
; Have maximum number of links been reached?
5$
; If not, then assign a channel to NET
W~DCL_CHAN,R3
; Use the original channel
#I0$_ACCESS!I0$M_AB0RT R4;Set up with connect reject code
25$
; Go make the reject

BLBS
BRW

MBXNAM=W~MBXDESC
RO,10$
EXITS

Associate the mailbox with new network device
If LBC then error
Branch (failure)

; Now, get the channel and unit numbers and put them in their respective lists.

10$:

19$:

20$:

22$:

;

$GETCHN_.s CHAN=W~DEV_CHAN,PRILEN=W~PRILEN,PRIBUF=W“PRIBUF
BLBS
RO,19$
BRW
EXITS
CLRL
R8
W~CHAN_LIST[R8]
TSTW
BEQL
22$
A0BLEQ W~COUNT.R8,20$
BRW
EXITS
MOVW
MOVW
INCL

Issue get chan system service
Address of word containing channel number
Address of word to put length returned
‘ Address of descriptor of buffer
If LBC then error
Branch (failure)
Initialize the index
Is it empty?
Branch if an empty slot is found
Increment the index and try again
No empty slots?

W~DEV_CHAN, W~CHAN_LIST [R8];Put the chan number in the chan list
W~PBUF+DIB$W_UNIT,W~UNIT_LIST[R8]; Put unit number in unit list
W~COUNT
; Increment the number of entries

Issue the connect confirm QIO.

25$:

30$:

40$:

W~DEV_CHAN,R3
MOVW
MOVZWL S~#I0$_ACCESS,R4
$QI0W_S CHAN=R3,FUNC=R4,I0SB=W~I0SB,P2=#NCBDESC
BLBS
BRW
MOVZWL
BLBS
BRW
RSB

RO,30$
EXITS
W~I0SB,R0
RO,40$
EXITS

Set up with address of assigned chan
Set up with connect accept function code
Issue connect confirm/reject request
Use assigned channel
Request a logical link
Address of I/O status block
Address of NCB descriptor
If LBC then error
Branch (failure)
Get I/O completion status
If LBC then error
Branch (failure)
Return from subroutine

;+
; Subroutine to disconnect a channel and remove its entry from the lists.
DISCONNECT:
MOVZWL W~MBXMSG+2,RO
CLRL
R8
CMPW
W~UNIT_LIST[R8],R0
5$:
10$
BEQL
AOBLEQ W~COUNT,R8,5$
MOVZWL W~CHAN_LIST[R8],R9
10$:
$DASSGN._S •
CHAN=R9
RO.20$
BLBS
BRW
EXITS

Get the unit number
Initialize the index
Locate the unit number in the list
If EQL then success
Increment the index and try again
Channel number is located
Deassign the channel
Channel number
If LBC then error
Branch (failure)

The channel has been deassigned. Remove the entries from the unit and
channel lists.

(Continue

8-48

CLRW

W~UNIT_LIST[R8]

;

START

;

Clear the unit list entry
Return from subroutine

RSB
.END

Image transfer address

CONNECT
.TITLE

CONNECT - ISSUE A CONNECT REQUEST TO DECLAR

.SBTTL

READONLY.DATA
CONNECT$RDDATA

.PSECT

DEVDESC:.ASCID
MAXMSG: .LONG
BUFQUO: .LONG

SHR,NOEXE RD,NOWRT,BYTE

/.NET:/
64
64

.SBTTL READWRITE.DATA
.PSECT CONNECT$RWDATA
DEV.CHAN:
.BLKW
MBX.CHAN:
.BLKW
MBXMSG: . BLKB
IOSB:
. BLKQ
NCBDESC: .LONG
.LONG
NCB:
.ASCII
.ASCII
.WORD
.ASCII
NCB_SIZE==.-NCB
.SBTTL

(DECLARED NAME)

Pseudo-device and descriptor
Largest size mailbox message allowed
Mailbox quota
SHR,NOEXE,RD,WRT,BYTE

; Word to receive device channel number

1
64
1

; Word to receive mailbox channel number
; Mailbox buffer
; I/O status block

NCB.SIZE
NCB
7DENVER::?
?"(TASK=DECLAR/?
0
/"/

; Network connect block and descriptor
;
;
;
;
;

Node-spec string
Task-spec string (declared name)
Must be zero
End of NCB
Size of NCB

MAIN

This program demonstrates how to make a connection request to a task
that has declared a network name. It does not perform any useful work
but does serve to illustrate DECnet nontransparent I/O.
.PSECT
.ENTRY

C0NNECT$C0DE
START,~M<>

N0SHR,EXE,RD,NOWRT,BYTE

Use the Run-Time Library routine, LIB$ASN_WTH_MBX to establish
a communication path to DECnet software in preparation for
nontransparent I/O operations.
This routine will create a temporary mailbox and assign a channel to it and
assign a channel to .NET: and associate the temporary mailbox with it.

The mailbox can be used to obtain supplementary information from
DECnet software about logical link operations.
PUSHAW
PUSHAW
PUSHAL
PUSHAL
PUSHAQ
CALLS
BLBS
BRW

W~MBX.CHAN
W“DEV_CHAN
W~BUFQU0
W~MAXMSG
W~DEVDESC
#5,LIB$ASN_WTH_MBX
RO,10$
EXITS

Address to receive mailbox channel numbe
Address to receive device channel number
Mailbox quota
Largest size mailbox message allowed
Address of device name descriptor
Assign channel and associate mailbox
If LBC then error
Branch (failure)

10$:

$QI0W_S CHAN=VT DEV.CHAN,FUNC=#IO$_ACCESS,I0SB=W~I0SB,P2=#NCBDESC

Issue connect initiate request
Use assigned channel
Request a logical link
Address of I/O status block
Address of NCB descriptor

BLBC
MOVZWL
BLBC

If LBC then error
Get I/O completion status
If LBC then error

RO,EXITS
VTIOSB.RO
RO,EXITS

Established a logical link with DECLARNAM. Useful code could be inserted
here before continuing with the disconnect.
Disconnect the logical link by deassigning the channel.

EXITS:

$DASSGN_S CHAN=VTDEV_CHAN
BLBC
RO.EXITS

Issue the deassign request
Address of word containing channel number
If LBC then error

$EXIT_S RO

Exit with status to be displayed
on error condition
.END

8-50

START

File Operations in a Heterogeneous Network
Environment
This chapter contains material to assist you in using DECnet-VAX Version
4 to initiate remote file operations in a heterogeneous network environment.
Restrictions on using DCL commands and RMS service calls to access files on
the following types of remote systems are discussed in this chapter:
VAX/VMS to IAS
VAX/VMS to P/OS
VAX/VMS to RSTS/E
VAX/VMS to RSX using RMS-based FAL
VAX/VMS to RSX using FCS-based FAL
VAX/VMS to RT-11
VAX/VMS to TOPS-IO
VAX/VMS to TOPS-20
VAX/VMS Version 4 to VAX/VMS Version 3
VAX/VMS Version 4.4 to previous VAX/VMS version
The chapter is organized by operating system type: one section for each
heterogeneous system with which your VAX/VMS system running DECnetVAX Version 4 may wish to communicate. Each section describes differences
in file system operation between the two systems and constraints on the use
of VAX/VMS file processing commands. The restrictions on the remote file
operations you can perform from a VAX/VMS Version 4 node to a particular
heterogeneous node result from file system design differences and DECnet
implementation restrictions between the systems.
Specifically, the appropriate section for each remote system itemizes the
VAX Record Management System (RMS) features that are supported between
DECnet-VAX Version 4 systems, but are not supported when accessing files
on the heterogeneous system. The section also discusses limitations on the
DIGITAL Command Language (DCL) commands that you can use when
communicating with the remote node. Throughout this chapter comments are
provided to help you handle the differences in file system design.
The most recent version of DECnet used by each heterogeneous system is
represented in this chapter.

9.1

General DECnet-VAX Restrictions
This section is a brief summary of VAX RMS features that are not supported
by DECnet-VAX for remote file access. The list is not complete; it is meant
only to highlight the more important differences between local and remote file
access capabilities. For more complete information on this subject, refer to the
description of the various RMS control blocks in the VAX Record Management
Services Reference Manual.
•

The following VAX RMS service calls are not supported for network use:
SENTER

•

SNXTVOL

SREMOVE

The Terminal XAB is not supported for network operations; it is ignored.

9-1

File Operations in a Heterogeneous Network Environment

•

New fields in the Protection XAB for VAX/VMS Version 4 to support
access control lists are ignored for network operations.

•

Only one data stream per open file is allowed. That is, the multistream
(MSE) bit option of the file sharing (SHR) field of the FAB is not supported
for network use.

•

Access to files on magnetic tapes mounted on a remote VAX/VMS system
is not supported. You can, however, copy files from a local magnetic tape
to disk on a remote node.

•

When multiple Allocation XABs are linked to the FAB, they must be in
ascending order by area number (AID field). Similarly, when multiple
Key Definition XABs are used, they must be in ascending order by key of
reference (REF field).

•

File protection information may not be completely preserved if the two
nodes do not fully support each other's protection attributes.
An example of this incompatibility occurs between RSX-11M/RSX-11MPLUS and VAX/VMS systems. Although both systems represent their
protection masks as RWED, RSX-11M/RSX-11M-PLUS interprets that
as Read, Write, Extend, and Delete, while VAX/VMS interprets RWED as
Read, Write, Execute, and Delete. This results in the "E" protection field
being unmappable between these two systems.

9.2

VAX/VMS to IAS Network Operation
This section pertains to a VAX/VMS node communicating with an IAS node
running DECnet-IAS V3.0. The discussion focuses on file operations initiated
from the VAX/VMS node to access remote files by means of the FAL at the
IAS node.

9.2.1

File System Constraints
The restrictions described below are related to incompatible features in file
system design between the two systems.

9.2.1.1

File Formats and Access Modes
The following types of files and access methods are not supported by
VAX/VMS when communicating with an IAS node:
File organizations and record formats:
Sequential

Stream (STM)
Stream_CR (STMCR)
Stream_LF (STMLF)
Variable with fixed control (VFC) where fixed header size is
not 2 bytes

•

Relative

All formats

Indexed

All formats

Record attributes:
Print file carriage control (PRN)

9-2

File Operations in a Heterogeneous Network Environment

•

File access modes:
Random access by relative record number
Random access by key value
Random access by record file address
Block I/O

You can copy a sequential file in VFC format from a VAX/VMS node to an
IAS node provided that the file has a 2-byte fixed header with a carriage
control attribute other than print file. To transfer a file having print file
carriage control, such as a VAX/VMS batch log file, use the command
$ CONVERT/FDL=VAR.FDL input-file output-file

where the FDL control file VAR.FDL contains
FILE
ORGANIZATION

sequential

FORMAT
CARRIAGE.CONTROL

variable
carriage.return

RECORD

The CONVERT command and associated FDL control file will transform the
input file to variable-length format with implied carriage control and copy it
to the remote node according to the output file specification.

9.2.1.2

VAX RMS Interface
The following VAX RMS features, supported between two VAX/VMS nodes,
are not supported between a VAX/VMS node and an IAS node:
•

VAX RMS service calls:
$DELETE

SDISPLAY

$EXTEND

$FIND

$FREE

$READ

$RELEASE

SRENAME

SREWIND

SSPACE

STRUNCATE

SUPDATE

SWRITE
•

RMS extended attribute blocks:
Allocation XAB
Key Definition XAB
Summary XAB

•

Significant fields and bit options of the FAB:
CBT (contiguous-best-try) bit of FOP field
DEQ (default extend quantity) field

9.2.1.3

File Specifications
The general format of a file specification for naming a file on a remote IAS
system is
node::device:[directory]name.type;version

The following are major differences in syntax between file specifications used
on IAS and on VAX/VMS:
•

IAS does not support dollar sign ($) and underscore (_) characters in file
name components.

•

IAS does not recognize the percent sign (%) as a valid wildcard character.

9-3

File Operations in a Heterogeneous Network Environment

9.2.2

•

The directory component of an IAS file specification cannot be a named
directory list, such as [A.B.C]; it must be in UIC (user identification code)
format, such as [100,3].

•

The file name component has a maximum length of nine characters and
the file type cannot exceed three characters. IAS systems will return an
error if you specify a longer file name or file type.

•

IAS uses octal version numbers in file specifications whereas VAX/VMS
uses decimal version numbers.

DCL Considerations
Of the VAX/VMS DCL commands that can be used over the network, the
following are not supported between VAX/VMS and an IAS node:

9.2.2.1

•

ANALYZE/RMS-FILE

•

BACKUP

•

OPEN/WRITE

•

RENAME

APPEND
In using the APPEND command, you are limited to appending one local
input file to the output file residing on the IAS node.

9.22.2

COPY
The /EXTENSION and /PROTECTION qualifiers for the COPY command
are not supported and will be ignored if specified.
File creation date and time information is not preserved on a file copy
operation to an IAS node where wildcards are used in the output file
specification. Instead, the current date and time is used as the file creation
date and time.
Because the IAS system uses octal version numbers in file specifications, an
attempt to copy a file with a version number containing an 8 or 9 is rejected
by the remote system, as shown in the following example:
$ COPY A.DAT;9 IAS::*.*
'/.COPY-E-OPENOUT, error opening _IAS: :A.DAT;9 as output
-RMS-F-FNM, error in file name

There are two ways to circumvent this problem. You can either specify an
appropriate octal version number in the output file specification, or you can
specify a null or zero version number in the output file specification to force
highest version number processing on the remote node. This latter technique
is particularly useful when several files are copied with one DCL command.
For example:
$
$
$
$

9-4

COPY
COPY
COPY
COPY

A.DAT;9
B.DAT;28
B.DAT;28
*.DAT

IAS::A.DAT;11
IAS:
IAS::*.*;0
IAS::*.*;0

File Operations in a Heterogeneous Network Environment

9.3

VAX/VMS to P/OS Network Operation
This section pertains to a VAX/VMS node communicating with a P/OS
node running DECnet-PRO VI.0. The discussion focuses on file operations
initiated from the VAX/VMS node, to access remote files by means of the
FAL at the P/OS node.

9.3.1

File System Constraints
The restrictions described below are related to incompatible features in file
system design between the two systems.

9.3.1.1

File Formats and Access Modes
The following types of file and record attributes are not supported by
VAX/VMS when communicating with a P/OS node:
•

File organizations and record formats:
Sequential

Stream_CR (STMCR)
Stream_LF (STMLF)

Indexed

All prologue 3 formats
With 64-bit binary (BN8) key types
With 64-bit integer (IN8) key types
With descending key types (DSTG, DIN2, DBN2, DIN4,
DBN4, DIN8, DBN8, DPAC)

•

Record attributes:
(Record attributes are compatible)

•

File access modes:
(Modes are compatible)

9.3.1.2

VAX RMS Interface
The following VAX RMS features, supported between two VAX/VMS nodes,
are not supported between a VAX/VMS node and a P/OS node:
•

VAX RMS service calls:
SRELEASE

•

Significant fields and bit options of the FAB:
CBT (contiguous-best-try) bit of FOP field
SCF (submit command file) bit of FOP field
SPL (spool file) bit of FOP field

9—5

File Operations in a Heterogeneous Network Environment

9.3.1.3

File Specifications
The general format of a file specification for naming a file on a remote P/OS
system is:
node::device:[directory]name.type;version

The following are major differences in syntax between file specifications used
on P/OS and VAX/VMS:

9.3.2

•

P/OS does not support dollar sign ($) and underscore (_) characters in
file name components.

•

The directory component in a P/OS file specification cannot be a named
directory list, such as [A.B.C]; it can be a single directory name, such
as [USERFILES], or it can be expressed in UIC (user identification code)
format, such as [15,1].

•

The file name component has a maximum length of nine characters and
the file type cannot exceed three characters. P/OS systems will return an
error if you specify a longer file name or file type.

DCL Considerations
Of the VAX/VMS DCL commands that can be used over the network, the
following are not supported between VAX/VMS and a P/OS node:

9.4

•

OPEN/WRITE

•

PRINT/REMOTE

•

SUBMIT/REMOTE

VAX/VMS to RSTS/E Network Operation
This section pertains to a VAX/VMS node communicating with a RSTS/E
node running DECnet/E V3.0. The discussion focuses on file operations
initiated from the VAX/VMS node, to access remote files by means of the
FAL at the RSTS/E node.

9.4.1

File System Constraints
The restrictions described below are related to incompatible features in file
system design between the two systems.

9.4.1.1

File Formats and Access Modes
The following types of file and access methods are not supported by
VAX/VMS when communicating with a RSTS/E node:
•

File organizations and record formats:
Sequential

Stream_CR (STMCR)
Stream_LF (STMLF)

9-6

File Operations in a Heterogeneous Network Environment

Indexed

All prologue 3 formats
With 64-bit binary (BN8) key types
With 64-bit integer (IN8) key types
With descending key types (DSTG, DIN2, DBN2, DIN4,
DBN4, DIN8, DBN8, DPAC)

•

Record attributes:
(Attributes are compatible)

•

File access modes:
Random access by key value
Random access by record file address

DECnet/E does not support record mode access to indexed files; it supports
only block I/O access to indexed files.
Note that an attempt to access an indexed file located on a RSTS/E node
in record mode will result in an RMS-F-BUG—DAP error instead of an
RMS-F-SUPPORT error.

9.4.1.2

VAX RMS Interface
The following VAX RMS features, supported between two VAX/VMS nodes,
are not supported between a VAX/VMS node and a RSTS/E node:
•

•

VAX RMS service calls:
SDISPLAY

SEXTEND

$FREE

SRENAME

SSPACE

STRUNCATE

$RELEASE

RMS extended attribute blocks:
Allocation XAB
Key Definition XAB
Summary XAB

•

Significant fields and bit options of the FAB:
CBT (contiguous-best-try) bit of FOP field
DEQ (default extend quantity) field

9.4.1.3

File Specifications
The general format of a file specification for naming a file on a remote
RSTS/E system is
node::device:[directory]name.type

The following are major differences in syntax between file specifications used
on RSTS/E and on VAX/VMS:
•

RSTS/E does not support dollar sign ($) and underscore (_) characters in
file name components, except for the special use of the dollar sign at the
start of a file name.

•

RSTS/E does not recognize the percent sign (%) as a valid wildcard
character.

9—7

File Operations in a Heterogeneous Network Environment

•

The directory component of a RSTS/E file specification cannot be a named
directory list, such as [A.B.C]; it must be in UIC (user identification code)
format, such as [1,2]. RSTS/E systems, however, express UICs in decimal
radix, whereas VAX/VMS systems use octal numbers. On the RSTS/E
system, the UIC is referred to as a PPN (project programmer number).
To access a RSTS/E file whose directory component in PPN format
contains decimal digits, use the quoted string form of the file specification.
For example:
$ TYPE RSTS::"SY:[9,18]TEST.DAT"

9.4.2

•

The file name component has a maximum length of six characters and the
file type cannot exceed three characters. If you specify a longer file name,
RSTS/E will truncate the name to six characters.

•

RSTS/E does not support version numbers. It will accept a file
specification containing a version number without returning an error,
but will ignore the version number.

DCL Considerations
Of the VAX/VMS DCL commands that can be used over the network, the
following are not supported between VAX/VMS and a RSTS/E node:

9.4.2.1

•

PURGE

•

RENAME

APPEND
In using the APPEND command, you are limited to appending one local
input file to an output file on the RSTS/E node.

9.4.22

COPY
The /EXTENSION and /PROTECTION qualifiers for the COPY command
are not supported and will be ignored if specified.
File creation date and time information is not preserved on a file copy
operation to a RSTS/E node where wildcards are used in the output file
specification. Instead, the current date and time is used as the file creation
date and time.
Because RSTS/E does not support version numbers in file specifications (it
will ignore any version number supplied), an attempt to copy a file with
an explicit version number will fail if a file with the same name and type
already exists at the RSTS/E node. For example, if a file with the name
RSTS::TEST.DAT already exists on the remote node, an attempt to update it
by copying a new version of that file to the node will produce the following
results:
$ COPY TEST.DAT;2 RSTS::*.*
'/.COPY-E-OPENOUT, error opening _RSTS: : TEST.DAT; 2 as output
-RMS-E-FEX, file already exists, not superseded

9-8

File Operations in a Heterogeneous Network Environment

9.4.2.3

DELETE
If you use the DELETE command with a wildcard file specification to delete
several files from a directory on a remote RSTS/E node, the operation may
appear to complete successfully even though some of the files may remain in
the directory. This behavior is caused by a file system incompatibility in the
way VAX/VMS and RSTS/E perform wildcard file deletion operations. This
problem will occur only if the remote directory has at least 30 files cataloged.
To determine if all the files you specified have been deleted successfully,
issue a DIRECTORY command to examine the remote directory. Then repeat
the wildcard DELETE command if necessary to remove unwanted files. If
the number of files you are attempting to delete is small, using the /LOG
qualifier with the DELETE command may help you to determine if all the
files have been deleted.

9.4.2.4

DIRECTORY
When you issue a DIRECTORY/FULL command to examine a RSTS/E
file, the information displayed will differ from that which is displayed for a
VAX/VMS file in the following respects:
•

The file owner is displayed as [0,0] if the owner of the file is identified by
a UIC that contains decimal digits.

•

The file revision number shown will be either 0 or 1. A revision number
of 0 indicates the file has not been revised; a revision number of 1
indicates the file has been revised.

•

Under the attributes of an indexed file, information about the number of
keys, the number of areas, and the prologue version number of the file is
not displayed. This information is omitted because the RSTS/E FAL does
not return file attribute information stored in the prologue portion of an
indexed file.

•

Under the attributes of a relative file, the maximum record number is
displayed as 0.

9.4.2.5 DUMP/RECORDS and TYPE Commands
Because RSTS/E does not support record mode access (nonblock I/O access)
to indexed files, you cannot use the DCL commands DUMP/RECORDS and
TYPE to examine indexed files located on the remote RSTS/E node.

9.5

VAX/VMS to RSX Network Operation Using RMS-Based FAL
This section pertains to a VAX/VMS node communicating with an RSX
node running either DECnet-llM Version 4 or DECnet-llM-PLUS V2.0
where the RSX File Access Listener (FAL) calls RMS-11 to perform local
file operations. The discussion focuses on file operations initiated from the
VAX/VMS node, to access remote files by means of the FAL at the RSX node.

9.5.1

File System Constraints
The restrictions described below are related to incompatible features in file
system design between the two systems.

9-9

File Operations in a Heterogeneous Network Environment

9.5.1.1 File Formats and Access Modes
The following types of file and record attributes are not supported by
VAX/VMS when communicating with an RSX node running the RMS-based
FAL:
•

File organizations and record formats:
Sequential

Stream_CR (STMCR)
Stream_LF (STMLF)

Indexed

All prologue 3 formats
With 64-bit binary (BN8) key types
With 64-bit integer (IN8) key types
With descending key types (DSTG, DIN2, DBN2, DIN4,
DBN4, DIN8, DBN8, DPAC)

•

Record attributes:
(Record attributes are compatible)

•

File access modes:
(Modes are compatible)

9.5.1.2 VAX RMS Interface
The following VAX RMS features, supported between two VAX/VMS nodes,
are not supported between a VAX/VMS node and an RMS-based RSX node:
•

VAX RMS service calls:
SRELEASE

•

Significant fields and bit options of the FAB:
CBT (contiguous-best-try) bit of FOP

9.5.1.3 File Specifications
The general format of a file specification for naming a file on a remote
RSX-11M or RSX-11M-PLUS system is:
node::device:[directory]name.type;version

The following are major differences in syntax between file specifications used
on RSX and VAX/VMS:

9-10

•

RSX systems do not support dollar sign ($) and underscore (_) characters
in file name components.

•

The directory component in an RSX file specification cannot be a named
directory list, such as [A.B.C]; it must be in UIC (user identification code)
format, such as [15,1].

•

The file name component has a maximum length of nine characters and
the file type cannot exceed three characters. RSX systems will return an
error if you specify a longer file name or file type.

•

RSX systems use octal version numbers in file specifications whereas
VAX/VMS uses decimal version numbers.

File Operations in a Heterogeneous Network Environment

9.5.2

DCL Considerations
Of the VAX/VMS DCL commands that can be used over the network, the
following is not supported between VAX/VMS and an RMS-based RSX node:
•

9.5.2.1

OPEN/WRITE

COPY
Because RSX-11M and RSX-11M-PLUS systems use octal version numbers in
file specifications, an attempt to copy a file with a version number containing
an 8 or 9 is rejected by the remote system. For example:
$ COPY A.DAT;9 RSX::*.*
'/.COPY-E-OPENOUT, error opening RSX: :A.DAT;9 as output
-RMS-F-FNM, error in file name

There are two ways to circumvent this problem. You can specify an
appropriate octal version number in the output file specification, or you
can specify a null or zero version number in the output file specification to
force highest version number processing on the remote node. This latter
technique is particularly useful when several files are copied with one DCL
command. For example:
$
$
$
$

9.6

COPY
COPY
COPY
COPY

A.DAT;9
B.DAT;28
B.DAT;28
*.DAT

RSX::A.DAT;11
RSX::*.*;
RSX::*.*;0
RSX::*.*;0

VAX/VMS to RSX Network Operation Using FCS-Based FAL
This section pertains to a VAX/VMS node communicating with an RSX node
running DECnet-llM Version 4 or DECnet-llM-PLUS V2.0 where the RSX
FAL calls the File Control Services (FCS-11) to perform file operations. The
discussion focuses on file operations initiated from the VAX/VMS node to
access remote files by means of the FAL at the RSX node.

9.6.1

File System Constraints
The restrictions described below are related to incompatible features in file
system design between the two systems.

9.6.1.1

File Formats and Access Modes
The following types of files and access methods are not supported by
VAX/VMS when communicating with an RSX node running the FCS-based
FAL:
•

File organizations and record formats:
Sequential

Stream (STM)
Stream_CR (STMCR)
Stream_LF (STMLF)
Variable with fixed control (VFC) where fixed header size is
not 2 bytes

9-11

File Operations in a Heterogeneous Network Environment

•

Relative

All formats

Indexed

All formats

Record attributes:
Print file carriage control (PRN)

•

File access modes:
Random access by relative record number
Random access by key value
Random access by record file address
Block I/O

You can copy a sequential file in VFC format from a VAX/VMS node to an
FCS-based RSX node provided that the file has a 2-byte fixed header with a
carriage control attribute other than print file. To transfer a file having print
file carriage control, such as a VAX/VMS batch log file, use the command
$ CONVERT/FDL=VAR.FDL input-file output-file

where the FDL control file VAR.FDL contains
FILE
ORGANIZATION

sequential

FORMAT
CARRIAGE.CONTROL

variable
carriage.return

RECORD

9.6.1.2

VAX RMS Interface
The following VAX RMS features, supported between two VAX/VMS nodes,
are not supported between a VAX/VMS node and an FCS-based RSX node:
•

VAX RMS service calls:
SDELETE

SDISPLAY

SEXTEND

$FIND

$FREE

$READ

SRELEASE

$RENAME

SREWIND

$SPACE

STRUNCATE

SUPDATE

SWRITE
•

RMS extended attribute blocks:
Allocation XAB
Key Definition XAB
Summary XAB

•

Significant fields and bit options of the FAB:
CBT (contiguous-best-try) bit of FOP field
DEQ (default extension quantity) field

9-12

File Operations in a Heterogeneous Network Environment

9.6.1.3

File Specifications
The general format of a file specification for naming a file on a remote
RSX-11M or RSX-11M-PLUS system is:
node::device:[directory]name.type;version

The following are major differences in syntax between file specifications used
on RSX and VAX/VMS:

9.6.2

•

RSX systems do not support dollar sign ($) and underscore (_) characters
in file name components.

•

The directory component in an RSX file specification cannot be a named
directory list, such as [A.B.C]; it must be in UIC (user identification code)
format, such as [15,1].

•

The file name component has a maximum length of nine characters and
the file type cannot exceed three characters. RSX systems will return an
error if you specify a longer file name or file type.

•

RSX systems use octal version numbers in file specifications whereas
VAX/VMS uses decimal version numbers.

DCL Considerations
Of the VAX/VMS DCL commands that can be used over the network, the
following are not supported between VAX/VMS and an FCS-based RSX node:

9.6.2.1

•

ANALYZE/RMS-FILE

•

BACKUP

•

OPEN/WRITE

•

RENAME

APPEND
In using the APPEND command, you are limited to appending one local
input file to an output file residing on the FCS-based RSX node.

9.6.2.2

COPY
The /EXTENSION and /PROTECTION qualifiers for the COPY command
are not supported and will be ignored if specified.
File creation date and time information is not preserved on a file copy
operation to an RSX node where wildcards are used in the output file
specification. Instead, the current date and time is used as the file creation
date and time.
Because RSX-11M and RSX-11M-PLUS systems use octal version numbers in
file specifications, an attempt to copy a file with a version number containing
an 8 or 9 is rejected by the remote system, as shown below:
$ COPY A.DAT;9 RSX::*.*
'/.COPY-E-OPENOUT, error opening RSX: :A.DAT;9 as output
-RMS-F-FNM, error in file name

9-13

File Operations in a Heterogeneous Network Environment

$ COPY A.DAT;9

RSX::A.DAT;11

$ COPY B.DAT;28 RSX::*.*;
$ COPY B.DAT;28 RSX::*.*;0
$ COPY *.DAT

9.7

RSX::*.*;0

VAX/VMS to RT-11 Network Operations
This section pertains to a VAX/VMS node communicating with an RT-11
node running DECnet-RT V2.1. The discussion focuses on file operations
initiated from the VAX/VMS node, to access remote files by means of the
FAL at the RT node.

9.7.1

File System Constraints
The file systems used by RT-11 and VAX/VMS are dissimilar in many
respects. A fundamental difference between them involves the handling of
file attribute information. When a file is created on a VAX/VMS system,
attribute information about the file is stored in a header block on disk for use
when the file is subsequently opened. The implication is that the structure of
an established file cannot change. In contrast, RT-11 does not save attribute
information such as file format with a file; it expects the user to provide this
information when the file is opened. File attribute information, however, is
not an input to VAX RMS when a file is opened.
To provide transparent access to files on a remote RT-11 system, VAX RMS
restricts the types of files that you can create and open on the remote node.
When you access an RT-11 file in record mode, VAX RMS treats the file
as having stream format. Block I/O access is permitted; the remote file is
viewed as having fixed length 512 byte records where virtual block number is
translated to relative record number.

9.7.1.1

File Formats and Access Modes
The following types of files and access methods are not supported by
VAX/VMS when communicating with an RT node:
•

File organizations and record formats:
Sequential

Fixed length (FIX) without implied carriage control
Stream_CR (STMCR)
Stream_LF (STMLF)
Variable length (VAR) without implied carriage control
Variable with fixed control (VFC)

•

Relative

All formats

Indexed

All formats

Record attributes:
FORTRAN carriage control (FTN)
Print file carriage control (PRN)
None specified (embedded carriage control)

•

Record access modes:
Random access by relative record number
Random access by key value
Random access by record file address

9—14

File Operations in a Heterogeneous Network Environment

For record mode access, the only file type in common between the two
systems is a sequential file in STM (stream) format. For convenience,
however, when you are transferring a file to an RT-11 node, VAX RMS
will automatically convert a VAX/VMS sequential file with fixed or variable
format and implied carriage control to a sequential file with stream format
and embedded carriage control. This automatic conversion is performed
during a file create operation, and VAX RMS returns an alternate success code
(RMS$_CVT_STM) to indicate that the file format has been modified.
Note also that when a stream format file is retrieved from an RT-11 node,
VAX RMS automatically changes the record attribute from embedded carriage
control to implied carriage control.
In general, text files created by the SOS Editor without line numbers being
saved or by the EDT Editor can be copied to an RT-11 system. VAX/VMS
batch log files and files created by the SOS Editor with line numbers intact,
however, are stored in VFC format and cannot be copied to an RT-11 system
in that form. To transfer this type of file, use the DCL command
$ CONVERT/FDL=STM.FDL input-file output-file

where the FDL control file STM.FDL contains
FILE
ORGANIZATION

sequential

FORMAT
CARRIAGE.CONTROL

stream
none

RECORD

The CONVERT command and associated FDL control file will transform the
input file to stream format with embedded carriage control and copy it to the
remote node according to the output file specification.

9.7.1.2

VAX RMS Interface
The following VAX RMS features, supported between two VAX/VMS nodes,
are not supported between a VAX/VMS node and an RT-11 node:
•

VAX RMS service calls:
SDELETE

•

SDISPLAY

SEXTEND

$FIND

SFREE

SRELEASE

SRENAME

SREWIND

SSPACE

STRUNCATE

$UPDATE

RMS extended attribute blocks:
Key Definition XAB
Summary XAB

•

Significant fields and bit options of the FAB:
ALQ (allocation quantity) field
DEQ (default extend quantity) field
CBT (contiguous-best-try) bit of FOP field
CTG (contiguous) bit of FOP field
SCF (submit command file) bit of FOP field
SPL (spool file) bit of FOP field

•

Significant fields and bit options of the RAB:
EOF (position to end of file) bit of ROP field

9-15

File Operations in a Heterogeneous Network Environment

9.7.1.3

File Specifications
The general format of a file specification for naming a file on a remote RT-11
system is
node::device:name.type

The following are major differences in syntax between file specifications on
RT-11 and VAX/VMS:

9.7.2

•

RT-11 does not support dollar sign ($) and underscore (_) characters in
file name components.

•

RT-11 does not recognize the percent sign (%) as a valid wildcard
character.

•

RT-11 does not have a directory component in its file specification.

•

The file name component has a maximum length of six characters and the
file type cannot exceed three characters. If you specify a longer file name
or file type, RT-11 will return an error.

•

RT-11 does not support version numbers. Specification of a version
number, however, is permitted when you refer to an RT-11 file, because
VAX RMS discards any version number before sending the file specified to
the RT-11 FAL.

DCL Considerations
Of the VAX/VMS DCL commands that can be used over the network, the
following are not supported between VAX/VMS and an RT-11 node:

9.7.2.1

•

ANALYZE/RMS—FILE

•

APPEND

•

BACKUP

•

OPEN/WRITE

•

PRINT/REMOTE

•

PURGE

•

RENAME

•

SUBMIT/REMOTE

COPY
The /ALLOCATION, /CONTIGUOUS, /EXTENSION, and /PROTECTION
qualifiers for the COPY command are not supported and will be ignored if
specified.
Using COPY to merge several files into a single output file is not supported.
RT-11 does not support version numbers in file specifications and supersedes
files by default. Therefore, if you attempt to copy a file with the same name
and type as one that already exists on the remote RT-11 node, the new file
will supersede the old one. No warning message is displayed.

9-16

File Operations in a Heterogeneous Network Environment

9.7.2.2

DELETE
The DCL command DELETE requires that you specify an explicit or wildcard
version number in the file specification. However, since RT-11 does not
accept a file specification containing a version number, VAX RMS removes
the version number before sending the file specification to the RT-11 system.
To satisfy the requirements of both systems, specify a null version number in
the file specification, as shown below.
$ DELETE RT::TEST.DAT;

9.8

VAX/VMS to TOPS-IO Network Operations
This section pertains to a VAX/VMS node communicating with a TOPS-10
node running DECnet-10 Version 4. The discussion focuses on file operations
initiated from the VAX/VMS node, to access remote files by means of the
FAL at the TOPS-IO node.

9.8.1

File System Constraints
The file systems used by TOPS-IO and VAX/VMS are dissimilar in many
respects. A fundamental difference between them involves the handling of
file attribute information. When a file is created on a VAX/VMS system,
attribute information about the file is stored in a header block on disk for use
when the file is subsequently opened. The implication is that the structure
of an established file cannot change. In contrast, TOPS-IO does not save
attribute information such as file format with a file; it expects the user to
provide this information when the file is opened. File attribute information,
however, is not an input to VAX RMS when a file is opened.
To provide transparent access to files on a remote TOPS-IO system, VAX
RMS restricts the types of files that you can create and open on the remote
node. When you access a TOPS-IO file in record mode, VAX RMS treats the
file as having stream format.

9.8.1.1

File Formats and Access Modes
Because of differences in file system design, the following types of files and
access methods are not supported by VAX/VMS when communicating with a
TOPS-IO node:
•

File organizations and record formats:
Sequential

Fixed length (FIX) without implied carriage control
Stream _CR (STMCR)
Stream_LF (STMLF)
Variable length (VAR) without implied carriage control
Variable with fixed control (VFC)

•

Relative

All formats

Indexed

All formats

Record attributes:
FORTRAN carriage control (FTN)
Print file carriage control (PRN)
None specified (embedded carriage control)

9-17

File Operations in a Heterogeneous Network Environment

•

Record access modes:
Random access by relative record number
Random access by key value
Random access by record file address
Block I/O

For record mode access, the only file type in common between the two
systems is a sequential file in STM (stream) format. For convenience,
however, when you are transferring a file to a TOPS-10 node, VAX RMS
will automatically convert a VAX/VMS sequential file with fixed or variable
format and implied carriage control to a sequential file with stream format
and embedded carriage control. This automatic conversion is performed
during a file create operation, and VAX RMS returns an alternate success code
(RMS$_CVT_STM) to indicate that the file format has been modified.
Note also that when a stream format file is retrieved from a TOPS-10 node,
VAX RMS automatically changes the record attribute from embedded carriage
control to implied carriage control.
In general, text files created by the SOS Editor without line numbers being
saved or by the EDT Editor can be copied to a TOPS-10 system. VAX/VMS
batch log files and files created by the SOS Editor with line numbers intact,
however, are stored in VFC format, and cannot be copied in that form to a
TOPS-10 system. To transfer this type of file, use the DCL command
$ CONVERT/FDL=STM.FDL input-file output-file

where the FDL control file STM.FDL contains
FILE
ORGANIZATION

sequential

FORMAT
CARRIAGE.CONTROL

stream
none

RECORD

9.8.1.2

VAX RMS Interface
The following VAX RMS features, supported between two VAX/VMS nodes,
are not supported between a VAX/VMS node and a TOPS-10 node:
•

VAX RMS service calls:
$DELETE

SDISPLAY

SEXTEND

$FIND

SFREE

SREAD

$RELEASE

SRENAME

$REWIND

$SPACE

STRUNCATE

SUPDATE

$WRITE
•

RMS extended attribute blocks:
Allocation XAB
Key Definition XAB
Summary XAB

•

Significant fields and bit options of the FAB:
ALQ (allocation quantity) field
DEQ (default extend quantity) field
CBT (contiguous-best-try) bit of FOP field

9—18

File Operations in a Heterogeneous Network Environment

9.8.1.3

File Specifications
The general format of a file specification for naming a file on a remote
TOPS-IO system is
node::device[directory]name.type

The following are the major differences in syntax between file specifications
on TOPS-IO and on VAX/VMS:
•

The directory component of a TOPS-IO file specification is in PPN (project
programmer number) format, such as [3655,7031], where the two numbers
are in octal radix. The directory component can also be in extended PPN
format containing up to five levels of subdirectories. An example of a
directory component in extended PPN format is [10,20,A,B,C,D,E].
VAX/VMS cannot parse directory components in PPN format (with
numbers larger than 377 octal) or handle extended PPN formats
containing subdirectories. The DECnet-10 implementation, however,
will accept directory components using period (.) instead of comma
(,) delimiters, and will convert commas to periods when returning file
specifications to VAX/VMS systems. Consequently, when you enter a file
specification for a remote TOPS-IO system, use the VAX/VMS named
directory list format for expressing TOPS-IO PPNs and extended PPNs.
For example, use [3655.7031] or [10.20.A.B.C.D.E] to specify a directory
component.

9.8.2

•

The file name component has a maximum length of six characters and the
file type cannot exceed three characters. If you specify a longer file name,
TOPS-IO will truncate the name to six characters.

•

TOPS-IO does not support version numbers. It will accept a file
specification containing a version number without returning an error,
but will ignore the version number.

DCL Considerations
Of the VAX/VMS DCL commands that can be used over the network, the
following are not supported between VAX/VMS and a TOPS-IO node:

9.8.2.1

•

ANALYZE/RMS-FILE

•

APPEND

•

BACKUP

•

OPEN/WRITE

•

RENAME

COPY
The /ALLOCATION and /EXTENSION qualifiers to the COPY command are
not supported and will be ignored if specified.

9-19

File Operations in a Heterogeneous Network Environment

9.8.2.2

DIRECTORY
When you issue a DIRECTORY/FULL command to examine a TOPS-IO file,
the information displayed will differ in the following respects from that which
is displayed for a VAX/VMS file:

9.9

•

The file owner is displayed as [0,0] to indicate that this information is not
available.

•

The file revision number is not shown and file revision date and time
information is not available from the TOPS-IO system.

•

The blocks used and blocks allocated values displayed, which indicate the
size of the file, refer to 128-word pages (providing 640 bytes of storage),
not 512-byte blocks.

VAX/VMS to TOPS—20 Network Operations
This section pertains to a VAX/VMS node communicating with a TOPS-20
node running DECnet-20 V3.0. The discussion focuses on file operations
initiated from the VAX/VMS node, to access remote files by means of the
FAL at the TOPS-20 node.

9.9.1

File System Constraints
The file systems used by TOPS-20 and VAX/VMS are dissimilar in many
respects. A fundamental difference between them involves the handling of
file attribute information. When a file is created on a VAX/VMS system,
attribute information about the file is stored in a header block on disk for use
when the file is subsequently opened. The implication is that the structure
of an established file cannot change. In contrast, TOPS-20 does not save
attribute information such as file format with a file; it expects the user to
provide this information when the file is opened. File attribute information,
however, is not an input to VAX RMS when a file is opened.
To provide transparent access to files on a remote TOPS-20 system, VAX
RMS restricts the types of files that you can create and open on the remote
node. When you access a TOPS-20 file in record mode, VAX RMS treats the
file as having stream format. Although block I/O is supported by DECnet20, it is not supported between VAX/VMS and TOPS-20 because the block
sizes are different.

9.9.1.1

File Formats and Access Modes
Because of differences in file system design, the following types of files and
access methods are not supported by VAX/VMS when communicating with a
TOPS-20 node:
•

File organizations and record formats:
Sequential

Fixed length (FIX) without implied carriage control
Stream_CR (STMCR)
Stream_LF (STMLF)
Variable length (VAR) without implied carriage control
Variable with fixed control (VFC)

9-20

File Operations in a Heterogeneous Network Environment

•

Relative

All formats

Indexed

All formats

Record attributes:
FORTRAN carriage control (FTN)
Print file carriage control (PRN)
None specified (embedded carriage control)

•

Record access modes:
Random access by relative record number
Random access by key value
Random access by record file address
Block I/O

For record mode access, the only file type in common between the two
systems is a sequential file in STM (stream) format. For convenience,
however, when you are transferring a file to a TOPS-20 node, VAX RMS
will automatically convert a VAX/VMS sequential file with fixed or variable
format and implied carriage control to a sequential file with stream format
and embedded carriage control. This automatic conversion is performed
during a file create operation, and VAX RMS returns an alternate success code
(RMS$_CVT_STM) to indicate that the file format has been modified.
Note also that when a stream format file is retrieved from a TOPS-20 node,
VAX RMS automatically changes the record attribute from embedded carriage
control to implied carriage control.
In general, text files created by the SOS Editor without line numbers being
saved or by the EDT Editor can be copied to a TOPS-20 system. VAX/VMS
batch log files and files created by the SOS Editor with line numbers intact,
however, are stored in VFC format, and cannot be copied in that form to a
TOPS-20 system. To transfer this type of file, use the DCL command
$ CONVERT/FDL=STM.FDL input-file output-file

where the FDL control file STM.FDL contains
FILE
ORGANIZATION

sequential

FORMAT
CARRIAGE.CONTROL

stream
none

RECORD

9-21

File Operations in a Heterogeneous Network Environment

9.9.1.2

VAX RMS Interface
The following VAX RMS features, supported between two VAX/VMS nodes,
are not supported between a VAX/VMS node and a TOPS-20 node:
•

VAX RMS service calls:
SDELETE

SDISPLAY

SEXTEND

$FIND

SFREE

$READ

$RELEASE

SRENAME

SREWIND

SSPACE

STRUNCATE

SUPDATE

$WRITE
•

RMS extended attribute blocks:
Allocation XAB
Key Definition XAB
Summary XAB

•

Significant fields and bit options of the FAB:
ALQ (allocation quantity) field
DEQ (default extend quantity) field
CBT (contiguous-best-try) bit of FOP field
CTG (contiguous) bit of FOP field

•

Significant fields and bit options of the RAB:
EOF (position to end of file) bit of ROP field

9.9.1.3

File Specifications
The general format of a file specification for naming a file on a remote
TOPS-20 system is
node::device<directory>name.type.version

The following are the major differences in syntax between file specifications
on TOPS-20 and on VAX/VMS:

9.9.2

•

TOPS-20 uses angle brackets ( <> ) to delimit the directory string
instead of square brackets ([]). To facilitate communication with
TOPS-20, VAX RMS recognizes angle brackets as valid directory
component delimiters.

•

TOPS-20 uses the period (.) to delimit the version number instead of the
semicolon (;). However, you can specify either a period or a semicolon
because VAX RMS converts a semicolon version number delimiter to a
period before sending the file specification to the TOPS-20 FAL.

DCL Considerations
Of the VAX/VMS DCL commands that can be used over the network, the
following are not supported between VAX/VMS and a TOPS-20 node:

9-22

•

ANALYZE/RMS-FILE

•

APPEND

•

BACKUP

•

OPEN/WRITE

•

RENAME

File Operations in a Heterogeneous Network Environment

9.9.2.1

COPY
The /ALLOCATION, /CONTIGUOUS, /EXTENSION, and /PROTECTION
qualifiers to the COPY command are not supported and will be ignored if
specified.
File creation date and time is not preserved during a file copy operation.
Using COPY to merge several files into a single output file is not supported.

9.9.2.2

DIRECTORY
When you issue a DIRECTORY/FULL command to examine a TOPS-20 file,
the information displayed will differ in the following respects from that which
is displayed for a VAX/VMS file:

9.10

•

The file owner is displayed as [0,0] to indicate that this information is not
available.

•

The file revision number is not shown.

•

The blocks used and blocks allocated values displayed, which indicate the
size of the file, refer to 128-word pages (providing 640 bytes of storage),
not 512-byte blocks.

•

TOPS-20 does not have the equivalent of world protection, so this
attribute is displayed as a null string.

VAX/VMS to VAX/VMS Network Operations (Version 4 to
Version 3)
This section pertains to file operations initiated on a VAX/VMS Version 4
node running DECnet-VAX Version 4 where the remote system is a V3.n
node running DECnet-VAX V3.1.

9.10.1 File System Constraints
The restrictions described below are related to new features in DECnet-VAX
Version 4 for remote file access that were not supported in DECnet-VAX
V3.1.

9.10.1.1

File Formats and Access Modes
The following types of files and access methods are not supported by
VAX/VMS when communicating with a VAX/VMS V3.n node:
•

File organizations and record formats:
Sequential

Stream_CR (STMCR)
Stream_LF (STMLF)

Indexed

With 64-bit binary (BN8) key types
With 64-bit integer (IN8) key types
With descending key types (DSTG, DIN2, DBN2, DIN4,
DBN4, DIN8, DBN8, DPAC)

•

Record attributes:
(Record attributes are compatible)

9-23

File Operations in a Heterogeneous Network Environment

•

File access modes:
(Modes are compatible)

9.10.1.2

VAX RMS Interface
The following VAX RMS features, supported between two VAX/VMS Version
4 nodes, are not supported between a VAX/VMS Version 4 node and a
VAX/VMS V3.n node:
•

VAX RMS service calls:
SRENAME

•

RMS extended attribute blocks:
(No differences)

•

Significant fields and bit options of the FAB:
(No differences)

9.10.1.3

File Specifications
The general format of a file specification for naming a file on a remote
VAX/VMS V3.n system is
node::device:[directory]name.type;version

The following are major differences in syntax between file specifications used
on VAX/VMS V3.n and on VAX/VMS Version 4:
•

VAX/VMS V3.n systems do not support dollar sign ($) and underscore
(_) characters in file name components.

•

The file name component has a maximum length of nine characters and
the file type cannot exceed three characters. VAX/VMS V3.n systems will
return an error if you specify a longer file name or file type.

9.10.2 DCL Considerations
Of the VAX/VMS DCL commands that can be used over the network, the
following is not supported between a VAX/VMS Version 4 node and a
VAX/VMS V3.n node:
•

9.11

RENAME

VAX/VMS to VAX/VMS Network Operations (Version 4.4 to
Previous Version)
This section pertains to file operations initiated on a VAX/VMS Version
4.4 node running DECnet-VAX Version 4.4 where the remote system is a
VAX/VMS node running a previous release of DECnet-VAX.

9.11.1 File System Constraints
The restriction described below indicates a new feature not previously
supported by DECnet-VAX.

9-24

File Operations in a Heterogeneous Network Environment

9.11.1.1

File Formats and Access Modes
The following type of file is not supported by VAX/VMS when
communicating with a VAX/VMS node running a previous DECnet-VAX
release:
•

File organization and record format:
Indexed

With descending key types (DSTG, DIN2, DBN2, DIN4,
DBN4, DIN8, DBN8, DPAC)

9-25

Area Routing Configuration

Phase IV DECnet supports area routing, which permits the configuration
of networks in which the nodes are grouped into areas. This appendix
presents recommendations and guidelines for configuring networks that use
area routing. It illustrates the guidelines with an example of the design of a
multiple-area network, and indicates the NCP commands required to build
the configuration database for this network. The appendix also recommends a
procedure for converting an existing network to a multiple-area network. The
next section of the appendix describes problems that can occur when you are
configuring an area-based network, and includes suggestions for solving these
problems. The final section discusses area routing on the Ethernet.
Area routing concepts are described in detail in Section 2.4. Area routing
techniques enable configuration of a network consisting of a number of areas;
each area is a group of nodes that forms a subnetwork. DECnet supports
routing of packets within areas and a second level of routing between areas.
The router that performs routing within an area is called a level 1 router; the
router that performs routing to and from other areas as well as within its own
area is called a level 2 router (or area router).
Each level 1 router keeps information on the state of all nodes in its area, but
not on the state of nodes outside its area. It routes all packets addressed to
nodes outside its area to the nearest level 2 router. Each level 2 router keeps
information on the least-cost path to areas throughout the network, as well as
the state of the nodes in its own area. When a level 1 router receives a packet
destined for a node in another area, it uses level 1 routing to send the packet
to the nearest level 2 router in its own area. The level 2 router forwards the
packet along the least-cost path to the nearest level 2 router outside its area.
The packet is transmitted along a level 2 path to the level 2 router in the
destination area; this level 2 router sends the packet by level 1 routers to the
destination node.
Thus, a basic reason for dividing a network into multiple areas would be
to reduce the amount of routing traffic that would occur in a single-area
network.

A.1

Area Routing Configuration Guidelines
Configuration of a network that consists of multiple areas is more complex
than configuration of a network that, by default, consists of a single area.
The design of a multiple-area network introduces a second, higher level of
routing that links the areas. Designing a network for area routing involves
awareness of certain network topological restrictions unique to area routing
configurations. The area routing configuration guidelines presented below are
based on these restrictions. The guidelines are intended to prevent problems
such as loss of routing path, isolation of nodes, or incorrect routing of packets.
These potential problems are discussed in Section A.5.

A—1

Area Routing Configuration

When you configure a multiple-area network, you should follow these
guidelines:
•

Each node must belong in only one area. This restriction applies to all
nodes in the network. Phase III nodes as well as Phase IV nodes. Phase
III nodes must be logically associated with a single area even though they
are not assigned an area number by network management, and must not
have circuits outside the area.

•

Only a level 2 router can establish a circuit with a node in another area,
thus enabling communication between the areas. A level 1 router cannot
have any circuits outside its own area.

•

Within a network, the level 2 routers must form a subnetwork; that is,
they must be connected in such a way that they create a network of their
own. There must be a level 2 routing path between any pair of level 2
routers across the network. Level 1 routers do not forward level 2 routing
information.

•

Treat each area as though it were a separate network. Each area must
be physically intact and capable of running on its own. Within the area,
there must be a level 2 path between any pair of level 2 routers.

•

Provide enough redundancy within each area and between areas to avoid
having a single point of failure in the network. For redundancy within
an area, you could include more than one level 2 router and provide for
alternate paths between nodes. This redundancy will prevent loss of the
routing path within the area or isolation of any one node. For redundancy
between areas, you could provide for alternate paths between areas so that
loss of a line does not disconnect any area from the rest of the network.
Complete redundancy may not be feasible, however, for certain networks,
such as small networks.

•

Place all Phase III nodes on the periphery in each area. Do not place a
Phase III node in a path between two Phase IV nodes. A Phase III node
cannot communicate directly with nodes in other areas or with nodes in
the same area that have addresses greater than 255.

•

Do not link a Phase III node in one area with a node in another area.
Such a connection could lead to area leakage, a problem described in
Section A.5.2.2.

The recommended approach to designing a multiple-area network
configuration is to begin by designing the level 2 routers, area by area, into
a level 2 subnetwork. Then, in each area, add the level 1 routers. Finally,
add the end nodes required to complete each area. This design approach is
illustrated below.

A.2

Designing a Multiple-Area Network
This section demonstrates the use of the configuration guidelines in designing
a multiple-area network. The goal of the design process is to build a robust,
redundant network that will not be subject to a single point of failure.
Figure A-l shows the level 2 routers as a subnetwork of a multiple-area
network. For purposes of illustration, DMR lines are used to connect level 2
routers within each area and DMC lines to connect level 2 routers in different
areas. In each area, the level 2 routers are configured in pairs for redundancy
and connected by enough DMR lines so that the loss of one DMR line does
not prevent the flow of level 2 routing traffic through the area. Redundancy

A—2

Area Routing Configuration

between different areas is achieved by the way in which the DMC lines
connect level 2 routers in the different areas. If one of the DMC lines fails,
level 2 routing traffic can still reach each area by an alternate path. In area 9,
the redundant level 2 routers that form part of a VAXcluster are connected by
a Cl line.

Figure A-1

Level 2 Router Subnetwork of a Multiple-Area
Network

AREA 7

AREA 8

ZK-1995-84

Figure A-2 shows the next stage of the design process: adding the level 1
routers and the end nodes to each area. The figure does not include all the
nodes that might be required to make the network complete. It illustrates
only a few typical uses of level 1 routers and end nodes, indicating the way
in which you could add such nodes to the level 2 subnetwork to complete the
network design.

A—3

Area Routing Configuration

Ethernet
ZK-1996-84

In Figure A-2, in area 7, an end node and a level 1 router are attached
directly to the first Ethernet. MicroVMS end nodes are connected to the
level 1 router by means of DDCMP asynchronous lines. Another end node
is connected to a level 2 router attached to the second Ethernet (lower left)
in area 7. Because this end node is not on a routing path between level 2
routers, it could possibly be a Phase III end node. In area 9, two level 1
routers are added to the redundant level 2 routers in a VAXcluster.

A—4

Area Routing Configuration

The network design shown in Figure A-2 ensures a robust network not
vulnerable to a line or node failure that could isolate or bring down an area.
A fully redundant multiple-area network, such as that in Figure A-2, may not
be practical for smaller networks, however. Redundancy is a desirable design
goal, not a requirement, in a multiple-area network.
When you complete the design of a multiple-area network, begin network
configuration by configuring each area separately, as though it were a network
by itself. An example of the NCP commands required to configure area 7 of
the network in Figure A-2 is given in the following section. Once you have
configured all areas in the network and they are running and stable, connect
the areas.

A.3

Sample Multiple-Area Network Configuration
The example below illustrates how you can use NCP commands to configure
a multiple-area network. It lists the NCP commands required to build the
permanent database for one area of the large multiple-area network shown in
Figure A-2, and indicates how to complete the network configuration.
This example builds a database for a network configuration of twelve nodes
in area 7, as depicted in Figure A-3. Area 7 is connected to areas 8 and 9.
The database being built is for node A. Similar commands would be issued
to create the database for each of the other nodes in area 7, and each of the
nodes in areas 8 and 9.

A—5

A—6

DEFINE EXECUTOR ADDRESS 7.1 BUFFER SIZE 576 STATE ON TYPE AREA DEFAULT PROXY BOTH

Define common node parameters for the local node.
B
sure to add the NETNONPRIV user to your system
authorization file by using the Authorize Utility.
DEFINE EXECUTOR NAME A NONPRIVILEGED USER NETNONPRIV PASSWORD NONPRIV -

Define the remaining nodes. Note that no default outb
access control information is specified. This assume
the default access control information will be suppl
each remote node when it
as a result of a proxy 1<
DEFINE
DEFINE
DEFINE
DEFINE
DEFINE
DEFINE
DEFINE
DEFINE
DEFINE
DEFINE
DEFINE

NODE B ADDRESS
NODE C ADDRESS
NODE D ADDRESS
NODE E ADDRESS
NODE F ADDRESS
NODE G ADDRESS
NODE H ADDRESS
NODE I ADDRESS
NODE J ADDRESS
NODE K ADDRESS
NODE L ADDRESS

7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12

If node L is a Phase III
to specify routing initialization passwords to
initialize this node.
Using the number of the area
which the Phase III node resides as part of the passw
will avoid accidental connection to another area.
Define a receive password for node L as follows:
DEFINE NODE L RECEIVE PASSWORD AREA7
In this case, on node L, the transmit password would
set to match:
DEFINE NODE A TRANSMIT PASSWORD AREA7
! (on nod

Note that although nodes M and N reside in different
areas, no special action is needed in defining them.
Continue defining nodes in other areas in this fashio
DEFINE NODE M ADDRESS 8.3
DEFINE NODE N ADDRESS 9.42

Set up the line and circuit for the Ethernet connecte
to node A.
DEFINE LINE UNA-0 STATE ON
DEFINE CIRCUIT UNA-0 STATE ON

Area Routing Configuration

Set up the line and circuit for each DMR connected to
node A. Note that a DMR line is treated like a DMC line.
DEFINE
DEFINE
DEFINE
DEFINE

LINE DMC-1 STATE ON
CIRCUIT DMC-1 STATE ON
LINE DMC-2 STATE ON
CIRCUIT DMC-2 STATE ON

Set up the line and circuit for the DMC connected to
node A.
Because the DMC leads to another area, you
may want to leave this circuit and line in the OFF state
while you are initially configuring your area, turning
them on only after the connections within your area
have been tested.
DEFINE LINE DMC-0 STATE ON
DEFINE CIRCUIT DMC-0 STATE ON
The object database does not need to be defined, since it
defaults to the standard list of objects known to VAX/VMS.
Define the transmitter-related logging parameters.
DEFINE LOGGING MONITOR KNOWN EVENTS
Define receiver-related logging parameters.
DEFINE LOGGING MONITOR STATE ON

A.4

Converting an Existing Network to a Multiple-Area Network
Converting an existing single-area network to a multiple-area network
requires careful planning. Because the network addresses of existing nodes
will change, there may be a period during which some nodes are unreachable
while the conversion is under way. The following steps illustrate an approach
that can keep this disruption to a minimum.
1

Plan ahead. Completely define what the entire network topology will be
with multiple areas. Make sure the topology follows the guidelines listed
in Section A.l. Decide which nodes should be level 2 routers, level 1
routers, and end nodes.

2 If the new design requires that some nodes be moved, make the required
changes before you begin converting node addresses. (For example, the
redesign may involve reconnecting a Phase III node so that it is not in a
path between two Phase IV nodes.)

3 Create new node databases. Without modifying the existing permanent
node databases, create a new copy of the node database on each node in
the network. This is most easily done as follows for DECnet-VAX nodes:

A—8

Use the logical name NETNODE —REMOTE to point to the working
copy of the remote node file you are creating and use the logical name
NETNODE—LOCAL to point to the working copy of the local node file
you are creating. These logical names will be translated when NCP is
reading the permanent database, and the default versions

Area Routing Configuration

of NETNODE_REMOTE.DAT and NETNODE_LOCAL.DAT in
SYS$SYSTEM: will remain untouched. Set up this environment as
follows:
$ COPY SYS$C0MM0N:[SYSEXE]NETNODE.REMOTE.DAT _ SYS$MANAGER:NEWNETN0DE_REM0TE.DAT
$ COPY SYS$SPECIFIC:[SYSEXE]NETNODE.LOCAL.DAT _ SYS$MANAGER:NEWNETNODE.LOCAL.DAT
$ ASSIGN/USER.MODE SYS$MANAGER:NEWNETNODE.REMOTE.DAT NETNODE.REMOTE
$ ASSIGN/USER.MODE SYS$MANAGER:NEWNETNODE.LOCAL.DAT NETNODE.LOCAL
$ RUN SYS$SYSTEM:NCP
NCP>

When the NCP prompt appears, enter the changes, which will be made
to the new database.
b

In your remote node file, change the addresses of existing nodes in
the network to reflect the new topology with areas. If you are adding
new nodes to the network (for example, if two existing separate
networks are to be merged), include their new addresses in your file
now. Make sure these changes are only made to the working copies
of the files, and not to SYS$SYSTEM:NETNODE_JREMOTE.DAT
or SYS$SYSTEM:NETNODE_LOCAL.DAT. For now, the database
changes need to be made on only one node in the network. Also, to
modify the executor, issue the commands
ncp>purge executor address
NCP>DEFINE NODE local._node_.name ADDRESS ...
NCP>DEFINE EXECUTOR ADDRESS ...

When SYS$MANAGER:NEWNETNODE_REMOTE.DAT and
SYS$MANAGER:NEWNETNODE_LOCAL.DAT correctly reflect the
new topology, copy SYS$MANAGER:NEWNETNODE_REMOTE.DAT
to the SYS$MANAGER directory on each node in the network. (Note
that this should be done only for nodes which are running the same
version of VAX/VMS. If you have different versions in the network,
the conversion procedure should be followed independently for each
version.)
On each VAX/VMS node on the network, define the executor
parameters in NEWNETNODE_LOCAL.DAT as follows:
$ COPY SYS$SPECIFIC:[SYSEXE]NETNODE.LOCAL.DAT _ SYS$MANAGER:NEWNETNODE.LOCAL.DAT
$ ASSIGN/USER.MODE SYS$MANAGER:NEWNETNODE.REMOTE.DAT NETNODE.REMOTE
$ ASSIGN/USER.MODE SYS$MANAGER:NEWNETNODE.LOCAL.DAT NETNODE.LOCAL
$ RUN SYS$SYSTEM:NCP
NCP>DEFINE EXECUTOR ADDRESS ...

Using the NCP command DEFINE EXECUTOR, set up each local
node with the correct area and node address, correct executor type
(nonrouting IV, routing IV, or area), and other executor parameters.
Similarly, convert the node database on each non-VAX node in your
network using the tools available for each implementation.
4

Shut down the network and bring it up again with the new database.
This is the only part of the conversion process which benefits from
real-time cooperation among the nodes in your network. If this level
of coordination is not feasible, then avoid using area number 1 for any
area in the revised network, since node address duplications might occur
during the transition period.

A—9

Area Routing Configuration

At approximately the same time, have each node in the network shut
down DECnet. It is not necessary to shut down the operating system. Use
the command
NCP>SET EXECUTOR STATE SHUT

When all nodes have shut down DECnet (or after an agreed-upon interval
during which all nodes should have shut down DECnet), rename the new
copy of the database and restart the network at each node:
$ RENAME SYS$MANAGER:NEWNETNODE_REMOTE.DAT _ SYSSCOMMON:[SYSEXE]NETNODE_REMOTE.DAT
$ RENAME SYS$MANAGER:NEWNETNODE_LOCAL.DAT _ SYS$SPECIFIC:[SYSEXE]NETN0DE_L0CAL.DAT
$ <DSYS$MANAGER: STARTNET

Note that if your node is on an Ethernet to which applications other
than DECnet (such as LAT) are connected, these applications should also
be shut down along with DECnet, and then restarted after DECnet is
restarted. This step is necessary because DECnet will be changing the
Ethernet physical address of your node to reflect the new executor node
address (see Section 3.3.4.1).

5 Use NCP to monitor the reconfigured network.
Depending on the size of the network and the care with which the conversion
was done, there may be a period of debugging the network to ensure that
all desired connections have been made. You can simplify debugging the
conversion if you can run each area separately for a while before connecting
them. You can do this by turning the circuits between level 2 routers in
different areas to the OFF state in the new copy of the database. Once you
are confident that an area is operating to your satisfaction, you can turn on
the circuits joining this area to its neighboring areas. Of course, while the
interarea circuits are off, nodes in those areas will not be accessible to nodes
in other areas. This circumstance may be viewed as a tradeoff to reduce the
number of variables during the conversion.

A.5

Problems in Configuring a Multiple-Area Network
The use of area routing techniques in configuring a network can lead to
certain problems that may not be readily identifiable. This section describes
some problems related to violation of the area routing configuration guidelines
presented in Section A.l, and explains how to solve these problems.

A.5.1

Partitioned Area Problem
Improper configuration of the network topology for a multiple-area network
can result in a failure condition that can cause traffic to be incorrectly routed
and/or lost. The problem is called area partitioning; it occurs when an area
is broken into separate parts as the result of the failure of one or more lines
or nodes. As a consequence of partitioning, a node may be isolated within an
area.

A—10

Area Routing Configuration

Figure A-4 illustrates an improper network design, in which an area is
vulnerable to partitioning if a single line should fail. All circuit costs in
Figure A-4 are equal to 1. Node C in area 3 attempts to communicate with
node D in area 4. If either link w or x fails, there is no problem because the
remaining path into area 4 provides a route to node D. If link y or z fails, the
level 2 router in area 3 will find the path to the level 2 router in area 4 on the
basis of the least-cost algorithm; the path would be from node C to node B to
node A. Because link y or z is down, however, it is not possible to get to the
destination node D.
Figure A-4

Partitioned Area Problem

AREA 2

AREA 3

ZK-2000-84

When the initial connection is attempted, the network turns on the "return
to sender" bit and sends a message to the sender indicating the node is
unreachable. If the two nodes have already established a link before the
connection breaks, the sender will time out, because the network will not
route back traffic once it arrives at the destination area. Thus a node in an
area is isolated because of a line failure.

A—11

Area Routing Configuration

Figure A-4 illustrates another problem. If link z is down and node D wants
to create a link to node B, the path that node D chooses is to route through
area 2 and then to node B. On the return trip, however, node B will attempt
to send the reply to node A, but link z is down, and therefore the reply will
not be delivered to node D.
The solution to the problem of area partitioning is to treat each area as a
separate network when configuring a multiple-area network. Designing an
area as a straight-line configuration, as in area 4 in the figure, should be
avoided. Also, all the level 2 routers in a given area should be linked in a
level 2 routing path; a level 1 router should not be included on the same
path. In the configuration in Figure A-4, installing a link between nodes A
and D would provide for an alternate path between nodes in the same area.

A.5.2

Problems in Mixed Phase Ill/Phase IV Networks
In a Phase IV multiple-area network. Phase III nodes can be included
provided certain rules are followed: Phase III nodes in a multiple-area
network must not be in the routing path between Phase IV nodes and must
not be linked to nodes outside their own area. These limitations are based on
the following restrictions under which Phase III nodes operate in a Phase IV
network:
•

DECnet-VAX Phase III nodes cannot assume a node address greater than
255, and cannot directly address a node with a node address greater than
255. They also cannot route through traffic for nodes with addresses
greater than 255. (Note that this limit may vary for other DECnet Phase
III nodes, up to a maximum possible address of 1023.)

•

Phase III nodes cannot recognize area numbers in node addresses. A
Phase III node cannot assume an area address, directly address a node
outside its own area, or route through traffic for nodes in other areas.

•

Phase III nodes cannot be connected directly to an Ethernet.

•

Phase III nodes must use routing initialization passwords when they are
initialized in a Phase IV network (see Section A.5.2.2).

The node address is represented in different ways in Phases III and IV. In
Phase III a node address is represented by a single decimal number, such as
99. For DECnet-VAX, the maximum node address of a Phase III node is 255.
In Phase IV a node address is represented by a number in the format
area-number.node-number

where the maximum area-number is 63 and the maximum node-number is
1023. If Phase IV node number 99 is in area 33, its node address is 33.99. (If
a Phase IV network is not configured into areas, node number 99, by default,
is in area number 1 and is represented in the database by the node address
1.99.)
Whenever a Phase III node is brought up in a Phase IV multiple-area
network, the physical link is initialized with the Phase III protocol and all
references to the area number are dropped. Routing in the network is affected
in different ways, depending on the direction in which traffic is flowing:
•

A—12

If traffic is going from a Phase IV node to the Phase III node, the area
number is dropped from the node address. For example, when node
address 19.201 is passed to a Phase III node, the node address becomes
201.

Area Routing Configuration

A.5.2.1

•

If traffic is going from a Phase III node to a Phase IV node, the area
number of the Phase IV node is added to the node address. For example,
if node address 143 is sent to Phase IV node 75.5, the node address 143
becomes 75.143.

•

If a packet is routed through a Phase III node, the area number is dropped
from both the source and destination node addresses in the routing header
of the packet.

Problem of a Phase III Node in a Phase IV Path
An example of the problem caused by placing a Phase III node in the
routing path between two Phase IV nodes in the same area is illustrated
in Figure A-5.

Figure A-5

Problem of Phase III Node In Phase IV Path
Packet 1

G (4.45)
Phase IV

From Source Node Address

□

To Destination Node Address
L2

Level 2 router

ZK-1998-84

A—13

Area Routing Configuration

No problem occurs if the entire logical link path is within a single area and
if none of the nodes have node numbers greater than 255. For example, for
node 4.88 to send a packet to node 4.45, the packet first goes to node 22 (the
Phase III node has no area number even though it is in area 4). Node 22
discards the area number from the destination node address 4.45, making it
address 45, and from the source node address 4.88, making it address 88. The
packet is then forwarded to node 4.45, which adds its own area number to
the destination address, making it 4.45, and to the source address 88, making
it 4.88.
During the return trip from node 4.45 to 4.88, the packet (with source address
4.45 and destination address 4.88) goes through node 22 and loses the
area numbers from the source and destination node addresses in its routing
header. When the packet arrives at its destination, node 4.88 adds its own
area number to the node addresses in the routing header, making the source
address 4.45 and the destination address 4.88.
A problem occurs, however, during communication between nodes in
different areas, when the routing path in one area includes a Phase III
node between two Phase IV nodes. In the example in Figure A-5, if node
2.72 wants to send a packet to node 4.45, the packet goes from node 2.72 to
node 4.88 and then to node 22, which drops the area number from both the
source and destination addresses in the routing header, making the source
address 72 and the destination address 45. Node 22 then sends the packet to
the destination, node 4.45, which adds its area number to the source address,
making it 4.72, and to the destination address, making it 4.45. The problem
arises during the return trip. Node 4.45 attempts to respond by sending a
packet addressed to destination node 4.72 instead of 2.72. If a node with
address 4.72 does exist, the return packet is incorrectly delivered to that node.
Node 2.72 does not receive a reply and eventually times out.

A.5.2.2

Area Leakage Problem
When a Phase III node is included in a Phase IV network that has been
divided into multiple areas, the Phase III node should not be connected to
a node outside its own area (as in Figure A-6). A Phase III node drops the
area number from a node address. Permitting a Phase III node to have a
link to another area causes a problem known as "area leakage." When the
Phase III node builds its routing database, it includes the node addresses of
adjacent nodes minus their area numbers. This incorrect information is then
transmitted (or "leaked") across the area boundaries. This problem occurs
whether the Phase IV nodes are level 1 or level 2 routers.
In Figure A-6, node R is a Phase III node with links to nodes in areas 12
and 14. Node R will build a routing database that contains the addresses
of nodes P, Q, and S, but the area numbers will be missing from the node
addresses. Node R will send routing updates to all adjacent nodes, without
recognizing area boundaries. Thus node R will send routing information
about nodes P and Q (minus the correct area designation) to node S. Node
S will assume that nodes P and Q are nodes in its own area that have the
addresses 12.6 and 12.7, respectively, instead of the correct addresses 14.6
and 14.7. Similarly, node R will send the address of node S (minus its area
number) to nodes P and Q; nodes P and Q will assume that node S is in their
own area and has the address 14.5 rather than the correct address 12.5.
Routing initialization passwords are required when a Phase III node is
initialized in a Phase IV network (see Section 2.10.1 for a description of
the passwords). If no password is specified during routing initialization, a
specific event class message will be generated, indicating that a password is
required or is mismatched. If the network manager has turned on the event
logger, he or she can read these messages to learn which Phase III nodes

A—14

Area Routing Configuration

Figure A-6

Area Leakage Problem

AREA 14

AREA 12

P<14.6)
Phase IV

S(12.5)
Phase IV

Q(14.7)
Phase IV
ZK-1999-84

have not been initialized. The network manager can use this information to
prevent Phase III nodes from linking to nodes outside their own areas, or to
identify which Phase III nodes need to have the transmit password set. It is
recommended that the number of the area in which the node resides be used
in the password, to prevent accidental connection to a node in a wrong area.
Note that this technique will not locate Phase III nodes improperly linked
to nodes in other areas if the Phase III nodes were configured using
routing initialization passwords before conversion to area routing, unless
the passwords were changed as recommended during the conversion.

A.6

Area Routing on an Ethernet
Phase IV DECnet supports configuration of multiple areas on an Ethernet.
This configuration results in higher message overhead because a packet must
be routed through two level 2 routers rather than being delivered directly to
the destination node. Figure A-7 shows two areas sharing the same Ethernet
cable. When a node in area 5 wishes to communicate with a node in area 7,
the packet is routed through the two level 2 routers. For example, if node 5.3
sends a packet to node 7.8, the packet follows this path:
•

Node 5.3 to node 5.2 (source to its nearest level 2 router)

•

Node 5.2 to node 7.4 (level 2 router to level 2 router)

•

Node 7.4 to node 7.8 (level 2 router to destination)

A—1 5

Area Routing Configuration

Figure A—7

Area Routing on an Ethernet

AREA 5

(5.2)

(5.3)

(5.7)

AREA 7

(7.4)

(7.1)

(7.3)

(7.8)

ZK-2001-84

A—16

Glossary

access control: Validating connect, login, or file-access requests to determine whether
they can be accepted. User name and password provide the most common means of
access control.

account name: A string that identifies a particular account used to accumulate data
on a job's resource use. This name is the user's accounting charge number, not the
user's UIC.

active component:

A component whose operational state is other than OFF.
The word ACTIVE can be used with the SHOW or LIST commands to display
information about active lines, circuits, nodes, and logging.

adjacent node: A node removed from the local node by a single physical line.
alias node identifier:

An optional node name or address, common to some or all
nodes in a VAXcluster, that permits the VAXcluster to be treated as a single node.

area: A group of nodes in a network that can 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 (level 1 routing) and a second, higher level of routing
between areas (level 2 routing).

asynchronous transmission:

A mode of data transmission in which the time
intervals between transmitted characters may be of unequal length. Asynchronous
transmission most commonly occurs over terminal lines.

bandwidth:

The range of frequencies assigned to a channel or system (that is, the
difference expressed in Hertz between the highest and lowest frequencies of a band).

bilateral closed user group (BCUG): An optional packet switching data network
(PSDN) facility that restricts a pair of DTEs to communicating with each other.

broadcast addressing: A special type of multicast addressing, in which all nodes are
to receive a message.

broadcast circuit: A circuit on which multiple nodes are connected and on which a
message can be transmitted to multiple receivers.

carrier sense:

A signal provided by the Physical layer to indicate that one or more
stations (nodes) are currently transmitting on the Ethernet channel.

Carrier Sense, Multiple Access with Collision Detect (CSMA/CD): A link
management procedure used by the Ethernet. Allows multiple stations to access the
broadcast channel at will, avoids contention by means of carrier sense and deference,
and resolves contention by means of collision detection and retransmission.

Glossary—1

Glossary

CCITT: Comite Consultatif International Telegraphique et Telephonique. An
international consultative committee that sets international communications usage
standards.

channel:

A means of transmission. For VAX PSI, a logical path between a DTE and
a DCE over which data is transmitted. Each channel is identified by a unique
reference number called a logical channel number (LCN).

characteristics: A display type for the SHOW and LIST commands. It refers to static
information about a component that is kept in either the volatile or permanent
database. Such information may include parameters defined for that component by
either the SET or DEFINE command.

circuit:

Virtual communication path between nodes or DTEs. Circuits operate over
physical lines and are the medium on which all I/O occurs. X.25 circuits are virtual
circuits.

closed user group (CUG): An optional PSDN facility that restricts two or more DTEs
in the same group to communicating with each other.

collision:

Multiple transmissions overlapping in the physical channel, resulting in
garbled data and necessitating retransmission.

collision detect:

A signal provided by the Physical layer to the Data Link layer to
indicate that one or more stations (nodes) are contending with the local station's
transmission.

command node: The node from which an NCP command is issued.
component:

An element in the network that can be controlled and monitored.
Components include lines, circuits, nodes, modules, logging, and objects.
Components form part of the NCP command syntax.

configuration database:

The combination of both the permanent and the volatile
databases. It consists of information about the local node, and all nodes, modules,
circuits, lines, and objects in the network.

congestion loss: A condition in which data packets are lost when Routing is unable
to buffer them.

connector node: A node which serves as an X.25 gateway to permit VAX/VMS host
nodes to access a packet switching data network.

control station: The node at the controlling end of a multipoint circuit. The control
station controls the tributaries for that circuit.

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:

Performance and error statistics kept for a component, such as lines or

nodes.

data circuit-terminating equipment (DCE): A CCITT X.25 term referring to the
network equipment that establishes, maintains and terminates a connection and
handles the signal conversion and coding between the data terminal equipment and
the network. The switching exchange of the network to which DTEs are connected.
(In non-X.25 usage, the term is synonymous with modem.)

Glossary—2

Glossary

data link mapping (DLM): Capability of using an X.25 virtual circuit as a DECnet data
link.

data terminal equipment (DTE): An X.25 term referring to the user's equipment
(computer or terminal) connected to a DCE on a packet switching data network for
the purpose of sending and/or receiving data.

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.

designated router:

A routing node on the Ethernet selected to perform routing
services on behalf of end nodes.

disconnect abort: Nontransparent tasks can deaccess a logical link via a disconnect
abort operation without deassigning the channel. This form of disconnection
indicates to the receiver that not all messages sent have necessarily been received.

downline system load:

A DECnet-VAX function that allows an unattended target
node to receive an operating system file image from another node.

downline task load:

A function that allows a remote target node to receive an
RSX-11S task from another node.

end node: A node that can receive packets addressed to it and send packets to other
nodes, but cannot route packets through from other nodes. Also called a nonrouting
node.

event:

A network or system-specific occurrence for which the logging component
maintains a record.

event class: A particular classification of events. Generally, this classification follows
the DNA architectural layers; some layers may contain more than one class. Class
also includes the identification of system-specific events.

event type: A particular form of event that is unique within an event class.
executor node: The node at which an NCP command actually executes.
frame: A unit delimited by flags that includes a header, and is used by the link level
to exchange packets as well as control and error information between the DTE and
the DCE on a packet switching data network.

handshaking sequence: The exchange of logical link connection information between
two tasks. This exchange takes place to enable the successful completion of a logical
link connection.

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.

hop: The logical distance between two nodes. One hop is the distance from one node
to an adjacent node.

host node: For DECnet, a node that provides services for another node (for example,
the host node supplies program image files for a downline load).
For VAX PSI, a node that accesses a packet switching data network by means of an
X.25 multihost connector node.

Glossary—3

Glossary

inbound connection:

The term refers to the fact that a task receives logical link

connection requests.

interrupt:

For VAX PSI, a packet, sent through a PSDN, that bypasses normal flow
control procedures used by data packets.

interrupt message:

During nontransparent task-to-task communication, a user¬
generated message sent outside the normal exchange of data messages. This usage
of the term interrupt is contrary to the normal usage, which means to designate a
software or hardware interrupt mechanism.

known component: The classification for one or more of the same components. This
classification includes all active and inactive occurrences of the component type. For
example, known nodes include all active and inactive nodes in the network.

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: The network management component that provides a distinct physical data path.
Link Access Protocol (LAP): A set of procedures used for link control. X.25 defines
two sets of procedures:
•

LAP—The DTE/DCE interface is defined as operating in two-way simultaneous
Asynchronous Response Mode (ARM) with the DTE and DCE containing a
Primary and Secondary function.

•

LAPB—The DTE/DCE interface is defined as operating in two-way
Asynchronous Balanced Mode (ABM).

In addition, LAPB with extended sequence numbering (that is, frame numbering
modulo 128) is known as LAPBE.

local node: The node at which you are physically located.
logical channel:

A logical link between a DTE and its DCE. The physical
communications line between a DTE and DCE is divided into a set of logical
channels.

logical channel number (LCN): A unique reference number that identifies a logical
channel. A DTE recognizes a virtual circuit by its associated LCN.

logical link: A carrier of a single stream of full-duplex traffic between two user-level
processes.

logging: The network management component that routes event data to a logging sink
such as a console or file.

logging console: A logging sink that is to receive a human-readable record of events.
Typically, a logging console is a terminal or a user-specified file.

logging file: A logging sink that is to receive a machine-readable record of events for
later retrieval. The logging file is user defined.

Glossary—4

Glossary

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.

loop node: A local node that is associated with a particular line and is treated as if it
were a remote node. All traffic to the loop node is sent over the associated line.

maximum visits:

The maximum number of nodes through which a packet can be
routed before reaching its destination.

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 circuit: A circuit connecting two systems, with one of the systems (the
control station) controlling the circuit, and the other system serving as a tributary.

network connect block (NCB): For DECnet, a user-generated data structure used in a
nontransparent task to identify a remote task and optionally send user data in calls
to request, accept, or reject a logical link connection.
For VAX PSI, a block that contains the information necessary to set up an X.25
virtual circuit or to accept or reject a request to set up an X.25 virtual circuit.

network status notifications:

Notifications that provide information about the
state of both logical and physical links over which two tasks communicate. A
nontransparent task can use this information to take appropriate action under
conditions such as third-party disconnections and a partner's exiting before I/O
completion.

network task:

A nontransparent task that is able to process multiple inbound
connection requests; that is, it has declared a network name or object number.

node: A network management component that supports DECnet software.
node address: The required, unique, numeric identification of a specific node in the
network.

node name: An optional alphanumeric identification associated with a node address
in a strict one-to-one mapping. A node name must contain at least one alphabetic
character.

nonprivileged: In DECnet-VAX terminology, this term means no privileges other than
NETMBX and TMPMBX. NETMBX is the minimal requirement for any network
activity.

nonrouting node: An end node.

Glossary—5

Glossary

object:

A DECnet-VAX process that receives a logical link request. It performs a
specific network function (a nonzero object such as FAL or NML), or is a userdefined image for a special-purpose application (a zero-numbered object).

A VAX PSI management component that contains records to specify account
information for incoming calls and to specify a command procedure that is initiated
when the incoming call arrives.

outbound connection:

The term refers to the fact that a task sends logical link

connection requests.

packet:

A unit of data to be routed from a source node to a destination node. For
VAX PSI, the unit of data switched through a PSDN; normally a user data field
accompanied by a header carrying destination and other information.

packet assembly/disassembly (PAD) device: A device at a PSDN node that allows
access from an asynchronous terminal. The terminal connects to the PAD and the
PAD puts the terminal's input data into packets (assembles) and takes the terminal's
output data out of packets (disassembles).

packet switching: A data transmission process, utilizing addressed packets, whereby
a channel is occupied only for the duration of transmission of the packet.

packet switching data network (PSDN): A set of equipment and interconnecting
links that provides a packet-switching communications service to subscribers.

Packetnet System Interface (PSI): The name for the software product that allows
DIGITAL operating systems to participate in a packet-switching environment.

parameter: An entry in the volatile or permanent database for a network management
component.

path: The route a packet takes from source to destination.
path cost: The sum of the circuit costs along a path between two nodes.
path length: The number of hops along a path between two nodes; that is, the number
of circuits a packet must travel along to reach its destination.

permanent database:

A file containing information about network management

components.

permanent virtual circuit (PVC): A permanent logical association between two DTEs
which is analogous to a leased line. Packets are routed directly by the network from
one DTE to the other.

physical address:

The unique address value associated with a given system on an
Ethernet circuit. An Ethernet physical address is defined to be distinct from all other
physical addresses on an Ethernet.

point-to-point circuit: A circuit that connects two nodes, operating over a single line.
polling:

The activity that the control station performs with a multipoint circuit's
tributaries to grant the tributaries permission to transmit.

privileged:

In DECnet-VAX terminology, this term means any user privileges in
addition to NETMBX and TMPMBX.

protocol: An agreed set of rules governing the operation of a communications link.
Glossary—6

Glossary

proxy login: The procedure that permits a remote user to access a specific account at
the local node, without supplying the user name and password.

reachable node: A node to which the local node has a usable communications path.
remote DTE: Any DTE in a network other than the one at which the user is located.
remote node: To any one node in the network, this node is any other network node.
router: A node that can send and receive packets, and route packets from one node to
another.

routing: The network function that determines the path along which data travels to its
destination.

routing node: A router.
sink node:

A node where logging sink types, such as a file or console, are actually

located.

source task: The task that initiates a logical link connection request in a task-to-task
communication environment.

state:

The functions that are currently valid for a given component. States include
line, circuit, local node, module, DTE, and logging.

status: A display type for the SHOW and LIST commands. Status refers to dynamic
information about a component that is kept in either the volatile or permanent
database.

substate: An intermediate circuit state that is displayed for a circuit state display via
the SHOW or LIST command.

summary: The default display type for the SHOW and LIST commands. A summary
includes the most useful information for a component, selected from the status and
characteristics information.

switched virtual circuit (SVC): A temporary logical association between two DTEs
connected to a PSDN, which is analogous to connection by a dialup line. An SVC is
set up only when there is data to transmit and is cleared when the data transfer is
complete.

synchronous disconnect:

The disconnect that occurs when a nontransparent task
issues a call to terminate I/O operations over a logical link without deassigning the
channel. Thus, the task can use the channel for subsequent I/O operations with the
same or a different remote task.

synchronous transmission:

A mode of data transmission in which the time of
occurrence of each signal representing a bit is related to a fixed time frame.

target node: The node that receives a memory image during a downline load; a node
that loops back a test message.

target task: The task that receives and processes a logical link connection request in a
task-to-task communication environment.

task: In this manual, the term refers to an image running in the context of a process.

Glossary—7

Glossary

task specifier: Information provided to DECnet-VAX software so that it can complete
a logical link connection to a remote task. This information includes the name of the
remote node on which the target task runs and the name of the task itself.
terminal emulator: A program that acts as a transparent interface between two ports,
making it appear as though a terminal on the local processor is directly connected to
a remote processor.
tributary:

A physical termination on a multipoint circuit that is not a control station.

tributary address:

A numeric address that the control station uses to poll a tributary.

upline dump: A DECnet-VAX function that allows an adjacent unattended node to
dump its memory to a file on a VAX/VMS system.
virtual circuit: An association between two nodes (or two DTEs connected to a
PSDN) whereby the two nodes (or DTEs) are able to interact as if a specific
circuit were dedicated to them throughout the transmission. In reality a logical
connection is established, the actual physical circuits being allocated according to
route availability, overload conditions, and so on.
virtual terminal: A pseudodevice which connects a process to a physical terminal
device. The virtual terminal can be disconnected from the physical terminal and
reconnected later.
volatile database: A memory image that contains information about network
management components.
window: A range of packets authorized for transmission across an X.25 DTE/DCE
interface. The lowest sequence number in the window is referred to as the lower
window edge (0 when the virtual circuit is just established). The packet send
sequence number of the first data packet not authorized to cross the interface is the
value of the upper window edge (that is, the lower window edge plus the window
size).
X.3: A CCITT recommendation that specifies the packet assembly/disassembly (PAD)
facility in a public data network.
X.25: 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.28: A CCITT recommendation that specifies the DTE/DCE interface for a start-stop
mode DTE accessing the packet assembly/disassembly (PAD) facility in a public
data network situated in the same country.
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.
X.29 terminal:

Glossary-8

A terminal connected to a packet assembly/disassembly (PAD) facility.

Index

A
Access
network* 1-23
remote file* 1-20, 8-1
remote task* 1-23
Access control • 8-10, 8-11
commands* 3-85
default • 2-37
default for inbound connection • 2-40
default nonprivileged • 1-24
default nonprivileged DECnet account *2-39
default privileged* 1-24
for a network*2-35
for an object • 2-30
for inbound connections • 2-38
for logical links*2-37
for network applications* 1-24
for outbound connections • 2-37
for remote command execution • 2-40, 3-88
for remote file access* 1-23
for task-to-task communication* 1-23
for VAX PSI Access software • 3-80
LOGINOUT image*2-37, 8-11
NML, privileges for*3-87
node level *2-40, 3-88
NONPRIVILEGED parameter • 3-87
nonprivileged string *2-37
privileged string *2-37
PRIVILEGE parameter*3-87
proxy login* 1-24, 2-36, 2-41, 3-89
routing initialization • 2-35
setting default information • 3-87
system level *2-37, 3-87
user authorization file (UAF)*8-1 1
Access module
See X.25
ACCESS parameter • 3-88
SET NODE command *2-40
Account
default nonprivileged DECnet* 1-24, 2-39
PSI *3-74
ACNT privilege • 5-2
ACP (ancillary control process) • 5-2, 6-1
ACTIVE
plural form of component name *3-91
ACTIVE BASE parameter • 3-39

Active component*3-91
ACTIVE INCREMENT parameter • 3-39
Address
area number*2-2, 3-7, 3-12, 3-61
broadcast* 1-7
conversion of node address • 2-22, 3-61
DTE *2-5
Ethernet hardware • 2-18, 3-11
Ethernet node *3-11
Ethernet physical* 1-7, 2-18, 3-11
multicast* 1-6, 1-7
node *2-2, 2-22
Phase III node* A-12
Phase IV node* A-12
Address extension facility • 3-76
ADDRESS parameter • 3-4, 3-61
SET EXECUTOR command *3-7
SET NODE command *3-8
Adjacent node* 1-1
on Ethernet • 2-6
ALIAS MAXIMUM LINKS parameter • 3-67
Alias node
See Alias node identifier
Alias node address* 1-11, 2-4, 2-30, 3-9, 8-7
Alias node identifier* 1-11, 2-4, 2-30, 3-9 to
3-10, 8-7
enabling • 3-10
restrictions*2-4, 8-7
setting *3-10
specifying maximum logical links *3-67
use with objects *2-30, 3-71
Alias node name* 1-11, 2-4, 2-30, 3-9
ALL
word in component name *3-2, 6-2
Applications user
function *1-3
Area • 1-2
default number*2-2, 3-7
definition • 2-22
leakage* A-14
number*2-2, 2-21, 2-22, 3-7, 3-61
number in Ethernet address *3-12
partitioning • A-10
path control parameters • 3-65
Area leakage problem* A-14
AREA MAXIMUM COST parameter • 3-65
AREA MAXIMUM HOPS parameter • 3-65

Index—1

Index

Area router

Bootstrap (cont'd.)

See Level 2 router
Area routing* 1-2, 2-20
advantages *2-22
alternate paths *A-3
avoiding problems* A-10
concepts* 2-22
configuration guidelines • A-2
converting to multiple areas* A-8
design considerations* A-1
design redundancy • A-2
dropping area number* A-12
example of configuration procedure • A-5
leakage problem* A-2, A-14
limiting number of areas *3-62
on Ethernet • 2-25, A-15
partitioned area problem* A-10
Phase III node problem* A-12
techniques* A-1
ASSISTANT PHYSICAL ADDRESS parameter*
7-11
ASTLM quota *5-34
Asynchronous circuit

ROM • 4-3
Broadcast address* 1-7, 3-13
Broadcast routing timer *2-27
BROADCAST ROUTING TIMER parameter • 3-66
Buffer size
changing for executor • 3-18
decreasing *3-18
for executor*2-3
for line*3-17, 3-53
increasing *3-18
requirements *3-17
setting for executor • 3-8, 3-17
BUFFER SIZE parameter
for executor • 3-8, 3-17
for line*3-53
BYPASS privilege* 5-2
BYTLM quota *5-34

See Circuit
See DDCMP
Asynchronous connection
DDCMP* 1-8
dynamic* 1-4, 1-7, 1-8
line parameters*3-56
static* 1-4, 1-7, 1-8
Asynchronous line

Call
destination of X.25 call *2-32
DLM incoming and outgoing • 3-45
outgoing from DTE *3-26
Call handler
server module *2-32
CALL MASK parameter
for incoming X.25 calls *3-76
Call redirection facility • 3-77
CALL TIMER parameter • 3-28
CALL VALUE parameter
for incoming X.25 calls *3-76
Carrier Sense Multiple Access with Collision Detect

See DDCMP
See Line
Asynchronous terminal
See X.29 terminal
AUTHORIZE command *5-4
AUTOGEN facility *5-32
AUTO prefix *3-36

B
Babble timer*3-40
Base priority of circuit *3-39
BCUG (bilateral closed user group) *2-6, 3-30,
3-75
Bilateral closed user group
See BCUG
BIOLM quota *5-34
Bootstrap
primary *4-2, 4-13

Index—2

See CSMA/CD
Carrier sense on Ethernet* 1-6
CCITT recommendation* 1-3, 1-12
Channel *8-10
assigning for logical link *8-10, 8-18, 8-29
deassignment of *8-13, 8-17
_NET: • 8-23
Channel, communications* 1-5, 1-7
CHANNEL parameter
for PVC • 3-43
CHANNELS parameter
for DTE *3-26
CHARACTERISTICS display type *3-91
Checkpointing RSX-1 IS tasks*4-20
Cl (computer interconnect)
as DECnet line* 5-7
as VAXcluster connector* 1-10

Index

Cl (computer interconnect) (cont'd.)
as VAXcluster data link* 1-10, 2-25
cable* 1-10
circuit* 2-6
circuit device *2-10
configuration • 1 -4
controller* 2-10
driver • 2-10
end node*2-25
end node backup circuit• 2-25, 3-66
line *2-12
line device*2-17
node addressing • 3-32
router* 2-25
CI-750 device *2-10, 2-12
Cl—780 device *2-10, 2-12
Circuit* 1-1, 1-19
asynchronous DDCMP devices *2-8
Cl *2-6
commands* 3-31
cost *2-26, 3-62
counters* 3-47
database • 3-1
DDCMP* 1-8, 2-6, 3-33
definition • 2-6
determining cost *3-63
device name *3-31
DLM* 1-1, 2-11, 3-33, 3-44
dynamic asynchronous • 2-8
Ethernet* 1-6, 2-6, 3-33
identification *3-31, 3-33
loopback test*7-6
multiaccess* 2-6
multipoint control *2-6
multipoint tributary • 2-6
name • 2-7
parameters *3-33
point-to-point • 2-6
polling • 3-39
service • 4-2
service operations • 3-37
setting base priority • 3-39
state*2-7, 3-36
static asynchronous* 1-9
synchronous DDCMP devices *2-7
timers • 3-37
types *3-33
verification • 3-37
virtual* 1-1, 1-3, 1-6, 1-8
X.25* 2-6, 2-11, 3-33, 3-43
Circuit-level loopback test *7-1
Ethernet* 7-9
CLEAR EXECUTOR command *3-17

CLEAR NODE command • 3-17, 7-3
CLEAR TIMER parameter • 3-28
Closed user group
See CUG
Cluster alias node identifier
See Alias node identifier
CMKRNL privilege *5-2
CNDRIVER • 5-3, 5-7
Code
system service status return *8-17, 8-29
Collision detect
Ethernet* 1-6
Command
NCP command verbs *3-3
NCP functions • 3-3
remote execution of *3-5
syntax • 3-4
Command node *4-1
Command procedure
See also DCL command procedure
for object • 3-72
identification • 3-72
Command terminal, heterogeneous • 8-1
Communication
task-to-task • 1-3, 1-20, 8-1
Component name
plural forms *3-91
Components* 3-1
Computer interconnect
See Cl
Configuration
automatic* 1-17
Cl* 1-4
database
See Configuration database
end node*2-21
Ethernet* 1-4, 1-5
for area routing* A-1
guidelines for area routing* A-2
guidelines for system *5-31 to 5-38
multipoint* 1-4, 1-7
NETCONFIG.COM* 1-17, 5-4 to 5-7
network • 1-4, 5-1
of a DDCMP dynamic asynchronous network*
5-18
of a DDCMP multipoint network *5-15
of a DDCMP point-to-point network *5-13
of a DDCMP static asynchronous network *5-17
of a DECnet-VAX node *1-17
of a DLM (data link mapping) network *5-22
of a multiple-area network* 1-2, A-2
of an Ethernet network *5-21

Index—3

Index

Configuration (cont'd.)

Cost (cont'd.)

of an X.25 multihost mode network*5-26
of an X.25 multinetwork connection • 5-30
of an X.25 native mode network *5-25
of a PSI DTE* 1-16, 1-17, 2-5
of a single-area network* 1-2
point-to-point • 1-4, 1-7
prerequisites* 5-1
procedure examples*5-12 to 5-29
procedure for automatic • 5-4 to 5-7
required privileges* 5-2
routing considerations*2-19
sample Phase IV DECnet-VAX* 1-5
typical VAXcluster* 1-10
VAX PSI* 1-4, 5-1
Configuration database • 2-1, 3-1, 5-4, 5-13
circuit entry • 2-7
DECnet-VAX* 1-17, 3-1
line entry • 2-12
logging entry *2-35
node entry *2-2, 3-4
VAX PSI* 1-17, 3-3
X.25 access module entry *2-6
X.25 protocol module entry *2-5
X.25 server module entry *2-32
Configurator module
disabling surveillance*3-43
enabling surveillance • 3-41
Ethernet* 1-19, 2-10, 3-41
NICONFIG* 1-15
CONNECT NODE command *4-21
PHYSICAL ADDRESS parameter *4-21
SERVICE CIRCUIT parameter • 4-21
SERVICE PASSWORD parameter • 4-21
Connector node
See X.25
CONNECT VIA command *4-21
Control
of line traffic • 3-52
of logical link activity • 2-28, 3-67
of tributaries *3-39
station • 1-7, 2-8
Controller loopback test *7-6, 7-8
Copying node database* 1-17, 2-3, 3-20
COPY KNOWN NODES command *3-20
FROM parameter *3-21
TO qualifier *3-21
USING qualifier • 3-21
WITH CLEAR qualifier • 3-21
WITH PURGE qualifier *3-21
Cost
circuit • 3-62
control for circuit *2-26

determining for circuit *3-63
for routing • 2-25
COST parameter
for circuit *3-62
Counters
circuit *3-47
line *3-59
logging *3-24
node *3-24
X.25 protocol module *3-31
zeroing *3-24
COUNTERS display type *3-91
Counter timer*3-24
COUNTER TIMER parameter
for circuit *3-47
for executor *3-24
for node*3-24
CPU (central processing unit)
identification for downline load *4-12
time requirements*5-35
CSMA/CD • 1-6
CUG (closed user group) *2-6, 3-30, 3-75

Index—4

D
Database
circuit *3-1
clearing or purging before copying node entries*
3-21
configuration
See Configuration database
copying node* 1-17, 2-3, 3-20
DECnet-VAX* 1-17
line • 3-1
logging *3-1
module*3-1, 3-3
node* 3-1
object*3-2, 3-3
permanent* 1-16, 3-2, 5-38
VAX PSI* 1-16, 3-3
volatile* 1-16, 3-2
Data circuit-terminating equipment
See DCE
Datagrams
Ethernet* 1-6
Data link control *2-3, 3-17
Data link mapping
see DLM
Data network* 1-1

Index

Data terminal equipment
See DTE
DCE (data circuit-terminating equipment) • 1-12
DCL command procedure*8-4, 8-37
example for task-to-task operations • 8-37
for starting object *8-37
DCL commands* 1-21
DDCMP (DIGITAL Data Communications Message
Protocol) • 1-4
asynchronous* 1-4, 1-7, 2-8, 2-12, 3-32, 5-8
asynchronous line* 1-5, 3-49
circuit *2-6, 3-31, 3-33
configuration • 1-7
CONTROL line *3-49
DMC line *3-49
dynamic asynchronous network configuration*
5-18
formula for determining maximum number of
messages *3-55
line*2-12, 3-50
MOP *4-14
multipoint* 1-7
multipoint network configuration • 5-15
multipoint tributary addressing • 3-32
POINT line *3-49
point-to-point* 1-7
point-to-point addressing • 3-32
protocol* 1-8
static asynchronous network configuration*
5-17
synchronous* 1-4, 1-7, 2-7, 2-12
synchronous devices* 1-8
synchronous line* 1-5
synchronous point-to-point network
configuration *5-13
TRIBUTARY line *3-49
DEAD THRESHOLD parameter • 3-39
Dead timer*3-54
DECnet-VAX
configuration database* 1-14
configuration on a VAX/VMS system* 1-2
configuration on a MicroVMS system* 1-2
configuration prerequisites • 5-1
functions* 1-3
host services* 1-3, 1-14
over terminal lines *5-7
over the Cl • 5-7
software* 1-15
DECnet-VAX license* 1-15, 2-21
end node kit* 1-15, 6-1
full function kit* 1-15, 6-1
installing the key* 1-15, 5-6, 6-1

DECS A (DIGITAL Ethernet Communications Server)
connection to remote console *4-20
DEFAULT ACCESS parameter • 3-88
SET EXECUTOR command *2-40
DEFAULT DATA parameter
for X.25 circuit *3-27
Default DECnet account
See Default nonprivileged DECnet account
Default nonprivileged DECnet account
creation by NETCONFIG.COM • 5-1, 5-5
example* 5-1
use in access control • 2-39, 3-87
DEFAULT PROXY parameter • 3-89
SET EXECUTOR command *2-41
DEFAULT WINDOW parameter
for X.25 circuit *3-27
DEFINE EXECUTOR command
TYPE parameter *3-60
DEFINE NODE command *5-4
Delay timer • 3-54
DELUA
See UNA
DELUA communications controller*2-18, 3-11
DEQNA
See QNA
DEQNA communications controller* 1-6, 2-18,
3-11
Designated router
See Ethernet
Destination
of X.25 call *2-32
DESTINATION qualifier • 3-74
DETACH privilege*5-2
DEUNA
See UNA
DEUNA communications controller* 1-6, 2-18,
3-11
Device
CI-750*2-10, 2-12
Cl—780* 2-10, 2-12
DHU11 asynchronous • 2-8, 2-12
DHV11 asynchronous • 2-8, 2-12
DMC1 1 • 1-8, 2-7, 2-12
DMF32 • 1-8, 2-7, 2-12
DMF32 asynchronous *2-8, 2-12
DMP1 1 • 1-8, 2-7, 2-12
DMR11 • 1-8, 2-7, 2-12
DM VI 1*2-7
DMZ32 asynchronous*2-8, 2-12
DPV1 1*2-18
DUP11-DA *2-18
DZ1 1 • 1-8

Index—5

Index

Device (cont'd.)

Downline system load (cont'd.)

DZ11 asynchronous *2-8, 2-12
DZ32 asynchronous*2-8, 2-12
DZV11 asynchronous*2-8, 2-12
KMS11-BD* 2-18
KMS1 1-PX *2-18
KMS1 1-PY *2-18
KMV1 1*2-18
KMY *2-18
QNA *2-10, 2-18
UNA *2-10, 2-18
DHU1 1 asynchronous device *2-8, 2-12
DHV11 asynchronous device *2-8, 2-12
DIAGNOSE privilege*5-2
Dialup line* 5-8
DIGITAL Network Architecture
See DNA
DIOLM quota *5-34
Disconnect • 8-13
abort *8-13, 8-28
synchronous *8-13
DISCONNECT LINK command *3-67
Display type
CHARACTERISTICS • 3-91
COUNTERS *3-91
EVENTS *3-91
STATUS *3-91
SUMMARY *3-91
DLM (data link mapping)* 1-1, 1-3, 1-12
circuit* 1-1, 2-7, 2-11, 3-33
CIRCUIT parameters *3-44
incoming and outgoing calls *3-45
network configuration • 5-22
OWNER EXECUTOR circuit parameter*3-45
setting up a circuit *3-47
subaddresses • 3-46
DMC11 device* 1-8, 2-7, 2-12
DMF32 asynchronous device *2-8, 2-12
DMF32 device* 1-8, 2-7, 2-12
DMP11 device* 1-8, 2-7, 2-12
DMR11 device* 1-8, 2-7, 2-12
DM V11 device *2-7
DMZ32 asynchronous device *2-8, 2-12
DNA (DIGITAL Network Architecture)
layers* 1-4
protocols* 1-4
Downline system load
default loader files *4-13
definition *4-1
load requirements *4-5
load sequence *4-4
network example *5-13

operator-initiated *4-1, 4-5
over DDCMP circuit *4-6
over Ethernet *4-2, 4-6
target-initiated • 4-2
unattended systems *4-1
Downline task load *4-16
DPV11 device *2-18
DTE (data terminal equipment)* 1-12, 2-5
address* 2-5
bringing up *6-2
configuration* 1-16, 1-17, 2-5, 6-2
definition *2-1
handling incoming calls *2-33
handling outgoing calls *3-26
subaddress *3-75
DTE parameter
for GROUP *3-30
for PVC*3-43
DTE qualifier
CHANNELS parameter • 3-26
LINE parameter*3-26
MAXIMUM CIRCUITS parameter • 3-26
SET MODULE X25-PROTOCOL command *3-25
STATE parameter*3-25
DTR (DECnet Test Receiver) • 2-29
DUMP ADDRESS parameter *4-14
Dump assistance multicast address *4-15
DUMP COUNT parameter *4-14
DUMP FILE parameter *4-14
Dumping unattended system memory *4-14
DUP11-DA device *2-18
Duplex mode *3-54
DUPLEX parameter *3-54
DYING BASE parameter • 3-39
DYING INCREMENT parameter • 3-39
DYING THRESHOLD parameter • 3-39
Dynamic allocation of map registers and device
drivers* 5-36
Dynamic asynchronous circuit *2-8
VERIFICATION INBOUND parameter • 3-38,
3-86
Dynamic asynchronous connection* 1-4, 1-7
network configuration • 5-18
password • 2-36
reasons for failure *5-11
Dynamic asynchronous line* 1-9, 2-14, 5-8
HANGUP parameter*3-56
installing *5-10
LINE SPEED parameter*3-56
shutting down *5-12
SWITCH parameter • 3-56

Index—6

Index

Dynamic switching

Ethernet (cont'd.)

manual switching of line *2-17
procedure for line *2-14
setting up lines • 5-10
DYNSWITCH image*2-16
installing *5-10
DZ1 1 asynchronous device *2-8, 2-12
DZ1 1 device* 1-8
DZ32 asynchronous device *2-8, 2-12
DZV11 asynchronous device *2-8, 2-12

downline system load *4-6
dump assistance multicast address *4-15
end node* 1-7, 2-24, 3-40
end node caching *2-24
hardware address• 2-18, 3-1 1, 3-57, 7-9
limiting end nodes *3-62
limiting routers *3-61
line* 2-12
line device*2-18
line parameters*3-57
line protocol • 3-49
multiaccess* 1-6
multicast address* 1-7, 2-3
multicast address definition • 3-13
multicast address values *3-13
network configuration • 5-21
node* 1-6
node address *2-2, 3-1 1
node number in address *3-12
non-DECnet application • A-10
packets* 1-6
physical address* 1-7, 2-2, 2-7, 2-18, 3-11,
4-6, 7-9
physical address definition • 3-13
physical address values *3-13
protocol • 1-5, 2-7
resetting physical address *3-1 1
router* 1-7, 2-24, 3-40
service operations • 3-36
specification • 1-5
topology* 1-6
upline memory dump *4-15
Ethernet loopback test *7-9
to remote system • 7-9
UNA device • 7-9
Event
class • 3-82
definition • 2-34
identification • 3-82
identifying location of *3-83
list *2-34
sink-related • 2-34
source* 3-83
source-related • 2-34
type • 3-82
Event logger

E
End node* 1-1, 1-15
caching on Ethernet • 2-24
configuration • 2-21
DECnet-VAX license kit* 1-15, 6-1
definition *2-19
Ethernet* 1-7, 2-24
non-Ethernet* 1-7
on VAXcluster* 1-11
Phase IV *2-21
ENQLM quota • 5-34
Error messages
HLD *4-19
loopback testing • 7-6
Error reporting• 8-17, 8-29
system service status*8-17, 8-29
Ethernet* 1-5
address conversion • 3-61
address format *3-1 1
adjacent node *2-7
area number in address *3-12
area routing on*2-25, A-15
broadcast address* 1-7, 2-3
broadcast routing timer *3-66
cable* 1-6
carrier sense* 1-6
characteristics* 1-6
circuit* 1-4, 1-6, 2-6, 3-33
circuit device* 1-6, 2-10
circuit identification • 3-33
circuit parameters • 3-40
configuration • 1-4, 1-5
configurator module* 1-15, 1-19, 2-10, 3-41
datagrams* 1-6
data link for VAXcluster* 1-10
data rate • t -6
designated router* 1-7, 2-19, 2-24, 3-40
determining physical address *3-12
displaying physical address *3-12

See EVL
Event logging example *3-84
EVENTS display type *3-91
EVL (event logger) • 1-15, 2-29, 2-34

Index—7

Index

Executor node *2-2, 4-1
commands* 3-5

F
FAL (file access listener)* 1-15, 2-29
File
default access control* 1-23
logical name in specification* 1-25
manipulation over the network* 1-20
specification • 1-23
specification access control string* 1-23
specification over the network* 1-23
File access
over network* 1-3
remote* 1-20
File access listener* 1-15, 2-29
FILE parameter
for DECnet-VAX command procedure • 3-73
FILLM quota *5-34
Frame control
X.25 lines*3-57
FROM parameter
COPY KNOWN NODES command *3-21

G
Gateway node
See X.25
GROUP parameter
for X25-SERVER module *3-75
GROUP qualifier
DTE parameter • 3-30
for X25-PROTOCOL module *3-30
NUMBER parameter • 3-30
TYPE parameter*3-31
Guidelines
system configuration • 5-31 to 5-38

H
HANGUP parameter • 3-56
Hardware address
Ethernet *3-11
HARDWARE ADDRESS parameter
SET NODE command *4-8
Hardware loopback device *7-6

Index—8

Hello timer *3-37
HELP parameter
LOOP CIRCUIT command *7-11
Heterogeneous command terminal* 1-3, 1-21,8-1
Heterogeneous network
remote file operations*9-1
Higher-level language statements* 1-21
HLD (host loader)* 1-16, 2-29, 4-16
mapping table *4-18
HLDTBS *4-18
HNODE$ *4-18
Hop *2-25
Host identification
for downline task load *4-10
Host loader
See HLD
Host node
for X.25 connection* 1-3, 3-78, 3-79
Host services
DECnet-VAX* 1-3, 1-14, 4-1
on Ethernet *2-3
HTASKS *4-18

i
IAS node • 9-2
Identification
of circuits*3-31
of events *3-82
of lines *3-48
of network *3-25
of node address *2-2, 3-7
of node name *2-2, 3-7
of objects *3-70
of X.25 connector node *3-80
IDENTIFICATION parameter
for local node*3-8
INACTIVE BASE parameter • 3-39
INACTIVE INCREMENT parameter*3-39
INACTIVE THRESHOLD parameter • 3-39
INACTIVITY TIMER parameter • 3-68
Inbound logical link connection* 1-24
INBOUND parameter
SET NODE command *3-89
Incoming calls to a DTE *2-33
INCOMING TIMER parameter • 3-68
Initialization
of DDCMP node* 1-8
of Ethernet node* 1-6
of Phase III node*2-36, A-14

Index

Installation
network* 6-1
VAX PSI • 6-2
IRPCOUNT parameter* 5-32
ISO networks • 3-30

K
Key
DECnet-VAX license* 1-15, 2-21
KMS11
dumping microcode* 7-13
KMS1 1-BD device *2-18
KMS11-PX device *2-18
KMS11-PY device *2-18
KMS/KMV DUMP Analyzer
See PSIKDA
KM VI 1
dumping microcode • 7-13
KM V11 interface *2-18
KMY interface *2-18
KNOWN
plural form of component name *3-91

L
LAN (local area network)
Ethernet* 1-4
LAPBE line
See X.25 line
LAPB line
See X.25 line
LCN (logical channel number) *3-26
LEF (local event flag) state *8-16
Level 1 router* 1-2, 2-19, 2-21, A-1
Level 2 router* 1-2, 2-19, 2-21, A-1
subnetwork • A-3
LIB$ASN_WTH_MBX library routine• 8-1 1, 8-23
License
See DECnet-VAX license
Line* 1-1
asynchronous DDCMP devices *2-12
buffers for DDCMP line *3-54
buffer size • 3-53
Cl• 2-12
commands • 3-48
counters* 3-59
database* 3-1

Line (cont'd.)
DDCMP *2-12
definition *2-11
device name *3-48
dialup* 5-8
dynamic asynchronous* 1-9, 2-14, 5-8
dynamic switching • 2-14
Ethernet *2-12, 3-57
identification • 3-48
installing dynamic asynchronous • 5-10
installing static asynchronous • 5-8
LAPB *3-49
LAPBE *3-49
multipoint* 2-13
name *2-12
operational state *3-52
parameters* 3-50
point-to-point *2-13
protocol • 3-49
state *2-12
static asynchronous* 1-9, 2-14, 5-8
synchronous DDCMP devices *2-12
terminal* 1-9
timers *3-54
types *3-50
X.25*2-12
LINE parameter
for DTE *3-26
LINE SPEED parameter *3-56
Link
See Logical link
LIST command *3-90
Load assistance multicast address *4-2
Load file identification
for downline load *4-10
LOAD NODE command *4-2, 4-7
HOST parameter *4-10
overriding default parameters • 4-9
SECONDARY LOADER parameter • 4-12
SERVICE DEVICE parameter *4-13
SERVICE PASSWORD parameter • 4-13
SOFTWARE IDENTIFICATION parameter • 4-12
SOFTWARE TYPE parameter *4-12
TERTIARY LOADER parameter • 4-12
LOAD VIA command *4-7
PHYSICAL ADDRESS parameter• 4-8, 4-13
SERVICE DEVICE parameter*4-13
Local area network
See LAN
Local loopback test *7-5
Local node* 1-14, 1-20, 2-2, 3-5
operational state *3-20
restrictions* 6-3
Index—9

Index

Local node (cont'd.)

Logical name (cont'd.)

setting address *3-7
states* 6-3
Local-to-local loopback test *7-4
Local-to-remote loopback test *7-3
Logging* 1-19, 2-34
commands *3-80
console*2-35, 3-81
database* 3-1
file *2-35, 3-81
monitor• 2-35, 3-81, 3-84 to 3-85
parameters* 3-80
sink *2-35, 3-81
state *3-83
Logical channel number

use in network application* 1-25
LOGINOUT image*2-37, 2-39, 8-11, 8-26
Loopback
assistance* 7-11
connector* 7-6
Loopback mirror *7-2
Loopback test
circuit • 7-6
circuit-level • 7-1
controller* 7-6, 7-8
local node*7-5
local-to-local* 7-4
local-to-remote • 7-3
node-level • 7-1
over Ethernet circuit *7-9
software*7-6, 7-7
to a remote node *7-2
using a loop node name *7-2
X.25 line-level *7-12
LOOP CIRCUIT command *7-6
ASSISTANT NODE parameter • 7-1 1
ASSISTANT PHYSICAL ADDRESS parameter*
7-11
HELP parameter* 7-11
NODE parameter*7-10
PHYSICAL ADDRESS parameter* 7-10
LOOP EXECUTOR command *7-5
LOOP LINE command
COUNT parameter* 7-13
LENGTH parameter*7-13
WITH parameter*7-13
LOOP NODE command *7-2
CIRCUIT parameter* 7-2
Loop node name *7-2
LRPCOUNT parameter*5-32
LRPSIZE parameter*5-32

See LCN
Logical link* 1-1, 1-19, 8-7, 8-9, 8-10, 8-13, 8-16
aborting • 8-9, 8-28
access control information* 1-24
assigning channel for*8-16, 8-29
commands* 3-66
completing connection of*8-1 1, 8-16, 8-26,
8-31
control • 2-28
controlling activity • 3-67
default access control information* 1-24
definition • 2-27
disconnecting • 2-28, 3-67, 8-9, 8-13, 8-28,
8-34
handshaking sequence*8-10
inactivity timer *2-28
inbound* 1-24, 3-67
incoming timer *2-28
maximum number *2-28, 3-67
outbound* 1-24, 3-67
outgoing timer *2-28
parameters* 2-28
protocol operation • 2-28
protocol parameters*3-67
rejecting a request *8-32
requests*8-7, 8-10, 8-11, 8-16, 8-24, 8-26,
8-30
retransmission delay *2-28
retransmission time *2-28
SYS$NET *8-11
terminating • 8-9, 8-13, 8-17, 8-21, 8-29
timers *3-68
Logical name
as device name* 1-25
as node name* 1-25
in process logical name table* 1-25
translation • 1-25

Index—10

M
MACRO programs
in network application* 1-21
Mailbox *8-7, 8-23, 8-24
creation of using SYSSCREMBX • 8-23
message format • 8-24
MAIL object *2-4, 2-29, 2-30, 3-71
Maintenance operation protocol
See MOP
Maintenance operations over the network *4-1
MAXIMUM ADDRESS parameter • 3-8

Index

MAXIMUM AREA parameter*3-62
MAXIMUM BLOCK parameter
for X.25 line*3-58
MAXIMUM BROADCAST NONROUTERS
parameter
for Ethernet circuits • 3-62
MAXIMUM BROADCAST ROUTERS parameter
for Ethernet circuits*3-62
Maximum buffers
for executor • 3-19
MAXIMUM BUFFERS parameter*3-19, 3-40
MAXIMUM CIRCUITS parameter
for DTE *3-26
for executor node *3-19
for X.25 server module*3-78
MAXIMUM CLEARS parameter • 3-28
MAXIMUM COST parameter • 3-64
MAXIMUM DATA parameter
for PVC • 3-44
for X.25 lines*3-57
for X.25 virtual circuit*3-27
MAXIMUM HOPS parameter • 3-64
MAXIMUM LINKS parameter • 3-67
MAXIMUM RECALLS parameter • 3-45
MAXIMUM RESETS parameter • 3-29
MAXIMUM RESTARTS parameter• 3-29
MAXIMUM RETRANSMIT parameter • 3-57
MAXIMUM ROUTERS parameter • 3-41
for an Ethernet circuit *3-61
MAXIMUM TRANSMITS parameter • 3-40
Maximum visits *2-26
MAXIMUM VISITS parameter• 3-64
MAXIMUM WINDOW parameter
for PVC *3-44
for SVC *3-27
for X.25 line*3-58
Memory pool *5-32
Memory requirements
normal • 5-32
worst-case • 5-34
Message*8-7, 8-12, 8-19, 8-20
data *8-12
exchanging* 8-12, 8-17, 8-27
interrupt• 8-7, 8-27
mailbox* 8-7, 8-12
network status *8-7
optional user data *8-7, 8-10, 8-21
Microcode* 1-8
dumping KMS11*7-13
dumping KMV1 1*7-13
MICROCODE DUMP parameter • 7-13

MicroVMS system
as DECnet-VAX node* 1-2, 5-3
MIRROR (loopback mirror)* 1-16, 2-29
Mixed Phase Ill/Phase IV network* A-12
Modem *5-8, 7-6
Module* 1-19
database *3-1
Ethernet configurator* 1-19, 2-10, 3-41
X.25 access* 1-19, 2-34, 3-79
X.25 protocol* 1-19, 3-24
X.25 server* 1-19, 2-32, 3-74
X.25 trace* 1-19
X.29 server* 1-19, 2-32, 3-74
MOM subprocess of NML*4-2
Monitor Utility (MONITOR) • 5-34
MOP (maintenance operation protocol) • 4-2, 4-14
error recovery *4-5
request memory dump message *4-14
Multiaccess
circuit • 2-6
Ethernet* 1-6
Multicast address* 1-6, 1-7
broadcast *3-13
dump assistance *4-15
Ethernet *3-13
group *3-13
load assistance *4-2
Multihost connector node
See X.25
Multinetwork configuration • 5-30
Multiple-area network* 1-2
conversion to* A-8
design of • A-2
example of configuration • A-5
example of design* A-3
Multiple inbound connects• 8-7, 8-27, 8-36
Multipoint
circuit • 2-8
configuration • 1-4, 1-7, 5-15
control circuit *2-6
control station *2-8
line* 2-13
polling • 2-8
tributary • 2-8
tributary address *2-8, 3-32
tributary circuit *2-6

N
NAME parameter
identifying logging device *3-81

Index—11

Index

NAME parameter (cont'd.)

Network (cont'd.)

SET NODE command *3-7
NCB (network connect block) *3-71, 8-10, 8-24
destination descriptor • 8-25
for incoming X.25 call *2-33
NCP (Network Control Program)* 1-14, 1-16
command functions • 3-3
commands* 1-14
command syntax *3-4
command words *3-3
definition • 3-3
invalid grouping error message *3-16
LIST command *3-90
SHOW command *3-90
specifying plural components • 3-4, 3-91
tailoring the configuration database *5-7
TELL prefix *3-6
users* 1-14
using commands *3-1
_NET: • 8-23, 8-29
NETACP (network ancillary control program)*
1-16, 5-35
NETCONFIG.COM *1-17, 3-2, 5-4 to 5-7
creation of default nonprivileged DECnet
account* 5-1
supplying node address *5-5
NETDRIVER (network driver) • 1-16, 5-35
NETMBX privilege *2-38, 5-2
NETNODE_LOCAL.DAT • A-8
NETNODE_REMOTE.DAT • A-8
NETSERVER
See Network server process
NETSERVER.LOG *4-19
NETSERVERSTIMEOUT • 2-30
NETUAF.DAT*2-37, 2-41
Network
access control *2-35
access levels* 1-21
bringing up *6-1
configuration* 1-4, 5-1
conversion to multiple-area network* A-8
CPU time requirements • 5-35
decentralized • 1-2
displaying • 8-1
example* 1-17
identification • 3-25, 3-59
ISO *3-30
limiting number of areas *3-62
monitoring • 3-90
multinetwork • 5-30
multinode* 1-2
multiple-area • 1-2
multiple-area configuration • A-2

normal memory requirements • 5-32
object • 3-2
passwords* 2-39
restrictions on mixed *2-20, A-12
security • 2-39
shutting down *6-2
terminal • 3-81
testing • 7-1
topology* 1-17
user interface to* 1-20
user operations* 1-20, 8-1
worst-case memory requirements • 5-34
Network configuration procedure • 5-12 to 5-29
Network connect block
See NCB
Network Control Program

Index—12

See NCP
Network driver
See NETDRIVER
Network Information and Control Exchange
See NICE
Network interface
VAX/VMS operating system* 1-2
Network management
functions* 1-3
responsibilities* 1-14
Network name
declaring • 8-26, 8-36
Network process failures
potential causes *2-31
NETWORK qualifier
for X.25 access module *3-79
Network server process *2-30
Network Services Program
See NSP
Network task
declaring • 8-7, 8-11, 8-26
NICE (Network Information and Control Exchange)*
3-3
NICONFIG (Ethernet Configurator)* 1-15
NML (network management listener)* 1-16, 2-29,
6-1

access control *3-87
Node* 1-1, 1-19, 3-7
address*2-2, 2-22, 3-7, 3-61, A-12
address conversion • 3-61
addressing Cl node *3-32
adjacent* 1-1, 2-20
alias node identifier
See Alias node identifier
area number *2-2

Index

Node (cont'd.)
automatic configuration • 5-4
bringing up DECnet-VAX node *6-1
changing local address *3-9
checking type* 1-9, 2-42, 3-89
clearing or purging database before copying
3-21
commands • 3-4
configuring for DECnet-VAX* 1-17
conversion of Phase IV address *2-22
copying database* 1-17, 2-3, 3-20
counters* 3-24
database* 3-1
default access account* 1-24
definition • 2-1
displaying network *8-1
display of type *3-60
end node* 1-1, 2-19
Ethernet address *2-2, 3-1 1
executor*2-2, 3-5
identification • 2-2, 2-22, 3-7
initialization request *3-38
local node* 1-14, 1-20, 2-2, 3-5
logical name in file specification* 1-25
name*2-2, 3-7
non-Ethernet* 1-7
nonrouting • 2-20
number*2-2, 2-22, 3-7
number in Ethernet address *3-12
parameters • 2-3, 3-14
phases *2-20
reachable *2-25
remote *3-38
remote node* 1-14, 1-20, 2-2, 3-5
removing remote name and address *3-9
routing* 1-1, 2-19, 2-20
shutting down DECnet-VAX node *6-2
specification access control string* 1-23
specification string for node* 1-23
state *2-3, 3-20
type *2-20, 3-60
X.25 connector* 1-3
X.25 host* 1-3
Node-level access control *2-40
Node-level loopback test *7-1
logical link operation • 7-1
over specific circuit *7-1
NODE parameter*7-9
for X.25 host node*3-78
identifying X.25 connector• 3-80
NODRIVER*2-14, 5-3, 5-7
Nonpaged dynamic memory pool *5-32

Nonprivileged access control string *2-37
Nonrouting node
See End node
Nontransparent
communication* 1-23
user network operations* 1-20
Nonzero object *2-29
NPAGEDYN parameter • 5-32
NSP (Network Services Program)
message retransmission • 2-28, 3-68
receive buffers *3-17
NUMBER parameter
for DECnet objects *3-70
for DLM circuit *3-45
for GROUP *3-30

o
Object *1-19
access control *2-30
addressing • 2-29
command procedure for DECnet-VAX • 2-29,
3-72
command procedure for PSI*2-32
commands *3-70
database *3-2
DECnet-VAX *2-29
definition • 2-28
identification • 3-70, 3-73
name*2-28, 3-70
network • 2-28, 3-2
nonzero*2-29, 3-70
number*8-26, 8-36
parameters* 3-70
proxy login access *2-42
PSI account information • 2-32
TASK *2-29, 3-70
type *2-28, 8-10
type number*2-29, 3-70
user-defined • 2-28
use with alias node identifier • 2-30, 3-71
VAX PSI *2-28, 2-32, 3-73
zero-numbered • 2-29, 3-70
OBJECT parameter • 3-78
OPCOM (Operator Communication Facility) • 2-35,
3-81, 6-3
Operational state
of circuit • 3-36
of lines *3-52

Index—13

Index

Operator Communication Facility
See OPCOM
Operator-initiated downline load *4-1, 4-5
OPER privilege • 5-2
Outbound logical link connection* 1-24
Outgoing call
from DTE *3-26
OUTGOING TIMER parameter • 3-68
Overlaying RSX-1 IS tasks*4-20
OWNER EXECUTOR parameter
for DLM circuit *3-45

p
P/OS node*9-5
Packet assembly/disassembly facility
See PAD
Packet size parameters • 3-27
Packet switching data network
See PSDN
PAD (packet assembly/disassembly facility)* 1-3,
3-76
Partitioned area problem* A-10
example of • A-1 1
Password
for dynamic connection • 2-36, 2-42
receive*2-36, 3-86
routing initialization* 1-9, 2-20, 2-36, 3-86,
A-14
transmit • 2-36, 3-86
Path *2-25
Path control parameters • 3-64
for areas • 3-65
Permanent database* 1-16, 3-2, 5-38
considerations • 5-38
copying node entries *3-21
Permanent virtual circuit
See PVC
Phase III node*2-20
in Phase IV network* A-12
restrictions* A-12
Phase II node*2-20
Phase IV
end node *2-21
node* 2-20
node address *2-22
router • 2-21
PHONE object *2-4, 2-29, 2-30, 3-71
Physical address
Ethernet* 1-7, 3-1 1, 3-13

Index—14

PHYSICAL ADDRESS parameter
for LOOP CIRCUIT command *7-9
for TRIGGER command *4-6
Pipeline quota *2-28, 3-69
PIPELINE QUOTA parameter
SET EXECUTOR command *3-69
Point-to-point
circuit* 2-6
configuration • 1-4, 1-7, 5-13
DDCMP addressing • 3-32
line* 2-13
security for connection • 2-42, 3-86
Polling* 1-7, 2-8
POLLING STATE parameter • 3-39
Primary loader *4-2
PRIORITY parameter*3-77
Privilege
ACNT • 5-2
BYPASS *5-2
CMKRNL* 5-2
DETACH *5-2
DIAGNOSE *5-2
for access control *2-37
for network operations • 5-2
NETMBX • 2-38, 5-2
OPER *5-2
required for NCP commands*2-39
SECURITY *5-2
SYSNAM • 5-2
SYSPRV • 5-2
TMPMBX • 2-38, 5-2
to configure network *5-2
to issue CLEAR ALL or PURGE command *2-39
to issue SET ALL or DEFINE command *2-39
to modify permanent database • 2-39
to modify volatile database • 2-39
to start the network *2-39
Program load request *4-2
over Ethernet *4-2
Programming language
in network application* 1-21
selecting for network operation* 1-22
Protocol module
See X.25
PROTOCOL parameter*3-49
Protocols* 1-4
Proxy
access* 2-41
access display for executor • 3-89
access display for object *3-90
access file specification • 3-89
account* 2-41

Index

Proxy (cont'd.)
login • 2-41
Proxy login
access control* 1-24, 2-41
access control commands • 3-89
account* 2-41
control • 2-41
DEFAULT PROXY parameter • 2-41
enabling access *2-41
NETUAF.DAT *2-41
PROXY parameter* 2-42
PROXY parameter*3-89
SET OBJECT command *2-42
PSDN (packet switching data network)* 1-1, 1-3,
1-4, 1-12, 2-5
identification • 3-79
installation • 6-2
PSIACP (PSI ancillary control process)* 1-16
PSI ancillary control process
See PSIACP
PSIKDA
KMS/KMV Dump Analyzer* 7-13
PURGE EXECUTOR command *3-17
PVC (permanent virtual circuit)* 1-12, 2-7, 2-11
parameters *3-43

Q
QNA
Ethernet circuit device *2-10
Ethernet line device *2-18
Quota
pipeline • 2-28, 3-69

R
RCF (remote console facility)
error messages • 4-21
invoking • 4-21
Reachable node *2-25
RECALL TIMER parameter • 3-45
Receive buffers *3-17
RECEIVE BUFFERS parameter
for DDCMP line *3-54
for X.25 line *3-59
Receive password • 2-36
Remote command execution • 3-5
Remote console connection • 4-20
Remote file access* 1-20, 8-1

Remote file operations
general DECnet-VAX restrictions • 9-1
heterogeneous network *9-1
VAX/VMS to VAX/VMS
Version 4.4 to previous version *9-24
Version 4 to Version 3*9-23
VAX/VMS to IAS *9-2
VAX/VMS to P/OS *9-5
VAX/VMS to RSTS/E • 9-6
VAX/VMS to RSX (using FCS-based FAL)*
9-1 1
VAX/VMS to RSX (using RMS-based FAL) *9-9
VAX/VMS to RT-1 1*9-14
VAX/VMS to TOPS-10*9-17
VAX/VMS to TOPS-20* 9-20
Remote node* 1-14, 1-20, 2-2, 3-5
copying database • 2-3, 3-20
loopback test • 7-2
setting name and address *3-7
RESET TIMER parameter • 3-29
Responsibilities of system manager* 1-14
RESTART TIMER parameter • 3-29
Retransmit timer *3-54
formula for*3-55
RMS calls* 1-21
Router* 1-1, 1-15, 3-40, 6-1
area* 1-2, 2-21
definition *2-19
designated* 1-7, 2-19, 2-24
Ethernet* 1-7, 2-24
level 1 • 1-2, 2-19, 2-21, A-1
level 2* 1-2, 2-19, 2-21, A-1
on VAXcluster* 1-11
Phase IV *2-21
redundant level 2 routers *A-3
ROUTER PRIORITY parameter*3-41
Route-through control *3-64
Routing *2-19
area • 1-2
broadcast message timer *2-27
commands *3-60
concepts *2-25
configuration considerations *2-19
control parameters • 3-62
cost • 2-25
definition *1-1
hop* 2-25
initialization passwords • 2-20, 2-36, 2-42,
3-86, A-14
maximum visits *2-26
message• 2-27, 3-65
message timer *2-27

Index—15

Index

Routing (cont'd.)

Service (cont'd.)

parameters* 2-25
path *2-25
path control parameters*3-64
path cost *2-25
path length*2-25
reachable node *2-25
route-through control parameters*3-64
segmented message *2-27
setting configuration limits *3-61
timer* 3-65
timing of messages • 2-27
verification • 3-37
Routing initialization password* 1-9
Routing node *2-19

operations for circuit *3-37
password for downline load *4-13
SERVICE CIRCUIT parameter *4-6
SERVICE DEVICE parameter *4-13
Service timer *3-54
SET CIRCUIT command
CHANNEL parameter*3-43
COST parameter *3-62
COUNTER TIMER parameter • 3-47
DTE parameter *3-43
MAXIMUM BUFFERS parameter • 3-40
MAXIMUM DATA parameter • 3-44
MAXIMUM RECALLS parameter • 3-45
MAXIMUM ROUTERS parameter • 3-41, 3-61
MAXIMUM TRANSMITS parameter • 3-40
MAXIMUM WINDOW parameter • 3-44
NUMBER parameter*3-45
OWNER EXECUTOR parameter • 3-45
polling control parameters • 3-39
POLLING STATE parameter • 3-39
RECALL TIMER parameter • 3-45
ROUTER PRIORITY parameter • 3-41
SERVICE parameter*3-37, 4-5, 4-15
STATE parameter*3-36, 4-15
TRIBUTARY parameter • 3-32
TYPE parameter*3-43
USAGE parameter*3-43, 3-46
VERIFICATION INBOUND parameter • 3-38,
3-86
VERIFICATION parameter• 3-37
SET EXECUTOR command
ADDRESS parameter*3-7, 3-61
ALIAS INCOMING parameter*3-10
ALIAS MAXIMUM LINKS parameter • 3-67
ALIAS NODE parameter • 3-10
AREA MAXIMUM COST parameter • 3-65
AREA MAXIMUM HOPS parameter • 3-65
BROADCAST ROUTING TIMER parameter • 3-66
BUFFER SIZE parameter*3-8, 3-17
COUNTER TIMER parameter • 3-24
DEFAULT ACCESS parameter • 2-40, 3-88
DEFAULT PROXY parameter*2-41, 3-89
DELAY FACTOR parameter • 3-68
DELAY WEIGHT parameter • 3-68
IDENTIFICATION parameter • 3-8
INACTIVITY TIMER parameter • 3-68
INCOMING TIMER parameter • 3-68
local node address *3-7
MAXIMUM ADDRESS parameter • 3-8
MAXIMUM AREA parameter • 3-62
MAXIMUM BROADCAST NONROUTERS
parameter* 3-62

See Router
Routing timer *2-27
RSTS/E node *9-6
RSX-1IS
checkpointing tasks *4-20
downline load of system *4-1
NETGEN procedure • 4-16
overlaying tasks *4-20
task load *4-16
RSX node *9-9, 9-11
RT—11 node *9-14

s
Satellite Loader
See SLD
Satellite transmission control *3-55
Scheduling timer *3-54
Secondary loader*4-5, 4-10
SECONDARY LOADER parameter • 4-12
Security
for dynamic asynchronous connection* 1-9
for point-to-point connection • 2-42, 3-86
protecting network configuration files *2-39
SECURITY privilege *5-2
SEGMENT BUFFER SIZE parameter
for executor *3-18
SENDING ADDRESS parameter
for DTE *3-75
Server module
See X.25 server module and X.29 server
module
Service
circuit identification for downline load *4-13
device identification for downline load *4-13

Index—16

Index

SET EXECUTOR command (cont'd.)
MAXIMUM BROADCAST ROUTERS parameter*
3-62
MAXIMUM BUFFERS parameter • 3-19

SET MODULE X25-ACCESS command (cont'd.)
PASSWORD parameter*3-80
USER parameter • 3-80
SET MODULE X25-PROTOCOL command *3-24

MAXIMUM CIRCUITS parameter • 3-19

CALL TIMER parameter • 3-28

MAXIMUM COST parameter • 3-64

CLEAR TIMER parameter • 3-28

MAXIMUM HOPS parameter • 3-64

DEFAULT DATA parameter • 3-27

MAXIMUM LINKS parameter • 3-67

DEFAULT WINDOW parameter• 3-27

MAXIMUM VISITS parameter • 3-64

DTE qualifier*3-25

OUTGOING TIMER parameter*3-68

GROUP qualifier*3-30

PIPELINE QUOTA parameter • 3-69

MAXIMUM CLEARS parameter • 3-28

RETRANSMIT FACTOR parameter • 3-68

MAXIMUM DATA parameter • 3-27

ROUTING TIMER parameter • 3-65

MAXIMUM RESETS parameter • 3-29

SEGMENT BUFFER SIZE parameter*3-18

MAXIMUM RESTARTS parameter • 3-29

STATE parameter*3-20, 6-2

MAXIMUM WINDOW parameter• 3-27

SUB ADDRESSES parameter • 3-46

RESET TIMER parameter • 3-29

SET EXECUTOR NODE command *3-5

RESTART TIMER parameter • 3-29

access control information • 3-88

SET MODULE X25-SERVER command

SET HOST command
heterogeneous command terminal* 1-21, 8-2
SET LINE command
BUFFER SIZE parameter• 3-17, 3-53

CALLED ADDRESS parameter• 3-77
CALLED DTE parameter• 3-77
CALL MASK parameter • 3-76
CALL VALUE parameter • 3-76

CONTROLLER parameter • 7-12

DESTINATION qualifier • 3-74

DUPLEX parameter*3-54

EXTENSION MASK parameter • 3-76

INTERFACE parameter • 3-59

EXTENSION VALUE parameter • 3-76

MAXIMUM BLOCK parameter • 3-58

GROUP parameter*3-75

MAXIMUM DATA parameter• 3-57

INCOMING ADDRESS parameter• 3-77

MAXIMUM RETRANSMIT parameter• 3-57

MAXIMUM CIRCUITS parameter• 3-78

MAXIMUM WINDOW parameter • 3-58

NODE parameter*3-78

MICROCODE DUMP parameter*7-13

OBJECT parameter*3-78

PROTOCOL parameter*3-49, 3-50

PRIORITY parameter*3-77

RECEIVE BUFFERS parameter • 3-54

RECEIVING DTE parameter• 3-77

SERVICE TIMER parameter• 4-5, 4-15

REDIRECT REASON parameter• 3-77

STATE parameter*3-53, 7-12

SENDING ADDRESS parameter• 3-75, 3-77

TRANSMIT PIPELINE parameter• 3-55, 3-69

STATE parameter*3-79

SET LOGGING command *3-90
EVENTS parameter*3-82, 3-84
NAME parameter *3-81
STATE parameter*3-83
SET LOGGING EVENTS command *3-81
SET LOGGING MONITOR command
SINK parameter*3-83

SUBADDRESSES parameter • 3-75
SET NODE command *7-3
ACCESS parameter • 2-40, 3-88
ADDRESS parameter • 3-4, 3-8
COUNTER TIMER parameter • 3-24
DIAGNOSTIC FILE parameter • 4-13
HARDWARE ADDRESS parameter• 4-6, 4-8

SET LOGGING STATE command *3-81

INBOUND parameter*3-89

SET MODULE CONFIGURATOR command

NAME parameter*3-7

KNOWN CIRCUITS parameter • 3-43

NONPRIVILEGED parameter • 3-87

STATUS display *3-42

PRIVILEGED parameter *3-87

SURVEILLANCE DISABLED parameter • 3-43

RECEIVE PASSWORD parameter • 3-86

SURVEILLANCE ENABLED parameter • 3-42
SET MODULE X25-ACCESS command

remote node name and address *3-7
SERVICE CIRCUIT parameter • 4-8

ACCOUNT parameter*3-80

SERVICE DEVICE parameter • 4-13

NETWORK qualifier *3-79

SERVICE PASSWORD parameter*4-13

NODE parameter*3-80

SOFTWARE IDENTIFICATION parameter • 4-12

Index—17

Index

SET NODE command (cont'd.)
SOFTWARE TYPE parameter • 4-12
TRANSMIT PASSWORD parameter • 3-86
SET OBJECT command
ACCOUNT parameter*3-74
ALIAS INCOMING parameter*3-10, 3-71
ALIAS OUTGOING parameter*3-10, 3-71

STATE parameter (cont'd.)
for line *3-52
for X25-SERVER module *3-79
Static asynchronous connection* 1-4, 1-7, 1-9
network configuration *5-17
reasons for failure *5-9
Static asynchronous line* 1-9, 2-14, 5-8

FILE parameter • 3-73

installing • 5-8

NUMBER parameter • 3-70

shutting down *5-9

PASSWORD parameter*3-74, 3-87

STATUS display type *3-91

PRIVILEGE parameter *3-87

Stream timer *3-54

PROXY parameter*2-42, 3-89

SUBADDRESSES parameter

USER parameter*3-74, 3-87
SHOW command *3-90
SHOW EXECUTOR CHARACTERISTICS command
display of proxy access *3-89
SHOW EXECUTOR command
CHARACTERISTICS display *3-8
display of Ethernet address *3-12
display of executor type *3-60
SHOW LINE command
Ethernet hardware address • 3-57, 7-10
SHOW MODULE CONFIGURATOR command*
3-41, 3-42
SHOW NETWORK command *8-1, 8-2
display of network status *8-1
SHOW NODE command
COUNTERS parameter*3-24
display of node type *3-60
Sink *2-34

for SET EXECUTOR command *3-46
for X25-SERVER module *3-75
SUMMARY display type *3-91
SVC (switched virtual circuit)* 1-12, 2-7, 2-11
for DLM use*2-7, 2-1 1
for X.25 native use*2-7
Switched virtual circuit
See SVC
SWITCH parameter*3-56
Synchronous connection* 1-4
Synchronous disconnect• 8-9, 8-13, 8-28, 8-34
SYSSASSIGN • 5-2, 8-16
format*8-18, 8-29
_NET: • 8-29
nontransparent use of *8-23
transparent use of *8-16
SYS$CANCEL* 8-28
SYSSCREMBX • 5-2, 8-23

logging • 2-35, 3-81

SYSSCREPRC • 5-2

name* 2-35

SYSSDASSGN*8-13, 8-17, 8-21, 8-37

node* 2-35

format* 8-21

related event • 2-34

SYSSGETDVI • 8-29

state* 2-35

SYSSLOGIN: NETSERVER.LOG *2-31,4-19

SINK parameter*3-83

SYS$LOGIN:objectname.COM • 3-72

Slave node *4-14

SYS$MANAGER:EVL.LOG • 3-84

SLD (Satellite Loader) *4-16

SYS$MANAGER:NET.LOG • 3-92

building *4-16

S YS$M AN AGER: NETCONFIG.COM • 5-5

SOFTWARE IDENTIFICATION parameter*4-12

SYSSMAN AGER:RTTLOAD.COM • 6-1

Software loopback test *7-6, 7-7

SYS$MANAGER:STARTNET.COM • 5-6, 5-13, 6-1

Source-related event *2-34

SYSSNET *8-11, 8-17, 8-26

Source task *8-10

SYSSQIO

STARTNET.COM *5-4, 5-13, 6-2

format *8-30, 8-31, 8-32, 8-34, 8-35, 8-36

State

IO$_ACCESS• 8-24, 8-27, 8-30, 8-31

logging • 3-83

IO$_ACCESS!IO$M_ABORT*8-27, 8-32

of circuit • 2-7

IO$_ACPCONTROL* 8-27, 8-36

of line *2-12

IO$_DEACCESS!IO$M_ABORT • 8-28, 8-29,
8-35

of local node • 2-3
STATE parameter

IO$_DEACCESS!IO$M _SYNCH • 8-34

for circuit • 3-36

IO$_READVBLK • 8-33

for DTE *3-25

IO$_WRITEVBLK • 8-33

for executor node *3-20

Index—18

Index

SYS$QIO (cont’d.)
IO$_WRITEVBLK! IO$M_INTERRUPT • 8-28,
8-34
SYS$QIO(IO$_ACCESS!IO$M_ABORT) • 8-27
format* 8-32
SYS$QIO(IO$_ACCESS) • 8-24, 8-27
format *8-30, 8-31
SYS$QIO(IO$_ACPCONTROL) • 8-27
format* 8-36
SYS$QIO(IO$_DEACCESS!IO$M—ABORT) • 8-28,
8-29
format • 8-35
SYS$QIO(IO$_DEACCESS!IO$M—SYNCH)
format • 8-34
SYS$QIO(IO$_READVBLK) • 8-33
format* 8-20
SYS$QIO(IO$_WRITEVBLK! IO$M_INTERRUPT)
format* 8-34
SYS$QI0(I0$_WRITEVBLK) • 8-33
format* 8-19

Task (cont'd.)
downline load *4-16
general purpose *4-18
identifier in specification* 1-23
installation *4-18
source *8-12
specification • 1-23
specification access control string* 1-23
specification for task* 1-23
specification over the network* 1-23
target*8-12, 8-19
Task-to-task communication • 1-3, 1-20, 8-1,
8-13, 8-21
nontransparent• 8-6, 8-7, 8-21
nontransparent MACRO example *8-43
transparent • 8-1, 8-13
transparent FORTRAN example *8-38
transparent MACRO example *8-41
TELL prefix
description • 3-6

SYS$SYSTEM:objectname.COM • 3-72

Terminal, heterogeneous command *8-1

SYS$SYSTEM:SYSGEN

Terminal connection

See SYSGEN

to remote console *4-20

SYS$TRNLOG system service call *8-1 1

Terminal emulator* 1-9, 2-16

SYSGEN

Terminal line

IRPCOUNT parameter* 5-32
LRPCOUNT parameter* 5-32

conversion to DECnet line* 1-9, 2-14, 5-7
Terminal server

LRPSIZE parameter* 5-32

LAT* A-10

NPAGEDYN parameter • 5-32

on Ethernet* 1-11

running • 5-32

Tertiary loader *4-4, 4-10

updating parameters for DECnet*5-32

Test

SYSNAM privilege *5-2, 8-27

circuit loopback test *7-6, 7-9

SYSPRV privilege *5-2, 5-5

controller loopback test *7-8

System configuration guidelines*5-31 to 5-38

Ethernet loopback test *7-9

System-level access control *2-37

local loopback test *7-5

System management

local-to-remote test *7-3

responsibilities* 1-14
VAX PSI* 1-14, 5-4
System service call* 1-21, 8-13, 8-21
summary for nontransparent use *8-22, 8-29
summary for transparent use *8-15, 8-18

node-level test *7-1
remote loopback test *7-2
software loopback test *7-7
X.25 test *7-12
Testing the network *7-1
Timer
babble *3-40

call *3-28

Tailoring the configuration database *5-7

counter • 3-24

Target-initiated downline load *4-2

dead• 3-54

Target node *4-1

delay • 3-54

Target task* 8-10

hello *3-37

Task

inactivity • 2-28, 3-68

broadcast routing *3-66
clear • 3-28

declaring for network *8-7

incoming • 2-28, 3-68

definition • 1 -20

line • 3-54

Index—19

Index

Timer (cont'd.)
logical link *2-28
outgoing • 2-28, 3-68

recall • 3-45
reset* 3-29
restart* 3-29
retransmit *3-54, 3-57

UAF (user authorization file) *8-11
creation of default nonprivileged DECnet
account• 5-1

routing • 2-27, 3-65

UETP (User Environment Test Package) • 5-6, 6-2

scheduling • 3-54

UNA

service* 3-54

Ethernet circuit device *2-10

stream • 3-54

Ethernet line device *2-18

transmit • 3-40
TLK image *4-16

loopback test*7-9
Unattended system

TMPMBX privilege *2-38

memory dump *4-14

Topology

slave *4-14

of a multiple-area network* 1-17
of a single-area network* 1-17
TOPS-10 node *9-17
TOPS-20 node *9-20
TO qualifier
COPY KNOWN NODES command *3-21

UNIBUS
devices* 5-36
map registers*5-36
Upline memory dump
definition *4-14
over Ethernet *4-15

TQELM quota *5-34

procedures *4-14

Transmit password • 2-36

requirements *4-15

TRANSMIT PIPELINE parameter • 3-55
Transmit timer *3-40
Transparent
communication* 1-23, 8-1
user network operations* 1-20
Tributary* 1-7, 2-8

RSX-1 IS system*4-14
USAGE parameter
for DLM circuit *3-46
for PVC • 3-43
User
interface to network* 1-20

address* 2-8

network operations • 8-1

circuit timers *3-40

transparent network operations* 1-20

control *3-39, 3-40
TRIBUTARY parameter • 3-32
TRIGGER command *4-2, 4-6
PHYSICAL ADDRESS parameter• 4-6
SERVICE PASSWORD parameter • 4-6
Trigger message *4-2
Trigger operation

User-defined object *2-28
User Environment Test Package
See UETP
User group
See BCUG, CUG, and X.25
USING qualifier
COPY KNOWN NODES command *3-21

bootstrap ROM • 4-3
primary bootstrap *4-2
primary loader *4-2
TRIGGER command *4-6
TRIGGER VIA command *4-13
TYPE parameter

v
VAXcluster

for executor node *3-60

configuration *1-10

for GROUP *3-31

end node* 1-1 1, 2-25

for PVC • 3-43

router* 1-11, 2-25

Index—20

Index

VAXcluster (cont'd.)

Volatile database* 1-16, 3-2

use of an alias node identifier* 1-11, 2-4, 2-30,
3-9, 8-7

copying node entries *3-21

use of Cl data link* 1-10

use of *3-2

display information • 3-90

use of DECnet-VAX data link* 1-10
VAX Packetnet System Interface
See VAX PSI
VAX PSI* 1-3

bringing up a DTE *6-2
command procedure for object *2-32
configuration* 1-4, 1-17, 5-1, 5-26, 5-30

Wildcard character
for events*3-82

connector node *6-2

Window size parameter• 3-27

database* 1-16, 3-3

WITH qualifier

dumping KMS11 microcode* 7-1, 7-13

COPY KNOWN NODES command *3-21

dumping KMVI 1 microcode • 7-1, 7-13
line-level loopback test *7-1, 7-12
multihost installation • 6-2
multihost mode* 1-3, 1-14, 5-1

multinetwork configuration • 5-30
native mode* 1-3, 1-14
native user programs *2-7
object*2-32, 3-73
software* 1-15, 2-1
system management* 1-14, 5-4
test facilities* 7-1
users* 1-14
VAX PSI Access software* 1-12, 2-1, 2-6, 2-34,
5-1, 6-2

X.25* 1-3, 2-5
access module* 1-19, 2-6, 2-34
access module commands • 3-79
BCUG • 2-6, 3-30, 3-75
call destination • 2-32
CCITT recommendation* 1-3, 1-12
circuit *2-6, 3-33
circuit devices *2-11
circuit identification • 3-33

VAX/VMS node *2-1

circuit parameters *3-43

VAX/VMS operating system

connector node* 1-1, 1-3, 1-4, 1-12, 1-17,
2-1, 2-6, 2-32, 2-34, 3-78, 3-79, 5-1, 6-2

network interface* 1-2
nonpaged dynamic memory pool *5-32
VAX/VMS to VAX/VMS network operation
Version 4.4 to previous version *9-24
Version 4 to Version 3*9-23
VAX/VMS to IAS network operation • 9-2
VAX/VMS to P/0S network operation • 9-5
VAX/VMS to RSTS/E network operation • 9-6
VAX/VMS to RSX (using FCS-based FAL) network
operation* 9-11
VAX/VMS to RSX (using RMS-based FAL)
network operation • 9-9

connector node configuration • 5-26
CUG • 2-6, 3-30, 3-75
data packet control • 3-27, 3-44
gateway node* 1-3, 5-1
handling incoming calls *3-74
host node* 1-3, 1-12, 1-17, 2-1, 2-6, 2-32,
2-34, 3-78, 3-79, 5-1
host node configuration • 5-26
LAPBE line protocol • 3-49
LAPB line protocol • 3-49
line*2-11, 2-12, 3-50

VAX/VMS to RT-11 network operation • 9-14

line device *2-18

VAX/VMS to TOPS-10 network operation • 9-17

line-level loopback test *7-12

VAX/VMS to TOPS-20 network operation • 9-20

line parameters*3-57

VERIFICATION INBOUND parameter • 3-38, 3-86

line receive buffers *3-59

VERIFICATION parameter • 3-38

multihost installation • 6-2

Virtual circuit* 1-6, 1-8

multihost mode* 1-12, 2-6, 5-1

See also X.25 virtual circuit
Virtual terminal* 1-9, 2-16
enabling* 5-10
VMR *4-16

multihost mode network configuration • 5-26
multinetwork configuration • 5-30
native mode* 1-12
native-mode network configuration • 5-25

Index-21

Index

X.25 (corn'd.)
protocol module* 1-19, 2-1, 2-5, 3-24
PSDN • 1-1
PVC • 2-7, 2-11, 3-33
server module* 1-19, 2-5, 2-6, 2-32
server module commands • 3-74
SVC• 2-7, 2-11, 3-33
trace module* 1-19
user group *2-6, 3-30, 3-75
virtual circuit* 1-1, 1-3, 1-12,2-7,2-11
X.29
CCITT recommendation • 1-3, 1-12
incoming calls *3-76
server module* 1-19, 2-5, 2-32
server module commands • 3-74
terminal* 1-12
X25-PROTOCOL module
commands *3-24
counters • 3-31
parameters • 3-24
X25-SERVER module
identification • 3-74
parameters* 3-74
X29-SERVER module
See X25-SERVER module

ZERO CIRCUITS command *3-48
ZERO EXECUTOR command *3-24
Zeroing
line counters • 3-60
node counters*3-24
ZERO LINE command *3-60
ZERO NODE command *3-24
Zero-numbered object *2-29

Index-22

VAX/VMS
Networking Manual
AA-Y512C-TE

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

Assembly language programmer
Higher-level language programmer
Occasional programmer (experienced)
User with little programming experience
Student programmer
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

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

SSG PUBLICATIONS ZK1-3/J35
DIGITAL EQUIPMENT CORPORATION
110 SPIT BROOK ROAD
NASHUA, NEW HAMPSHIRE 03062-2698

.II,IIm,,IImmI,II.I,.I,ImI,I,,II.Ml
Do Not Tear - Fold Here

VAX/VMS
Networking Manual
AA-Y512C-TE

READER'S
r'niUllUICIUTC
l*UIVIIVIClil I O

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

Assembly language programmer
Higher-level language programmer
Occasional programmer (experienced)
User with little programming experience
Student programmer
Other (please specify) _

Name _Date_
Organization _
Street City __State_Zip Code_
or Country

- —

—

Do Not Tear - Fold Here and Tape

mmm

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

SSG PUBLICATIONS ZK1-3/J35
DIGITAL EQUIPMENT CORPORATION
110 SPIT BROOK ROAD
NASHUA, NEW HAMPSHIRE 03062-2698

III.II.IImmIImmI.II,I,,I,I..I,ImII,
Do Not Tear - Fold Here

Cut Along Dotted Line

- — —