Network Related Posts,
more network related posts,
more network related posts,
even more,
HSDT related posts,
List of Archived Posts,
home

NSFNET Announcement and Award


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:
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 is more expensive
System is less expensive
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

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
  1. ims hot standby
  2. 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