It is expected that when there is matching hardware, the symbolic
programs will take this into account and avoid any unnecessary
computing. This is immediately possible through the code
translation constructs of DEL. It may someday be possible through
program composition (when Crocker tells us how??)
AHI NLS - USER CONSOLE COMMUNICATION - AN EXAMPLE
BLOCK DIAGRAM
The right side of the picture represents functions done at the
user's main computer; the left side represents those done at the
host computer.
Each label in the picture corresponds to a statement with the
same name.
There are four trails associated with this picture. The first
links (in a forward direction) the labels which are concerned
only with network information. The second links the total
information flow (again in a forward direction). The last two
are equivalent to the first two but in a backward direction.
They may be set with pointers t1 through t4 respectively.
[">tif:] OR I" >nif"]; ["<tif:] OR ["<nif"];
USER-TO-HOST TRANSMISSION
Keyboard is the set of input devices at the user's console.
Input bits from stations, after drifting through levels of monitor
and interrupt handlers, eventually come to the encode translator.
[>nif(encode)]
Encode maps the semi-raw input bits into an input stream in a
form suited to the serving-host subsystem which will process the
input. [>nif(hrt)<nif(keyboard)]
The Encode program was supplied by the server-host subsystem
when the subsystem was first requested. It is sent to the user
machine in symbolic form and is compiled at the user machine
into code particularly suited to that machine.
It may pack to break characters, map multiple characters to
single characters and vice versa, do character translation, and
give immediate feedback to the user.
1 dm Immediate feedback from the encode translator first goes to
local display management, where it is mapped from the NET standard
to the local display hardware.
A wide range of echo output may come from the encode
translator. Simple character echoes would be a minimum, while
command and machine-state feedback will be common.
It is reasonable to expect control and feedback functions not
even done at the server-host user stations to be done in local
display control. For example, people with high-speed displays
may want to selectively clear curves on a Culler display, a
function which is impossible on a storage tube.
Output from the encode translator for the server-host goes to the
invisible IMP, is broken into appropriate sizes and labeled by the
encode translator, and then goes to the NET-to-host translator.
Output from the user may be more than on-line input. It may be
larger items such as computer-generated data, or files
generated and used exclusively at the server-host site but
stored at the user-host site.
Information of this kind may avoid translation, if it is already in
server-host format, or it may undergo yet another kind of translation
if it is a block of data.
hrp It finally gets to the host, and must then go through the
host reception program. This maps and reorders the standard
transmission-style packets of bits sent by the encode programs
into messages acceptable to the host. This program may well be
part of the monitor of the host machine. [>tif(net mode)<nif(code)]
HOST-TO-USER TRANSMISSION
decode Output from the server-host initially goes through decode,
a translation map similar to, and perhaps more complicated than,
the encode map. [>nif(urt)>tif(imp ctrl)<tif(net mode)]
This map at least formats display output into a simplified
logical-entity output stream, of which meaningful pieces may be
dealt with in various ways at the user site.
The Decode program was sent to the host machine at the same
time that the Encode program was sent to the user machine.
The program is initially in symbolic form and is compiled
for efficient running at the host machine.
Lines of charaters should be logically identified so that
different line widths can be handled at the user site.
=3= |