RFC (unknown status)
New MULTICS Network Software Features. M.A. Padlipsky. November 1972. RFC411. (Format: TXT=3024 bytes) (Status: UNKNOWN) (DOI: 10.17487 / RFC411)
Network Working Group M. A. Padlipsky
Request for Comments #411 MIT-MULTICS
NIC 124D3 November 14, 1972
NEW MULTICS NETWORK SOFTWARE FEATURES
Two recently-installed features of the Multics Network software
might be of general interest to the Network community, and should
be of particular interest to those who use Multics via TIP's:
In order to allow Network users at upper-case-only terminals on
systems which do not furnish case-mapping to access Multics,
typing "MAP" (upper-case, followed by Telnet New-line)
immediately after receipt of the Multics load message actuates
Multics software which applies the following typing conventions:
1) as most Multics input is lower-case, alphabetic input is
mapped to lower-case, except for any letter immediately
preceded by "
2) back (left) arrow is treated as underscore, up arrow as
circumflex, apostrophe as acute (right) accent
3) escape sequences exist for the following:
backspace = -
grave (left) accent = '
left brace =
vertical line =
right brace = )
tilde = =
4) the sequence "\" is treated as "
octal escape, it is only necessary to type a "
The case-mapping software is also actuated if "HELP" (upper-case)
is typed prior to login in response to the system's "login
incorrect" message, in which case the normal information (which
would appear in response to lower-case "help" as well) on login
format will be printed out. (Note: the escape sequences are the
same as existing Multics conventions for direct-dialled Model
33/35 TTY's. On these particular devices, "
indicated on the key-caps: it is input as SHIFT-L.)
Output to systems which give small allocations has long been a
problem, both to the remote user (who experienced frequent pauses
in the output at his terminal) and to the Multics "Network
Daemon" process (which encountered considerable inefficiency
because of being frequently awakened to process the ALL control
messages). To alleviate this, we have introduced interrupt-time
code which processes the ALL's and outputs the next group of
bytes without causing the Network Daemon to take a wakeup. As
attendees of the ICCC will have already observed, response is far
superior under the new scheme. (System Programmers responsible
for NCP's might be interested to know that some 75% of our
control-message processing deals with ALL's.)
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the ]
[ direction of Alex McKenzie. 1/97 ]
Java Enterprise Edition (EE)
Java Standard Edition (SE)
RFC (standard status)
RFC (proposed standard status)
RFC (draft standard status)
RFC (informational status)
RFC (experimental status)
RFC (best current practice status)
RFC (historic status)
RFC (unknown status)
All information of this service is derived from the free sources and is provided solely in the form of quotations.
This service provides information and interfaces solely for the familiarization (not ownership) and under the "as is" condition.
Copyright 2016 © ELTASK.COM. All rights reserved.
Site is optimized for mobile devices.
Downloads: 72 / 158763736. Delta: 0.00670 с