RTS/8 DECNET/8 User's Guide Order No. AA-5184A-TA DISCLAIMER This document file was created by scanning the original document and then editing the scanned text. As much as possible, the original text format was restored. Some format changes were made to insure this document would print on current laser printers using 60 lines per page. The original spelling and grammar has been preserved. 1-Jun-1996 digital equipment corporation - maynard, massachusetts First Printing, February 1977 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. Digital Equipment Corporation assumes no responsibility for the use or reliability of its software on equipment that is not supplied by DIGITAL. Copyright - 1977 by Digital Equipment Corporation The postage prepaid READER'S COMMENTS form on the last page of this document requests the user's critical evaluation to assist us in pre- paring future documentation. The following are trademarks of Digital Equipment Corporation: DIGITAL DECsystem-10 MASSBUS DEC DECtape OMNIBUS PDP DIBOL OS/8 DECUS EDUSYSTEM PHA UNIBUS FLIP CHIP RSTS COMPUTER LABS FOCAL RSX COMTEX INDAC TYPESET-8 DDT LAB-8 TYPESET-10 DECCOMM DECsystem-20 TYPESET-11 2/77-14 CONTENTS Page PREFACE vii CHAPTER 1 INTRODUCTION 1-1 1.1 DEFINITION OF COMPUTER NETWORKS 1-1 1.2 DEFINITION OF DECNET/8 1-2 1.3 STRUCTURE OF DECNET/8 1-2 1.4 USER CAPABILITIES 1-5 1.4.1 Terminal Communication Utility 1-5 1.4.2 Network Information Program 1-6 1.4.3 Communication Between User-Written Programs 1-6 CHAPTER 2 RTS/8 INTERTASK COMMUNICATION 2-1 2.1 RTS/8 ASSEMBLY LANGUAGE FACILITIES OVERVIEW 2-1 2.1.1 RTS/8 SEND Executive Request (ER) 2-1 2.1.2 Asynchronous System Trap (AST) 2-3 2.1.3 Connect Control Block (CCB) 2-3 2.1.4 Basic Procedure 2-3 2.2 ISSUING DECNET/8 REQUESTS 2-4 2.2.1 DECNET/8 Function Calls 2-5 2.2.2 CONINI 2-8 2.2.3 CONCNF 2-12 2 2 4 CONREJ 2-14 2 2 5 DISCON 2-16 2.2.6 TRNSMT 2-18 2.2.7 INTRPT 2-21 2.2.8 RCVMSG 2-23 2.2.9 RCNMSG 2-25 2.2.10 RCVSM 2-27 2.2.11 TRNSM 2-30 2.3 DECNET/8 AST ROUTINES 2-31 2.4 CONNECT CONTROL BLOCK 2-35 CHAPTER 3 TERMINAL COMMUNICATIONS UTILITY (TLK) 3-1 3.1 INTRODUCTION 3-1 3.2 INVOKING TLK 3-1 3.3 EXAMPLES 3-2 3.4 ERROR MESSAGES 3-2 CHAPTER 4 NETWORK INFORMATION PROGRAM (NIP) 4-1 4 1 INTRODUCTION 4-1 4 2 PHYSICAL LINE STATUS 4-1 4.3 LOGICAL LINK STATUS 4-2 4 4 PHYSICAL LINE ERROR STATUS 4-3 4 5 SAMPLE NIP PRINTOUT 4-5 CHAPTER 5 RTS/8 DECNET/8 SYSTEM GENERATION 5-1 5.1 NETWORK GENERATION OVERVIEW 5-1 iii CONTENTS (Cont.) Page 5.2 DECNET/8 SYSTEM GENERATION PROCEDURES 5-2 5.3 USER TASK PARAMETERS 5-2 5.4 PARAMETER FILE 5-4 5.4.1 DECNET/8 Task Priorities 5-6 5.4.2 DDCMP and NSP Parameters 5-7 5.4.3 NIP Parameters 5-9 5.4.4 TLK and LSN Parameters 5-11 5.5 NODE NAME TABLE 5-11 5.6 INTERRUPT SERVICE ROUTINES 5-13 5.7 LINE CONTROL FILE 5-14 5.8 ASSEMBLY PROCESS 5-16 5.9 LOAD PROCESS 5-16 5.10 SAVE 5-16 5.11 SAMPLE DECNET/8 PARAMETERS 5-17 5.12 EXAMPLE OF A LINE CONTROL FILE 5-25 CHAPTER 6 INTERNAL NETWORK DESCRIPTION 6-1 6.1 NETWORK OVERVIEW 6-1 6.1.1 Protocol Fields 6-1 6.2 DDCMP 6-2 6.2.1 Message Formats 6-3 6.2.2 DDCMP Executive Routine 6-7 6.2.3 Events 6-8 6.2.4 NSP to DDCMP Requests 6-9 6.2.5 Input 6-11 6.2.6 Output 6-13 6.2.7 Message Timing 6-14 6.2.8 Interrupt Service Routines and Buffer Formats 6-15 6.2.9 Line Control Blocks 6-18 6.2.10 CRC-16 Routine 6-22 6.2.11 Major DDCMP Support Subroutines 6-23 6.3 NSP OVERVIEW 6-24 6.3.1 NSP Message Format 6-25 6.3.1.1 Extensible Binary and Extensible ASCII 6-27 6.3.2 Overall Layout of the NSP Task 6-28 6.3.3 DDCMP Function Call Completion Processing 6-30 6.3.4 DDCMP Events 6-30 6.3.5 User Function Calls 6-31 6.3.6 Major NSP Support Routines 6-41 6.3.7 NSP Tables 6-43 CHAPTER 7 STAND-ALONE USE OF DDCMP 7-1 7.1 STAND-ALONE USE OF THE DDCMP TASK 7-1 7.1.1 Bringing Up a Physical Link 7-1 7.1.2 Transmitting and Receiving Messages 7-2 7.1.3 Breaking the Physical Link 7-2 7.2 ISSUING DDCMP FUNCTION CALLS 7-2 7.2.1 STARTUP 7-3 7.2.2 TRNSMT 7-4 7.2.3 HALT 7-4 7.3 DDCMP EVENTS 7-5 7.3.1 RCVMSG 7-5 iv CONTENTS (Cont.) Page 7.3.2 LINDWN 7-6 7.3.3 STRT RECEIVED 7-6 7.3.4 Sample DDCMP Support Subroutines 7-7 APPENDIX A GLOSSARY A-1 INDEX Index-1 FIGURES FIGURE 1-1 Computer Network Composed of Two Nodes Connected by a Physical Link 1-1 1-2 Functional Levels of DECNET/8 1-2 1-3 Components of the Program Dialogue Level 1-3 1-4 Sample Message Transmission from Node 1 to Node 2 1-4 1-5 Terminal Communication Utility (TLK) Used on Two PDP-8s 1-6 2-1 User Task/NSP Relationship in DECNET/8 2-1 2-2 Sample Sequence of I/O Requests 2-4 5-1 Node Name Table 5-12 6-1 DDCMP Field (DDCFLD) 6-1 6-2 NSP Field (NSPFLD) 6-2 6-3 Control Message Formats 6-4 6-4 Example of the Uses of Control Messages 6-5 6-5 Format of Data Messages 6-6 6-6 Overall Organization of DDCMP 6-8 6-7 NSP to DDCMP Function Call Format 6-9 6-8 DDCMP Completion Queue 6-11 6-9 DDCMP to NSP Function Call Format 6-13 6-10 ISR to DDCMP Packet Format 6-16 6-11 Layout of DDCMP's Input Queue for ISRs 6-17 6-12 Data Ring Buffer 6-18 6-13 LCBTAB Location 6-18 6-14 General NSP Message Format 6-25 6-15 Overall Layout of NSP 6-29 6-16 CCBTAB 6-43 6-17 LNKTAB 6-44 6-18 NETTAB 6-44 TABLES TABLE 2-1 DECNET/8 Function Calls 2-2 2-2 Destination Block Format 2-10 4-1 Error Conditions Printed by NIP 4-3 5-1 User Task Parameters 5-3 5-2 NETGEN Parameters 5-4 5-3 DDCMP and NSP Parameters 5-8 5-4 NIP Parameters 5-10 v CONTENTS (Cont.) Page 5-5 TLK and LSN Parameters 5-11 5-6 Interrupt Service Routines Supported by DIGITAL 5-14 5-7 Line Control File Parameters 5-14 6-1 Decision Table for Control Messages Received by DDCMP 6-12 6-2 Line Control Block Format 6-19 vi PREFACE This manual describes the DECNET/8 facilities available to both the RTS-8 programmer and terminal user. It is assumed that the user of this manual is familiar with RTS-8. The chapters in this document are as follows: Chapter 1 provides a brief overview of DECNET/8 and explains the capabilities offered to terminal users. This chapter should be read by DECNET/RTS-8 operators as well as programmers and terminal users. Chapter 2 is an overview of the DECNET/8 language facilities. It introduces communications and network protocols. Chapters 3 and 4 are the specific DECNET/RTS-8 utilities, such as the Terminal Communications Utility (TLK) and the Network Information Program (NIP). These chapters can be used by operators, programmers, and terminal users. Chapter 5 is directed to users who will perform system and network generation. Chapter 6 is an internal network description that should be used preferably by the programmer. It explains the implementation of the protocols. Chapter 7 describes how a protocol can be used as a stand-alone task and it also provides guidelines for users writing their own protocols. vii CHAPTER 1 INTRODUCTION 1.1 DEFINITION OF COMPUTER NETWORKS A computer network is a group of two or more independent computer systems interconnected to provide information exchange. Each separate computer thus becomes a local part (a node) of the larger whole (the network). Each node in a network is an independent computer system that can operate alone or interact with another node. Nodes need not be identical. Therefore, each node is not required to maintain a full complement of processing capabilities. If a user requires a processing or device capability not available locally, a network can meet that need by providing access to another, possibly distant, node that maintains the needed capabilities. The connection between two adjacent nodes is called a physical link and can be any of several types of permanent or temporary connections. A direct wire is an example of a permanent link and a telephone circuit is an example of a temporary link. Figure 1-1 shows two nodes connected by a satellite link. A user located at Node 1 regards that node as the local node and Node 2 as the remote node. A user at Node 2 regards Node 2 as local and Node 1 as remote. ******* * * * Satellite * * * NODE . . ******* . . NODE 1 . . . . . . 2 . . . . . . -------- -------- | Data | | Data | ........| set | | set |........ . -------- -------- . . . ------------ ------------ | Computer | | Computer | ...| | | |... . ------------ ------------ . . . -------- -------- | User | | User | | 1 | Physical | 2 | -------- |<------- Link ------->| -------- Figure 1-1 Computer Network Composed of Two Nodes Connected by a Physical Link 1-1 INTRODUCTION 1.2 DEFINITION OF DECNET/8 DECNET is the collective name for software and hardware products that extend the facilities of various DIGITAL operating systems so that they can be joined to form computer networks. DECNET/8 is the software package that supplies network capabilities for the RTS/8 operating system. DECNET/8 provides a general set of tools that allows user programs operating at different nodes to communicate. User programs can open conversation paths (logical links) between two different nodes and exchange messages. 1.3 STRUCTURE OF DECNET/8 DECNET/8 operations are distributed over four functional levels, hierarchically arranged to provide an orderly flow of information between the user and the physical link (Figure 1-2). 1 2 3 4 -------- ------- --------- ------------- | User | | NSP | | DDCMP | | Physical | Physical | task |-->| |-->| |-->| Link |........... -------- ------- --------- | Interface | . To | (ISR) | ........> Remote ------------- Link Node Figure 1-2 Functional Levels of DECNET/8 Information passes from one level to another by means of interfaces that are an integral part of each level. In addition, each level can communicate with its counterpart at a distant node by adhering to rules of operation known as protocols. Each level uses one or more protocols to govern the format, control, and sequencing of information exchange. The four levels shown in Figure 1-2 are described in the following: Level 1. Program Dialogue Level (User Task) The program dialogue level consists of communicating programs, interfaces to the user and to the logical link control level, and one or more protocols governing message exchange. The basic components of this level are as follows: a. User Request - This interface is the user's entry to DECNET. It is composed of DECNET utility names as well as function calls that can be incorporated in user-written programs. The user interface also allows network programs to access peripheral devices. 1-2 INTRODUCTION b. Communicating Programs - DECNET/8 supplies two special-purpose utility programs. Other applications can be provided by incorporating network function calls in user-written programs. c. Logical Link Control Interface - The dialogue level also includes a transparent interface to the logical link control level. Figure 1-3 shows the basic components of the dialogue level and the ways in which the user requests DECNET/8 services. User Request Communicating Logical Link Programs Control Interface ------------------ ------------- Invoke | Terminal | | | Utility --------->| Communications |--------->| | | Utility (TLK) | | | ------------------ | | | | | | ------------------ | | Invoke | Network | | | Utility --------->| Management |--------->| NSP |-----> To | Utility (NIP) | | Interface | NSP ------------------ | | | | | | ------------------ | | Enter | User-written | | | Program --------->| Network |--------->| | | Programs | | | ------------------ ------------- Figure 1-3 Components of the Program Dialogue Level Level 2. Logical Link Control Level (NSP) A logical link is a conversation path between two programs. The Network Services Protocol (NSP) is the logical link protocol. NSP functions include routing and sequence control of messages, diagnosis of information transfer problems, and maintenance of error statistics for logical links. A principal feature of NSP is its ability to maintain several simultaneous conversations (logical links) between programs over a single physical link. Level 3. Physical Link Control Level (DDCMP) The physical link control level is responsible for maintaining an error-free physical data path between nodes. 1-3 INTRODUCTION The DIGITAL Data Communications Message Protocol (DDCMP) is the physical link control level protocol. Level 4. Physical Link Interface Level (ISR) This level transmits and receives messages over a physical link and is usually implemented by a hardware device such as a modem or data set. The physical link interface is handled by an Interrupt Service Routine (ISR). DECNET/8 supports communication between dialogue-level programs at different nodes by routing user requests through the four functional levels shown in Figure 1-2. The interaction between levels can be illustrated by tracing a sample message transmission from one node to another. Figure 1-4 shows a user request passing from Node 1 to Node 2. NODE 1 NODE 2 1 4 ------------- ------------- | Sending | | Receiving | | Program | | Program | ------------- ------------- | ^ 2 V 3 | ------------- ------------- | NSP | | NSP | | | | | ------------- ------------- | ^ 3 V 2 | ------------- ------------- | DDCMP | | DDCMP | | | | | ------------- ------------- | ^ 4 V 1 | ------------- ------------- | Physical | Physical | Physical | | Link |.................. | Link | | Interface | ..................>| Interface | | (ISR) | Link | (ISR) | ------------- ------------- Figure 1-4 Sample Message Transmission from Node 1 to Node 2 The numbered steps in Figure 1-4 correspond to the following sequence of events: At Node 1: 1. The user issues a network service request. The user interface level receives the request, translates it to a 1-4 INTRODUCTION DECNET message, fetches the required function call or utility, and passes the request to NSP. All this happens under the control of the RTS/8 Executive. 2. NSP determines where the message is to be sent, adds routing information, and passes it, along with the message, to DDCMP. 3. DDCMP adds test characters to the message (for error checking by DDCMP at Node 2) and passes the message to the physical link interface for transmission. 4. The physical link interface (the Interrupt Service Routine) transmits the message over the physical link. At Node 2, the sequence of events is reversed: 1. The physical link interface (the ISR) receives the message and passes it to DDCMP. 2. DDCMP examines the test characters to ensure message integrity and acknowledges message receipt by returning the test result to DDCMP at Node 1. If the message is error-free, DDCMP at Node 2 passes it to NSP. If, however, the message is not error-free, DDCMP at Node 1 initiates retransmission. 3. NSP determines the destination of the message and passes it to the specified user program or utility under the control of the RTS/8 Executive. 4. The destination program receives the message. This basic sequence of events is the foundation for all DECNET/8 user capabilities. 1.4 USER CAPABILITIES DECNET/8 provides the user with capabilities that include the following: o Terminal Communication o Network Information Utility o Communication Between User-Written Programs 1.4.1 Terminal Communication Utility The terminal user can communicate with any other terminal in the network by invoking the DECNET/8 utility TLK. For example, TLK can be used to request that the console operator at a remote node mount a specific file-structured device. In order to receive a message sent by TLK, the receiving node must have the Listen (LSN) utility or an 1-5 INTRODUCTION equivalent active task. Figure 1-5 shows TLK being used to send a message between two remote PDP-8s. The numbered steps correspond to those used in Figure 1-4. TLK is explained in detail in Chapter 3. NODE 1 NODE 2 -------------------- -------------------- | TLK request: | | TLK Message: | | Please Mount DK1 | | Please Mount DK1 | -------------------- -------------------- | ^ | | 1 V 4 | ------------- ------------- | TLK | | LSN | | | | | ------------- ------------- | ^ 2 V 3 | ------------- ------------- | NSP | | NSP | | | | | ------------- ------------- | ^ 3 V 2 | ------------- ------------- | DDCMP | | DDCMP | | | | | ------------- ------------- | ^ 4 V 1 | ------------- ------------- | Physical | Physical | Physical | | Link |.................. | Link | | Interface | ..................>| Interface | ------------- Link ------------- Figure 1-5 Terminal Communication Utility (TLK) Used on Two PDP-8s 1.4.2 Network Information Program DECNET/8 provides a program called NIP for reporting the network status. NIP (Network Information Program) retrieves node and link information such as error counters (maintained by NSP) and the status of each node that can be accessed by the local node. NIP is described in Chapter 4. 1.4.3 Communication Between User-Written Programs Two programs in a network can use DECNET facilities to exchange data. An RTS/8 program uses DECNET/8 Executive Requests to communicate with other programs in the network. Refer to Chapter 2. 1-6 CHAPTER 2 RTS/8 INTERTASK COMMUNICATION 2.1 RTS/8 ASSEMBLY LANGUAGE FACILITIES OVERVIEW In DECNET/8, user tasks at different nodes communicate with each other using the network protocols NSP and DDCMP. NSP provides a user interface to the network. The user task issues a request to NSP, which passes the request to DDCMP and then to the physical link interface for transmission to a remote node. This sequence is shown in Figure 2-1. A task communicates with NSP by means of the following facilities: 1. The RTS/8 SEND (or SENDW) Executive Request (ER), which uses the DECNET/8 function calls; 2. The DECNET/8 Asynchronous System Trap (AST); 3. A shared data area called the Connect Control Block (CCB). Figure 2-1 shows the relationship of these facilities to one another and to the overall system. These facilities are discussed in detail in this chapter. User Task NSP DDCMP ---------- ---------- ---------- | | RTS/8 | | RTS/8 | | | Main |--------->| |<-------->| | | Code | Messages | | Messages | | ISR | | | | | | ---------- |--------| | | | | | | | AST |Interrupts| | | | | | | |<---------| | | |<----->| |--> |--------| |--------| | | | | | CCB | Shared | CCBTAB | | | | | | |<-------->| | | | | | ---------- Data ---------- ---------- ---------- Subroutnie/Event Flag Linkage Figure 2-1 User Task/NSP Relationship in DECNET/8 2.1.1 RTS/8 SEND Executive Request (ER) User-written communications operations are performed by sending RTS/8 messages to the NSP task using SEND and SENDW ERs. The form used for sending RTS/8 messages to NSP is explained in Section 2.2.1. For a complete description of these and other ERs, consult the RTS/8 User's ____________ Manual (DEC-08-ORTMA). ______ 2-1 RTS/8 INTERTASK COMMUNICATION RTS/8 tasks communicate with other tasks in a network by using DECNET/8 function calls with the RTS/8 SEND ER. Using these function calls the RTS/8 task can: o Request a logical link connection with another task, optionally passing up to 16 bytes of data to the target task at the time the link is requested; o Accept or reject a request from the source task for a logical link connection, optionally passing a maximum of 16 bytes of data to the source task as part of the acceptance or rejection; o Transmit messages to, and receive messages from, other tasks over established logical links; o Transmit up to 16 bytes in an interrupt message for the immediate attention of the target task; o Disconnect a logical link; o Receive and transmit single messages between two tasks without a logical link. The DECNET/8 function calls used with the RTS/8 SEND ER are listed in Table 2-1. These function calls are discussed in detail in Section 2.2. Table 2-1 DECNET/8 Function Calls ---------------------------------------------------------------------- | Function Call | Function | | Symbol | | ---------------------------------------------------------------------- | | | | CONINI | Initiate the creation of a logical link | | | | | CONCNF | Confirm the creation of a logical link | | | | | CONREJ | Reject the request for a logical link | | | | | DISCON | Disconnect a logical link | | | | | TRNSMT | Transmit a solicited data message to a | | | partner task over a logical link | | | | | INTRPT | Interrupt a task at a remote node, passing| | | it a brief interrupt message | | | | | RCVMSG | Receive data from a task at a remote node | | | | | RCNMSG | Queue a receive request without soliciting| | | data with a link status message | ---------------------------------------------------------------------- 2-2 RTS/8 INTERTASK COMMUNICATION Table 2-1 DECNET/8 Function Calls (cont'd) ---------------------------------------------------------------------- | | | | RCVSM | Receive a single message over a physical | | | line | | | | | TRNSM | Transmit a single message over a physical | | | line | ---------------------------------------------------------------------- 2.1.2 Asynchronous System Trap (AST) A task must provide a special routine, called an AST routine, to receive control when NSP detects an interrupt condition on the logical link. Interrupt conditions that can be detected by NSP include: an unsolicited connect from a remote node; receipt of an interrupt message over a logical link; breaking of the logical link resulting from disruption of the physical link; the remote node disconnecting from the logical link. The DECNET/8 AST routine is discussed in detail in Section 2.3. 2.1.3 Connect Control Block (CCB) The user task must provide a special data area, shared with NSP, to store the context of a connection with a remote task. This shared data area is called the CCB. If the task is disk resident, the CCB must reside in the resident portion of the task. There is one CCB for each connection in the system, and generally only one CCB per task. The CCB contains all the internal state information that NSP needs to handle events related to that CCB. The CCB is discussed in detail in Section 2.4. 2.1.4 Basic Procedure The basic procedure for transmitting a message from an RTS/8 task in one node to an RTS/8 task in a remote node is: o Create a logical link The initiating task issues a DECNET/8 connect initiate to the NSP task via a SEND ER with the function code CONINI. The target task is interrupted and is passed the connection request. Based on the information (if any) accompanying the interrupt, the target task can either accept or reject the connection. A task running under RTS/8 accepts a connection by issuing SEND ER with the function code CONCNF; it rejects a connection by issuing SEND ER with the function code CONREJ. o Transmit messages 2-3 RTS/8 INTERTASK COMMUNICATION If the target task accepts the connection, a logical link is created and the two tasks can exchange messages. Either task can then issue the SEND ER with the function call TRNSMT to send messages, or with the function call RCVMSG to receive messages. o Disconnect the logical link Either task can disconnect the logical link between them. A task running under RTS/8 disconnects the link by issuing a SEND ER with the function call DISCON. Figure 2-2 illustrates a sample sequence of I/O requests by both the source task and the target task. Source Task Target Task -------------------- | CONINI |---------->(AST starts Running) -------------------- -------------------- (Posted) <----------| CONCNF | -------------------- . . . . -------------------- | TRNSMT |----------> -------------------- -------------------- <----------| RCVMSG | -------------------- -------------------- | DATA MESSAGE |----------> (Posted) -------------------- . . -------------------- (AST runs) <----------| DISCON | -------------------- -------------------- |Disconnect Confirm|----------> (Posted) -------------------- Figure 2-2 Sample Sequence of I/O Requests 2.2 ISSUING DECNET/8 REQUESTS User-written communications are performed by issuing DECNET/8 function codes. A DECNET/8 function code is issued by sending an RTS/8 message 2-4 RTS/8 INTERTASK COMMUNICATION to the NSP task using the SEND or SENDW ER with the required function code as an argument. The standard format of an RTS/8 message is: RTSMSG, ZBLOCK 3 /THE STANDARD RTS/8 MESSAGE HEADER STATUS FUNCTION /COMMON INFORMATION PRESENT IN ALL CHANNL /NSP FUNCTION CALLS P1 P2 P3 /FUNCTION-DEPENDENT PARAMETERS where: STATUS is the status word upon completion of the function. The initial value of this word does not affect the command. NSP sets the value of STATUS before posting the message. Zero indicates successful completion. Unsuccessful completion leaves a nonzero completion code in this word. Status codes are defined symbolically in the source file CCB.PA. FUNCTION is one of the function calls listed in Table 2-1, and defined in the source file CCB.PA. This word is never modified by NSP. CHANNL is a user-assigned channel number. This word is used by NSP to associate the proper CCB with this function during I/O. This word is never modified by NSP. P1,P2,P3.. The number of parameters depends on the function being requested. No modifications should be made to any word in an NSP message while completion is pending. Such modifications can result in system failure. 2.2.1 DECNET/8 Function Calls RTS/8 tasks request services from NSP by issuing function calls in the form of RTS/8 messages. The following groups of functions are available in DECNET/8: . CONNECT . RECEIVE . TRANSMIT . INTERRUPT . DISCONNECT . RECEIVE SINGLE MESSAGE . TRANSMIT SINGLE MESSAGE CONNECT. A connection is made when two tasks, a source task and a target task, establish a communications path (logical link) between them. The target task can accept or reject the connection requested by the source task. Accordingly, the following connect function calls 2-5 RTS/8 INTERTASK COMMUNICATION are part of the DECNET/8 set of function calls: . CONINI Connect Initiate . CONCNF Connect Confirm . CONREJ Connect Reject The function call CONINI allows a task to request connection to a remote task that is specified by name in the request. Under RTS/8, the target task is interrupted by means of the DECNET/8 AST routine (described in Section 2.3). The name and location of the source task requesting the link are passed to the target task in the shared data area, the CCB (see Section 2.4). The target task must then accept or reject the connection. The decision to accept or reject is based on the name of the source, or the availability of a buffer or device. If the connection is accepted with a CONCNF, resources tentatively allocated when the connection was requested (CONINI) are permanently allocated, and the connection is established. Once the logical link has been confirmed by a CONINI/CONCNF sequence, the dialog between tasks can begin. If the connection is rejected with a CONREJ, the source task's function call event flag is posted, and the resources are reassigned by both the source task's NSP and the target task's NSP. NSP also allows the user to add "optional data" to connect messages to pass preliminary connection information between nodes without using separate data messages. For example, a task sending a message to a remote terminal could pass the number of the remote terminal and receive confirmation that the remote terminal is available in the connect sequence. The subsequent data could then be confined to the terminal message itself. Optional data is limited to 16 (8-bit) bytes. RECEIVE. A task must request the reception of data by reserving a buffer to receive the requested data before the data can be sent over the physical link. Thus, the user is responsible for data buffer management. The following receive function calls are available to request data from a remote node. . RCVMSG Receive message . RCNMSG Receive message without link status RCVMSG sends the buffer address to NSP and instructs it to transmit a request for data to the remote node. This request is made using an internal NSP message called the link status message. The local NSP transmits a link status message to the remote NSP to notify the remote task that the user task at the local node has issued a receive request. RCNMSG passes the buffer address to a waiting queue, but no link status message is sent. Instead, a subsequent RCVMSG passes a cumulative link status message to the remote node. Thus, to transmit the requests, a task can issue n-1 (maximum of 15) RCNMSGs, then follow with a RCVMSG. 2-6 RTS/8 INTERTASK COMMUNICATION TRANSMIT. The TRNSMT (transmit) function call must be used to send data to a remote task. If a message request has been received by the local task, TRNSMT sends data to the requesting remote task at once. Otherwise, the data is queued and transmitted when a requesting link status message RCVMSG is received. INTERRUPT. Frequently, a task must inform its remote partner of an urgent condition requiring immediate attention. The INTRPT (interrupt) function call allows either task to bypass the buffering scheme and to transmit an interrupt message. This interrupt message is transmitted to the remote NSP, which interrupts the remote task using an AST routine and passes the interrupt message to its CCB. DISCONNECT. Tasks can disconnect from a logical link by issuing a DISCON (disconnect) function call. This function breaks the logical link and interrupts the remote task to inform it of the disconnection. Either task can issue a DISCON at any time without the other's consent. SINGLE MESSAGES. The single-message function allows a message to be sent between two tasks that do not have a logical link connecting them. The two nodes must be connected by a physical link. Single-message requests reduce the amount of nondata traffic on the line because no logical link or NSP status messages are sent over the line. Single-message requests are suited to an inquiry/response environment. The function calls for single messages are: . RCVSM Receive single message . TRNSM Transmit single message DECNET/8 does not guarantee the delivery of single messages. As in normal receive and transmit requests, a task must request to receive data by reserving a buffer to store the message. If a task receives a single message without issuing a receive single-message request, the message is discarded and no notification is sent to the transmitting task. Single-message functions should be used only in well-structured environments. The interaction of the CCB, the AST, and the function calls is explained further in the descriptions of the individual function calls. In the examples in the subsequent sections, the following RTS/8 coding conventions are observed: CUR is defined in the task as CURRENT FIELD multiplied by 10 (to build a CDF instruction). CHANNL is equated to the task's CCB number; it is NOT an address of a word containing the number. All symbolic function codes described in this chapter are predefined at system generation. 2-7 RTS/8 INTERTASK COMMUNICATION ---------- ---------- | CONINI | | CONINI | ---------- ---------- 2.2.2 CONINI FUNCTION: Initiate the creation of a logical link between the source task and the target task. MESSAGE FORMAT: ZBLOCK 3 /RTS/8 HEADER STATUS /RESERVED FOR COMPLETION STATUS CONINI /FUNCTION CALL CHANNL /CHANNEL NUMBER P1 P2 /PARAMETERS P3 P4 PARAMETERS: P1 is a pointer to the 6-bit destination node name. As with all DECNET/8 names, the node name must be null-padded, and it has a maximum of six characters. If this parameter is zero, the message is sent to the local node. P2 is a pointer to the destination block. The format for this 9-word block is shown in Table 2-2. Refer to Usage Note 3. P3 is a pointer to an optional data buffer being transmitted. If P3=zero, no optional data is sent. Otherwise, a maximum of 16 bytes is transmitted with the connection request. The first negative word encountered delimits the data string in the buffer. P4 is a pointer to a confirm/reject optional 17-word data buffer being received. On completion of the request, the first word is set to a negative byte count, and the next 16 words contain any optional data sent by the remote task in its connect-confirm or connect-reject call. (There is one byte per word.) USAGE NOTES: 1. The source task uses CONINI to request a logical link between itself and a remote task. 2. Under RTS/8, a tentative logical link is created when the remote node receives a CONINI from the source task. If the remote node rejects the request, the tentative logical link is deassigned at once. There is no limit to the number of 2-8 RTS/8 INTERTASK COMMUNICATION logical links that can be created. Generally, one task has one logical link but it is possible to have several tasks assigned to the same logical link. 3. Table 2-2 shows the format of the destination block. Words 8 and 9 of this block contain a user identification code. In multiuser environments, each user or group of users is assigned a user identification code or UIC (also called a programmer/project number or PPN). The UIC is a combination of a group code and a user code, separated by a comma and enclosed in square brackets ([,]). Group and user codes must be in the range of 1 through 7777 (octal). For example, [2,345] and [67,10] are both acceptable UICs. In many operating systems, a UIC is associated with files or tasks, and helps distinguish them. Thus, more than one file or task on the same device can have the same name, but different UICs. Since a remote operating system might have several tasks with the same name, the user may have to specify the group and user codes to identify a specific file or task. If the group or user code for a file or task is not known, a 0 (zero) should be specified for either code. NSP will then use the default user or group code. For DECNET/8, the default user code is 1; the default group code is 2. Thus, a task expecting incoming connection requests should specify [1,2] as its UIC. If another UIC is given, the remote task can connect to the local task only if it specifies the correct UIC. If a task specifies its UIC as [0,0], a remote task cannot connect to it. STATUS CODES: SUCST Success. DISST A disconnect has preempted completion of the connection process. DRJST The remote NSP has issued a disconnect request. CRJST The remote task has rejected the connection. Any optional data is stored in the user-assigned optional data buffer. ILLST Illegal connection request. The local NSP rejected the connection request because the CCB was not in an idle state. This error might indicate that a connection is already established. NODST The requested node name is not part of the network. Refer to the SYSGEN procedures in Chapter 5 for information on entering a node name into the DECNET/8 system. 2-9 RTS/8 INTERTASK COMMUNICATION ERRST An NSP error occurred that preempted the source task's request. (This error should not occur. ERRST indicates either a software error or a user error that has caused system failure.) LDNST The physical link has broken, thus preempting the pending connection. Table 2-2 Destination Block Format ---------------------------------------------------------------------- | Word | Contents | |--------|-----------------------------------------------------------| | 1 | The object type code for the target task. This code is | | | zero for task-to-task communication. Maximum value is | | | 127. | | | | | 2-7 | The 6-bit, null-padded symbolic name of the target task. | | | This can hold 12 characters. This can be created with a | | | PAL/8 text pseudo-op. | | | | | 8 | The target task's group code (for compatibility with | | | other operating systems). If zero, the remote node uses | | | its default. The default group code is specified at | | | system generation. Refer to Section 5.3. | | | | | 9 | The target task's user identification code (UIC). The | | | UIC is used in various operating systems as a means of | | | identifying user files. Refer to Usage Note 3. | ---------------------------------------------------------------------- EXAMPLE: /SAMPLE CONNECT INITIATE (CONINI) CALL . . CAL /MAINLINE CODE ISSUES SENDW /CALL AND WAITS NSP CONIMS . . CONIMS, ZBLOCK 3 /RTS/8 MESSAGE HEADER 0 /CURRENT STATUS CONINI /FUNCTION CODE CHANNL /CHANNEL CODE FOR CCB P1, DNODE /POINTER TO DEST. NODE NAME P2, DNAME /POINTER TO DEST. NAME BLOCK P3, 0 /ZERO = NO OPTIONAL DATA SENT P4, REPOPT /POINTER TO USERS REPLY OPT DATA BUF DNODE, TEXT /MAYNRD//6 CHAR NODE NAME *.-1 /ORIGIN OVER EXTRA ZERO PUT OUT /BY TEXT STATEMENT 2-10 RTS/8 INTERTASK COMMUNICATION DNAME, 0 /OBJ TYPE=0 FOR TASK-TASK TEXT /PARTNR//NAME OF MY PARTNER TASK ZBLOCK 2 /PADDING FOR SIX-WORD NAME 1,2 /USE DEFAULT GROUP, USER CODES REPOPT, 0 /WILL GET -# OPT BYTES SENT BACK ZBLOCK 10 /STORAGE AREA FOR REPLY OPT DATA 2-11 RTS/8 INTERTASK COMMUNICATION ---------- ---------- | CONCNF | | CONCNF | ---------- ---------- 2.2.3 CONCNF FUNCTION: Confirm the creation of a logical link between the target task and the source task. The target task must use CONCNF to confirm a logical link creation. MESSAGE FORMAT: ZBLOCK 3 /RTS/8 HEADER STATUS /RESERVED FOR COMPLETION STATUS CONCNF /FUNCTION CODE CHANNL /CHANNEL NUMBER P1 /PARAMETER PARAMETER: P1 is a pointer to an optional data buffer that is transmitted to the task that issued the connection request. The buffer contains 8-bit bytes, one per word, terminated by a negative word. A maximum of 16 bytes can be returned to an RTS/8 task. If P1 = 0, no optional data is sent. USAGE NOTES: 1. CONCNF instructs the local NSP to confirm the creation of a logical link between the source task and the target task. Upon receipt of the CONINI message from the source task, the target NSP creates a tentative logical link and schedules the target task's AST routine. When the source task receives the target task's CONCNF, the source task NSP transmits a CONCNF message and marks the tentative logical link as waiting for a link status message. Upon receipt of the link status message, the source task's NSP marks the tentative logical link as "on-line" and posts the pending CONCNF. At this time a logical link is established and communication between tasks can begin. 2. The most appropriate time to issue CONCNF is from the AST routine when a CONINI is received. 2-12 RTS/8 INTERTASK COMMUNICATION EXAMPLE: /SAMPLE CONNECT CONFIRM (CONCNF) CALL . . . CAL /MAINLINE CODE ISSUES SENDW /CALL AND WAITS NSP CONFRM . . . CONFRM, ZBLOCK 3 /RTS/8 HEADER 0 /CURRENT STATUS CONCNF /FUNCTION CODE CHANNL /CHANNEL CODE FOR CCB CNFOPT /POINTER TO OPT DATA CNFOPT, "O;"K;-1 /2 BYTES OF OPT DATA /TERMINATED BY -1 STATUS CODES: SUCST Success. ILLST Illogical request. The remote task did not issue a connection request. ERRST An NSP error occurred that preempted the source task's request. (This error should not occur. ERRST indicates either a software error or a user error that has caused system failure.) LDNST The physical link has been broken, thus preempting the pending connection. 2-13 RTS/8 INTERTASK COMMUNICATION ---------- ---------- | CONREJ | | CONREJ | ---------- ---------- 2.2.4 CONREJ FUNCTION: Reject the creation of a logical link between the source task and the target task. The target task must issue CONREJ to reject the request for a logical link. MESSAGE FORMAT: ZBLOCK 3 /RTS/8 HEADER STATUS /RESERVED FOR COMPLETION CODE CONREJ /FUNCTION CODE CHANNL /CHANNEL NUMBER P1 /PARAMETER PARAMETER: P1 is a pointer to an optional data buffer. The buffer contains 8-bit bytes, one per word, terminated by a negative word. A maximum of 16 bytes can be transmitted to an RTS/8 task with this request. If P1 = 0, no optional data is sent. USAGE NOTES: 1. The target task can pass optional data to the source task. For example, the tasks can be coded to transmit rejection reasons in the optional data buffer. 2. When a CONREJ is issued, the tentative logical link is immediately deassigned, and the function call is posted as complete. 3. The field is assumed to be the current field and the byte string is terminated by a delimiter. 4. The most appropriate time to issue CONREJ is from the AST when a CONINI is received. 2-14 RTS/8 INTERTASK COMMUNICATION EXAMPLE: /SAMPLE CONNECT REJECT (CONREJ) CALL . . . CAL /MAINLINE CODE ISSUES SENDW /CALL AND WAITS NSP REJMSG . . . REJMSG, ZBLOCK 3 /RTS/8 HEADER 0 /CURRENT STATUS CONREJ /FUNCTION CODE CHANNL /CHANNEL CODE FOR CCB REJOPT /OPT DATA PTR (P1) REJOPT, 0 /MUST BE SET TO THE USER'S REJECT CODE /BEFORE ISSUING A FUNCTION CALL -1 /DELIMITER STATUS CODES: SUCST Success. ILLST Illogical request. The remote task did not make a connection request. ERRST An NSP error occurred that preempted the source task's request. (This error should not occur. ERRST indicates either a software error or a user error that has caused system failure.) LDNST The physical link has been broken, thus preempting the connection. 2-15 RTS/8 INTERTASK COMMUNICATION ---------- ---------- | DISCON | | DISCON | ---------- ---------- 2.2.5 DISCON FUNCTION: Disconnect the logical link between the source task and the target task. MESSAGE FORMAT: ZBLOCK 3 /RTS/8 HEADER STATUS /RESERVED FOR COMPLETION CODE DISCON /FUNCTION CODE CHANNL /CHANNEL NUMBER P1 /PARAMETER PARAMETER: P1 is a pointer to an optional data buffer. The buffer contains 8-bit bytes, one per word, terminated by a negative word. A maximum of 16 bytes can be transmitted to an RTS/8 task with this request. If P1=0, no optional data is sent. USAGE NOTES: 1. DISCON instructs NSP to break the logical link. Either task can issue this function call at any time without consent of the partner task. 2. If a logical link existed, a DISCON is sent to the partner task. In DECNET/8, the partner task is interrupted via an AST routine and informed of the disconnect. The logical link is broken. If there are any pending messages when the DISCON is issued, the DISST status code is returned to the task that originated the DISCON. 3. If the logical link is tentative, the DISCON is not sent. Instead, the status code DISST is returned to the task requesting the connection, and the CCB is made idle. 4. If there is no logical link, the DISCON function call is an effective no-opt The user can issue this call as part of an error recovery routine to ensure that the logical link has been broken. 2-16 RTS/8 INTERTASK COMMUNICATION EXAMPLE: /SAMPLE DISCONNECT (DISCON) CALL . . . CAL /MAINLINE CODE ISSUES SENDW /CALL AND WAITS NSP DISMSG . . . DISMSG, ZBLOCK 3 /RTS/8 HEADER 0 /CURRENT STATUS DISCON /FUNCTION CODE CHANNL /CHANNEL CODE FOR CCB DISOPT /POINTER TO OPTIONAL DATA DISOPT, 0 /REASON FOR DISCON AS OPT DATA -1 /DELIMITER STATUS CODES: SUCST Success. DISST A disconnect has preempted completion of any data being transmitted or received. ILLST Illegal disconnect request. The disconnection has been rejected because no logical link connection was established. ERRST An NSP error occurred that preempted the source task's request. (This error should not occur. ERRST indicates either a software error or a user error that has caused system failure.) LDNST The physical link has been broken, thus preempting the connection. 2-17 RTS/8 INTERTASK COMMUNICATION ---------- ---------- | TRNSMT | | TRNSMT | ---------- ---------- 2.2.6 TRNSMT FUNCTION: Transmit a data message over the logical link. MESSAGE FORMAT: ZBLOCK 3 /RTS/8 HEADER STATUS /RESERVED FOR COMPLETION CODE TRNSMT /FUNCTION CODE CHANNL /CHANNEL NUMBER P1 P2 /PARAMETERS P3 PARAMETERS: P1 is a CDF to the message buffer. P2 is the address of the first byte of the data buffer. P3 is a negative byte count, indicating the number of bytes to be transmitted from the user data buffer. USAGE NOTES: 1. The CDF, ADDR, and -CNT form is used in the TRNSMT, RCVMSG, RCNMSG, and INTRPT function calls. This form differs from the form used in the CONINI, CONCNF, and CONREJ function calls (in which the field is assumed to be the current field and the byte string is terminated with a delimiter instead of a byte count). 2. TRNSMT causes NSP to transmit the data in the buffer to the target task when the target task has a receive request pending. 3. The data buffer must be in the resident portion of a checkpointable task. 4. For compatibility with other operating systems, the data buffer must not be larger than 192 bytes in length. The CDF pointer pairs are not counted in the 192 bytes. 5. If the target task's buffer is too small to accept all the data sent to it, the task is warned that data will be lost. 6. The data in the buffer consists of 8-bit bytes, usually positive (see Example 1). A negative byte indicates that 2-18 RTS/8 INTERTASK COMMUNICATION the data is continued in another buffer. The negative number is a CDF to a new field; the next word is an address-1 (for auto index register usage). See Example 2. Data buffers can be linked together in this manner to allow users to insert their own message headers. EXAMPLE 1: /SAMPLE TRANSMIT (TRNSMT) CALL BC=5 /BYTE COUNT . . CAL /MAINLINE CODE ISSUES SENDW /CALL AND WAITS NSP SENDBF /SEND A "HELLO" . . SENDBF, ZBLOCK 3 /RTS/8 HEADER 0 /CURRENT STATUS TRNSMT /FUNCTION CODE CHANNL /CHANNEL CODE FOR CCB CDF CUR /FIELD OF THIS TASK BUFFER /ADDRESS OF THE BUFFER -BC /BYTE COUNT BUFFER, "H;"E;"L;"L;"O EXAMPLE 2: BC=5 /BYTE COUNT . . CAL /MAINLINE CODE ISSUES SENDW /CALL AND WAITS NSP SNDBF2 /SEND A "HELLO" . . SNDBF2, ZBLOCK 3 /RTS/8 HEADER 0 /CURRENT STATUS TRNSMT /FUNCTION CODE CHANNEL /CHANNEL CODE FOR CCB CDF CUR /FIELD OF THIS TASK BUF2 /ADDRESS OF THE BUFFER -BC /BYTE COUNT BUF2, "H;"E;"L;CDF CUR;BUF3-1 . . BUF3, "L;"O 2-19 RTS/8 INTERTASK COMMUNICATION STATUS CODES: SUCST Success. DISST A disconnect has preempted completion of any data being transmitted or received. ILLST Illegal transmit request. There is no logical link connection or the connect initiate message (CONINI) is still pending. ERRST An error occurred that preempted the source task's request. (This error should not occur. ERRST indicates either a software error or a user error that has caused system failure.) LDNST The physical link has been broken, thus preempting the request. 2-20 RTS/8 INTERTASK COMMUNICATION ---------- ---------- | INTRPT | | INTRPT | ---------- ---------- 2.2.7 INTRPT FUNCTION: Interrupt a partner task and send it a short interrupt message. MESSAGE FORMAT: ZBLOCK 3 /RTS/8 HEADER STATUS /RESERVED FOR COMPLETION STATUS INTRPT /FUNCTION CODE CHANNL /CHANNEL NUMBERS P1 P2 /PARAMETERS P3 PARAMETERS: P1 is a CDF to the message buffer. P2 is the address of the first byte of the data buffer. P3 is a negative byte count indicating the number of bytes to be transmitted from the user data buffer. USAGE NOTES: 1. This function bypasses the normal synchronous buffering scheme and sends a short interrupt message to the partner task. The partner task is notified of the interrupt by means of an AST routine; for DECNET/8, the interrupt message is placed in the partner task's AST optional data buffer. 2. The maximum interrupt message size is 16 bytes. 3. Only one interrupt transmission request can be outstanding at a time. The interrupt is posted complete when data has been transmitted and acknowledged by DDCMP. If a task issues another interrupt message before the pending one is finished, the second message is rejected with an illegal interrupt request status code (ILLST). 4. The data buffer must be in the resident portion of a disk-resident task. 2-21 RTS/8 INTERTASK COMMUNICATION EXAMPLE: /SAMPLE INTERRUPT (INTRPT) CALL . . . CAL /MAINLINE CODE ISSUES SENDW /CALL AND WAITS NSP WAKMSG /THIS MESSAGE RETURNS WHEN DONE . . WAKMSG, ZBLOCK 3 /RTS/8 HEADER 0 /STATUS WORD INTRPT /FUNCTION CODE CHANNL /CHANNEL CODE FOR CCB CDF CUR /CDF TO CURRENT RTS/8 TASK FIELD WAKTXT /ADDRESS OF STRING -10 /-LENGTH OF STRING, 8 (DECIMAL) CHARACTERS WAKTXT, "W;"A;"K;"E;" ;"U;"P;"! /"WAKE UP!" STATUS CODES: SUCST Success. DISST A disconnect has preempted completion of any data being transmitted or received. ILLST Illegal interrupt request; there is no established logical link connection or the line has failed due to a hardware error. This status code is also returned if an interrupt message is already pending. ERRST An NSP error occurred that preempted the source task's request. (This error should not occur. ERRST indicates either a software error or a user error that has caused system failure.) LDNST The physical link has been broken, thus preempting the request. 2-22 RTS/8 INTERTASK COMMUNICATION ---------- ---------- | RCVMSG | | RCVMSG | ---------- ---------- 2.2.8 RCVMSG FUNCTION: Receive data from a remote task. MESSAGE FORMAT: ZBLOCK 3 /RTS/8 HEADER STATUS /RESERVED FOR COMPLETION STATUS RCVMSG /FUNCTION CODE CHANNL /CHANNEL NUMBER P1 P2 /PARAMETERS P3 PARAMETERS: P1 is a CDF to the message buffer. P2 is the address of the first byte of the data buffer. P3 is a negative count of the size of the receive buffer excluding the CDF; ADDR pair. This word is altered to contain the negative count of data bytes actually received. USAGE NOTES: 1. This function inserts the user's buffer into a waiting queue and then transmits a link status message to the remote NSP to inform it that a buffer is available. When a TRNSMT request addressing the local task is issued, data is passed to the buffer and the RCVMSG request is posted. 2. The user should reinitialize P3 each time a RCVMSG has been issued because P3 may change if fewer than P3 bytes of data are received. 3. The buffer must be in the resident portion of a checkpointable task that is issuing a RCVMSG. 4. Words reserved for data bytes must contain positive numbers to distinguish them from CDF instructions. For example, the ZBLOCK pseudo-op can be used during assembly. There is no need to clear the buffer before issuing another RCVMSG request. 5. For compatibility with other operating systems, the number of data bytes in the buffer must not be larger than 192 bytes, excluding CDF; ADDR pairs. 2-23 RTS/8 INTERTASK COMMUNICATION EXAMPLE: /SAMPLE RECEIVE MESSAGE (RCVMSG) CALL /BUFFLD, BUFLOC, BUFSIZ ARE DEFINED BY USER . . . TAD (-BUFSIZ /INITIALIZE THE BUFFER SIZE DCA SIZPRM /LIMIT CAL /MAINLINE CODE ISSUES SENDW /CALL AND WAITS NSP GETMSG . . . GETMSG, ZBLOCK 3 /RTS/8 HEADER 0 /CURRENT STATUS RCVMSG /FUNCTION CODE CHANNL /CHANNEL CODE FOR CCB CDF BUFFLD /P1 = CDF TO BUFFER FIELD BUFLOC /P2 = ADDRESS OF BUFFER SIZPRM, -BUFSIZ /P3 = -BUFF SIZE UPON ISSUE /AND P3 = -DATA COUNT UPON /COMPLETION . . . FIELD BUFFLD%10 /CODE TO DEFINE THE BUFFER *BUFLOC ZBLOCK BUFSIZ . . . STATUS CODES: SUCST Success. DISST A disconnect has preempted completion of any data being transmitted or received. ILLST Illegal receive request. There is no logical link connection. LSTST Data lost. The message was too long to fit into the data buffer. Only P3 bytes of data were transmitted; the remaining bytes in the message are lost. ERRST An NSP error occurred that preempted the source task's request. (This error should not occur. ERRST indicates either a software error or a user error that caused system failure.) LDNST The physical link has been broken, thus preempting the request. 2-24 RTS/8 INTERTASK COMMUNICATION ---------- ---------- | RCNMSG | | RCNMSG | ---------- ---------- 2.2.9 RCNMSG FUNCTION: Queue a receive request without soliciting data with a link status message. MESSAGE FORMAT: ZBLOCK 3 /RTS/8 HEADER STATUS /RESERVED FOR COMPLETION STATUS RCNMSG /FUNCTION CODE CHANNL /CHANNEL NUMBER P1 P2 /PARAMETERS P3 PARAMETERS: P1 is a CDF to the message buffer. P2 is the address of the first byte of the data buffer. P3 is the negative length of the buffer in bytes (excluding CDF; ADDR pairs). This word is altered to contain the negative count of data bytes actually received. USAGE NOTE: The usage notes for RCVMSG apply, with the following exception: RCNMSG only queues a buffer; it does not send a link status message to the remote NSP. Thus, the target task cannot receive data until a subsequent RCVMSG is issued. (A subsequent RCVMSG request automatically transmits a cumulative request count for all outstanding RCNMSGs.) Therefore, to issue n requests for data, the user must issue n-1 RCNMSG calls (n has a maximum value of 16), followed by an RCVMSG. Each receive request is posted when data is received in the specified buffer. This procedure saves line overhead by eliminating the need to send individual link status messages with each request for data. When issuing an RCNMSG, the user must never use SENDW; refer to the following example. 2-25 RTS/8 INTERTASK COMMUNICATION EXAMPLE: /SAMPLE RECEIVE WITHOUT LINK STATUS (RCNMSG) CALL /QUEUE 1 RECEIVE AND ISSUE ANOTHER WITH /LINK STATUS FOR BOTH . . . CAL /QUEUE INITIAL RECEIVE ONLY SEND /NEVER USE SENDW WITH RCNMSG! NSP /THIS CALL IS NOT POSTED UNTIL NOLKST /AN RCVMSG IS ISSUED CAL SENDW /QUEUE FINAL RECEIVE AND NSP /WAIT FOR ALL OF THEM FINRCV /LINK STATUS WILL BE SENT NOW . . . NOLKST, ZBLOCK 3 /RTS/8 HEADER 0 /CURRENT STATUS RCNMSG /FUNCTION CODE CHANNL /CHANNEL CODE FOR CCB CDF BUFFLD /CDF TO BUFFER FIELD BUF1 /BUFFER FOR INITIAL RECEIVE -BUFSIZ /BUFFER SIZE FINRCV, ZBLOCK 3 /RTS/8 HEADER 0 /CURRENT STATUS RCVMSG /FUNCTION CODE (LS SENT) CHANNL /CHANNEL CODE FOR CCB CDF BUFFLD /CDF TO BUFFER FIELD BUF2 /BUFFER FOR FINAL RECEIVE -BUFSIZ /BUFFER SIZE STATUS CODES: SUCST Success. DISST A disconnect has preempted completion of any data being transmitted or received. ILLST Illegal receive request. There is no logical link connection. LSTST Data lost. The message was too long to fit into the target buffer. Only P3 bytes of data have been transmitted to the buffer. The remaining bytes in the message are lost. ERRST An NSP error preempted the source task's request. (This error should not occur. ERRST indicates either a software error or a user error that caused system failure.) LDNST The physical link has been broken, thus preempting the request. 2-26 RTS/8 INTERTASK COMMUNICATION ---------- ---------- | RCVSM | | RCVSM | ---------- ---------- 2.2.10 RCVSM FUNCTION: Receive a single message from a remote node. MESSAGE FORMAT: ZBLOCK 3 /RTS/8 HEADER STATUS /RESERVED FOR COMPLETION STATUS RCVSM /FUNCTION CODE CHANNL /CHANNEL NUMBER P1 P2 P3 /PARAMETERS P4 P5 PARAMETERS: P1 is a pointer to the 3-word area reserved for the name of the node sending the message. P2 is a pointer to the 9-word area reserved for the name of the source task sending the message. (Refer to Usage Note 3.). P3 is a CDF instruction to set the pointer to the buffer memory field. P4 is the address of the first byte of the user buffer to receive the data message. P5 is a negative word count of the maximum length of the message that can be received. USAGE NOTES: 1. If a remote task sends a single message (TRNSM) and the local task has not issued an RCVSM, the message is discarded and no notification is sent to the issuing task. 2. A task that issues a RCVSM must set the node name/task name buffers to zero. When the single message is received, the node name and task name buffers are set to the location and value of the sending task. 3. The value of the CHANNL parameter is used to locate the CCB to be used for passing the request. 2-27 RTS/8 INTERTASK COMMUNICATION This function reserves a 3-word area called NODNAM. When a single message is received, NODNAM is updated with the name of the node from which the single message was received. A 17-word area is reserved to hold source task information arranged in the same format as a connect message. Refer to Table 2-2. This area is updated when the message is received to contain the source task name. 4. Enough space should be reserved to hold the largest single message that the task expects to receive. The default is 192 words. This value is stored in location BUFLEN. EXAMPLE: . . . CAL /MAINLINE CODE ISSUES SEND /SEND NSP /NSP IS THE TASK THE MESSAGE GOES TO RECVSM /ADDRESS OF THE AREA CONTAINING THE RECEIVE /SINGLE-MESSAGE ARGUMENTS . . . RECVSM, ZBLOCK 3 /RTS/8 HEADER RECVST, 0 /STATUS INITIALLY SET TO ZERO RCVSM /RECEIVE SINGLE-MESSAGE FUNCTION CODE CHANNL NODNAM /POINTER TO AREA RESERVED FOR NODE NAME TSKBLK /POINTER TO 9-WORD AREA RESERVED FOR TASK /INFORMATION CDF BUFFLD /CDF TO BUFFER MEMORY FIELD RCVBUF /ADDRESS OF USER BUFFER TO HOLD DATA BUFLEN /NEGATIVE WORD COUNT OF MAX. MESSAGE THAT CAN BE /RECEIVED . . NODNAM, ZBLOCK 3 /RTS/8 HEADER TSRBLK, 0 /OBJECT TYPE OF 0 TSRNAM, ZBLOCK 6 /6 WORDS FOR TASK NAME GRPNUM, 0 /GROUP NUMBER USRNUM, 0 /USER NUMBER RCVBUF, ZBLOCK 300 /RESERVES 192-WORD BUFFER AREA BUFLEN, -300 /NEGATIVE WORD COUNT OF MAXIMUM MESSAGE STATUS CODES: SUCST Success. ILLST Too many RCVSM requests outstanding. A task can have only one RCVSM request outstanding at any time. 2-28 RTS/8 INTERTASK COMMUNICATION NODST The requested node name is not part of the network. Refer to the SYSGEN procedures in Chapter 5 for information on entering a node name into a DECNET/8 node. ERRST An NSP error occurred that preempted the source task's request. (This error should not occur. ERRST indicates either a software error or a user error that has caused system failure.) LDNST The physical link has been broken, thus preempting the pending connection. 2-29 RTS/8 INTERTASK COMMUNICATION ---------- ---------- | TRNSM | | TRNSM | ---------- ---------- 2.2.11 TRNSM FUNCTION: Transmit a single message over a logical link. MESSAGE FORMAT: ZBLOCK 3 /RTS/8 HEADER STATUS /RESERVED FOR COMPLETION STATUS TRNSM /FUNCTION CODE CHANNL /CHANNEL NUMBER P1 P2 P3 /PARAMETERS P4 P5 PARAMETERS: P1 is the address of the destination node name. P2 is the address of the destination task block (see Table 2-2). P3 is a CDF instruction to the buffer memory field. P4 is the address of the buffer containing the message to be transmitted. P5 is a negative word count of the length of the message to be transmitted. USAGE NOTES: 1. The transmit single-message request not only contains the data message to be transmitted (like a normal transmit message request) but also identifies the node and task to receive the single message (like a connect initiate). 2. NSP uses the CHANNL value to locate the CCB to be used when sending the message. 3. If the physical link used to transmit the single message is not "on-line", it is brought up when TRNSM is issued. 4. If the task specified in the TRNSM request does not exist, no notification is given to the user of the request failure. 2-30 RTS/8 INTERTASK COMMUNICATION EXAMPLE: . . . CAL /MAINLINE CODE ISSUES SEND /SEND NSP /USE THE NSP TASK XMITSM /ADDRESS OF THE SINGLE-MESSAGE BUFFER AREA . . . XMITSM, ZBLOCK 3 /RTS/8 HEADER XSMSTA, 0 /STATUS, SET TO 0 INITIALLY TRNSM /FUNCTION CODE CHANNL /CHANNEL CODE FOR CCB NODNAM /ADDRESS OF DESTINATION NODE NAME TSKNAM /ADDRESS OF DESTINATION TASK NAME CDF BUFFLD /CDF INSTRUCTION TO BUFFER FIELD XMTBUF /ADDRESS OF BUFFER TO BE TRANSMITTED XMTLEN /NEGATIVE WORD COUNT OF LENGTH OF MESSAGE TO BE /SENT . . . NODNAM, TEXT/NODE.C/ /DESTINATION NODE NAME TSKNAM, 0 /DESTINATION OBJECT TYPE TEXT /CHKTSK/ /DESTINATION TASK NAME ZBLOCK 2 /PADDING FOR SIX-WORD NAME 1;2 /STANDARD GROUP AND USER VALUES STATUS CODES: SUCST Success. ILLST Too many TRNSM requests outstanding. A task can have only one TRNSM request outstanding at any time. NODST The requested node name is not part of the network. Refer to the SYSGEN procedures in Chapter 5 for information on entering a node name into a DECNET/8 node. ERRST An NSP error occurred that preempted the source task's request. (This error should not occur. ERRST indicates either a software error or a user error that has caused system failure.) LDNST The physical link has been broken, thus preempting the pending connection. 2.3 DECNET/8 AST ROUTINES An RTS/8 task using DECNET/8 facilities must have an AST routine. 2-31 RTS/8 INTERTASK COMMUNICATION This routine is scheduled asynchronously with the task when any of the following interrupt conditions occur: o A remote task requests a connection with the local task. o A remote task sends an interrupt message to the local task. o An established logical link is broken by the partner task, by the remote NSP (because of an abort of the partner task's execution), or by the loss of contact with the remote node. Unlike a normal RTS/8 derail subroutine, the DECNET/8 AST does not save and restore the state of the accumulator, the link, or the data field. In addition, AST execution can be requested while the current AST is running. NSP queues the AST requests. Additional requests are honored when the current AST routine exits, on a strict first-come first-served basis. The AST routine is effectively "jumped" to at the address of the symbol USRAST with the accumulator zero and the data field random. The AST routine is exited by jumping to the symbol CCBRTN in the CCB. Upon entry to an AST routine, a task's CCB contains the following information: ------------------------------------------------------------------ | Location in CCB.PA | Contents | |--------------------|-------------------------------------------| | CCBRSN | A reason code for the interrupt set for | | | each execution of the AST. | | | | | CCBOPL | The negative byte count of any optional | | | data or interrupt data passed, up to a | | | maximum of 16 bytes. If the mainline code| | | depends on any of this optional data, the | | | AST should buffer the data as a safeguard | | | against loss. If a subsequent AST | | | execution is requested, the optional data | | | could be overwritten. | | | | | CCBOPT | A 16-word optional data buffer. This data| | | is also vulnerable if another AST is | | | executed. It should be buffered as a | | | precaution against loss if it is important| | | data. | | | | | CCBDOT | The object type of the partner task. | | | Because these optional data locations are | | | vulnerable, the AST should examine these | | | values first. | | | | | CCBDN1-CCBDN6 | The 6-bit name of the partner task (task | | | name is limited to 12 null-padded | | | characters). This name is changed only if| | | a CONINI request is received. | | | | 2-32 RTS/8 INTERTASK COMMUNICATION | | | | CCBDG,CCBDU | The group and owner codes from the user | | | identification code used by the partner | | | task (for compatibility with other | | | operating systems). | ------------------------------------------------------------------ Further information on these locations can be obtained by referring to the CCB.PA source listings. A task can examine this information (depending on the context of the interrupt) and act accordingly (such as, accept or reject connections). The AST routine runs at the same priority as the user task. When an interrupt condition occurs on the logical link (such as a connect request from a remote node or reception of an interrupt message), NSP saves the task's PC, AC, LINK, and DF in the task's CCB. NSP then changes the task's PC to point to the location USRAST. Thus, the next time the task is run, the task starts in the AST routine, and not at the point where it was when it was interrupted. (While the AST routine is executing, the task is said to be at "AST level.") If the task cannot be run, the AST routine does not run. However, NSP clears the task's message wait bit (MSGWT and EORMWT) before scheduling an AST routine. If a task's mainline code is to wait for completion of an AST routine, the task can go to sleep with the following code: CAL BLKARG MSGWT When the AST routine has completed execution, the user task leaves AST level and returns to the mainline code by jumping to location CCBRTN in the CCB. The contents of CCBRTN determines if other AST requests are pending. If other AST requests are pending, the AST routine is reentered at location USRAST; otherwise, the user task resumes execution at the point at which it was interrupted. If a task wants to wait for an event flag to be posted and also allow ASTs to run, it should wait for the event using the RTS/8 WAITX ER rather than the WAITE ER. If the task issues a WAITE and an AST occurs, the AST routine does not run until the event is complete. The reason for this is, NSP does not clear the event flag wait bit (EFWT) in a task that has received an AST. The WAITX ER places the task in EORMWT. The AST routine can determine where execution was interrupted in the mainline code by examining the following locations in the CCB. Location Contents ________ ________ CCBPC The next address to be executed in the mainline code. 2-33 RTS/8 INTERTASK COMMUNICATION CCBAC The contents of the task's AC. CCBXDF A CDF to the data field of the task. (A task can determine if it is at AST level by examining the contents of this location: if it is nonzero, the task is at AST level.) The AST routine can change the contents of these locations. For example, the AST routine can set the value of location CCBPC to a different address in the mainline code to abort the section that was running. When the AST routine exits, control transfers to that address. DECNET/8 tasks must have all executable code in a single field. An AST routine does not save and restore the task's MQ. An AST routine that uses the EAE must save and restore the MQ and, if required, the step counter. If a task wishes to send a message to another task that allows an event flag for that message, or, to schedule AST, use the following routine: /ROUTINE TO SEND A MESSAGE TO A TASK /ALLOWING EVENT OR MESSAGE WAIT TO /UNBLOCK THAT TASK /THE EVENT FLAG ON THE MESSAGE TO BE /SENT MUST BE CLEAR ON ENTRY /CALL+1 = DESTINATION TASK NUMBER /CALL+2 = MESSAGE ADDRESS /AC = 0 /DF = CUR /EXIT TO CALL+3 WHEN MESSAGE IS POSTED SENDWM, 0 TAD I SENDWM /GET DEST TASK NUMBER ISZ SENDWM DCA SNDTSK /STORE IN LINE TAD I SENDWM /GET MESSAGE ADDRESS ISZ SENDWM DCA SNDMSG /STORE INLINE CAL SEND /NOW SEND IT WITHOUT WAITING SNDTSK, 0 /GETS TASK NUMBER SNDMSG, 0 /GETS MESSAGE ADDRESS TAD SNDMSG /COPY EVENT FLAG ADDRESS DCA SNDEF CAL /ISSUE RTS/8 WAITX DIRECTIVE TO ALLOW ASTS TO RUN WAITX SNDEF, 0 JMP I SENDWM /RETURN TO CALLER 2-34 RTS/8 INTERTASK COMMUNICATION 2.4 CONNECT CONTROL BLOCK An RTS/8 task using DECNET/8 must provide a Connect Control Block (CCB) to store the context of any connection made with a remote task. Each connection in the network must have its own CCB. In addition to user data, the CCB contains queue listheads and internal NSP state information. The CCB is defined in the source file CCB.PA. Refer to Chapter 5 for more information on the CCB parameters. Before the CCB can be used, the user task must initialize the following locations: Location Value ________ _____ CCBDRL The entry point of the task's AST routine. CCBSOT The object type of the local task (normally zero). CCBSN1-CCBSN6 Local task name. CCBSG,CCBSU Local task group and owner codes for the user identification code (for compatibility with other operating systems). The CCB (as well as all event flags and buffers) must reside in the resident portion of nonresident RTS/8 tasks. The CCB is not longer than 120 (octal) words and must lie in a PDP-8 page of core. (The CCB contains a small CCB exit routine at location CCBRTN, which uses current page references.) Once a connection is in progress, the contents of the CCB cannot be modified dynamically. Altering the contents of the CCB dynamically could cause a system failure. 2-35 CHAPTER 3 TERMINAL COMMUNICATIONS UTILITY (TLK) 3.1 INTRODUCTION The utility TLK consists of two tasks: "TALK" (TLK) and "LISTEN" (LSN). TLK allows the user to send messages from one terminal to another terminal in the same node or in a different node. The tasks TLK and LSN both require a CCB. TLK is invoked by an MCR request followed by a single line of input containing the node name, the terminal designation, and the message. At the target node, the LSN task prints the name of the node and the terminal sending the message, and the text of the message. Both TLK and LSN respond with a TLK> prompt and have the task name "TLK." For further information regarding MCR requests, refer to the RTS/8 User's Manual (DEC-08-ORTMA). ___________________ 3.2 INVOKING TLK An MCR REQ command is used to invoke TLK; TLK then prompts for input. The format of the command is: MCR>REQ TLK TLK>[dstnode_][dev:]['message] where: dstnode_ is the name of the target node. If the target node is the local node, this argument can be omitted. If the target node is specified, the node name must be terminated by an underscore or a backarrow. dev: is the device designation of the terminal at the target node, which will receive the message. If the terminal is the operator's console, this argument can be omitted. When using the TLK utility, the device designation usually has the form TTYn, in which n is the terminal number of the target terminal. TLK uses only the number n in determining where to send the message. For example, to talk to terminal 3, the following device designations are all acceptable: TTY3:, TT3:, or 3:. The console terminal is always terminal zero. 'message is any ASCII string containing the message to be transmitted. The message must be preceded by a single quote (') and cannot extend beyond the end of the current line. 3-1 TERMINAL COMMUNICATIONS UTILITY (TLK) If the line is terminated with RETURN, TLK prompts for additional input. If the line is terminated with ESCAPE, TLK stops running and enters run-wait mode. The message is printed at the target terminal in the following form: TLK>srcnode_TTYn: 'message where: srcnode_ is the name of the node that originated the message. TTYn: is the device designation of the source terminal. 'message is the message printed at the target terminal. 3.3 EXAMPLES If the user on TTYO: at NODE1 types the message: TLK>NODE3_TTY2:'HELLO. PLEASE TURN LP ON-LINE then the following message is printed on TTY2: at NODE3: TLK>NODE1_TTY0:'HELLO. PLEASE TURN LP ON-LINE The following command prints a message on the operator's console at the local node: TLK>' PLEASE MOUNT DECTAPE PART60 ON UNIT DTA2 To send messages longer than one line, the user must wait until TLK has transmitted a line successfully (indicated by a prompt) before entering another line. For example: TLK>NODE12_TTYl:'IF YOU WANT HOSE LISTINGS, TAPE ON DTA1 TLK>NODE12_TTYl:'UIC 256,40 NAMES H20,H2S04,HCL.FT 3.4 ERROR MESSAGES If TLK cannot complete transmission, it prints one of the following messages on the source terminal: CONNECT ABORTED The network has terminated the connection abnormally. Reissue the TLK command. DEST LSN TASK NOT INSTALLED The connection could not be established because LSN, or a similar task, is not installed at the target node. Contact the operator at the target node 3-2 TERMINAL COMMUNICATIONS UTILITY (TLK) personally. NO SUCH NODE The node name specified for the target node is not in the network. The target node name might be misspelled. Reissue the TLK command with the correct node name. NONEXISTENT TERMINAL The operating system at the target node cannot access the specified terminal. The terminal might be dedicated to another job, or no terminal at the target node has the specified number. SYNTAX ERROR A syntactical error occurred in the TLK command. Refer to Section 3.2 for the format of the TLK command. Common sources of error include omission of the underscore (or backarrow) following the node name or the single quote preceding the message. 3-3 CHAPTER 4 NETWORK INFORMATION PROGRAM (NIP) 4.1 INTRODUCTION The Network Information Program (NIP) prints status and diagnostic information about the local node and its surroundings. NIP can be made nonresident, requiring only one page of resident code and not requiring a CCB. NIP can be invoked either from the MCR terminal or by running under program control. A NIP printout consists of three parts: physical line status, logical link status, and physical line error status. The data for each part is summarized in the following sections. All numbers are octal unless otherwise specified. 4.2 PHYSICAL LINE STATUS LINE The line number of the physical line (refer to the example in Section 4.5). Line numbers begin with zero. NODNAM The name of the node adjacent to the local node on the specified line. (#) The number of the node adjacent to the local node. Node numbers are absolute and are assigned at network generation time. Nodes recognize each other by these numbers; node names can vary from node to node. STATE The state of the local line. The state is one of the following: ON-LINE OFF-LINE STARTING A line can be "ON-LINE" even though no task is currently using it. DRIVER The type of driver (e.g., KL8A and DKC8A). VRSN The version number (decimal) of the driver being used. UPSINCE If the line is "ON-LINE," the time and date when the line came up are listed under this heading. The time is in decimal, specifying hours, minutes, and seconds after midnight. 4-1 NETWORK INFORMATION PROGRAM (NIP) 4.3 LOGICAL LINK STATUS CHAN The channel number of the logical link. Channel numbers begin at one. There is one channel number for each CCB. STATE The state of the logical link using the specified channel. The state is one of the following: UNUSED IN-USE WAKING (In the process of creating a logical link) BOOT (Used in BOOT mode) LINE The physical line number used by the logical link. TASK The task number using (or waiting to use) this channel. (The task's name can be determined via the SYSTAT MCR command and may not be the same as its source name.) SRCE-NAME[PPN] The DECNET name of the task using this channel on the local node. This name can differ from the task's RTS/8 name. The PPN is of the form [GRP,USER] and is not used by RTS/8. Group and user numbers are restricted to twelve bits. TYPE The DECNET object type of the source task. The object type code is reserved for future releases of DECNET/8 providing special functions. This code should be set to 0 for task-to-task communication. LINK The logical link number of the local task using this channel. This is an internal reference number used by NSP to define the link. The logical link number can be different from the channel number. DEST-NAME[PPN] The DECNET name, group, and user number of the remote task using the logical link. TYPE The object type of the remote task. LINK The logical link number being used by the remote task. 4-2 NETWORK INFORMATION PROGRAM (NIP) 4.4 PHYSICAL LINE ERROR STATUS This portion of the NIP output prints the internal DDCMP error counters. DDCMP maintains two different groups of error counters for the ISR associated with each physical line. One group of error counters deals with error conditions that have been detected by the DDCMP module at the other end of the physical link; these errors have been reported in a NAK message. The other group of counters is for error conditions detected by the local DDCMP task in messages it has received. The same type of error occurs at both the local and the remote DDCMP. NIP prints the number of errors of each type for each line in decimal. The type of error is printed in a short English phrase. Error counters set to zero are not printed. The seven types of errors in each group are shown in Table 4-1. Table 4-1 Error Conditions Printed by NIP ---------------------------------------------------------------------- | Remote DDCMP | Local DDCMP | |----------------------------------|---------------------------------| | 1 NAK with Header CRC Error | Message with Header CRC Error | | | | | 2 NAK with Data CRC Error | Message with Data CRC Error | | | | | 3 a. NAK with Rep Response Error | b. Rep Response Time-out Error | | | | | 4 NAK with Data Overrun Error | Message with Data Overrun Error | | | | | 5 NAK with Buffer Unavailable | Message with Buffer Unavailable | | Error | Error | | | | | 6 NAK with Header Format Error| Message with Header Format Error| | | | | 7 NAK with Message Too Long | Message Too Long Error | | Error | | ---------------------------------------------------------------------- Error Condition Explanation _______________ ___________ 1 Header CRC Error The CRC value generated for the DDCMP message header at the receiving node does not match the CRC value received in the message header. All header information for this message has been discarded and the data portion of the message has been ignored. 2 Data CRC Error The CRC value generated for the data portion of the message does not match the CRC value received. The data has been discarded. 4-3 NETWORK INFORMATION PROGRAM (NIP) 3a Reply Response Sent by the receiving DDCMP module in reply to a REP issued by the transmitting DDCMP. This is used to indicate that all the data messages that the transmitting DDCMP claims to have sent, have not been received by the receiving DDCMP. 3b Reply Response Time-out When the transmitting DDCMP tasks the receiving DDCMP for verification of the sequence number of the last data message received, the transmitting DDCMP starts a timer. If the receiving DDCMP has not responded within a specified period, a timeout occurs. 4 Data Overrun This condition occurs when data is coming in faster than the receiving DDCMP can accept it. This happens when the line interface device does not regain control fast enough to accept incoming characters. 5 Buffer Unavailable The DDCMP at the receiving node did not have enough pool space available to handle the incoming message. It does not imply that anything is wrong with the message. 6 Header Format Error The DDCMP message header contains invalid or illogical information. The entire message is ignored. 7 Message Too Long The incoming message is longer than the maximum size allowed by DDCMP when it was implemented. Normally, the maximum message size for any DECNET node is 192 characters including the message size and NSP header. 4-4 NETWORK INFORMATION PROGRAM (NIP) 4.5 SAMPLE NIP PRINTOUT The following is a typical NIP printout: NETWORK INFORMATION PROGRAM V1 PHYSICAL LINE STATUS [DDCMP V4B] LINE NODNAM (#) STATE DRIVER VRSN UP SINCE 0 ACTON (3) ON-LINE KL8J 3A 8:03:35 28-DEC-76 1 MAYNRD (2) OFF-LINE DKC8 2B 2 CONCRD (5) STARTING LOCAL 15A LOGICAL LINK STATUS [NSP VllE] CHAN STATE LINE TASK SRCE-NAME[PPN] TYPE LINK DEST-NAME[PPN] TYPE LINK 1 IN-USE 0 12 TARZAN[6,0] 10 4 JANE [3,1] 7 6 2 WAKING 1 3 DONALD[2,2] 3 3 3 UNUSED 1 3 DUMMY [4,4] 29 14 4 BOOT 2 6 MASS [1,23] 3 44 PHYSICAL LINE ERROR STATUS LINE 0: 3 NAKS WITH HEADER CRC ERRORS 5 NAKS WITH DATA CRC ERRORS 83 NAKS WITH REP ERRORS 1 NAK WITH BUFFER UNAVAILABLE 2 NAKS WITH HEADER FORMAT ERRORS 192 NAKS WITH MESSAGES TOO LONG 100 MSGS WITH HEADER CRC ERRORS 1 MSG WITH REP ERROR 1 MSG WITH DATA OVERRUN 10 MSGS WITH HEADER FORMAT ERRORS 9 MSGS WITH MESSAGES TOO LONG LINE 1: NO ERRORS LINE 2: 3 NAKS WITH DATA OVERRUNS 1 MSG WITH REP ERROR 4-5 CHAPTER 5 RTS/8 DECNET/8 SYSTEM GENERATION 5.1 NETWORK GENERATION OVERVIEW DECNET/8 consists of a set of assembly modules that run under the RTS/8 V2B Executive. The RTS/8 system generation procedure has not been modified by the addition of the DECNET/8 modules. In order to do a DECNET/8 system generation, a current RTS/8 user requires only the new parameter file that contains the DECNET/8 definitions. Users can write tasks that use the DECNET/8 facilities and incorporate them into their RTS/8 system. However, the user must also load the DECNET/8 support tasks and any Interrupt Service Routines (ISRs) that are needed. The DECNET/8 support tasks include DDCMP and NSP, as well as three optional tasks: TLK, LSN, and NIP. o DDCMP implements the DIGITAL Data Communications Message Protocol. This protocol allows message transmission over a communications line. o NSP implements the Network Services Protocol. This protocol handles network management functions including routing messages between nodes and within a node. o TLK controls the Talk utility. This utility allows a user to send a message to any terminal in the network. o LSN controls the Listen utility. This utility accepts messages from TLK and prints them on the appropriate terminal. o NIP controls the Network Information Program, which prints status and diagnostic information about the network. Before generating the RTS/8 DECNET/8 system, the user must: 1. Create the user tasks and application programs that are to use the network facilities; 2. Decide which tasks to run (e.g., TLK, LSN, and NIP are optional); 3. Assign priorities to each task; 4. Decide where the tasks are to be loaded in core. The user is then ready to start system generation. System generation involves physically mounting a copy of the distribution medium, bootstrapping the development system, and editing the parameter files to build the system to suit a particular configuration. 5-1 RTS/8 DECNET/8 SYSTEM GENERATION 5.2 DECNET/8 SYSTEM GENERATION PROCEDURES The general procedures for generating an RTS/8 DECNET/8 system are: 1. Bootstrap the development system (OS/8, PTS, or CAPS/8). 2. Create all the user tasks and application programs that are to use the network facilities. These tasks and facilities must be created before system generation because the names of each task, their priorities, and their locations must be specified when PARAM.PA is edited. Include the user task parameters, CHANNL, CCB, and USRAST with each task (explained in Section 5.3). 3. Obtain a listing of the file PARAM.PA. Under OS/8, the following command can be used: .LIST PARAM.PA 4. Use an editor to establish the values of the parameters in the parameter file (PARAM.PA). The RTS/8 Executive parameters that must be specified are explained in detail in the RTS/8 User's Manual. The network parameters are listed in Table 5-2 and described in detail in Section 5.4. PARAM.PA should be read in as an input file, edited, and then renamed as an output file; this procedure maintains the integrity of DIGITAL-supplied sources. 5. Edit the Line Control File (LCF); the parameters in this file are explained in Section 5.7. 6. After all the required parameters are defined, assemble the sources with the parameter file. Appendix B of the RTS/8 User's Manual lists all the RTS/8 components, their sizes, and their default origins. For networks, assemble DDCMP and NSP. Assemble the tasks TLK, LSN, and NIP if required. Section 5.8 describes the assembly process, which creates binary files from the sources. 7. Load the binaries of the system tasks, network tasks, and user tasks. Section 5.9 describes the load process. 8. Save the RTS/8 DECNET/8 system (see Section 5.10). Section 5.11 illustrates a sample RTS/8 DECNET/8 system generation. 5.3 USER TASK PARAMETERS Each user task must have three parameters defined in its source if it uses DECNET/8 facilities. These three parameters can be specified at any point in the user task. The parameters are described in Table 5-1. 5-2 RTS/8 DECNET/8 SYSTEM GENERATION Table 5-1 User Task Parameters ---------------------------------------------------------------------- | Parameter | Contents | |---------------|----------------------------------------------------| | CHANNL | Channel number of the logical channel used by the | | | task. This channel number is used by NSP to | | | associate logical links with this task. | | | | | CCB | First memory location of the Connect Control Block | | | (CCB) area used by the task. The CCB must reside | | | in the same area as the task (i.e., field CUR) and | | | must not cross a page boundary. | | | | | USRAST | Address of the user's AST routine. Each task | | | using DECNET/8 must have an AST routine. The AST | | | routine must reside in the same field as the user | | | task (i.e., field CUR). (This symbol is coded as | | | a tag rather than an equate because the user may | | | want to write code to handle any conditions that | | | may trap to this location.) | ---------------------------------------------------------------------- Example: CHANNL = 2 /USER TASK USES CHANNEL 2 CCB = 2023 /THE CONNECT CONTROL BLOCK STARTS AT /LOCATION 2023 (OCTAL) 1000 USRAST, /THE USER AST ROUTINE BEGINS AT LOCATION /1000 Each task using a Connect Control Block must insert nine words of initial data into the CCB. The contents of the nine words are: Word Contents ____ ________ 1 DECNET object type. For intertask communication between two DECNET/8 nodes, the object type should be zero indicating task-to-task communication. 2-7 DECNET name for this task. The name should be alphanumeric, 12 bytes, zero-padded on the right. 8 The number 1 to indicate a group code. 9 The number 2 to indicate an owner code. Words 8 and 9 contain the group and owner codes that form a user identification code. Although DECNET/8 does not support user identification codes (referred to as UIC or PPN in other operating systems), it assumes [1,2] if a default request is issued from another node. User identification codes must be in the range 1 through 7777. Refer to Usage Note 3 of the CONINI request (Section 2.2.2) for more information on UICs. 5-3 RTS/8 DECNET/8 SYSTEM GENERATION 5.4 PARAMETER FILE Before running RTS/8 or DECNET/8, the user must modify the DIGITAL-supplied parameter file (PARAM.PA). The parameter file contains several user-defined symbols. These symbols determine the specific configurations for a system. The parameter file also allows users to specify the locations of DECNET/8 tasks and their priorities. The DECNET/8 tasks are: DDCMP, NSP, NIP, TLK, and LSN. NSP and DDCMP parameters are described in Section 5.4.2. NIP parameters are described in Section 5.4.3. TLK and LSN parameters are described in Section 5.4.4. LCF parameters are explained in Section 5.7. Table 5-2 summarizes these parameters. All fields are expressed as the field number multiplied by 10. For example, field 3 is represented by 30. Table 5-2 NETGEN Parameters ---------------------------------------------------------------------- |Task/File|Parameter| Function | |---------|---------|------------------------------------------------| | DDCMP | MAXLIN | Sets the maximum number of physical lines to be| | | | used. | | | | | | DDCMP | KG8E | Indicates if the system includes KG8E (CRC | | | | computation) hardware. | | | | | | DDCMP | DDCFLD | Sets the number of the field (times 10) in | | | | which the DDCMP task resides. | | | | | | DDCMP | DDCLOC | Specifies the initial memory location within | | | | the DDCMP field. | | | | | | NSP | MAXCCB | Sets the maximum number of Connect Control | | | | Blocks to be used at any one time. | | | | | | NSP | MAXNOD | Sets the number of node names to appear in the | | | | Node Name Table. | | | | | | NSP | NSPFLD | Specifies the initial location of the field in | | | | which NSP resides. | | | | | | NSP | NSPLOC |Specifies the first memory location in the NSP | | | | field. | | | | | | NSP | NODNUM | Sets the number of the node on which this | | | | DECNET/8 system operates. | | | | | |NSP/DDCMP| MAXPKT | Sets the number of 14-word (octal) I/O packets | | | | in the node pool. | ---------------------------------------------------------------------- 5-4 RTS/8 DECNET/8 SYSTEM GENERATION Table 5-2 (Cont.) NETGEN Parameters ---------------------------------------------------------------------- |Task/File|Parameter| Function | |---------|---------|------------------------------------------------| | NIP | NIPFLD | Specifies the initial location of the field in | | | | which NIP resides. | | | | | | NIP | NIPLOC | Specifies the first memory location within the | | | | field for the NIP task. | | | | | | NIP | NIPART | Indicates if NIP is disk-resident. | | | | | | NIP | SKIMP | Indicates if the smaller version of NIP is to | | | | be used. | | | | | | TLK | TLK | Sets the task number assigned to the TLK task. | | | | | | TLK | TLKFLD | Specifies the field in which TLK resides. | | | | | | TLK | TLKLOC | Specifies the starting address of TLK. | | | | | | LSN | LSN | Sets the task number assigned to the LSN task. | | | | | | LSN | LSNCHN | Sets the channel number for the LSN task. | | | | | | LSN | LSNFLD | Specifies the field number in which LSN | | | | resides. | | | | | | LSN | LSNLOC | Specifies the starting address of LSN. | | | | | | LCF | LINE | Associates a physical line number with the Line| | | | Control File. | | | | | | LCF | ADJNOD | The node number of the node located at the | | | | other end of the physical line. | | | | | | LCF | ISRFLD | Specifies the field in which the Interrupt | | | | Service Routine resides. | | | | | | LCF | ISRLOC | Specifies the first memory location within the | | | | field for the Interrupt Service Routine. | | | | | | LCF | ISRDEV | Specifies the device code used by the Interrupt| | | | Service Routine. | | | | | | LCF | ISRBRK | Specifies the address of the data break | | | | location used by the DP8E. | | | | | | LCF | BUFFLD | Sets the number of the field for the I/O buffer| | | | in the Interrupt Service Routine to reside. | ---------------------------------------------------------------------- 5-5 RTS/8 DECNET/8 SYSTEM GENERATION Table 5-2 (Cont.) NETGEN Parameters ---------------------------------------------------------------------- |Task/File|Parameter| Function | |---------|---------|------------------------------------------------| | LCF | BUFLOC | Specifies the address of the start of the I/O | | | | buffer used by the Interrupt Service Routine. | | | | | | LCF | BUFLEN | Sets the length of the I/O buffer used by the | | | | Interrupt Service Routine. | | | | | | LCF | KLMDEV | Set to the device code for the KL8M modem | | | | control option. | | | | | | LCF | KL8AMD | Set to 1 for a KL8A with modem control | | | | features. Left undefined otherwise. | | | | | | LCF | /TASK | Set if the DKC8A parallel ISR is being | | | =DKC8A | assembled. The DKC8A requires a support task. | | | | | | LCF | KL8HDX | Set to 1 if KL8M or KL8A half-duplex features | | | | are required. | ---------------------------------------------------------------------- 5.4.1 DECNET/8 Task Priorities The user must edit the parameter file to assign priorities to the DECNET/8 tasks. The user must have two tasks to run DECNET/8: DDCMP and NSP. Optionally, the user can have NIP, TLK, and LSN. For example, to have DECNET/8 support with the option of using the NIP, TLK, and LSN utilities, the following lines in PARAM.PA could be edited as follows: Original: /DDCMP= /DDCMP TASK FOR DECNET /NSP= /NETWORK SERVICES PROTOCOL TASK /NIP= /NETWORK INFORMATION PROGRAM /TLK= /TALK UTILITY /LSN= /LISTEN UTILITY Edited version: DDCMP = 5 /DDCMP TASK FOR DECNET NSP = 6 /NETWORK SERVICES PROTOCOL TASK NIP = 32 /NETWORK INFORMATION PROGRAM TLK = 35 /TALK UTILITY LSN = 36 /LISTEN UTILITY The example sets the DDCMP priority to five, the NSP priority to six, NIP to 32, TLK to 35, and LSN to 36. The priority of DDCMP should always be higher than the priority of NSP. The priorities of DDCMP and NSP must be higher than user tasks but lower than the line driver. 5-6 RTS/8 DECNET/8 SYSTEM GENERATION If any of the DECNET/8 utilities (TLK, LSN, and NIP) are not required, the user should leave the original statements undefined: /NIP = /NETWORK INFORMATION PROGRAM TLK = 35 /TASK UTILITY LSN = 36 /LISTEN UTILITY In this example, NIP is not being used. 5.4.2 DDCMP and NSP Parameters The DDCMP and NSP parameters, which must be defined by the user if DECNET/8 is to run, are described in Table 5-3. These parameters are located in the parameter file under the conditional: IFDEF NSP < They should be edited to suit the system on which DECNET/8 will run. 5-7 RTS/8 DECNET/8 SYSTEM GENERATION Table 5-3 DDCMP and NSP Parameters ---------------------------------------------------------------------- | Parameter | Purpose | |---------------|----------------------------------------------------| | MAXLIN | Sets the maximum number of physical lines to be | | | used. The lines are numbered consecutively | | | beginning with zero. | | | | | MAXCCB | Sets the maximum number of Connect Control Blocks | | | (CCB) to be used at any one time. CCBs do not | | | have to be in use simultaneously. Sections 2.1.3 | | | and 2.4 describe the CCB. | | | | | MAXNOD | Sets the number of node names appearing in the | | | Node Name Table. Section 5.5 describes the Node | | | Name Table. If no names are to be entered in the | | | Node Name Table, MAXNOD = 0 should be specified. | | | MAXNOD = 0 should be used only when intertask | | | communication is not required. | | | | | MAXPKT | Specifies how much pool space is made available to | | | DDCMP, NSP, and the ISRs for communication and | | | queueing. The node pool is divided into packets | | | of 14 words each. Each page contains 10 decimal | | | packets. The node pool space is located in core | | | directly after the DDCMP code. The default value | | | is 20 (decimal). | | | | | KG8E | Indicates whether the system uses the KG8E | | | hardware. KG8E should be set to 6xx0 (where xx is | | | the KG8E device code) to cause DECNET/8 to use the | | | hardware. If the KG8E is not to be used, this | | | parameter should be left undefined. | | | | | NSPFLD | Sets the number of the field (times 10 octal) in | | | which the NSP task resides. | | | | | NSPLOC | Sets the first memory location in the specified | | | field for the NSP task. This location must be | | | less than or equal to 3200; otherwise, an | | | assembly error is flagged. This parameter, | | | together with NETFLD, defines the field and memory | | | location of the NSP task. | | | | | DDCFLD | Sets the number of the field (times 10 octal) in | | | which the DDCMP task resides. This field must be | | | different from NSPFLD. | | | | | DDCLOC | Sets the first memory location in the specified | | | field for the DDCMP task. This parameter, to- | | | gether with DDCFLD, defines the field and memory | | | location of the DDCMP task. The default for this | | | parameter is 200. | ---------------------------------------------------------------------- 5-8 RTS/8 DECNET/8 SYSTEM GENERATION Table 5-3 (Cont.) DDCMP and NSP Parameters ---------------------------------------------------------------------- | Parameter | Purpose | |---------------|----------------------------------------------------| | NODNUM | Sets the number of the DECNET/8 node on which this | | | system runs. The system manager assigns the node | | | number, which must be greater than one. Though | | | user tasks can refer to individual nodes by | | | symbolic names (see Section 5.5), all nodes must | | | refer (internally) to this number. This number | | | must be entered into the Node Name Table of all | | | other nodes where communication with this node is | | | required. This parameter also checks received | | | routing headers. | ---------------------------------------------------------------------- Example: IFDEF NSP < MAXLIN=3 /NUMBER OF PHYSICAL LINES BEING USED /E.G. 3 FOR 3 LINES /THESE ARE NUMBERED 0,1,2 MAXCCB=3 /NUMBER OF LOGICAL CHANNELS (CCB'S) BEING USED /E.G. 3 FOR 3 CHANNELS /THESE ARE NUMBERED 1,2,3 MAXNOD=4 /NUMBER OF NODE NAMES IN NODE TABLE MAXPKT= 24 /SET TO NUMBER OF NODE POOL PACKETS /THE NODE POOL EXISTS AT THE END OF DDCMP /JUST BEFORE THE LCB TABLE (SIMILAR TO THE CLOCK QUEUE) /EACH PACKET REQUIRES 14 WORDS OCTAL. (ABOUT 10. PER PAGE) /(THE DEFAULT REQUIRES 2 PAGES CORE) /KG8E=6110 /SET TO IOT SKELETON IF KG8E IS PRESENT (E.G. 6110) NSPFLD=20 /FIELD OF NSP TASK AND MOST NETWORK TABLES /(TABLES INCLUDE CCBTAB, LNKTAB, NODTAB AND NETTAB) NSPLOC=3200 /ORIGIN OF NSP TASK. MUST BE .LE. 3200 /THE DEFAULT IS CURRENTLY 3200 DDCFLD=10 /FIELD OF DDCMP TASK, LCBTAB AND 'NODE POOL' /THIS FIELD MUST BE DIFFERENT FROM NSPFLD DDCLOC=200 /ORIGIN OF DDCMP TASK /THE ABOVE MUST BE BELOW 5000-SIZE OF NODE POOL AND LCBTAB /THE DEFAULT IS CURRENTLY 200 NODNUM=ll /NODE NUMBER OF THIS NODE LCBSIZ= 32 /GLOBAL DEFINITION OF LCB SIZE (DO NOT ALTER) PKSIZE= 14 /GLOBAL DEFINITION OF PACKET SIZE (DO NOT ALTER) 5.4.3 NIP Parameters The NIP parameters, which must be defined if NIP is required, are described in Table 5-4. These parameters are located after the Node Name Table under the conditional: 5-9 RTS/8 DECNET/8 SYSTEM GENERATION IFDEF NIP < They should be edited to suit the user's configuration. Table 5-4 NIP Parameters ---------------------------------------------------------------------- | Parameter | Purpose | |---------------|----------------------------------------------------| | NIPFLD | Sets the number of the field (times 10 octal) in | | | which NIP resides. | | | | | NIPLOC | Sets the first location in the specified field for | | | NIP. This parameter, together with NIPFLD, | | | defines the field and memory location of NIP. | | | | | NIPLOG | Sets the number of a task to a line printer or TTY | | | task. For example, NIPLOG=TTY2. IF NIPLOG is not | | | specified it defaults to LPT. | | | | | NIPRES | Sets the non-resident part of NIP to 400 words. | | | | | NIPART* | Indicates if NIP is disk-resident. If NIPART is | | | not defined, NIP is always resident. For NIP to | | | be nonresident, NIPART must be set to the | | | partition in which it is to reside. | | | | | SKIMP** | Indicates that the 8-page version of NIP is to be | | | used instead of the standard 12-page version. If | | | this option is used, an abbreviated NIP display is | | | produced when NIP is run. The full version of NIP | | | is assumed by default. | ---------------------------------------------------------------------- * The first page of NIP is the resident portion. The remainder can be made nonresident. If part of NIP is to be nonresident, NIP should start on a page boundary that is not a multiple of 400. The partition numbers and their locations are defined in the swapper. ** The abbreviated NIP display does not contain any dates, times, or printouts obtained by the full-sized NIP. All DDCMP errors, however, are still properly logged by the abbreviated form of NIP. Example: IFDEF NIP < NIPFLD= 30 /FIELD OF NIP NIPLOC= 1000 /LOCATION OF NIP NIPART= 2 /PARTITION FOR NIP SKIMP= 1 /SET TO 1 TO GET SHORT NIP > In this example, NIP resides in Field 3 at location 1000. It runs in two partitions and the shorter 8-page version rather than the 12-page version is used. 5-10 RTS/8 DECNET/8 SYSTEM GENERATION 5.4.4 TLK and LSN Parameters The TLK and LSN parameters, which must be defined if network terminal communications is required, are described in Table 5-5. Table 5-5 TLK and LSN Parameters ---------------------------------------------------------------------- | Parameter | Purpose | |---------------|----------------------------------------------------| | TLKFLD | Sets the number of the field (times 10 octal) in | | | which TLK resides. | | | | | TLKCHN | Specifies the channel number to be used by TLK. | | | | | TLKLOC | Sets the first location in the specified field for | | | TLK. This parameter, together with TLKFLD, | | | defines the field and memory location of TLK. | | | | | LSNCHN | Specifies the channel number to be used by LSN. | | | | | LSNFLD | Sets the number of the field (times 10 octal) in | | | which LSN resides. | | | | | LSNLOC | Sets the first location in the specified field for | | | LSN. This parameter, together with LSNFLD, | | | defines the field and memory location of LSN. | ---------------------------------------------------------------------- Example: IFDEF TLK < TLKFLD = 30 /TLK RESIDES IN FIELD 3 TLKLOC = 1000 /TLK RESIDES IN LOCATION 1000 /OF FIELD 3 TLKCHN = 2 /TLK USES CHANNEL 2 IFDEF LSN < LSNFLD = 20 /LSN RESIDES IN FIELD 2 LSNLOC = 1000 /LSN RESIDES IN LOCATION 1000 OF /FIELD 2 LSNCHN = 3 /LSN USES CHANNEL 3 5.5 NODE NAME TABLE During system generation, the correspondence between node names and node numbers is specified in the Node Name Table. The network manager assigns a node number to each node in a network. Node numbers must be in the range one to 177 (octal). Each node number must be unique. In contrast, users assign node names for the nodes that they use. Consequently, a node in the network can have several names or none at all, but each has a unique node number. 5-11 RTS/8 DECNET/8 SYSTEM GENERATION The node name can be used by user tasks when referring to this node. The node number is used by NSP to recognize messages intended for this node. Figure 5-1 illustrates the Node Name Table section of the parameter file. ---------------------------------------------------------------------- | /NODE TABLE ENTRIES | | | | /EACH ENTRY HAS THE FORM | | /WORDS 1-3 NODE NAME (6-BIT, 0-PADDED) | | /WORD 4 LINE NUMBER | | /WORD 5 BIT 0=1 IF ADJACENT NODE | | / BITS 4-11 CONTAIN NODE NUMBER | | | | IFDEF TASK < IFZERO TASK-NSP < | | FIELD NETFLD%10 | | *7500 | | | | NODTAB, TEXT /NODE.Y/ | | *. - 1 | | 0 /LINE NUMBER | | 4000 /NODE NUMBER | | *NETTAB+4 | | NODNUM /OUR NODE NUMBER | | TEXT /NODE.X/ /OUR NODE NAME WITH ADJACENT FLAG | | /SET | | FIELD 0 | | >> | | > | ---------------------------------------------------------------------- Figure 5-1 Node Name Table The user modifies the line NODNUM /OUR NODE NUMBER to add the node number, and the line TEXT /NODE.X/ /OUR NODE NAME to add the node name. In the following example, three nodes are named. (The network can consist of more than three nodes.) Node 2 has the node name of NOD22 and is an adjacent node. (The node is directly connected to the user's system; no route-through is needed.) Node 3 has the node name NOD506 and is an adjacent node. Node 5 has the node name X and is not adjacent (that is, it is not directly connected). NODTAB, TEXT/NOD22/ *.-1 0 4002 TEXT/NOD506/ *.-1 5-12 RTS/8 DECNET/8 SYSTEM GENERATION 1 4003 TEXT/X/;0;0 1 5 To send messages to other terminals on the user's system, the user must include the local system's name in the Node Name Table. If a node number of an adjacent node is not known, the user should set the node number to zero in the Node Name Table. This procedure can be used only for adjacent nodes (i.e., one directly connected via a physical link). The number of entries in the Node Name Table must be equivalent to the parameter MAXNOD specified earlier in the parameter file. The user must enter the exact number of entries in the Node Name Table as indicated by MAXNOD. 5.6 INTERRUPT SERVICE ROUTINES Once information on NSP, DDCMP, NIP, TLK, and LSN has been incorporated and the Node Name Table set up, the user must specify information on the system's physical lines. For eac