Network Related Posts,
more network related posts,
more network related posts,
even more,
HSDT related posts,
List of Archived Posts,
home
NSFNET Program Announcement
NSFNET Award Announcement
A couple posts with old emails mentioning NSFNET:
6May85, 30Sep85, 7Apr86 and
17Apr86, 15May87.
Collected posts with old email mentioning NSFNET related activity
http://www.garlic.com/~lynn/lhwemail.html#nsfnet
Portions of Internet/Networking history threads
- Internet and/or ARPANET?
- Internet and/or ARPANET?
- Internet and/or ARPANET?
- Internet and/or ARPANET?
- Internet (TM) and USPTO
- Internet and/or ARPANET?
- Internet and/or ARPANET?
- [netz] History and vision for the future of Internet - Public Question
- Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
- Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
- Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
- Internet and/or ARPANET?
- Internet and/or ARPANET?
- Internet and/or ARPANET?
- Enter fonts (was Re: Unix case-sensitivity: how did it originate?
- Enter fonts (was Re: Unix case-sensitivity: how did it originate?
- Fault Tolerance
- System/1 ?
- System/1 ?
- new architechture every 10 years
- Series/1 as NCP (was: Re: System/1 ?)
- High Availabilty on S/390
- OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
- Dispute about Internet's origins
- Digital Commerce Trivia Questions
- distributed locking patents
- Difference between NCP and TCP/IP protocols
- Difference between NCP and TCP/IP protocols
- Difference between NCP and TCP/IP protocols
- Difference between NCP and TCP/IP protocols
- Mainframe operating systems
- Difference between NCP and TCP/IP protocols
Internet and/or ARPANET?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@garlic.com>
Subjet: Internet and/or ARPANET?
Newsgroup: alt.folklore.computers
Date: 1999/04/01
reposted ... originally
31dec1998 alt.folklore.computers
not so much from technical standpoint but
... arpanet/telenet/tymnet -> csnet -> nsfnet -> internet
my wife and I were effectively (a?) red team on both nsfnet1 and nsfnet2
... weren't actually allowed to bid (although nsf technical audit of
backbone my wife and I operated claimed what we were running was at
least five years ahead of all submitted bids ... to build something new).
Date: 10/22/82 14:25:57
To: CSNET mailing list
Subject: CSNET PhoneNet connection functional
The IBM San Jose Research Lab is the first IBM site to be registered on
CSNET (node-id is IBM-SJ), and our link to the PhoneNet relay at
University of Delaware has just become operational! For initial testing
of the link, I would like to have traffic from people who normally use
the ARPANET, and who would be understanding about delays, etc.
If you are such a person, please send me your userid (and nodeid if
not on SJRLVM1), and I'll send instructions on how to use the
connection. People outside the department or without prior usage of
of ARPANET may also register at this time if there is a pressing need,
such as being on a conference program committee, etc.
CSNET (Computer Science NETwork) is funded by NSF, and is an attempt
to connect all computer science research institutions in the U.S. It
does not have a physical network of its own, but rather is a set of
common protocols used on top of the ARPANET (Department of Defense),
TeleNet (GTE), and PhoneNet (the regular phone system). The
lowest-cost entry is through PhoneNet, which only requires the
addition of a modem to an existing computer system. PhoneNet offers
only message transfer (off-line, queued, files). TeleNet and ARPANET
in allow higher-speed connections and on-line network capabilities
such as remote file lookup and transfer on-line, and remote login.
... snip ... top of post, old email index
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Internet and/or ARPANET?
Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet,comp.org.ieee,alt.amateur-comp
Date: 02 Apr 1999 08:47:54 -0800
jmfbahciv writes:
In article <ur9q45d5u.fsf&garlic.com>,
1982? Just what timespan have we been talking about. I've
been talking about 1968-1978 or thereabouts.
/BAH
i didn't comment about when/what you were talking about ... & I wasn't
commenting about the technical issues. Part of the arpanet/internet
evolution was participation, deployment and funding of different
entities. CSnet (and NSFNET) was a NSF funded/deployed activity
... while ARPAnet nodes had a lot of funding/control by other
government agencies i.e. there can be facets considered other than
protocol/technology
looking at it from other facet ...
.. misc rfcs:
894 - Standard for the transmission of IP datagrams over Ethernet
networks 1984/04/01
826 - Ethernet Address Resolution Protocol: Or converting network
protocol addresses to 48 bit Ethernet address for transmission on
Ethernet hardware .. 1982/11/01
791 - Internet Protocol 1981/09/01
761 - DOD Standard Transmission Control Protocol 1980/01/01
739 - Assigned Numbers 1977/11/11
.... misc IEN:
IEN#1 - Issues in the Interconnection of Datagram Networks 1977/07/29
IEN#3 - Internet Meeting Notes 1977/08/15
IEN#5 - TCP Version 2 Specification 1977/03/
IEN#10 - Internet Broadcast Protocols 1977/03/07
IEN#11 - Internetting or Beyond NCP 1977/03/21
IEN#14 - Thoughts on Multi-net Control and Data Collection Factilities 1977/02/28
... and from IEN#16:
IEN # 16
Network Working Group Jon Postel
Request for Comments: 730 USC-ISI
NIC: 40400 20 May 1977
Section: 2.2.4.2 Extensible Field Addressing
Introduction
This memo discusses the need for and advantages of the expression of
addresses in a network environment as a set of fields. The suggestion
is that as the network grows the address can be extended by three
techniques: adding fields on the left, adding fields on the right, and
increasing the size of individual fields. Carl Sunshine has described
this type of addressing in a paper on source routing [1].
Motivation
Change in the Host-IMP Interface
The revised Host-IMP interface provides for a larger address space for
hosts and IMPs [2]. The old inteface allowed for a 2 bit host field and
a 6 bit IMP field. The new interface allows a 8 bit host field and a 16
bit IMP field. In using the old interface it was common practice to
treat the two fields as a single eight bit quantity. When it was
necessary to refer to a host by number a decimal number was often used.
For example host 1 on IMP 1 was called host 65. Doug Wells has pointed
out some of problems associated with attempting to continue such useage
as the new interface comes into use [3]. If a per field notation had
been used no problems would arise.
Some examples of old and new host numbers are:
Host Name Host IMP old # new #
--------------------------------------
SRI-ARC 0 2 2 2
UCLA-CCN 1 1 65 65537
ISIA 1 22 86 65558
ARPA-TIP 2 28 156 131100
BBNA 3 5 197 196613
Multinetwork Systems
The prospect of interconnections of networks to form a complex
multinetwork system poses additional addressing problems. The new
Host-IMP interface specification has reserved fields in the leader to
carry network addresses [2]. There is experimental work in progress on
interconnecting networks [4, 5, 6]. We should be prepared for these
extensions to the address space.
The addressing scheme should be expandable to increase in scope when
interconnections are made between complex systems.
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Internet and/or ARPANET?
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet,comp.org.ieee,alt.amateur-comp
Date: 07 Apr 1999 23:34:58 -0700
re: RFCs available ...
see the RFC index at http://www.garlic.com/~lynn/
many of the IENs are available as either IEN files or RFC files.
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Internet and/or ARPANET?
Refed: **, - **, - **
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet,comp.org.ieee,alt.amateur-comp
Date: 08 Apr 1999 00:17:37 -0700
re: files
for some related information see rfc2555 just released today
files can be found at ftp.isi.edu ... rfcs in directory in-notes
(which is where my rfc index points to retrieve the actual rfc).
iens can be found in directory in-notes/ien. just checking
ien-index.txt might be of some interest to see the IP evoluation
from 77 to 82.
from ien111:
August 1979
IEN: 111
Replaces: IENs 80,
54, 44, 41, 28, 26
Internet Protocol Specification
1. INTRODUCTION
1.1. Motivation
The Internet Protocol is designed for use in interconnected systems of
packet-switched computer communication networks. Such a system has
been called a "catenet" [1]. The internet protocol provides for
transmitting blocks of data called datagrams from sources to
destinations, where sources and destinations are hosts identified by
fixed length addresses. The internet protocol also provides for
fragmentation and reassembly of long datagrams, if necessary, for
transmission through "small packet" networks.
1.2. Scope
The internet protocol is specifically limited in scope to provide the
functions necessary to deliver a package of bits (an internet
datagram) from a source to a destination over an interconnected system
of networks. There are no mechanisms to promote data reliability,
flow control, sequencing, or other services commonly found in
host-to-host protocols.
1.3. Interfaces
This protocol is called on by host-to-host protocols in an internet
environment. This protocol calls on local network protocols to carry
the internet datagram to the next gateway or destination host.
For example, a TCP module would call on the internet module to take a
TCP segment (including the TCP header and user data) as the data
portion of an internet datagram. The TCP module would provide the
addresses and other parameters in the internet header to the internet
module as arguments of the call. The internet module would then
create an internet datagram and call on the local network interface to
transmit the internet datagram.
In the ARPANET case, for example, the internet module would call on a
local net module which would add the 1822 leader [2] to the internet
datagram creating an ARPANET message to transmit to the IMP. The
ARPANET address would be derived from the internet address by the
local network interface and would be the address of some host in the
ARPANET, that host might be a gateway to other networks.
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Internet (TM) and USPTO
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet (TM) and USPTO
Newsgroups: comp.protocols.tcp-ip.domains,misc.int-property,misc.legal,alt.folklore.computers
Date: 08 Apr 1999 13:09:34 -0700
bitnet (and its european cousin, earn) was a corporate sponsored
network for universities ... somewhat similar to nsfnet's sponsored
csnet. bitnet was based on technology from the corporate internal
network ... the courporate internal network was larger than
arpanet/csnet/nsfnet just about from day one thru about mid-80s
(possibly one of the biggest factors in arpanet/csnet/nsfnet exceeding
the corporate internal network in size were workstations that started
to come into vogue in the early '80s ... while the internal corporate
network remained mainframes, thousands of machines with hundreds of
thousands of users).
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Internet and/or ARPANET?
Refed: **, - **, - **
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet,comp.org.ieee,alt.amateur-comp
Date: 08 Apr 1999 14:58:15 -0700
the IEN documents imply that what they were working on in the 77-80
time-frame was an "internet protocol" (IP) for infrastructures
referred to as multinetwork systems (IEN-16) and catenet (ien-32).
both an "internet protocol" layer (ien-111) and "gateway" (ien-32) are
integral components of being able to accomplish multinetwork systems.
from ien-32 ...
CATENET MONITORING AND CONTROL:
A MODEL FOR THE GATEWAY COMPONENT
John Davidson
Bolt Beranek and Newman, Inc.
IEN #32
Internet Notebook Section 2.3.3.12
April 28, 1978
Catenet Monitoring and Control:
A Model for the Gateway Component
1. INTRODUCTION
At the last Internet meeting, some concern was expressed
that we don't have a real "model" for what a gateway is, what it
does, and how it does it, and that without such a model it is
somewhat dificult to describe the kinds of activities which
should be monitored or controlled by a Gateway Monitoring and
Control Center (GMCC). To respond to that concern, we have
written this note to express our recent thoughts about a gateway
model. Although the note centers primarily around the topic of a
gateway model, we have also included a few thoughts about
possible models for the other components of a general
internetwork structure.
The note proceeds as follows. In Section 2 we try to
establish a reason for wanting a model of a given internetwork
component, and present a brief overview of the potential benefits
of Monitoring and Control. This presentation is largely
pedagogical since it is assumed that this document will, for a
while at least, be the only introduction to the topic available.
In Section 3 we discuss the fundamental kinds of activities
which must be performed by any internet component if it is to
participate in Monitoring and Control. This section establishes
motivation for some of the mechanisms discussed in the rest of
the paper.
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Internet and/or ARPANET?
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers
Date: 12 Apr 1999 15:31:39 -0700
somewhat digression
many/most of the networking protocols seemed to assume a relatively
homogeneous environment ... i.e. arpanet with the IMPs providing
connectivity.
IEN (internet) work in the 77/78 timeframe resulted in gateways and a
"internet" layer (i.e. prior references to various IEN documents).
with ISO defining level3/network and level4/transport ... the internet
layer effectively fit someplace in-between ISO level3/level4.
this is similar to the internal corporate network (corporate
time-sharing product and the corporate network technology ... which
later was used in bitnet and earn) was done starting in the late 60s
in 545 tech. sq (in some extent shared common heritage with multics
back to ctss) ... which effectively had a gateway layer implemented at
ever node. That in part was responsible for the corporate network
being larger than the arpanet/internet from almost the beginning up
thru mid-80s (the other was the corporate time-sharing system that
also originated at 545 tech. sq. was running on a couple thousand
internal corporate mainframes). One of the things that drove the
arpanet/internet passed the internal corporate network was advent of
workstations as nodes.
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
[netz] History and vision for the future of Internet - Public Question
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: [netz] History and vision for the future of Internet - Public Question
Newsgroups: alt.internet-media-coverage,alt.culture.internet,alt.folklore.computers,news.misc,sci.econ,comp.org.ieee,alt.culture.usenet
Date: 13 Apr 1999 16:07:01 -0700
somewhat conjecture ... is that NSFNET1 contract covered possibly
1/4th to 1/10th the resources put into NSFNET1 ... the rest put in by
commercial corporations. Conjecture on my part is huge amount of dark
fiber laying around ... and necessary to break checken/egg situation
at the time with few apps to use the bandwidth, tariffs at the time
were barrier to new apps that might be evolve to use the
bandwidth. Strategy was to make significant bandwidth available as
seed environment that applications could evolve that would eventually
be able to utilize the excess capacity. While ARPANET activity has
some technology/protocol relationship to current Internet ... the huge
resources provided by commercial entities starting (at least) with
NSFNET1 ... significantly define the current Internet infrastructure
(in that sense ... commercialization happened over ten years ago).
Interop '88 had lots of vendors and loads of academic/arpanet people
that had or were in the process of making transition to commercial
companies.
folklore trivia question .... what was causing floor-net meltdown on
sunday before Interop '88 started (and led to configuration option
that is now required in all tcp/ip implemenations).
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
Newsgroups: comp.arch
Date: 16 Apr 1999 11:26:41 -0700
for service based applications ... where the design point is that
operation runs continuously with no human present ... the exception
code for service operation can easily be 4* as much as the code
supporting traditional straight-forward implementation ... frequently
there are numerous domain specific exceptions and domain specific
exception processing so that it is necessary to handle them in the
application (and not take the default of the infrastructure).
... and of course my motherhood statement ... many of the
infrastructures that grew up out of "batch" systems tend to be richer
in their support of exception since the design point assumption was
there wasn't a person directly connected to the application for
operation (as compared to infrastructures that grew-up out of desk-top
and/or interactive environments that had design point assumptions that
a person might ultimately deal with the situation).
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
Newsgroups: comp.arch
Date: 16 Apr 1999 13:19:41 -0700
... oh yes, trivial example.
in the summer of '95 i got to diagnose an epidemic system failure at a
large service provider. turned out to be the machine(s) were crashing
with resource exhausion because of large number of half-open sessions
(almost exactly to the day, a year prior to the denial of service
attack problem hit the press in the summer of '96).
in any case, ... it reminded me of network services deployed 20+
years early that trap/caught similar error condition and appropriately
released the resources. However, ... there was no way that I could set
a trap on a tcp/ip half-open session so that all associated ICMP
errors (like port not available and host not reachable) specific for
that half-session. From a service offering stand-point, I consider
that an error in both the tcp/ip implementation as well as in the
protocol (regardless of the architecture purity appearance of the
protocol).
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
Newsgroups: comp.arch
Date: 16 Apr 1999 13:30:17 -0700
oops, 2nd trivial example ... also from '95.
one of the web/browser companies had developed a lot of code that
would support server's doing web financial transactions. they had done
all the straight-line function and extensively stress-tested the code.
I went in with a failure-mode grid of 30-40 conditions and 4-5 states
and required that the server being able to recognize and take some
appropriate action (although as mentioned ... things like half-open
session traps were outside the capability of the infrastructure and
needed recommendations for other approaches for handling).
In any case, there was essentially 4* as much effort to try and turn
the application into a service-quality implementation as went into the
straight-forward base function.
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Internet and/or ARPANET?
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers
Date: 17 Apr 1999 10:16:03 -0700
re: homogeneous/heterogeneous
I was thinking in terms of the networking hardware and the protocol
being homogeneos. the end-point host machines (might be
heterogeneous) were attached to the IMPs and the IMPs managed the
network protocol. The 360s (lincolns '67 and UCLA's '91) would have an
IBM telecommunication controller (2702 or 2701) which would then talk
to the IMP.
ibm360s had interesting problems interacting with a ascii-based
infrastructure ... in part because of the ebcdic/ascii character
translation.
I had written tty/ascii support for CP/67 while I was an undergraduate
(circa 68) that IBM shipped to customers in CP/67 (VanVleck
immortalizes a y2k-type calculation "bug" at
http://www.multicians.org/thvv/360-67.html
since ttys were limited to 72 characters ... i did message transfer
information using one-byte/255 values; since cp/67 was shipped
w/source it was relatively straight-forward to modify it to support
devices that did transfers longer than 255 ... but they didn't change
my one byte code stuff ... as a result calculations resulted in bad
lengths and resulted in data operations off the end of the buffer,
which corrupted stuff leading to system failure).
About the same time (late '68) ... a couple of us at the university
built a replacement (using our own minicomputer) to replace the 2702
communication controller (which is supposedly credited with
originating the ibm OEM controller business). One of the reasons was
that we had original thot it was possible to dynamically associate
different line scanners with different lines (i.e. dynamically
determine protocol at time of modem connection on dial-up lines). It
turned out it almost work except IBM had taken short-cut and hardware
strapped the oscillator to a line ... so dynamic switching of line
scanner worked as long as all protocols operated at the same bit rate.
In any case, one of the things we implemented was strobbing of bit
raise/lower signal to support dynamic speed recognition.
Back to the ebcdic/ascii problem ... ebcdic is a 256bit code and ascii
is a 127bit code ... and even tho ebcdic had more bit positions
... there were also ascii characters that were not defined in ebcdic
(as well as vis-a-versa). Typically, character translation was done at
the 360 from ebcdic->ascii (on outgoing) and ascii->ebcdic (on
incoming) ... so the ascii network didn't have to worry about dealing
with non-ascci machines (it was done in the 360 host). Defining
the in-bound and out-bound character translation tables got to be
tricky.
in any case, the arpanet started out protocol, hardware, and character
set homogeneous ... with some of the end-point hosts (360s, with
different character set) trying to simulate homogeneous operation.
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Internet and/or ARPANET?
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers
Date: 17 Apr 1999 15:21:59 -0700
... from a slightly different perspective I know somebody that as a
UCSB undergraduate was hired by ARPA to do host/network penetration
studies prior to turning ARPANET on ... a couple years ago she
observed that after nearly 30 years she could still penetrate a number
of todays systems.
unless prepared it is hard to only fake strong-arm tactics.
--
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Internet and/or ARPANET?
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet and/or ARPANET?
Newsgroups: alt.folklore.computers
Date: 18 Apr 1999 09:55:18 -0700
Joel Winett at Lincoln did a number of early RFCs ... somewhat related
to the 360/67 ... unfortunately most of them aren't online:
109 Level III Server Protocol for the Lincoln Laboratory NIC 360/67
Host, Winett J., 1971/03/24 (12pp)
110 Conventions for using an IBM 2741 terminal as a user console for
access to network server hosts, Winett J., 1971/03/25 (4pp)
(Updated by 135)
147 Definition of a socket, Winett J., 1971/05/07 (2pp) (.txt=6438)
(Updates 129)
167 Socket conventions reconsidered, Bhushan A., Metcalfe R., Winett
J., 1971/05/24 (7pp) (.txt=7643)
183 EBCDIC codes and their mapping to ASCII, Winett J., 1971/07/21
(15pp)
393 Comments on Telnet Protocol changes, Winett J., 1972/10/03 (5pp)
(.txt=9435)
466 Telnet logger/server for host LL-67, Winett J., 1973/02/27 (8pp)
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Enter fonts (was Re: Unix case-sensitivity: how did it originate?
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Enter fonts (was Re: Unix case-sensitivity: how did it originate?
Newsgroups: alt.folklore.computers
Date: 16 Apr 1999 16:53:27 -0700
the precursor of SGML/HTML was GML (generalized markup language
... acronym were actually a hack on the three peoples last names) done
at the cambridge science center and implemented in the cms script
processor in the late 60s and early 70s. the script processor was
ported to a number of other environments and (at least in the ibm
mainframe world) could use output devices like the 3800 and the 6670
(san jose research hacked what was essentially an ibm copier3 with a
computer interface to create the 6670 ... it was the first computer
output device that I used that directly supported printing on both
sides of the paper). There was general deployment of 6670s and the
associated support by at least 1979.
Earlier implementations of font changes on 2741, ibm typerwritters and
ibm word processors was achieved by manual switching of the typeball,
in fact the early 3800/6670 font change processing relied on using the
existing script font/typeball change processing.
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Somewhat releated posts
Enter fonts (was Re: Unix case-sensitivity: how did it originate?
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Enter fonts (was Re: Unix case-sensitivity: how did it originate?
Newsgroups: alt.folklore.computers
Date: 18 Apr 1999 13:40:37 -0700
re: 6670 stories & off topic;
in 77/78 time-frame, 2 of the 3 people responsible for GML, the person
responsible for the internal network, and I transfered from 545
tech sq (csc) to sjr.
into the 6670 line-driver went the obvious support using the alternate
paper draw to print the file-seperator page (typically loaded with
green or blue paper). To make the file-seperator page a little more
interesting ... a feature called "6670 sayings" was added ... where
the line driver randomly selected a quotation that was printed
following the file ownership information.
SJR was having a security audit ... and the auditors were roaming
around buildings after hours looking to see if there was classified
information left out. One of the areas of interest was the 6670 output
rooms to see if there was classifed information printed and left out
(not immediately picked up). On the top of one 6670 was a pile of
output ... the top file having a seperator page with the definition of
an auditor being a person that goes around the battlefield after a war
stabbing the wounded. The auditor took it as personal insult & that
somebody had placed it on top the 6670 specifically to make a statment
about the character of auditors. Some amount of time was spent trying
to identify the individual responsible for the insult to auditors.
Lots of stuff used to be sent to me (back in the late '70s when global
networking was new & fresh it was exciting to be processing hundreds
of messages a day, ... as an example somebody had sent me the fortran
source for adventure that compiled on cms ... within three months of
adventure showing up at stanford ... one corporate type once claimed
that they had statistics that for some months they could blaim me for
upwards of 30% of all traffic on all links on the whole internal
network).
One year, the last week in march, somebody from an unnamed east coast
location sent me a "corporate memo" dated April 1st (which was on
sunday) that claimed to be a corporate password security memo
outlining 10-15 rules for password selection. The memo concluded that
there was only a single alphanumeric string that met all the criteria
and each individual was to contact their local security officer to
obtain that password. The first thing Monday morning (april 2) ... all
the corporate bulletin boards in the building had a copy of the memo
printed on corporate letterhead (and i wasn't responsible and/or had
prior knowledge).
By noon, quite a storm was brewing ... not withstanding the content of
the memo ... the date of the memo (april 1st) ... or that the date was
sunday (and corporate memos are never issued on sunday) ... a very
large percentage of people didn't realize it was an april 1st memo,
and got quite angry when it was pointed out. After much investigation,
the final outcome was that all corporate letterhead paper was to be
moved from open shelves in the 6670 print rooms to locked cabinets.
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Fault Tolerance
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Fault Tolerance
Newsgroups: comp.arch,alt.folklore.computers
Date: 18 Apr 1999 17:31:06 -0700
both my wife and I had done mainframe cluster stuff in the 70s and
then in the 80s ran skunkworks where we did HA/CMP and fiber-channel
scale-up (precursor to SP1/SP2, was going to start at 128-way). you
would be surprised at the people now espousing clusters that we had to
battle with at the time.
one of the bag of tricks for ha/cmp was ip-address take-over ...
required that MAC addresses be aged out of the client
ARP-caches. Turned up a bug in reno/tahoe (a lot of the
products/systems then were built on reno/tahoe) ... the IP code had a
one-address MAC as a special speed-up ... if new packet was the same
ip-address as the previous ip-packet ... it would use the previously
saved MAC address and not call the ARP code.
for some common client sysems that frequently interacted with a single
server over & over ... the ip/mac address would never change
regardless of the rules/processes flushing the ARP-cache. work-around
was for ha/cmp to ping all clients it could find ... from a totally
different ip-address ... in order to get the ip routine to change the
hidden MAC address.
then there are counter examples. in the late 70s, i was also playing
around in the disk engineering labs ... they had all these mainframe
processors dedicated to disk testing (and were significantly
under-utilized). If they tried to do concurrent testing of multiple
test-cells (there was lots of security around disk development
... final level being individual units in small steel-mesh cages
... maybe 4' sq and 7' high with combination locks ... called
test-cells) under an operating system ... it had MTBF of about 15
minutes (engineering disks tended to have some rather random & severe
error modes). I redesigned and rewrote input/ouput supervisor so that
it would never fail ... even if there were 6-12 test cells as well as
normal operating system use happening concurrently. The resulting code
was actually smaller than when I started (as well as much shorter path
length). Of course the secret was that the code had evolved
incrementally over a number of years ... and it was way overdue for
redesign and cleanup.
The upside ... were the processors were maybe 5% used ... even with
dozen test cells ... and the other 95% could be put to interesting
uses. The downside ... I had to learn something about disk engineering
... when the disk testing didn't produce the correct results ... it
wasn't uncommon for the operating system to be blaimed ... I would
have to go in and figure out what and heck they were doing.
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Following is from some related threads regarding unix in the mid-80s
and both unix and networking on the Series/1 platform
System/1 ?
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: System/1 ?
Newsgroups: alt.folklore.computers
Date: 02 May 1999 07:15:04 -0700
there was a port of NCP to the series/1 ... actually it was
re-implementation of the NCP function on series/1 ... bascially both
PU4 and PU5 emulation done on series/1 ... the "inside" of the network
was then peer-to-peer packet ... there was a 3705/ncp emulation board
done for mainframe channels ... and then the series/1 emulated pu5
cross-domain support to the vtam/pu5 running on the 370 host.
there was also a project to port the whole infrastructure to RIOS
base.
however ... misc pages from old overheads giving the series/1 to 3725
comparison:
System verses 3725NCP System:
- Higher availability
- More reliable
- More function
- Improved Useability
- Non-IBM Host Support
- Much better connectivity
- Much better performance
- Fewer components
- Easier to tune
- Easier to tailor
- Easier to manage
- Less expensive
a typical operation was taken and configured & costed for both 3725
and the series/1 based system. configuration was multiple distributed
datacenters with large end-user population with realistic distribution
(from actual measured data at customer shops) of messages going to
"owning" host ... as well as to other hosts in the environment. The
peer-to-peer internal packet networking was more reliable than the
sessions maintained by VTAM. The Series/1 would replicate the session
end-point and then could dynamically route the actual message
flows. Except for the end-points to the user's desk ... the
infrastructure was no single point of failure. The 3725 configuration
was less available ... since 80% of the terminal sessions were
cross-domain ... both the "owning" 3725 and the "owning" SSCP/PU5/VTAM
had to be available for session setup (in addition to the end-points).
It was possible to roll-in configuration updates into the Series/1 on
the fly w/o taking anything down. Configuration updates in the 3725
infrastructure typically involved taking everything down and updating
both the 3725 and VTAM configuration and then restarting (and hoping
that everything worked ... or you would have to reverse the process).
3725 is more expensive
- 3725 configuration is operating at saturation.
- 80 3725s chosen for minimal acceptable connectivity and availability
- Configurator rates the 3725 at 60 messages/sec. for this type of activity.
- There are 2700 terminal messages a second
- 95% of messages are forwarded (processed twice)
- Configuration needs to handle 5265 messages/sec (1.95*2700)
- 5265/80 = 66 messages/sec
3725 is more expensive
- System requires 117 3725s to handle load
- Maintain average operation at 75% capacity
- 45 messages/sec is 75% capacity
- 5265/45 = 117 3725s
- Configuration needs a 47% increase
- 3725s increase from 80 to 117
- 19.2kb links increase from 760 to 1112
- 19.2kb modems increase from 1520 to 2224
- Costs increase from $25.7m to $37.8m
System is less expensive
- $14.2m for System hardware + $120k for modems
- $11.5m 20 8-plex S/1 nodes @ $573k
- Duplex S1 (two processors) @ $90k (*4=$360k)
- Lines/duplex @ $39k (*4=$157k)
- Host interfaces/duplex @ $11k (*4=$44k)
- A400 interface/duplex @ $3k (*4=$12k)
- $1.8m for 40 A400 @ $45k
- $900k for 20 A715 @ $45k
- $120k for 20 T1 modems @ $6k
The port to RIOS would have increased processor power by orders of
magnitude. Also, the emulation software was really starting to bump its
head against the 16bit addressing (as well as available real memory)
of the Series/1. Numerous new functions for the emulator were being
severely restricted because of the addressing & memory constraints.
Of course, Raleigh wasn't very happy with this. They weren't very
happy with me as an undergraduate when I worked on the original
telecommunication clone (credited with originating the ibm OEM
controller business). This one was even more significant.
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
System/1 ?
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: System/1 ?
Newsgroups: alt.folklore.computers
Date: 02 May 1999 07:43:23 -0700
oh yes ... the presentation was dated june 25, 1986 ... I actually
gave it to the SNA architecture review board at the Oct meeting in
raleigh and managed to walk out relatively unscathed (or at least
i thot so at the time).
implementation had been running at customer shop with something like
13 datacenters and 60k+ terminals.
within 2-3 years ... it was all gone and in the process of being
forgotten.
another forey by the High Speed Data Transport (HSDT) skunkworks
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
new architechture every 10 years
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: new architechture every 10 years
Newsgroups: comp.arch
Date: 03 May 1999 09:56:39 -0700
In the early 70s, I had something like 30K instruction kernel
modification package of stuff that hadn't been released in the
standard products ... nominally being used on internal/corporate
mainframes ... however it leaked out to a couple places and (among
others) disappeared into AT&T longlines. Ten years later, somebody
from the marketing team handling longlines was tracking me down
because it apparently had propogated around longlines and was still in
use ... and it was not going to be able to even boot on the latest new
generation of mainframes (& longlines wasn't going to buy next
generation of mainframes because the kernel wouldn't run on it).
as aside ... a vanilla CMS 360 kernel should be able to boot
into a virtual 360 "machine" running on 390.
and for something completely different see:
http://www.funsoft.com/
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Series/1 as NCP (was: Re: System/1 ?)
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: Series/1 as NCP (was: Re: System/1 ?)
Newsgroups: alt.folklore.computers
Date: 06 May 1999 06:41:15 -0700
oops ... not '85, '86 ... COMMON Spring '86 Conference (session 43U,
Series/1 As A Front End Processor by John Erickson).
SSCP EMULATION
- Emulates PU5 host SSCP (System Services Control Point)
- Supports SNA cross domain protocols
- Support provided for following RU types:
- ER-OP, NC-ER-OP, ER-INOP, NC-ER-INOP
- NC-ER-ACT, NC-ER-ACT-REPLY
- NC-ER-TEST, NC-ER-TEST-REPLY, ROUTE-TEST, ER-TESTED
- NC-ACT-VR, NC-DACTVR
- ACTCDRM, DACTCDRM, SDT, CLEAR, RQR, CDTAKED, CDTAKEDC
- CDINIT, CDCINIT, CDTERM
- CDSESSF, CDSESSST, CDSESSTF, CDSESSEND
- INIT-OTHER-CD, TERM-OTHER-CD
- DSRLST, BINDF, UNBINDF
- Handles start-up, shut-down, and control for SSCP-SSCP sessions
- Uses cross domain protocols to control terminal to host sessions
- Supports multiple explicit and virtual routes
- Uses virtual route pacing to prevent buffer overflow
- Can emulate multiple SSCPs to bypass MAXSUBA problems
- Supports both ENA and Pre-ENA addressing
- Uses DSRLST to obtain host application status
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
High Availabilty on S/390
From: Lynn Wheeler <lynn@garlic.com>
Subject: Re: High Availabilty on S/390
Newsgroups: bit.listserv.ibm-main
Date: 09 May 1999 12:40:46 -0700
denisb@interlog.com (Denis Belton) writes:
I have been tasked with providing 7/24 availability or as near as
possible on the S/390 server platform. Environment is 9671 RB6 under
OS/390 V2R6. There are no plans to implement parallel SYSPLEX.
I plan to inventory the reasons why we currently do IPLs and attempt to
eliminate or reduce them. Other areas to investigate are dynamic LLA and LPA,
dynamic I/O config using HCD.
Any other suggestions would be most appreciated. Thanks in advance.
when my wife was con'ed into going to POK to be responsible for
loosely-coupled ... she origanted the Peer-Coupled Shared Data
architecture that was eventually the basis for IMS hot standby and
then parallel sysplex.
later when she & I were running the skunk works turning out high
availability cluster multiprocessing product ... I got a chance to
author a section in the corporate "continuous availability" strategy
document ... unfortunately both the rochester and the POK groups
non-concurred with the section as not being able to be met (by them).
recently one of the large financial settlement infrastructures
credited the two primary things contributing to them having 100%
availability for the last six years are
- ims hot standby
- automated operator
i.e. as other kinds of failure modes have been dealt with ... operator
"failure modes" have started to become significant percentage of all
failures
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Subject: Re: OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
Newsgroups: alt.folklore.computers
Date: Thu, 26 Aug 1999 04:46:11 GMT
99.html#112
from the 83 file .... 1000 mainframes on the internal worldwide
network 6/10/83.
* Date Sent 6-14-83
* Node Connected Machine DIV WHERE OPERATOR
* To/How Type NUMBER
+ CPHVMCE * CPHVM1/9 4341/VM EMEA Copenhagen, Denmark
- CPHVMEC * CPHVM1/9 4341/VM EMEA Copenhagen, Denmark
* I have just received word that CPHVMEC, the 1000th node that
* appeared 6/10/83 was the incorrect node name due to some misunder-
* standing in Copenhagen. CPHVMCE is the correct name.
couple more samples from the 83 file
* Date Sent 7-29-83
* Node Connected Machine DIV WHERE OPERATOR
* To/How Type NUMBER
+ BPLVM * PKMFGVM/9 4341/VM DSD Brooklyn, N.Y. 8-868-2166
+ FRKVMPF1 * STFFE1/9 4341/VM CSD Franklin Lakes, NJ 8-731-3500
+ FUJVM1 * FDLVM1/4 3033/VM AFE Fujisawa, Japan
+ GBGMVSFE * GBGVMFE3/C GUEST/MVS FED Gaithersburg, Md. 8-372-5808
+ LAGVM5 * LAGM3/9 168/VM CPD La Gaude, France
+ LAGVM7 * LAGM1/9 3032/VM CPD La Gaude, France
+ MVDVM1 * BUEVM1/2 4341/VM AFE Montevideo,Uruguay 98-90-17
+ RALVMK * RALVMA/C 4341/VM CPD Raleigh, N.C. 8-441-7281
+ RALVMM * RALVS6/C 4341/VM CPD Raleigh, N.C. 8-227-4570
+ RALVMP * RALVM2/C 3081/VM CPD Raleigh, N.C. 8-442-3763
+ RCHVM1PD * RCHVM1/C 4341/VM SPD Rochester, Mn.
+ RCHVM2 * RCHVM1/C 4341/VM SPD Rochester, Mn.
+ RCHVM3 * RCHVM1/C 4341/VM SPD Rochester, Mn.
+ SJMMVS16 * SNJMAS2/9 4341/MVS GPD San Jose, Ca. 8-294-5103
+ SJMMVS17 * SNJMAS1/9 4341/MVS GPD San Jose, Ca. 8-276-6657
+ TUCVMJ * TUCVMI/5 148/VM GPD Tucson, Arizona 8-562-7100
+ TUCVMN1 * TUCVM2/C 4341/VM GPD Tucson, Arizona 8-562-6074
+ UITECVM1 * UITHON2/9 4341/VM EMEA Uithoorn, Netherlands
* Date Sent 12-15-83
* Node Connected Machine DIV WHERE OPERATOR
* To/How Type NUMBER
+ ADMVM2 * ADMVM1/9 4341/VM EMEA Amsterdam, Neth. 20-5133034
+ BOEVMN * BOEVM1/9 4361/VM SPD Boeblingen, Ger. 49-7031-16-3578
+ BRMVM1 * MTLVM1/9 4341/VM AFE Bromont, Canada 514-874-7871
+ DUBVM2 * RESPOND/4 3158/VM EMEA Dublin, Ireland 785344 x4324
+ ENDVMAS3 * ENDCMPVM/C 3081/VM GTD Endicott, N.Y. 8-252-2676
+ KGNVME * KGNVMN/C 3081/VM DSD Kingston, N.Y.
+ KISTAINS * KISTAVM/9 4341/VM EMEA Stockholm, Sweden
+ MDRVM2 * MDRVM1/9 3031/VM EMEA Madrid, Spain 34-1-4314000
+ MSPVMIC3 * MSPVMIC1/9 4341/VM FED Minneapolis, Minn. 8-653-2247
+ POKCAD1 * PKDPDVM/9 4341/VM NAD Poughkeepsie, N.Y. 8-253-6398
+ POKCAD2 * POKCAD1/C 4341/VM NAD Poughkeepsie, N.Y. 8-253-6398
+ SJEMAS5 * SNJMAS3/S 4341/MVS GPD San Jose, Ca. 8-276-6595
+ TOKVMSI2 * FDLVM1/9 3031/VM AFE Tokyo, Japan
Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Dispute about Internet's origins
From: Lynn Wheeler
Subject: Re: Dispute about Internet's origins
Newsgroups: alt.folklore.computers,alt.culture.internet,alt.culture.usenet,alt.society.netizens
Date: Fri, 24 Sep 1999 22:23:21 GMT
somewhat related article
http://www.sjmercury.com/svtech/columns/gillmor/docs/dg092499.htm
NOTE Above URL has gone 404
Full text of articles can now be found here (for fee):
http://www.siliconvalley.com/mld/siliconvalley/archives/
But there is now also wayback machine
http://web.archive.org/web/20000124004147/http://www1.sjmercury.com/svtech/columns/gillmor/docs/dg092499.htm
IBM'S MISSED OPPORTUNITY WITH THE INTERNET
Source: DAN GILLMOR column
IN 1980, some engineers at International Business Machines Corp. tried
to sell their bosses on a forward-looking project: connecting a large
internal IBM computer network to what later became the Internet. The
plan was shot down, and IBM's leaders missed an early chance to grasp
the revolutionary significance of this emerging medium. This is one of
those who-knows-what-might-have-been stories, an intriguing little
footnote in Internet history. It's a cautionary tale
Published on September 24, 1999, Page 1C, San Jose Mercury News (CA)
Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Digital Commerce Trivia Questions
From: lynn.wheeler@xxxxxxxx
Newsgroups: dcsb@ai.mit.edu
Subject: Digital Commerce Trivia Questions
Date: Fri, 31 Dec 1999 04:10:29 PDT
In the following reference
http://www.garlic.com/~lynn/95.html#13
which two people left and became part of small startup in Menlo Park
where their job was to implement something called a commerce server &
do digital commerce?
Later the startup changed its name and moved to Mountain View. From
what company did they acquire the rights to their new name?
distributed locking patents
From: Lynn Wheeler
Subject: Re: distributed locking patents
Newsgroups: comp.arch
Date: Thu, 24 Feb 2000 17:20:41 GMT
ibm provided funding for athena at MIT ... equally with dec. ibm also
provided funding to cmu for the mach, andrew (toolkit & filesystem),
camelot, etc work ... to the tune of about 50% more than the combined
ibm/dec funding at athena. I believe ibm also provided substantial
seed for the transarc spin-off ... and then paid again substantially
when they bought the spin-off outright.
IBM PASC, started working with Locus in the early '80s and doing
ports to S/1 and a couple other boxes in Palo Alto ... including
process migration and fractional file caching (in addition to
distributed access and full file caching).
Early DCE meetings included key people from Locus, Transarc, and
several IBM locations.
there was also misc. other unix work like the AT&T/ibm port of
UNIX to TSS ... running as a TSS subsystem (I believe saw a large
deployment inside of AT&T).
prior to that ... in the early '70s, at least one of the commercial
service bureaus did cluster version of vm/cp ... on the 360/67. This
included process migration ... they had data centers on both the east
coast and the west coast ... and providing 7x24 access to clients
around the world. The hardware required regularly (weekly) scheduled
preventive maint (PM) and so one driver was both intra-datacenter and
inter-datacenter process migratin (there was no time-slot that could
be scheduled to take down a box for PM where there weren't users from
someplace in the world expecting uninterrupted service).
random references:
http://www.garlic.com/~lynn/99.html#63
http://www.garlic.com/~lynn/99.html#64
http://www.garlic.com/~lynn/99.html#66
http://www.garlic.com/~lynn/99.html#67
http://www.garlic.com/~lynn/99.html#36
http://www.garlic.com/~lynn/93.html#0
http://www.garlic.com/~lynn/93.html#19
http://www.garlic.com/~lynn/97.html#14
http://www.garlic.com/~lynn/99.html#237
Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Difference between NCP and TCP/IP protocols
Refed: **, - **, - **
From: Lynn Wheeler
Subject: Re: Difference between NCP and TCP/IP protocols
Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet
Date: Sat, 26 Feb 2000 15:20:16 GMT
as to similar discussion last spring
http://www.garlic.com/~lynn/internet.htm
Much of the internet protocol (aka IP) activity went on in IEN in
77/78 time-frame (references to TCP & TCP as part of HOST/HOST shows
up earlier)
IEN-11 has interesting title ... but the file contents
IEN-11
Section 2.3.3.4 (IEN # 11) is titled "Internetting or Beyond NCP" by
Danny Cohen of ISI. Please obtain copies from the author.
This memo is also assigned the numbers PRTN 213 and NSC 106, and is dated
21 March 1977.
some number of the early (offline) RFCs just went online this week
but nothing new for NCP.
misc online
rfc60 ... A simplified NCP Protocol
rfc215 .. NCP, ICP, and TELNET:
rfc381 .. TWO PROPOSED CHANGES TO THE IMP-HOST PROTOCOL
rfc394 .. TWO PROPOSED CHANGES TO THE IMP-HOST PROTOCOL
rfc550 .. NIC NCP Experiment
rfc618 .. A Few Observations on NCP Statistics
rfc660 .. SOME CHANGES TO THE IMP AND THE IMP/HOST INTERFACE
rfc687 .. IMP/Host and Host/IMP Protocol Change
rfc704 .. IMP/Host and Host/IMP Protocol Change
rfc773 .. COMMENTS ON NCP/TCP MAIL SERVICE TRANSITION STRATEGY
rfc801 .. NCP/TCP TRANSITION PLAN
from rfc801 (nov, 81; catenet shows up in ien111, august, 1979) ...
It was clear from the start of this research on other networks that
the base host-to-host protocol used in the ARPANET was inadequate for
use in these networks. In 1973 work was initiated on a host-to-host
protocol for use across all these networks. The result of this long
effort is the Internet Protocol (IP) and the Transmission Control
Protocol (TCP).
These protocols allow all hosts in the interconnected set of these
networks to share a common interprocess communication environment.
The collection of interconnected networks is called the ARPA Internet
(sometimes called the "Catenet").
The Department of Defense has recently adopted the internet concept
and the IP and TCP protocols in particular as DoD wide standards for
all DoD packet networks, and will be transitioning to this
architecture over the next several years. All new DoD packet
networks will be using these protocols exclusively.
Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Difference between NCP and TCP/IP protocols
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Subject: Re: Difference between NCP and TCP/IP protocols
Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet
Date: Mon, 28 Feb 2000 05:35:30 GMT
some other related information
from ... rfc1251 ... Who's Who in the Internet
Braden came to ISI from UCLA, where he had worked 16 of the preceding
18 years for the campus computing center. There he had technical
responsibility for attaching the first supercomputer (IBM 360/91) to
the ARPAnet, beginning in 1970. Braden was active in the ARPAnet
Network Working Group, contributing to the design of the FTP protocol
in particular. In 1975, he began to receive direct DARPA funding for
installing the 360/91 as a "tool-bearing host" in the National
Software Works. In 1978, he became a member of the TCP Internet
Working Group and began developing a TCP/IP implementation for the IBM
system. As a result, UCLA's 360/91 was one of the ARPAnet host
systems that replaced NCP by TCP/IP in the big changeover of January
1983. The UCLA package of ARPAnet host software, including Braden's
TCP/IP code, was distributed to other OS/MVS sites and was later sold
commercially.
from ... ien-166 Design of TCP/IP for the TAC
+---------+
+ +
+--------------- + Message + <-------------------+
|+-------------- + Buffers + <------------------+ \
|| + + \ \
VV +---------+ \ \
+---+ \ \
+--- + + Tumble \ \
|+-- + + Table +-----+ +----+ \ \
|| +---+ | | | | \ \
|| +>| TCP |<-->| IP |<-+ \ \
VV +--------+ | | | | | | +------+ \ \
+++++++ | | | +-----+ +----+ | | | +++++++
| MLC |<---->| Telnet |<-+ +-->| 1822 |<-->| IMP |
+++++++ | | | +-----+ | | | +++++++
|| +--------+ | | | | +------+ /\/\
|| +>| NCP |<-----------+ / /
|| +---+ | | / /
|+-->+ + Tumble +-----+ / /
+--->+ + Table / /
+---+ / /
|| +----------+ / /
|| + + / /
|+-----------> + Message + --------------------+ /
+------------> + Buffers + ---------------------+
+ +
+----------+
Figure 1.
Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Difference between NCP and TCP/IP protocols
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Subject: Re: Difference between NCP and TCP/IP protocols
Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet
Date: Mon, 28 Feb 2000 05:44:16 GMT
also ... rfc721 Out-of-Band Control Signals in a Host-to-Host Protocol
This note addresses the problem of implementing a reliable out-of-band
signal for use in a host-to-host protocol. It is motivated by the fact
that such a satisfactory mechanism does not exist in the Transmission
Control Protocol (TCP) of Cerf et. al. [reference 4, 6] In addition to
discussing some requirements for such an out-of-band signal (interrupts)
and the implications for the implementation of the requirements, a
discussion of the problem for the TCP case will be presented.
While the ARPANET host-to-host protocol does not support reliable
transmission of either data or controls, it does meet the other
requirements we have for an out-of-band control signal and will be drawn
upon to provide a solution for the TCP case.
The TCP currently handles all data and controls on the same logical
channel. To achieve reliable transmission, it provides positive
acknowledgement and retransmission of all data and most controls. Since
interrupts are on the same channel as data, the TCP must flush data
whenever an interrupt is sent so as not to be subject to flow control.
Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Difference between NCP and TCP/IP protocols
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Subject: Re: Difference between NCP and TCP/IP protocols
Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet
Date: Mon, 28 Feb 2000 06:47:35 GMT
as mentioned before ... similar discussion from last spring
http://www.garlic.com/~lynn/internet.htm
as mentioned the NCP -> TCP/IP transition included generic gateway for
heterogeneous network ... prior to that NCP/IMP was a homogeneous
network infrastructure ... which somewhat limited its extensibility.
The internal corporate network essentially included a gateway function
in every node from the beginning ... and also contributed to it being
larger than the Arpanet from ssentially the beginning until sometime
in the mid-80s (where the transition to tcp/ip w/gateways and the
advent of workstations as nodes help the arpanet/internet overtake the
internal corporate network in number of nodes).
random refs.
http://www.garlic.com/~lynn/99.html#7
http://www.garlic.com/~lynn/99.html#33
http://www.garlic.com/~lynn/99.html#39
http://www.garlic.com/~lynn/99.html#112
http://www.garlic.com/~lynn/99.html#124
& from rfc1705 ... Six Virtual Inches to the Left: IPng Problems
4.5 Compatibility Issues
The Internet community has a large installed base of IP users. The
resources required to operate this network, both people and machine,
is enormous. These resources will need to be preserved. The last
time a change like this took place, moving from NCP to TCP, there
were a few 100 nodes to deal with [Postel, 1981c]. A small close
knit group of engineers managed the network and mandated a one year
migration strategy. Today there are millions of nodes and thousands
of administrators. It will be impossible to convert any portion of
the Internet to a new protocol without effecting the rest of the
community.
Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Mainframe operating systems
From: Lynn Wheeler
Subject: Re: Mainframe operating systems
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 28 Feb 2000 22:54:06 GMT
oops, somehow I was under the impression that the ASP involved
Lockheed SEs. I believe Rick Haeckel also transferred out of the ASP
group to STL.
Bob@CPUPERFORM.COM (Bob Halpern) writes:
The ASP group was the same IBM development team that made the Direct
Couple into a commercial product. Direct Couple was an attached support
processor. This was the IBM Los Angeles Scientific Center staff based in
the Kirkiby Building in Westwood and at the UCLA Western Data Processing
Center (WDPC). WDPC was also the UCLA home of ARPAnet, but by UCLA staff.
The Direct Couple project also had UCLA staff (like me) on it. We got to
program some unusual systems, including some IBM stuff that never saw the
light of day. WDCOM was a communication system that serviced universities
all over the western United States into the Direct Couple system. It
supported some interactive products (e.g. 1050) and STR batch devices
like 7701, 7702, 1974, etc. I programmed the communicatins for the 7740
front end, which was the precusros to the 2701, 2702, and 2703 on the 360.
Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Difference between NCP and TCP/IP protocols
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Subject: Re: Difference between NCP and TCP/IP protocols
Newsgroups: alt.folklore.computers,comp.protocols.tcp-ip,alt.culture.internet
Date: Thu, 02 Mar 2000 02:38:10 GMT
following is excerpt from a collection of 1980 email looking at
some arpanet issues
The best single paper I've seen on internetwork design issues is:
Sunshine, Carl A., "Interconnection of computer networks," Computer
Networks 1, North-Holland Publishing Company, 1977, pp. 175-195.
It took some time for me to read and understand it, but I think it was
worth the effort and I recommend it. At roughly the same time that
paper was published, DARPA and their associates began work on a
specific approach for coherent interconnection of the myriad nets
surrounding ARPANET. One result of their work is a large volume of
documentation recording the design options that were taken and the
reasons for taking them. If you're interested I can send you some of
the pertinent documentation (most of which I have in soft copy), but
there's a lot of it.
the complete archive is at:
https://web.archive.org/web/20161224053106/http://www.edh.net/net_bakeoff.txt
a news article regarding the subject of the archive is at:
http://www.sjmercury.com/svtech/columns/gillmor/docs/dg092499.htm
NOTE Above URL has gone 404
Full text of articles can now be found here (for fee):
http://www.siliconvalley.com/mld/siliconvalley/archives/
But there is now also wayback machine
http://web.archive.org/web/20000124004147/http://www1.sjmercury.com/svtech/columns/gillmor/docs/dg092499.htm
IBM'S MISSED OPPORTUNITY WITH THE INTERNET
Source: DAN GILLMOR column
In 1980, some engineers at International Business Machines Corp. tried
to sell their bosses on a forward-looking project: connecting a large
internal IBM computer network to what later became the Internet. The
plan was shot down, and IBM's leaders missed an early chance to grasp
the revolutionary significance of this emerging medium. This is one of
those who-knows-what-might-have-been stories, an intriguing little
footnote in Internet history. It's a cautionary tale
Published on September 24, 1999, Page 1C, San Jose Mercury News (CA)
random ref:
http://www.garlic.com/~lynn/99.html#140
Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Network Related Posts,
more network related posts,
more network related posts,
even more,
HSDT related posts,
home