|
Copyright © 1982
Digital Research
P.O. Box 579
160 Central Avenue
Pacific Grove, CA 93950
(408) 649-3896
TWX 910 360 5001
All Rights Reserved
COPYRIGHT
Copyright © 1980, 1981, 1982 by Digital Research. All rights reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual or otherwise, without the prior written permission of Digital Research, Post Office Box 579, Pacific Grove, California, 93950.
Portions of this manual are, however, tutorial in nature. Thus, the reader is granted permission to include the example programs, either in whole or in part, in his own programs.
DISCLAIMER
Digital Research makes no representations or warranties with respect to the contents hereof and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose. Further, Digital Research reserves the right to revise this publication and to make changes from time to time in the content hereof without obligation of Digital Research to notify any person of such revision or changes.
TRADEMARKS
CP/M and CP/NET are registered trademarks of Digital Research. ASM, CP/NOS, DDT, LINK-80, MP/M II, RMAC, SID, and ZSID are trademarks of Digital Research. Altos is a registered trademark of Altos Computer Systems. Intel is a registered trademark of Intel Corporation. Keybrook is a registered trademark of Keybrook Business Systems, Inc. ULCnet is a registered trademark of Orange Compuco, Inc. Xerox, 820 Computer, and R820-II are registered trademarks of Xerox Corporation. Z80 is a registered trademark of Zilog, Inc. Corvus OMNINET is a trademark of Corvus Systems, Inc. DSC-2 is a trademark of Digital Microsystems. DB8/5200 is a trademark of Dynabyte. FileServer is a trademark of Keybrook Business Systems, Inc.
The CP/NET Network Operating System Reference Manual was prepared using the Digital Research TEX Text Formatter and printed in the United States of America by Commercial Press/Monterey.
Fifth Edition: November 1982
Foreword
CP/NET®, a network operating system, enables microcomputers to access common resources via a network. CP/NET allows microcomputers to share and transfer disk files, to share printers and consoles, and to share programs and data bases. CP/NET consists of servers running MP/M II® and requesters running CP/M®. The servers are hosts that manage the shared resources that the network requesters can access.
The hardware environment for CP/NET must include two or more microcomputers that can communicate in some way.
One of the microcomputers must execute the MP/M II operating system to provide the CP/NET server facilities. The processor executing MP/M II must be an 8080, 8085, or Z80 CPU with a minimum of 32K bytes of memory, 1 to 16 consoles, 1 to 16 logical or physical disk drives each containing up to eight megabytes, a clock/timer interrupt, and a network interface.
The CP/NET requester microcomputers must have 8080, 8085, or Z80 CPUs with at least 16K bytes of memory, 0 to 16 logical or physical disk drives each containing up to eight megabytes, and a network interface. A console is not absolutely required although it is strongly recommended.
The CP/NET Network Operating System Reference Manual is intended for several different levels of CP/NET users. It contains all the information you need to use CP/M applications programs on a CP/NET requester, to write new application programs under CP/NET, and to customize CP/NET for a specific network.
Section 1, an overview of the CP/NET system, discusses CP/NET features, network topologies, and the principles behind CP/NET operation.
Section 2 contains all the information you need to use the network when executing CP/M application programs. You need no skill level beyond that required for normal CP/M operation.
Section 3 describes the CP/NET interprocessor message format and each of the Network Disk Operating System (NDOS) functions you can invoke from application programs. This section provides the information you need to access the network primitives. Section 3 also discusses the implications of performing CP/M operations on a resource controlled by the MP/M II operating system.
Section 4 provides information for the systems programmer. This section describes how to write a custom Slave Network 1/0 System (SNIOS) that performs the CP/NET requester network functions. The mechanics of implementing and debugging a custom SNIOS are also discussed. Programmers attempting to develop an SNIOS should be familiar with CP/M and experienced in writing a custom CP/M BIOS. This section also explains how to write a custom Network Interface Process (NETWRKIF) that performs the CP/NET server network functions.
Section 4 also discusses implementing and debugging the NETWRKIF module. You must have a high degree of competence and experience with MP/M II to develop a custom NETWRKIF. You must be familiar with the process and queue descriptor data structures and the MP/M II XDOS primitive functions. Experience with implementing an XIOS for MP/M II might also be necessary.
Appendixes to this manual contain several example network communications packages.
Table of Contents
1 CP/NET Overview
1.1 CP/NET Features
1.2 CP/NET Configurations
1.3 How the Requester Works
1.4 How the Server Works
2 CP/NET Utilities
2.1 The LOGIN Command
2.2 The LOGOFF Command
2.3 The NETWORK Command
2.4 The LOCAL Command
2.5 The ENDLIST Command
2.6 The DSKRESET Command
2.7 The CPNETLDR Command
2.8 The CPNETSTS Command
2.9 CTRL-P
2.10 The MAIL Utility
2.10.1 Menus
2.10.2 Data Entry
2.10.3 MAIL Options
2.10.4 Error Messages
3 CP/NET Programmer's Guide
3.1 CP/NET Interprocessor Message Format
3.1.1 Message Format Code
3.1.2 Message Destination Processor ID
3.1.3 Message Source Processor ID
3.1.4 CP/M Function Code
3.1.5 Size
3.1.6 CP/NET Message
3.1.7 Additional Packaging Overhead
3.2 Running Applications Transparently Under CP/NET
3.2.1 MP/M II vs. CP/M File Systems
3.2.2 Error Handling Under CP/NET
3.2.3 Temporary Filename Translation
3.2.4 Opening System Files on User 0
3.2.5 Compatibility Attributes
3.2.6 Password Protection Under CP/NET
3.2.7 Networked List and Console Devices
3.3 CP/NET Function Extensions to CP/M
3.4 CP/NET Applications
4 CP/NET System Guide
4.1 General Network Considerations
4.1.1 Functions of the CP/NET Physical Modules
4.1.2 Interfacing a Computer to a Network
4.1.3 Developing a Network Layer
4.1.4 Error Recovery
4.2 Customizing the Requester's SNIOS
4.2.1 Slave Network 1/0 System Entry Points
4.2.2 Requester Configuration Table
4.2.3 Prefiguring the Configuration Table
4.2.4 Sending and Receiving Messages
4.2.5 Generating and Debugging a Custom SNIOS
4.3 Customizing the Server
4.3.1 Detecting and Receiving Incoming Messages
4.3.2 The Architecture of the NETWRKIF Module
4.3.3 Elements of the NETWRKIF
4.3.4 Enhancements and Additions to the NETWRKIF
4.3.5 MP/M II Performance Factors and NETWRKIF
4.3.6 Generating the NETWRKIF
4.3.7 Debugging the NETWIRKIF
4.4 Implementing Non-MP/M II Servers
Appendixes
A CP/NOS
A.1 Overview
A.2 System Requirements
A.3 Customizing the CP/NOS
A.4 Building the CP/NOS System
A.5 Debugging the System
B CP/NET 1.2 Standard Message Formats
C CP/NET 1.2 Logical Message Specifications
E A Simple RS-232C CP/NET System
E.1 Protocol Handshake
E.2 Binary Protocol Message Format
E.3 ASCII Protocol Message Format
E.4 Modifying the SNIOS
E.5 Modifying the NETWRKIF
F A CP/NET System for Use with ULCnet
F.1 Overview of ULCnet
F.2 Customizing a ULCnet SNIOS for the Requester
F.3 Creating the ULCnet Server
G Using CP/NET 1.2 With Corvus OMNINET
G.1 The Corvus Engineering Transporter
G.2 Implementation Structure
G.3 The SNIOS Implementation
G.4 The NETWRKIF Implementation Model
G.5 Possible Improvements to NETWRKIF
Tables
2-1. Receive Mail Message-handling Options
3-1. Interface Attributes
3-2. BDOS Error Modes
4-1. Requester Configuration Table
4-2. Server Configuration Table
4-3. Requester Control Block
B-1. Message Field Length Table
C-1. Conventional CP/NET Messages
G-1. Transporter Command Block
G-2. Receive Result Block
Figures
1-1. Standard CP/NET Configuration
1-2. CP/NOS Configuration
1-3. Single Requester Networked to MP/M II Server
1-4. Multiple Requesters in Hub-star Configuration
1-5. Multidrop Network
1-6. Hybrid Network
1-7. CP/NET Memory Structure
1-8. A Simple Server Supporting Three Requesters
4-1. Layered Model of a CP/NET Network Node
4-2. Network Status Byte Format
4-3. Algorithm for Interrupt-driven Requester Node
4-4. Server Architecture
4-5. Two-process NETWRKIF
4-6. Transport Process/Data-link Processes Interface
4-7. Directly Interfacing NETWRKIF to XIOS Routines
4-8. Synchronizing Data-link Activity Using Flags
4-9. A Typical Server Memory Map
4-10. Implementing Timeouts with Flags
B-1. CP/NET 1.2 Logical Message Format
E-1. Protocol Handshake
E-2. Binary Protocol Message Format
E-3. ASCII Protocol Message Format
Listings
2-1. A Typical CPNETLDR Execution
2-2. A Typical CPNETSTS Execution
4-1. SNIOS Jump Vector
4-2. Stack and Process Descriptor Allocation for Four-requester Server
E-1. Requester Network I/O System
E-2. Server Network I/F Module
F-1. Requester Network I/O System for ULCnet
F-2. NETWRKIF for Systems Running ULCnet
F-3. ULCnet Data-link Layer MP/M XIOS Module
G-1. Sample SNIOS for Corvus OMNINET
G-2. Sample Server Network I/F for Corvus OMNINET
By separating the logical operating system from the hardware environment and placing all hardware-independent code in a separate I/O module, CP/M and MP/M II have gained widespread industry acceptance. The CP/NET operating system uses this same design approach. CP/NET is network independent. The Slave Network I/O System (SNIOS) module contains all network-dependent code for the requester. The Network Interface Process (NETWRKIF) module contains all network-dependent code for the server. Logical messages passed to and from the SNIOS or NETWRKIF are transmitted over an arbitrary network between servers and requesters using an arbitrary network protocol.
CP/NET and CP/NOS can be combined in a composite network consisting of MP/M II servers, CP/M requesters, and diskless CP/NOS requesters.
CP/NET is a bridge between a microcomputer running MP/M II and a microcomputer running CP/M. The MP/M II server manages resources that are considered public to the network. The CP/NET requesters executing CP/M have access to the public resources of the server and to their own local private resources, which cannot be accessed from the network. This architecture permits the server's resources to be shared among the requesters, yet guarantees the security of the requester's resources.
The MP/M II server responds to the network asynchronously in real-time; the CP/M requesters perform sequential I/O and are usually not capable of monitoring a network interface in real-time. Figure 1-1 illustrates the relationship between CP/M, MP/M II, and CP/NET.
|
|
CP/NOS, the second network operating system product, is designed for applications where the requester microcomputer lacks disk resources and is therefore unable to run CP/M. CP/NOS consists of
At the user level, CP/NOS provides a virtual CP/M 2.X system to the requester microcomputer. A requester microcomputer can consist of no more than a processor, memory, and an interface to the network. Thus, a CRT with sufficient RAM can execute CP/M programs, performing its computing locally and depending on the network to provide all disk, printer, and other I/O facilities. Figure 1-2 illustrates the relationship between CP/NOS, MP/M II, and CP/NET.
|
CP/NET operates in multiple-processor environments ranging from tightly to loosely coupled to networked processors. In this manual, tightly coupled processors are those sharing at least a portion of common memory. Interprocessor messages communicate at memory speed. Loosely coupled processors do not have access to memory that is common or accessible by both processors; they communicate via a short, high-speed bus. Loosely coupled processors usually reside in the same physical box. Networked processors are usually physically separated and communicate over a serial link.
The CP/NET operating system is an upward-compatible version of CP/M 2.2, which provides system I/O facilities to requester microcomputers through a network. Additions to the Basic I/O System (BIOS) called the Slave Network I/O System (SNIOS) , and a new Basic Disk Operating System (BDOS) called the Network Disk Operating System (NDOS) , provide network access to System I/O facilities. The requester NDOS and NIOS are loaded and executed while running under CP/M 2.2.
In addition to the standard CP/M facilities, CP/NET provides the following capabilities:
The MP/M II server is implemented by adding some resident system processes at system generation (GENSYS) time. The resident system processes include server processes (SERVER) that perform the logical message-handling functions for the server and network interface processes (NETWRKIF) that you can customize for a particular hardware network interface.
CP/NET supports a number of different network topologies and a variety of system resources. The interprocessor message formats permit a requester to access more than one server for different resources.
Figure 1-3 illustrates an MP/M II system supporting a single CP/NET requester. The requester is a totally independent system, with its own console, printer, and disk resources. The requester can also access the MP/M II system's resources over the network. The MP/M II system also supports other users using local terminals.
Figure 1-4 shows an active hub-star network running CP/NET. Each requester is networked to the server through a unique network port. The requesters have their own local resources, but they also share the server's disk and printer resources. This topology is simple to implement because you can adapt the network protocol from the protocol used for RS-232 console drivers. The sample system in Appendix E uses this topology.
Figure 1-5 shows a system of three requesters and two servers networked together in a bus or multi-drop configuration. The network protocol must be capable of resolving conflicts when nodes attempt to use the network simultaneously. Each requester has access to the resources of both servers, in addition to its own local resources. Appendixes F and G provide examples of CP/NET systems using this network topology.
Finally, you can combine these topologies, as well as other topologies like loops and trees, into a hybrid network topology. Figure 1-6 depicts such a topology, combining the bus, star, and loop forms.
The CP/NET requester software runs under an unmodified CP/M version 2 operating system. The requester operating system consists Of three object modules: NDOS.SPR, SNIOS.SPR, and CCP.SPR. These modules are system page relocatable files that can be loaded directly under the CP/M BDOS and BIOS, regardless of their size or their location in memory.
The module NDOS.SPR contains the Network Disk Operating System (NDOS) , the logical portion of the CP/NET system. The NDOS determines whether devices referenced by CP/M function calls are local to the requester or whether they are located on a remote system across a network. If a referenced device is networked, the NDOS, prepares messages to be sent across the network, controls their transmission, and finally reformats the result received from the network into a form usable by the calling application program. NDOS.SPR is distributed in object form by Digital Research. No modification to this module is required to run CP/NET.
The Slave Network I/O System (SNIOS) is contained in the module SNIOS.SPR. The systems implementer must customize this software to run on a particular computer and network system. The SNIOS performs primitive operations that allow the NDOS to send and receive messages across a network. The SNIOS also provides a number of housekeeping and status functions to the NDOS. Digital Research distributes a number of example SNIOS modules in source form with CP/NET.
The final module, CCP.SPR, is a replacement for the normal CP/M CCP. Like the regular CCP, CCP.SPR is loaded directly below the operating system. However, CCP.SPR performs a number of special network functions that initialize the environment for a program.
The logical origin of SPR files is location zero. Each file has a 256-byte header, with locations 1 and 2 defined as the length of the code in the f ile. A bit map, appended to the end of the code, identifies bytes of the code that must be relocated when the code is loaded on a particular page (256-byte) boundary.
The CP/NET utility CPNETLDR relocates the bytes def ined by the bit map. CPNETLDR loads SNIOS.SPR directly below the CP/M BDOS. NDOS.SPR is loaded directly below the SNIOS. CPNETLDR then passes control to an initialization routine. This routine modifies key areas of the operating system:
After these modifications have been made, the NDOS calls the SNIOS to initialize the network. The NDOS then jumps to its own warm boot routine, which performs a disk system reset, loads CCp.SPR, and then passes control to the CCP.
When an application program calls the CP/NET operating system via location 5, the NDOS is entered instead of the BDOS. Invalid functions return to the user program immediately as errors. Functions dealing with console or printer I/O immediately pass through to the local BDOS; but these functions are intercepted by the NDOS again when the BDOS calls the BIOS. At this level, the NDOS checks whether the console or printer is a networked device. If so, the NDOS sends a request across the network for the input or output.
Some functions have no meaning when they are sent across the network to a remote server. Examples of these are Function 26 (Set DMA Address), Function 32 (Get/Set User Number), and Function 12 (Return Version Number) . The local BDOS always handles these functions. But the NDOS saves certain parameters from these functions for its own use, processing them before allowing them through to the BDOS.
Finally, the NDOS checks most functions that deal with either the disk drive system or the file system to determine whether they reference local devices. If so, these functions pass unmodified to the BDOS. The NDOS also checks whether these functions reference devices that exist somewhere out on the network. If they do, the NDOS constructs a network message to be sent to the system on which the device exists. The network message contains the network function to be performed and the information necessary to perform it.
Figure 1-7 illustrates how the CP/NET operating system is organized. The solid line outlines the function flow of an operation on a networked disk drive. The dotted line traces the flow of an I/O operation to a networked list device or console. Arrows indicate possible function flow.
When an NDOS requester sends a function message out over the network, a response from the addressed server is implied. As soon as the NDOS has successfully called the SNIOS to send the message, the NDOS calls the corresponding message receive routine, also in the SNIOS. This procedure precludes the problem of trying to recover sequencing information from an arbitrary stream of messages.
The NDOS uses the network response to update the application program that made the function call. The NDOS then returns to the application program. If the device referenced was local, then the requester's BDOS updates the application program.
Unlike the requester, the server software that runs under Mp/M II does not modify the actual operating system. Rather, the operating system is a set of cooperating processes under MP/M II.
In its most basic form, each requester to be attached to a server requires two processes, communicating through two queues. One process, resident in the NETWRKIF.RSP module, performs the physical message transport task. The systems implementer must modify this process to accommodate the network's node-to-node protocol. The process's protocol must be compatible with that of the requester's SNIOS.
The NETWRKIF must be capable of monitoring one or more network lines in real-time and detecting when a requester is trying to send a message. The NETWRKIF must then receive the message, check it for data integrity, and send it on to the logical portion of the server, contained in the module SERVER.RSP. When the SERVER module returns its response to the logical message, the NETWRKIF must receive the message and then transmit it across the network back to the requester.
The module SERVER.RSP performs the logical operation the requester specifies. After receiving the message from the NETWRKIF, SERVER.RSP checks to make sure that the requester is logged in properly. Then SERVER.RSP responds to the message by performing a series of MP/M II operating system calls. Using the information returned by those calls, the SERVER constructs a response message and sends it to the NETWRKIF module for transmission.
Both the NETWRKIF and SERVER modules are Resident System Process files (RSPs) . RSPs are built into the MP/M II system during its GENSYS operation. When MP/M II is cold started, all RSPs are automatically dispatched. Each RSP module might contain multiple processes, but only one process per RSP is automatically dispatched. Because each requester bound to a server might require one process from the NETWRKIF and one from the SERVER, both RSPs contain initialization code to create additional copies of themselves. These processes can be reentrant. They can share the same code, but they have separate data areas to avoid conflict between program variables.
One of the simplest server architectures is shown in Figure 1-8.
Processes from the NETWRKIF are named NtwrkIP<x>
where <x> is the ASCII representation of a hexadecimal number
between 0 and F. SERVER processes are named
SERVR<x>PR.
A NtwrkIP<x> process writes the address of an input message to a queue named NtwrkQI<x>. A SERVR<x>PR process reads this queue while waiting for an input message. Because the queue is empty when the requester is not requesting service, the SERVR<x>PR process is suspended and consumes no CPU resources.
When the NtwrkIP<x> process writes to the queue, the SERVR<x>PR process is dispatched, and it begins to operate on the message. As soon as the NtwrkIP<x> process has finished sending the incoming message to NtwrkQI<x>, NTWRKIP<x> immediately tries to read a second queue, named NtwrkQO<x>. This queue is empty, and the NtwrkIP<x> process is consequently suspended until the SERVR<x>PR process writes the response message to it. The NtwrkIP<x> can then transmit the message back to the requester.
Server functions can be divided into four categories:
Session control functions permit a requester to log on to a server, log off, set compatibility attributes, set default passwords, and examine the server configuration table.
File serving functions make up the bulk of the server's work. These functions include opening and closing networked files, reading and writing files, and managing disk devices.
The server can operate as a print server in two different modes. If the MP/M module SPOOL.RSP is present in the system, requester outputs to a networked list device are spooled to a file for future printing. If no spooler exists in the system, the server manages the attaching and detaching of various print devices.
Finally, the NETWRKIF module can be designed to recognize a logical message that has no meaning to the SERVER module, but that can be operated on by a user-defined process. This feature allows you to use functions CP/NET does not provide.
Section 2 This section describes the requester commands that enable you
to access the network and use its resources. All the requester
commands are actually COM files that reside on disk at the
requester.
The LOGIN command allows a requester to log in to a specified
server. A requester must log in before any resources on the server
can be accessed. Once a requester has logged in, it is not
necessary to log in again even though the requester might power down
and then power up again. A requester can only be logged off a
server by an explicit LOGOFF command issued from the requester. The
command takes the general form:
where The LOGOFF command allows a requester to log off f rom a
specified server. Once a requester has logged off, the server
cannot be accessed again until you issue a LOGIN command. The
command takes the general form:
where 2.3 The NETWORK Command
The NETWORK command enables a requester to assign selected I/O
to the network. The NETWORK command updates the requester
Configuration table. The command takes the general form:
Note: when networking drive A: to a server, the file CCP.SPR must
reside on the networked drive, or warm boot operations fail. Do not
network a device to a nonexistent or off-line server because network
errors could result.
The LOCAL command enables a requester to reassign selected I/O
back to local from the network. The LOCAL command updates the
requester configuration table. The command takes the general
form:
where The ENDLIST command sends a hexadecimal 0FF to the list device,
signaling that a list output to a networked printer is finished. If
a spooler is resident on the server, the spool file is closed and
enqueued for printing. If no spool file is present, the networked
list device is freed for use by another requester.
Note: the CCP implements an endlist every time a program
terminates, provided that CTRL-P is not active at the time. Turning
CTRL-P off also causes an endlist.
The DSKRESET command functions exactly like the PRL that
executes under MP/M II. DSKRESET resets the specified drive, so a
disk can be changed. The command takes the general form:
where The following are typical disk resets:
The CPNETLDR command loads the requester CP/NET system.
Specifically, the SNIOS.SPR file loads and relocates directly below
the CP/M BDOS. The NDOS. SPR f ile loads and relocates directly below
the SNIOS.
From that point on, the BIOS, BDOS, SNIOS, and NDOS remain
resident in memory. The CPNETLDR requires no user customization.
CPNETLDR displays an error message when loader errors are
encountered. Listing 2-1 is a typical CPNETLDR execution.
The CPNETSTS command displays the requester configuration
table. The requester configuration table indicates the status of
each logical device that is either local or assigned to a specific
server on the network. Listing 2-2 shows a typical CPNETSTS
execution.
A CTRL-P causes console output to be echoed to the list device
until the next CTRL-P. The messages
and
are displayed at the console. When the requester list device has
been networked, the local system uses the server printer. The
second CTRL-P causes a hexadedimal FF to be sent to the server,
causing the server to close and print the spool file.
Note: when the requester uses the server printer with a CTRL-P
active, the requester must issue a second CTRL-P to cause the server
to close the spooled file and begin printing it. When the requester
is using the server printer and has invoked it with a program such
as PIP, the warm boot at program termination causes the required
endlist character to be sent to the server to close and print the
spooled file.
The program ENDLIST is not needed to terminate network list
output in these situations.
The MAIL utility allows you to send, receive, and manage
electronic mail in a network environment. MAIL operates using file
based function calls, so special processing by the server is not
required. MAIL runs transparently on either server or requester, so
only one program is required throughout the entire electronic mail
system.
MAIL allows you to send messages to a single node, broadcast
messages to all nodes currently logged in, or receive messages.
Messages are stored for your future examination on the
temporary file drives of CP/NET servers. A user's mail file is
named
where xx corresponds to your node ID. For example, if requester #5C
wants his mail, the MAIL program accesses files named 5CMAIL.TEX on
the temporary file drives of all the servers that node 5C currently
has logged in. Every server in the CP/NET system might have one of
these files, so other nodes in the network that do not have direct
access to all of node 5C's servers can still send messages
indirectly to it.
Menu-driven operation allows you to run the program with a
minimum of instruction. Messages are limited in size to 1.7K bytes.
You can enter messages into the system directly from the keyboard or
through a preedited file. Options allow you to answer a message
immediately while reading your mail and to delete unwanted entries.
Three basic menus can appear during a MAIL session:
The Main Menu determines the basic operation to be performed. The
Input Source Menu specifies whether input comes from a file or
whether you enter it directly. Finally, the Receive Response Menu
determines the disposition of messages you receive.
Enter a menu selection by typing the number associated with the
selection, followed by a carriage return. If you type an invalid
character or no character at all, the menu system defaults to the
last item on the menu. You simply press the carriage return for
common operations.
Main Mail Menu
The main mail menu appears when you enter the mail program and
when any of its options have completed execution. Main mail menu
options are
A simple carriage return or an invalid entry at this level return
you to CP/M or MP/M II command level.
Input Source Menu
The input source menu allows you to specify how message input
is entered into the system. The input source menu has only two
options:
Receive Response Menu
The receive response menu determines the disposition of
messages once the user has examined them. The options are
In addition to the menus, MAIL prompts you for a variety of
inputs. These inputs determine the destination of messages, input
files, and subjects.
Destination ID Prompt
When using the send mail option, MAIL requires an explicit
destination to deliver the message properly. The system prompts for
the destination. The legal value is a 2-digit hexadecimal number,
followed by a carriage return. This value corresponds to a CP/NET
server or requester ID value.
If you enter a value that is not a legal hexadecimal number,
the system displays an error message, and prompts you again. The
system does not check, however, to determine whether a requester or
server with this ID exists on the network.
Subject Prompt
With both the broadcast and send mail options, MAIL prompts for
a subject header. This header is displayed as the title of the
message and is also used for answering mail to the message that is
sent.
When the system prompts for subject, you can enter a subject
header from 0 to 80 bytes long, followed by a carriage return.
Input File Prompt
If a preedited file contains the text of a message, MAIL
prompts for the filename. You can then enter a valid CP/M file
specification. If the file specified does not exist, the system
displays an OPEN ERROR, and the program aborts.
Console Input Prompt
If you choose to enter a message directly from the console,
MAIL prompts for input. You can then simply type the message.
Individual message lines can be up to 78 characters long. A
message, whether input from the console or from a file, must be no
longer than 1764 characters, about enough to fill a standard
terminal display. Longer messages are truncated.
To terminate input, the user presses CTRL-Z, followed by a
carriage return.
This section explains how the CP/NET system gathers and
receives mail and how you control the disposition of mail.
Broadcast
The broadcast option sends a message to every node that it can
find logged in to the CP/NET system.
MAIL works differently when it is running on a server under
MP/M II, from the way it works when it is running on a requester
under CP/M or CP/NOS. If a requester is broadcasting, MAIL sends
the specified message to every server on which it is logged in as
well as to every other requester logged in to those servers. If a
server is broadcasting, MAIL sends the message only to every
requester logged in to that server. A server has no means of
initiating transactions with other servers, although it can use its
own local MP/M II system to file mail for its own requesters.
A message cannot be broadcast to the broadcasting node.
To send a message to a given server and its associated
requesters, MAIL must reference that server's temporary file drive
across the network. If a requester has not networked the temporary
file drive of a server, no messages are sent to that server.
When the broadcast option is entered, MAIL prompts you for a
subject and message. When the operation is completed, it returns to
the main menu.
Send Mail
The send mail option sends a message to a specific node in the
CP/NET system. The destination can be either a server or a
requester. If the option is running on a requester, it first
searches the network to see if the node specified is logged in. If
the option finds the node is logged in, it sends the message. if
the option does not find the node, it leaves the message on the
first server located when MAIL searches the local configuration
table. If a destination requester logs in later, its mail will be
waiting for it. Mail files can accumulate that were erroneously
sent to nonexistent requesters or to servers that the requester
sending the message had not logged onto when it sent the message.
If the option is running on a server, mail is left on that
server, whether the node it is being sent to is logged in or not.
Upon selecting the send mail option, MAIL prompts you for a
destination ID, a subject, and for the message itself. MAIL then
attempts to send the message. If MAIL cannot find a server with a
temporary file drive to accept the message, the error NO SERVER MAIL
DRIVE NETWORKED is displayed, and the program aborts.
Receive Mail
The receive mail option permits you to examine messages left
for you on all the servers on which you are currently logged in.
After each message is displayed, you are presented with a number of
message-handling options.
If you are running MAIL on the server, only the mail file on
the server is accessed. However, if MAIL is being run on a
requester, each server to which the requester is logged in is
searched for messages.
Each message is preceded by a header that tells you what node
the message came from and the subject of the message. The actual
message is then displayed. As a message is being displayed, you can
halt the display by pressing CTRL-S and resume display by pressing
CTRL-Q. At the end of the message, bring up the receive response
menu by pressing any key. You can then take one of the options
listed in Table 2-1.
Upon completion of any message-handling options, with the exception
of the reexamine option, the next message is displayed.
In addition to the error messages already mentioned, CP/NET
returns file system errors. These errors display
followed by a filename. After displaying such an error, MAIL
aborts.
It is possible to get the ERROR OPENING FILE message by
specifying a nonexistent input file for sending or broadcasting a
message. Almost all other instances of the messages, however,
indicate possibly serious trouble with the network, the server file
system, or the mail-handling system.
Section 3 This section provides information for the applications
programmer who wants to write programs to run under CP/NET or to
evaluate the performance and correctness of programs written for
CP/M or MP/M II under the CP/NET operating system.
MP/M II performs all operations on a networked device and makes
file security checks that CP/M does not usually make. Because MP/M
was designed to run unmodified CP/M applications, these checks
seldom prevent the use of a CP/M application under CP/NET.
3.1 CP/NET Interprocessor Message Format
The simple message format that CP/NET uses for interprocessor
communication includes packaging overhead and the message itself.
The packaging overhead is a header consisting of a message format
code, a CP/NET destination address, a CP/NET source address, a CP/M
function code, and a message size. The actual CP/NET message
follows the header.
The message format code is a single byte that specifies the
format of the message itself. Digital Research reserves message
formats 0-127 for general interprocessor message format codes and
future use. The general interprocessor format codes follow the
message format shown below, but differ in length of the individual
fields. (See Appendix B.)
The odd-numbered format codes are for response messages sent
baCk from servers to requesters. Thus, a CP/M disk read function
sent from a requester to a server has a message format code of 0,
and the return code sent back from the server to the requester has a
message format code of 1.
Implement the general interprocessor message formats 0 and 1 as
shown
in Appendix A
because these formats promote standardization among microcomputers
from different vendors.
3.1.2 Message Destination Processor ID
The message destination processor ID field is one byte long.
Destination IDs can be in the range O-0FE hex. An ID of 0FF is
illegal. Many CP/NET utilities use a server destination of 0 as a
default. For this reason, assign the most commonly used network
server a node ID of 0.
3.1.3 Message Source Processor ID
The message source processor ID field is usually one byte long.
The node sending the message always fills this field with its own
ID. Valid source IDs range from 0 to 0FE hex. An ID of 0FF is
illegal.
The CP/M function code field is one byte long. The size of the
message data field depends on the CP/M function. Each CP/M function
has a specific number of bytes to be sent to the server and a
specific number of bytes to be returned to the requester. Appendix
C provides the logical message specification for each of the CP/M
functions. Some of the CP/M function codes have no equivalent
network function.
The size field is one byte long. The size value has a bias of
1. Thus, a size of 0 specifies an actual size of 1, while a size of
255 specifies an actual size of 256. With a 1-byte size field, the
minimum data field is 1 byte, and the maximum is 256.
The CP/NET message consists of binary data and is from 0 to 256
bytes long. The meaning of the message depends on the format,
function, and size specified by the header.
3.1.7 Additional Packaging Overhead
Some networks might have to modify the standard CP/NET message
to transmit it over the physical network medium, route it to the
proper destination, and ensure its integrity.
For example, the message format shown in
Figure 3-1 contains no
cyclic redundancy code (CRC) or any other error checking as a part
of the packaging overhead. The user-written SNIOS can add the error
checking when it places the message onto the network, and then test
the message when the SNIOS receives a message from the network.
This function is intentionally left to the user, avoiding redundant
error checking where standard interface protocols, both in software
and hardware, might already provide error checking.
The NDOS always constructs messages using format 0. Likewise,
the server processes always expect to receive messages in format 0.
The server sends its response in format 1, which the NDOS requires
to interpret the response. If the SNIOS and NETWRKIF must
communicate using a different format, they must convert all received
messages back into the standard formats 0 and 1.
3.2 Running Applications Transparently under CP/NET
Applications that use local devices under CP/NET use the CP/M 2.2 BDOS file system.
Applications that use networked devices use he MP/M II file system. These operating
systems are largely compatible with each other, so applications written to run under CP/M
should run across the network with no changes.
But there are some differences between the two file systems:
Differences between the CP/M 2.2 BDOS and MP/M II file systems
are more fully described in the following sections.
3.2.1 MP/M II vs. CP/M File Systems
MP/M II is a real-time, multitasking operating system. To
function properly, MP/M II requires a file system capable of sharing
files among multiple processes and resolving access conflicts among
those processes. In contrast, CP/M is a single-task operating
system, so no such conflicts can arise.
One of MP/M II's key methods for maintaining file system
integrity is the File Control Block checksum. The FCB checksum
takes into account the process controlling the FCB, the physical
blocks allocated to the file, whether the file is open in a mode
that allows other processes to share it, and other factors. When
file-related functions are submitted to MP/M II, the checksum is
examined. If the checksum is found to be invalid, MP/M II returns
an error to the calling process.
Mp/M II also returns an error if
Because a single process handles all CP/NET activity on a
server all of these limitations apply to a CP/NET requester
performing file operations on a remote device. These limitations,
however, do not apply to a requester accessing a local device. The
systems implementer should take these factors into account when
designing servers for a CP/NET system.
3.2.2 Error Handling Under CP/NET
Most CP/NET function calls result in specific values returned
in the CPU registers. These values can be pointers to data objects,
bit vectors specifying drive status, directory codes, or success or
error conditions. Directory, success, and error codes are returned
in register A. Pointers and bit vectors are returned in register
HL. Register A is always equal to register L, and register B is
equal to register H for all CP/NET return codes.
Error Handling for Local Devices
When a CP/NET requester performs a local file operation, the
function parameters pass untouched to the CP/M BDOS. The BDOS
checks those parameters for validity and calls the BIOS to perform
physical I/O functions. Two types of errors can arise from these
local operations.
The BDOS can detect certain logical problems with a file
function and return a logical error. If it does, an error code is
returned in register A, but the calling application program is
allowed to continue.
A physical error is returned when the BIOS is unable to
successfully perform a physical operation requested by the BDOS.
When the BDOS is presented with a physical error, it prints the
following message on the console:
where <x> is the drive referenced when the error occurred, and
<error message> is one of the four following errors:
After the physical error message is printed, the BDOS waits for the
user to respond to the error with one of two actions. Pressing
CTRL-C causes the BDOS to perform a warm boot, aborting the program.
Pressing any other key causes the BDOS to ignore the physical error
and continue as if it had not occurred.
For a more complete discussion of CP/M 2.x errors, see the CP/M
Operating System Manual, published by Digital Research.
Error Handling for Network Devices
When an application references a networked device, the MP/M II
server performs the actual file operation and returns a message
defining whether the operation was successful or not. Unlike the
local case, the requester has only indirect knowledge of any error
status. Direct physical error indications are impossible to obtain
because a requester has no contact with the MP/M II XIOS. Instead,
if an error occurs, MP/M II returns a message indicating that an
error occurred and the type of error it was.
When referencing a remote device, the two types of errors
possible under CP/NET are logical errors and extended errors.
Like logical errors under local CP/M, logical network errors
define nonfatal error conditions, such as reading past the end of a
file or attempting to open a nonexistent file. Some serious error
conditions are returned as logical errors for functions that expect
to process their own errors. These functions are
Errors for these functions are returned in the return code field of
a CP/NET message. The NDOS formats this field into register A, so
the condition code upon return to the application program looks
exactly as it does under local CP/M.
Some of the following codes can be returned in register A for
each of the preceding functions:
Extended errors indicate that a potentially fatal condition has
occurred during the execution of an MP/M II function. The condition
can be a physical error, similar to the physical errors that can
occur under CP/M. Or the condition can be an error produced by the
file system, indicating that the specified operation violates the
integrity of the file system.
When an extended error occurs under MP/M II, the default mode
of operation displays the extended error message on the console
attached to the calling process, and the process aborts, MP/M II
provides, however, for returning extended errors to the calling
process without aborting that process. In this return error mode,
register A is set to FF hexadecimal, and register H contains the
extended error code.
The CP/NET server uses return error mode because if the server
aborted, it could not communicate further with the requester it was
servicing until MP/M II was restarted. When the server detects an
extended error, it constructs a special CP/NET message. The message
is two bytes long, with the first byte (the return code) set to FF.
The second byte is set to the extended error code.
When the requester detects one of these special messages, it
checks the error mode set by the application program with Function
45 (Set BDOS Error Mode). There are three possible modes:
If the NDOS is in default mode, it prints the following error
message:
where <xx> is the extended error code in hexadecimal, and <yy> is
the function being performed when the error occurred, also in
hexadecimal. The NDOS then performs a warm boot, aborting thc
program.
In return error mode, the NDOS does not display a message or
abort the program. Instead, the NDOS sets register A to FF and
register H to the extended error code; then it returns to the
application program.
If an extended error is detected in return and display error
mode, the NDOS displays the error message on the console. But the
NDOS does not abort the program, setting the registers in the same
manner as return error mode.
Function 45 (Set BDOS Error Mode) does not exist under CP/M.
Because of this, most CP/M applications automatically run in default
mode. If an extended error occurs, these applications abort.
The following extended error codes can be returned to the NDOS:
Extended error 0C hex is returned, not by MP/M II, but by the
server itself. This error indicates that the server is unable to
process an otherwise valid CP/NET message, either because the
requester is not logged in to that server or because the function
code contained in the message is invalid.
Extended error FF can result only from two special functions,
Get Allocation Vector Address and Get Disk Parameter Address.
Because these functions return a pointer in register pair HL, it is
not possible to detect a regular extended error. Instead, these
functions return an FFFF value in HL if a physical error occurs.
Not all CP/NET functions are capable of returning extended
errors. However, extended error 0C can be returned on any function,
even on MP/M II functions that normally have no extended error
associated with them. If an extended error is returned for such a
function, the NDOS ignores it. The following functions can result
in the performance of a network access but cannot produce an
extended error:
Any other function can cause a program to abort if an MP/M II
extended error occurs, if an unsupported function is passed to the
server, or if the server is not logged in.
3.2.3 Temporary Filename Translation
Many common application programs use temporary files. The
names of these files often have the form FILENAME.$$$ or $$$.SUB.
When multiple copies of these applications run on different
requesters logged on to the same server, a number of these temporary
files can have the same name, causing extended MP/M II errors that
abort the application program.
To solve this problem, each requester's NDOS recognizes
temporary filenames destined for networked drives and implicitly
renames them, so the filename an application presents to the
operating system is not the one the NDOS presents to the MP/M II
file system.
Each occurrence of the string $$$ in the first three bytes of a
filename, as well as any filetype of $$$, forms a CP/NET message
with a filename or filetype of $<xx>, where <xx> is the ASCII
representation of the requester ID byte. Because all requesters
have a unique ID, this modification guarantees the uniqueness of
temporary filenames.
This modification is transparent to the calling application
program. When the NDOS modifies a filename in a CP/NET message, it
converts the filename back to its original form before updating the
application's FCB. The only possible change to the FCB is that
interface attributes set in the high-order bits of the filename
strings modified are reset. This change poses no problems if
temporary files are truly temporary. Treat temporary files like
Read-Write files with the DIR attribute; delete them before the
application program terminates.
Functions 17 (Search For First Directory Entry) and 18 (Search
For Next Directory Entry) do not perform temporary filename
translation when referencing a networked drive. If a user creates
file with a temporary filename and then attempts to locate it within
his directory, this can be confusing.
For example, suppose that a user working on requester 5A enters
the command:
Then the user enters a DIR command. The file previously renamed
appears as
in the directory.
If a temporary file is referenced on a drive that is local to
the CP/NET system, the filename passes unmodified to the BDOS. -No
conversion is necessary, because there is no possibility of
conflict.
3.2.4 Opening System Files on User 0
Under MP/M II, a requester running in a user number other than
0 can access certain networked files in user 0. If an MP/M II file
has its t2' interface attribute set, the file is a system file. If
a networked file is opened in locked or Read-Only mode from a
nonzero user number, the following actions are taken:
The user of a CP/NET requester can make convenient use of these
options. Because the CCP.SPR always opens files in Read-Only mode,
all COM files can be placed in user 0 and marked as system files,
making them accessible to all user numbers.
Because this facility does not exist under CP/M 2.x, all COM
files on local devices must exist within the user numbers from which
they are to be executed.
3.2.5 Compatibility Attributes
Because of MP/M II's added file security, applications written
under CP/M might not work properly under MP/M II. Two basic factors
contribute to the incompatibility. The first is the FCB checksum
computation that MP/M II performs on open FCBs. Certain CP/M
applications modify their FCBs in a way that makes their checksums
invalid. Second, MP/M II defaults to opening all files in locked
mode, allowing only one process to have a file open at a time.
Although files can be opened in an unlocked or shared mode, an
application must explicitly specify that the file is to be opened
unlocked. CP/M applications have no knowledge of this procedure.
To enable CP/M applications to run unmodified under MP/M II, a
system of compatibility attributes has been added. This feature is
supported under CP/NET. Using compatibility attributes, a user can
selectively disable parts of the MP/M II file security mechanism.
When a requester's CCP opens a COM file for loading and
subsequent execution, it examines the high-order bits of the first,
second, third, and fourth bytes of the filename. These bits are
referred to as interface attributes Fl', F2', F3', and F4'. The CCP
constructs a byte based on the interface attribute set. It then
uses this byte as'a parameter for Function 70 (Set Compatibility
Attributes) . Function 70 causes the NDOS to send a logical
compatibility attribute message to every server of which it has
knowledge.
Table 3-1 defines the interface attributes.
The CCP uses the interface attributes to construct a one-byte
parameter for the set compatibility attributes call by setting the
following bits:
All other bits are set to zero.
The set compatibility attributes logical message causes the
server to change its process descriptor if the user has enabled
compatibility attributes during the MP/M II GENSYS operation.
Otherwise, the message is ignored.
When an application program terminates, the CCP resets all
compatibility attributes. This prevents a subsequent program from
operating in an environment with insufficient file security.
It is advisable to enable the minimum number of compatibility
attributes necessary to allow a program to run properly. Use the
following guidelines for setting the attributes:
You can use the SET utility under MP/M II to enter
compatibility interface attributes into a .COM file's directory entry
from an MP/M II console. For example,
If you cannot use MP/M II, you can set the interface attributes
under program control using Function 30 (Set File Attributes).
3.2.6 Password Protection Under CP/NET
The MP/M II file system limits file access by unprivileged
users through password protection for individual files. There are
three levels of password protection for files:
Use the SET utility to assign passwords under MP/M II. The
procedure for assigning passwords is described in the MP/M II
Operating System User' s Guide. CP/NET does not support the
assignment of passwords across the network.
CP/NET does, however, allow an application program to send a
Password across the network when a file is opened. This allows a
user on a CP/NET requester the most basic form of password support:
operation on networked files that have been previously password
protected.
If a read-protected file is opened and no password is
specified, an extended error is returned across the network, and the
Calling application aborts. The same error is also returned when an
application attempts to write to a write-protected file for which no
password was provided when the file was opened. Finally, any
attempt to delete, rename, or change the attributes of a delete
protected file without providing a password results in an extended
rror.
CP/NET also supports Function 106 (Set Default Password).
Function 106 provides a password against which all protected files
are checked if no password is provided or if the password is
incorrect. This function can relieve an application of the
responsibility to parse passwords constantly into the first eight bytes
of the current DMA buffer.
CCP.SPR does not support MP/M II's facility of supplying
passwords when the user enters a command line. Because of this, do
not password-protect COM files unless a default password utility is
provided to the user.
Because CP/M 2.x does not support any kind of file protection,
passwords are ignored when referencing files on drives local to a
CP/NET requester.
3.2.7 Networked List and Console Devices Under CP/NET
In addition to the 16 disk devices, CP/NET allows the user to
map the list and console devices across the network. A number of
requesters can share a printer, or a console can be logically
attached to a completely independent system running CP/NET or
CP/NOS. Such a system needs only a network interface to support
full CP/M capability.
Unlike most requester BDOS calls, whether a console or list
device is local or networked is determined, not at the BDOS
intercept level, but at the BIOS-intercept level. This feature
enables application programs to make direct BIOS calls for console
and printer I/O and to continue to run transparently across the
network.
List device I/O is handled in the following manner: when the
BIOS call is made to LISTOUT, the NDOS traps it. The NDOS examines
the configuration table to determine whether the list device is
local to the CP/NET system or networked. If the list device is
local, the call is passed through to the BIOS unchanged.
If the list device is networked, however, the NDOS stores the
character to be listed in a special buffer, located directly below
the requester configuration table. When 128 characters are stored,
the NDOS sends a List Output logical message to the server upon
which the list device is mapped. This buffering process improves
system performance because one-character messages that would congest
the network communication interfaces need not be sent between each
requester and server.
Under CP/M, there is no need to tell the list device when a
listing is complete because only one application can list at a time,
and that application has complete control of the device during that
time. Under CP/NET, however, more than one requester can share a
printer. So a mechanism must be included to notify the server that
a listing is done and that the list device is available to other
requesters.
A special provision must be included so a partially filled list
buffer can be flushed to the server when a listing is finished, and
so the server can release the list device. Endlist, a special
character equal to FF hex, is intercepted by the NDOS as the signal
to terminate a listing.
The endlist character can come from one of four sources:
The server can handle listing in two different modes. If the module
SPOOL.RSP is present in MP/M II, the server takes all list output
messages and writes them to a dedicated spooler file. When the
server detects an endlist, it inserts a CTRL-Z end-of-file character
into the message, closes the spooler file, and directs the SPOOL
process to begin printing the file on the appropriate list device
If a SPOOL process is not resident under MP/M II, the server,
upon receiving an initial list out message, performs an explicit
attach list function on the specified list device. This prevents
other requesters from using the list device until the requester
being serviced is finished listing. All other requesters are
suspended or receive network errors if they try to use the same list
device. When the server finally receives the endlist character, it
issues a detach list function, freeing the list device for another
process.
Both server modes have potential disadvantages. A printer that
uses a CTRL-Z as an escape sequence for special printing functions
cannot be used with the SPOOL.RSP. Using CTRL-Z causes the spooler
to terminate a print job prematurely, assuming that an end-of-file
was encountered. On the other hand, explicit attaching and
detaching of list devices can cause a network error if a requester
attempts to attach a list device that is already in use, has its
server become suspended, and eventually times out.
Console I/O cannot be buffered and sent across the network in
large blocks because it is not possible to determine when input
critical to the operation of an application is needed. The NDOS
must therefore send such I/O across the network one character at a
time.
As with list output, the NDOS traps console-related BIOS calls.
The NDOS determines whether the console is local or networked. If
the console is local, no action is taken, and the local BIOS is
entered. If the console is networked, a raw or unfiltered console
I/O message is sent to the server. The server performs the I/O
function and sends a response back to the requester.
If a networked console is used with CP/NET, the system behaves
unreliably when the console is also being used as a regular MP/M II
terminal because MP/M II allocates a Terminal Message Process
(TMP) to each known user console. Both a server process and a TMP
can be waiting for input from the same console. Because of this,
typed characters can be echoed normally, doubly echoed, or not
echoed at all. The actual processes might or might not receive
every character.
A networked console user should also be aware that, because
each character must be sent over the network, networked consoles
drastically degrade the performance of the entire CP/NET system.
Networked consoles are not recommended unless there is no way to
support a local console, as in certain industrial process-control
applications.
The CTRL-P facility of CP/M is partially handled by the NDOS.
The NDOS must know when CTRL-P is active because it must send an
endlist character when the facility terminates. If the CCP detects
that CTRL-P is active, it will not send an endlist, even if a
program terminates.
3.3 CP/NET Function Extensions to CP/M
Applications accessing networked drives use the MP/M II file
system to perform file operations. Many of those operations have
slightly different meanings than they do under CP/M. For example,
by setting the high-order bits of an FCB filename, a file can be
opened or made in locked mode, unlocked mode, or Read-Only mode.
CP/NET also allows an application to place a password in the current
DMA buffer for opening password-protected files. Similarly, a close
operation can perform either a permanent close or a partial close.
The return codes and side-effects of MP/M II functions also
differ. Error-handling differences are discussed in Section 3.2.2.
The open and make functions also differ. These functions return a
two-byte value, called the file ID, in the random record field of
the opened FCB. The file ID is necessary for performing record
locking functions.
For a complete description of how individual CP/M functions
work under MP/M II, see the MP/M II Operating System Programmer's
Guide.
This section describes CP/NET functions that have no
counterpart under CP/M. These include MP/M II functions that do not
exist under CP/M, as well as a set of dedicated CP/NET functions.
All of these functions adhere to exactly the same calling
conventions as the rest of CP/M and all follow the same conventions
regarding return codes.
The Access Drive function inserts a dummy open file item in the
stem lock list for each drive specified in the drive vector. The
drive vector is a 16-bit vector in which each possible drive is
presented. Bit 0 represents drive A:, bit 1, drive B:, continuing
through 15 for drive P:.
The NDOS separates the drive vector into a number of drive
vectors, one per server that the NDOS can find in the requester's
configuration table. The NDOS then sends a logical message to each
of these servers. If any of these messages result in an extended
error- thp funni-inn Ahc-)ri--,- [Sorry; I just don't know what to make of
that last bit. --Ed]
If a server's system lock list does not have enough room to fit
all the dummy items for all the drives specified, or if the open
file limit for the server process is exceeded, none of the items is
inserted and Function 38 returns an extended error.
Because the NDOS sends messages to each server in sequence, an
extended error on one server does not indicate that servers accessed
previously failed to insert open file items. This differs from
MP/M II, where only one file system controls the entire lock list.
Note that drives might have to be freed after a failure resulting
from an access drive call.
If the NDOS is in return error mode, an error condition on
function 38 causes register A to be set to 0FFH, and register H
contains one of the following codes:
Because Function 38 is meaningless to local drives under
CP/NET, no call to the local BDOS is made.
The Free Drive function purges servers' lock lists of all items
pertaining to the drives specified. The drive vector is a 16-bit
vector in which each possible drive is represented. Bit 0
represents drive A:, bit 1, drive B:, continuing through 15 for
drive P:.
Because dummy drive accesses, locked records, and open files
are all purged, close all important files before issuing the free
drive call. Otherwise, a checksum error is returned on the next
file access, and data might be lost.
The CP/NET CCP issues a free drive every time a program
terminates. This prevents the server process associated with the
requester from becoming clogged with useless files.
Because Free Drive is meaningless under CP/M, the operating
system ignores entries in the drive vector that specify drives local
to the requester.
Free Drive has no error return.
The Lock Record function grants a requester exclusive write
access to a specific record of a file opened in unlocked mode.
Using this function, any number of requester processes can
simultaneously update a common file.
To lock a record, a requester application must place the
logical record number to be locked in the random record field of the
file's FCB. The file ID number, a two-byte value that is returned
in the random record field when a file is opened in unlocked mode,
must be placed in the first two bytes of the current DMA buffer.
When the lock function is called, a pointer to the FCB must exist in
register pair DE.
The record to be locked must reside within a block currently
allocated for the file. The lock fails if the record is locked by
another process or requester. This prevents two processes from
simultaneously updating the same record and leaving it in an
indeterminate state.
If a file was opened in locked mode, the Lock Record function
always returns successfully, but no explicit action is taken because
the whole file is locked in the first place.
To use the Lock Record function, follow these steps:
The Lock Record function returns a 0 in register A if
successful. Otherwise, the Lock Record function returns one of the
following error codes in register A:
These extended errors can occur:
The Lock Record function has no meaning when a drive local to
the requester is referenced. The function returns with register A
set to 0.
The Unlock Record function releases a previously locked record,
allowing it to be locked and written to by another requester. The
record to be unlocked must be placed in the random record field of
the file's FCB. The file ID is a two-byte value that is returned in
the random field when a file is opened in unlocked mode. The file
ID must be placed in the first two bytes of the current DMA buffer.
Register pair DE must contain a pointer to the FCB.
The Unlock Record function returns successfully if
In all these cases, no action is performed.
Do not unlock a record until the requester's application
program has finished updating the locked record and has written it
back out to the file. Otherwise, another process might
inadvertently destroy the updated information.
The Unlock Record function returns a 0 in register A if
Successful. Otherwise, the function returns one of the following
error codes in register A:
These extended errors can occur:
CP/NET User's Guide
LOGIN {password}{[mstrID]}
password is an optional 8 ASCII-character password; the
default password is PASSWORD. [mstrID] is an optional two-digit
server processor ID; the default is [00]. The simplest form is
A>LOGIN
LOGOFF {[mstrID]}
[mstrID] is an optional two-digit server processor ID; the
default is [00]. The most simple form is
A>LOGOFF
NETWORK {local dev} {=} {server dev{[srvrID]}}
where local devserver dev is the specification of a server device such
as A:, B: ... P: in the case of a disk device or 0, 1 .... 15 in the
case of CON: or LST:. A missing server dev defaults to 0 in the
case of CON: or LST:. [srvrID] is an optional two-digit hexadecimal
server processor ID. The default is [00]. Typical assignments
are
A>NETWORK LST:
A>NETWORK LST:=3[07] (list dev #3 on server 07)
A>NETWORK CON:=2 (console #2 on dflt srvr)
A>NETWORK B:=D:[F] (logical B: is D: on server 0F)
LOCAL {local dev}
local dev is the specification of a local device such as LST: ,
A:,... CON:. The following are typical assignments:
A>LOCAL LST:
A>LOCAL B:
A>ENDLIST
DSKRESET {drive(s)}
drive is a list of the drive names to be reset. If any of
the drives specified cannot be reset, the console displays the
message:
***Reset Failed***
A>DSKRESET (resets all drives)
A>DSKRESET B:,F: (reset drive B: and F:)
CTL-P ON
CTL-P OFF
xxMAIL.TEX
1 - Broadcast
2 - Send Mail
3 - Receive Mail
4 - Exit Program
1 - File
2 - Console Input
1 - Stop Receiving Mail
2 - Answer Message
3 - Delete Message From Mail File
4 - Answer Message, Then Delete
5 - Re-Examine Last Message
6 - Get Next Message
ERROR READING FILE
ERROR WRITING FILE
or
ERROR OPENING FILE
CP/NET Programmer's Guide
BDOS Err on <x>:
<error message>
20 Read Sequential
21 Write Sequential
33 Read Random
34 Write Random
40 Write Random with Zero Fill
42 Lock Record
43 Unlock Record
00 Function Successful
01 Reading Unwritten Data or No Directory Space Available
02 No Available Data Block (Disk Full)
03 Cannot Close Current Extent
04 Seek to Unwritten Extent
05 No Directory Space Available
06 Random Record Greater than 3FFFF
08 Record Locked by Another Process
09 Invalid FCB
0A FCB Checksum Error
0B File Verify Error
0C Record Lock Limit Exceeded
0D Invalid File ID
0E No Room in System Lock List
NDOS Err <xx>, Func <yy>
01 Bad Sector--Permanent Disk Error
02 Read-Only Disk
03 Read-Only File
04 Drive Select Error
05 File Open by Another Process in Locked Mode
06 Close Checksum Error
07 Password Error
08 File Already Exists
09 Illegal ? in an FCB
0A Open File Limit Exceeded
0B No Room in System Lock List
0C Requester not Logged on to Server or Function Not Implemented on Server
FF Unspecified Physical Error
1 Console Input
2 Console Output
5 List Output
9 Print String
10 Read Console Buffer
24 Return Login Vector
28 Write Protect Disk
29 Get Read-Only Vector
37 Reset Drive
39 Free Drive
64 Login
66 Send Message on Network
67 Receive Message on Network
70 Set Compatibility Attributes
106 Set Default Password
REN $$$.$$$=BLAH.TMP
$5A.$5A
SET <filespec> [Fl=ON,F3=ON]
FUNCTION 38: ACCESS DRIVE
Prevents Drives from Being Reset
Register Value
Entry Parameters C 26H
DE Drive Vector
Return Values A Return Code
H Extended Error
0A Open File Limit Exceeded
0B No Room in the System Lock List
0C Server Not Logged In
FUNCTION 39: FREE DRIVE
Free Specified Disk Drives
Register Value
Entry Parameters C 27H
DE Drive Vector
FUNCTION 42: LOCK RECORD
Lock Records in a File
Register Value
Entry Parameters C 2AH
DE FCB Address
Return Values A Return Code
H Extended Error
01 Reading Unwritten Data
03 Cannot Close Current Extent to Access Extent Specified
04 Seek to an Unwritten Extent
06 Random Record Number Greater than 3FFFF
08 Record Locked by Another Process
0A FCB Checksum Error
0B Unlock File Verification Error
0C Process Record Lock Limit Exceeded
0D Invalid File ID in the DMA Buffer
0E No Room on the System Lock List
FF Extended Error
01 Permanent Error
04 Select Error
0C Requester Not Logged In to Server
FUNCTION 43: UNLOCK RECORD
Unlock Records in a File
Register Value
Entry Parameters C 2BH
DE FCB Address
Return Values A Return Code
H Extended Error
01 Reading Unwritten Data
03 Cannot Close Current Extent to Access Extent Specified
04 Seek to an Unwritten Extent
06 Random Record Number Greater than 3FFFF
0A FCB Checksum Error
0B Unlock File Verification Error
0D Invalid File ID in the DMA Buffer
FF Extended Error
01 Permanent Error
04 Select Error
0C Server Not Logged In
| FUNCTION 45: SET BDOS ERROR MODE | ||
|---|---|---|
| Defines CP/NET Error Handling | ||
| Register | Value | |
| Entry Parameters | C | 2DH |
| E | Error Mode | |
The Set BDOS Error Mode function provides the NDOS with these options:
All requester application programs are initially loaded in a default environment that causes the NDOS to abort on extended errors and to display the extended error code. Use Function 45 to change this default mode, according to the contents of register E.
Function 45 is not implemented across the network. The NDOS
maintains its own internal error mode flag and acts upon returning
network messages according to that flag.
The Set BDOS Error Mode function has no effect on physical
errors returned by the requester's local BIOS. These errors always
display an error message, then they give the user the option of
aborting the application program or continuing.
The Login function identifies a requester to a server and
initiates a session with that server. The Login function must
always be successfully called before a requester can access a
serverls resources. Register pair DE must contain a pointer to a
data structure that contains the following two fields:
The NDOS uses this structure to construct a logical LOGIN
message to the server specified. Only the LOGIN message can be
passed to the SERVER module without generating an extended error 0C,
requester not logged in.
The server checks to see whether the password matches the
password defined in the server configuration table. The server then
scans the configuration table to find out whether logging in another
requester exceeds the number of servers present in the system. If a
server exists for the requester, and the password matches, the NDOS
returns a 0 in register A. Otherwise, an error is flagged by
returning an 0FFH in register A. The NDOS also returns a 0 in
register A if the requester is already logged in.
The Logoff function completes a session and breaks the logical
binding between the server specified in register E and the calling
requester. Once a Logoff has been performed, the server process is
free to begin a session with another requester, if the the server's
NETWRKIF can support the dynamic binding of requester nodes to
server processes.
Function 65 returns a 0 if successful. It returns an extended
error 0C, requester not logged on to server, if unsuccessful.
The Send Message on Network function sends messages across the
network that might have no defined function on the MP/M II server.
This allows applications to be written under CP/NET that use non
CP/NET messages. Point-to-point communications packages, special
electronic mail systems, implementation of requester synchronization
functions, and special print spooling systems are examples of such
applications.
To use Function 66, the address of the message to be sent must
be passed in register pair DE. The message pointed to might have
the standard CP/NET structure of FMT, DID, SID, FNC, SIZ, and MSG,
or it might take some nonstandard format. In the latter case, the
SNIOS must be able to recognize the nonstandard message and send it
properly.
Unlike the usual CP/NET session protocol, the Send Message on
Network function does not automatically attempt to receive a
response to the message that was sent. So an application can send
throw-away messages that do not require a logical acknowledgment or
response. You can also define message types that can be broadcast
to every node in the network.
If an application requires a logical response to a message sent
using Function 66, make an explicit call to Function 67 (Receive
Message on Network).
As a rule, set the FMT field of the message header of any
nonstandard message sent through a CP/NET system to a value other
than those reserved for use by Digital Research. Future releases
can then run applications using Function 66, with minimal
modification.
Function 66 returns an FF in registers A, H, and L if a network
error occurred and the message was not sent.
The Receive Message on Network function is the counterpart of
Function 66, Send Message on Network. Invoke it immediately after
performing a send message if a logical response is expected.
Function 67 can also be used to wait for an unsolicited message from
another node.
To use Function 67, an application must pass a pointer to a
buffer area into which the message can be received in register DE.
Upon return, registers A, H, and L are set to OFFH if the function
failed to receive the message properly.
Like Function 66, Function 67 can handle nonstandard messages
across a CP/NET network, provided that the requester's SNIOS is
equipped to handle them. For a more detailed discussion on how to
use Functions 66 and 67, see section 3.4.
The Get Network Status function returns the configuration
table's network status byte in register A. It also resets any error
conditions in the status byte.
For a description of the fields contained in the network status
byte, see Section 4.2.1.
The Get Configuration Table Address function returns the
address of the requester configuration table maintained in the
SNIOS. Using this function, an application can dynamically modify
the mappings of devices across the network. The utilities NETWORK
and LOCAL use Function 69 to accomplish this kind of modification
For a description of the fields in the configuration table, see
Section 4.2.2.
The Set Compatibility Attributes function selectively disables
the file security mechanism on all MP/M II servers to which the
calling requester has networked drives. This allows certain
applications that run under CP/M but not under the MP/M II file
system to run under CP/NET and access networked devices.
The CCP.SPR checks the compatibility interface attributes of
all COM files that it loads for execution and performs a Set
Compatibility Attributes function based on the pattern it finds.
This is the only time to use this function. Applications should not
modify their compatibility mode in midexecution. Doing so might
produce unpredictable results.
The compatibility attribute byte is set according to the
interface attributes found in the COM file's name. The following
attributes cause the corresponding bits to be set in register E
prior to the call to Function 70:
For a complete description of how to use compatibility attributes,
see Section 3.2.5.
Function 70 has no error return. Extended error messages from
servers to which the requester is not logged in are ignored.
The Get Server Configuration Table Address function returns a
pointer to parts of the specified server's configuration table. The
ID of the server to be examined is passed in register E prior to
calling Function 71, and a pointer to the received information is
returned in register pair HL.
The data structure addressed by HL has the following format:
The
information is identical with that
contained in the server
conguration table, except that the login password has been
[?? --Ed], and a byte containing the server's temporary
file drive has
added to the front of the table.
Function 71 can determine whether other requesters are logged
into a server. The temporary file drive can be used when an
application wants to leave a file on a server but does not know the
capacity or type of the server's disk drives. The MAIL
utility makes frequent use of Function 71.
The server configuration table is returned across the network
in a Special buffer in the NDOS. If more than one call is to be
made to Function 71, and the calls reference a different server each
tim, the buffer is overwritten by each successive call. If an
application must examine more than one server configuration table at
once the table must be copied down into a buffer defined by the
application.
If Function 71 passes a server ID to which the calling
user is not logged on, an extended error 0C, requester not
logged in, is returned.
The Set Default Password function allows an application to
specify a password that is checked if an incorrect password is
presented during an Open File function. If a file is password
protected, MP/M II first checks for a password in the current DMA
buffer. If no match is found, MP/M II then checks the default
password set by Function 106. If MP/M II finds a match, it allows
the requested operation to succeed. Otherwise, MP/M II returns an
error.
When Function 106 is performed on a requester, the requester's
NDOS attempts to set the default password on every server to which a
drive is networked by that requester. Since Function 106 has no
error return, extended requester not logged in errors are ignored
Each server process uses an MP/M II default password slot,
starting with console 0 and using as many slots as there are
requesters supported.
The default password set by Function 106 persists until another
default password is set.
In addition to running standard CP/M applications packages on a
CP/NET requester, you can implement special applications using the
network functions available in CP/NET. The applications can handle
message processing in a distributed environment. Examples include
high-performance print spoolers, node-to-node transfer utilities,
and network management tools.
Using Functions 66 (Send Message on Network) and 67 (Receive
Message on Network) , you can define an entire set of specialized
messages to provide network functions. These messages must be
recognized and processed by the SNIOS and NETWRKIF, but once
implemented, they can be used by application programs as though they
were functions themselves.
Suppose a specific network application requires a print spooler
that provides special formatting features. You can write an
application program that creates messages with a special code in the
format byte of the CP/NET message header. When the application
wants to spool data to the special spooler on the server, it uses
Function 66 to send the data.
On the server side, the NETWRKIF must be capable of recognizing
the specially defined format code. When the NETWRKIF sees this
format, instead of routing the message to a server process, it
writes the message to a special queue. The actual spooler can
reside as a process under MP/M II. The spooler reads the queue and
spools the data.
Notice that Functions 66 and 67 are independent of the logical
protocol of CP/NET, where every message sent by a requester implies
that the requester waits to receive the message. This independence
permits an application using a feature like a special spooler to
return immediately after sending its message. The application need
not wait for a logical acknowledgment.
Another convenient application is a file copy program that
works without server intervention. Under the regular CP/NET
protocol, the only way to copy a f ile on a local requester drive to
the local drive of another requester is first to copy the file to a
common networked drive, then copy it back to the other requester's
drive. This is inefficient.
Instead, suppose that the users of the two requesters agree to
cooperate in the copying of the file. They can do this by sending
each other mail. One user invokes an application program called
RECEIVE, while the other brings up an application program called
SEND.
The SEND program merely reads the file into memory, then
sequentially sends it to the other requester, using Function 66.
The SEND program might or might not request verification from the
receiving requester via Function 67. In the meantime, the RECEIVE
program reads the messages from the network. No server intervention
is required; only the two SNIOS modules of the requester are
involved in the transmission. Even though the two requesters are
only capable of sequential processing, they are still able to send
and receive messages synchronously. This application does not
require modif ications to the SNIOS and NETWRKIF; the standard CP/NET
protocol is sufficient, because such applications never reference
the server.
Finally, a complex network might require automatic system
monitoring and maintenance utilities. Using special message
formats, you can design a set of messages that check which drives
are usable on various servers, compute the best path from a
requester to a given server and back, and notify the system's users
of servers and requesters going on or off line. These messages can
be handled automatically by the SNIOS or NETWRKIF software, or they
can be implemented under the control of special application
programs.
The requester's NDOS and the server's SERVER module are key
components in the logical structure of the CP/NET operating system.
These modules, however, do not deal with the physical problems of
moving a logical message from the source requester to the
destination server and back again. Implementing this task varies
depending on network topology, hardware, and the characteristics of
the host computer systems. These modules are therefore not portable
from machine to machine. You must customize them.
This section provides the network systems implementer with the
information necessary to design and implement a CP/NET system
efficiently. Section 4 is divided into four parts.
Section 4.1
discusses general network design issues that affect CP/NET
implementation. Section 4.2
details how to implement the requester
network software, the SNIOS.SPR. Section 4.3
discusses the design
and implementation of the server communications software, the
NETWRKIF.RSP. Section 4.4 describes
the design of a CP/NET server
that runs under an operating system other than MP/M II. Appendixes
to this manual contain several example network communications
packages.
4.1 General Network Considerations
This section explains some of the basic functions of network
communications software and describes, in the most general way, how
communications software fits into the overall architecture. If any
of the material in this section is unfamiliar to you, consult one of
the many excellent textbooks available on modern networking
technology. Theoretical knowledge can help you enormously in the
design and implementation of your network system.
4.1.1 Functions of the CP/NET Physical Modules
The SNIOS and NETWRKIF modules function on four levels. At the
lowest level, they must handle the physical transfer of a bit stream
from one network node to another. This physical layer must take
into account the I/O port numbers being used for communication, the
physical characteristics of the network medium, network contention
schemes, and other factors.
The next layer of functions must address the problem of getting
complete messages from one node to another with no errors or
redundant data. This data-link layer takes the bit stream from the
physical layer and processes it according to its own protocol.
If any routing from node to node is required, you must include,
a network-level protocol. The network layer can be as simple as
identifying when a message is destined for a particular node, or it
can perform complex store-and-forward operations, compute the best
route from node to node, and maintain open circuits for nodes that
want to communicate.
The last layer the SNIOS and NETWRKIF must address provides an
interface between the low-level communications software and the
logical level operating system software. In the SNIOS, this layer
must transport messages to and from the NDOS. In the NETWRKIF, the
transport layer reads and writes message from and to the appropriate
server queues.
The layered architecture presented here can be indistinct in
implementations, with single subroutines sometimes handling all four
layers at once. Figure 4-1
shows the relationship of the various
layers to the network interface. Notice that the physical, data
link, and network layers might have to participate in the interface
to recover information to perform their functions.
Notice also the interfaces between the various levels. As a
message migrates through the layers, the data in the message can
change. The interface between the physical layer and the data-link
layer yields bit or character data; the message itself is
incomplete. The interface between the data-link and network layers
produces messages, but the messages might contain routing
information irrelevant to the transport layer. When a message
reaches the transport layer, it might be in a format unusable by the
higher logical layers of the operating system. only when the
message is passed to those logical layers must it be complete and in
the standard format of a CP/NET message.
The architecture described above corresponds to the four lowest
layers of the network model described by the International Standards
Organization (ISO). However, there are some slight differences.
For example, the ISO definition of the transport layer concerns
itself mostly with migrating messages from a centralized network
controller to one of many possible hosts. In the model described
above, the transport layer deals with moving messages that have
already reached a host into the correct portion of the operating
system. The model in Figure 4-1
is the basis for the following,
more detailed discussion.
4.1.2 Interfacing a Computer to a Network
All network nodes need some method of controlling the
communication functions that take place on the communications medium
of the network. The simplest method is to have the node's CPU
directly control all network communications protocols.
In this case, the network interface is a direct line into the
host computer. When the communications software is called upon to
send a message, the CPU must initiate the message, possibly waiting
for an appropriate handshake response from the destination node.
The CPU must then transmit the message, receive and process any
acknowledgments, and determine whether the message should be
retransmitted. If the node is receiving a message, it must, under
program control, detect when the sender is trying to initiate a
message, perform any handshake with the sender, receive the message,
verify its correctness, and provide acknowledgment. All these tasks
must be performed using programmed I/O operations or possibly some
form of DMA for parts of the transmission or reception.
These tasks can take up a significant amount of the CPU's
processing power. For an SNIOS, this is not a problem, because the
NDOS is idle in the time interval after a message is sent and before
the response is received. For a NETWRKIF, however, the multitasking
nature of the server can result in serious performance degradation.
Another drawback to this method is that it places the burden of
engineering communications software on the host systems implementer.
This software can be extremely costly to develop for a high
performance network.
The principal advantage of this method is its simplicity. If
two computers have spare RS-232 ports, you can network them together
with no special hardware. Many simple protocols can be readily
modified to provide low-performance networks at low cost. Such a
protocol is provided in Appendix E.
For higher-performance networks, it might be necessary to
relieve the host CPU of the burden of physical, data-link, and
network processing. In this case, an intelligent network
communications controller can be useful. Many such controllers are
available, and there is a variety of methods of interfacing them to
a host computer.
An intelligent communications controller can perform all
physical and data-link processing, as well as many network layer
functions, with no host CPU intervention. The SNIOS and NETWRKIF
modules must be concerned only with a nominal amount of network
routing, if necessary, and with the problem of transporting the
message from the controller. Because the communications controller
can transfer data to the host at high speed with high reliability,
the host's transport layer can be very simple and requires little
CPU time. Appendix G
provides a CP/NET implementation utilizing an
intelligent network controller.
Intelligent controllers require special hardware that must be
added to the host computer. Interfacing this hardware is not always
possible. In addition, each network node needs a controller. This
can be expensive.
CP/NET also works in multiprocessor environments, both loosely
coupled and tightly coupled. A loosely coupled system can send
messages via a high-speed, reliable bus. This reduces the data-link
problem, so simply transferring data is often sufficient to ensure
the message's integrity. Tightly coupled processors can share
memory, so messages can be sent between nodes by mapping memory from
one processor to another.
4.1.3 Developing a Network Layer
Because CP/NET is independent of the network used, the
communication modules must be modified to support various network
topologies. The NETWRKIF that supports a multidrop, contention
network is different from the one that supports an active hub-star
configuration.
Some CP/NET configurations require extremely complex
interconnections. Messages destined for one server might have to
pass unmodified through several servers or requesters before they
reach their final destination. The network implementer must define
the software necessary to accomplish this routing. For simple
networks, a network layer is barely necessary. For example, a
simple work station cluster, where several requesters share a single
server, requires only that the destination ID field of the message
match the server's ID on a request, and that the destination match
the requester's ID when the server's response is sent back to the
requester.
In complex networks, each node might need to keep track of
other nodes on-line in the network. Some algorithms require the
exchange of routing messages to maintain an accurate picture of the
topology of the overall network. To do this, the communications
software must recognize these routing messages as nonstandard CP/NET
messages and not pass them to a server process or to the NDOS for
processing.
Even requesters might need a network layer. For example,
consider a daisy-chain network of several requesters with a server
at one end. All the traffic for requesters farther down the chain
passes through the requester adjacent to the server.
Because a CP/M requester can only operate a single task, the
communications software for receiving and forwarding a message must
be written as a series of interrupt routines. Because the NDOS
might call on the SNIOS to transmit or receive a message of its own,
these routines must be reentrant to the extent that NDOS requests
can be held up until an intermediate message has been processed.
Network transmission media are often unreliable. Messages are
occasionally garbled or lost. In addition to data-link errors,
networks can route messages incorrectly, or messages can be lost due
to congestion in a section of the network. Because of these
problems, a node must be able to recover from transmission errors
The most common form of error is garbled data. Bits that
should have been zeros are received as ones, and ones are received
as zeros. The easiest way to detect this type of error is to
transmit a check along with the message. The check is computed by
performing an arithmetic operation on the actual message before it
is transmitted. If the check does not match the result of
performing the same operation when the message is received, then a
transmission error has probably occurred.
Most data-link protocols provide a mechanism for acknowledging
that a message was received correctly. This mechanism requires a
special message as an acknowledgment. The node that received the
original message sends the special message back to the node that
sent the original message. If an error occurs, the receiver either
sends no acknowledgment or sends a negative acknowledgment, telling
the sender to retransmit the message immediately.
The sender must be able to detect a transmission error and take
steps to retransmit the message. This can be a problem because the
sender does not know what the receiver is doing. If an error
message comes back, the sender knows something has gone wrong. But
if a message is lost completely, the receiver might not know it was
sent and never send an error condition.
To solve this problem, the sender can send a message, then wait
a predetermined interval for acknowledgment. If no acknowledgment
arrives, the interval expires, and the sender times out. A timeout
condition can cause the sender to retransmit the message or take
other steps to recover from the error. When the message is finally
sent successfully, the sender can free up the buffer that held it
and continue with other processing.
For a CP/NET requester, two different levels of timeouts might
be necessary. At the data-link level, a timeout can be set on the
amount of time that elapses between sending a message and receiving
the acknowledgment that it was received correctly. This timeout
interval can be fairly short, since the transmission path is not
likely to be very long.
The second timeout addresses the logical structure of CP/NET.
Every message sent to the server implies a response to be sent back
to the requester. A timeout can be set upon entering the
requester's receive message routine. If the requester waits too
long for a response, it can be assumed that the communication link
or the server itself has crashed. With this kind of timeout, the
error recovery involves much more than just retransmitting the
initial message. A logical initialization must take place, probably
including a CP/M warm boot.
A timeout scheme can successfully retransmit lost or garbled
messages. Another problem arises, however, when the receiver's
acknowledgment signal is lost. The sender, not receiving the
acknowledgment, eventually times out and retransmits the message.
In the meantime, the message has actually been successfully
received. When the message arrives from the sender a second time,
the receiver must have some way of knowing that the message is a
duplicate. The receiver should ignore the message, but send an
acknowledgment to stop the sender from sending the duplicate yet
again.
The easiest way to detect duplicates is to assign a sequence
number to each message. If the receiver does not receive the
sequence number it was expecting, it ignores the message, even if
the message was received correctly. Every time a message is
received, the expected sequence number is incremented. Every time
the sender receives an acknowledgment, the sequence number to be
sent is incremented. If a message times out, however, the sequence
number is not incremented.
All error recovery schemes should be free from deadlocks. A
deadlock occurs when the sender is waiting for an action from the
receiver, but the receiver is not performing that action because it
is waiting for the sender to perform another action. Carefully
analyze networks that store and forward messages from node to node
for deadlocks because two nodes can try to transmit to one another
simultaneously.
The means of avoiding deadlocks varies according to the network
topology. A multidrop network can use collision detection. if two
nodes attempt to use the network at the same time, they immediately
detect that their messages are garbled and stop transmitting. To
avoid continuous collisions and a consequent
Register Explanation
0FFH Return Error Mode. BDOS returns
extended errors coming from the
network to the application program.
Register A is set to 0FFH, and
register H contains the extended
error code. No error message is
displayed on the console.
0FEH Return and Display Mode. BDOS returns
theextended error in the same manner
as in Return Error Mode, but also
displays an extended error message.
Any Other Value Default Mode.
FUNCTION 64: LOGIN
Initiate Session Between a Requester
and a Server
Register Value
Entry Parameters C 40H
DE Ptr to Login Msg
Return Values A Return Code
00-00 Server ID byte
01-08 Password
FUNCTION 65: LOGOFF
Terminate a Session Between
a Requester and a Server
Register Value
Entry Parameters C 41H
E Server ID
Return Values A Return Code
H Extended Error
FUNCTION 66: SEND MESSAGE ON NETWORK
Send a Message to Another Network Node
Register Value
Entry Parameters C 42H
DE Pointer to Message
Return Values A Return Code
FUNCTION 67: RECEIVE MESSAGE ON NETWORK
Receive Message from Another Network Node
Register Value
Entry Parameters C 43H
DE Receive Buffer Address
Return Values A Return Code
FUNCTION 68: GET NETWORK STATUS
Get Network Status Byte from the
Configuration Table
Register Value
Entry Parameters C 44H
Return Values A Network Status Byte
FUNCTION 69: GET CONFIGURATION TABLE ADDRESS
Get Configuration Table Address
Register Value
Entry Parameters C 45H
Return Values HL Table Address
FUNCTION 70: SET COMPATIBILITY ATTRIBUTES
Configure Server File Systems
for an Application
Register Value
Entry Parameters C 46H
E Compatibility Attribute Byte
F1' bit 7
F2' bit 6
F3' bit 5
F4' bits 4, 5, and 6
FUNCTION 71: GET SERVER CONFIGURATION TABLE ADDRESS
Get Information About a Server
Register Value
Entry Paramters C 47H
E Server ID
Return Value HL Server Configuration Table Address
00-00 Server Temporary File Drive
01-01 Server Network Status Byte
02-02 Server ID
03-03 Maximum Number of Requesters Permitted on the
Server
04-04 Number of Requesters Currently Logged In
Bit Vector of Requesters Logged In in the Requester
05-06 ID Table
07-16 Requester ID Table
FUNCTION 106: SET DEFAULT PASSWORD
Establish a Default Password
for File Access
Register Value
Entry Parameters C 46H
DE Password Address
