List of Archived Posts
2000 Newsgroup Postings (9/12 - 10/13)
- What good and old text formatter are there ?
- What good and old text formatter are there ?
- Ridiculous
- Ridiculous
- Ridiculous
- Is Al Gore The Father of the Internet?^
- Ridiculous
- Ridiculous
- Is a VAX a mainframe?
- Checkpointing (was spice on clusters)
- Is Al Gore The Father of the Internet?^
- Is Al Gore The Father of the Internet?^
- Restricted Y-series PL/1 manual? (was Re: Integer overflow exception)
- internet preceeds Gore in office.
- internet preceeds Gore in office.
- internet preceeds Gore in office.
- First OS with 'User' concept?
- X.25 lost out to the Internet - Why?
- Is Al Gore The Father of the Internet?^
- Is Al Gore The Father of the Internet?^
- Is Al Gore The Father of the Internet?^
- Competitors to SABRE? Big Iron
- Is a VAX a mainframe?
- Is Tim Berners-Lee the inventor of the web?
- older nic cards
- Test and Set: Which architectures have indivisible instructions?
- Al Gore, The Father of the Internet (hah!)
- OCF, PC/SC and GOP
- Is Al Gore The Father of the Internet?^
- Vint Cerf and Robert Kahn and their political opinions
- Is Tim Berners-Lee the inventor of the web?
- Cerf et.al. didn't agree with Gore's claim of initiative.
- Tektronics Storage Tube Terminals
- War, Chaos, & Business
- War, Chaos, & Business (web site), or Col John Boyd
- War, Chaos, & Business (web site), or Col John Boyd
- War, Chaos, & Business (web site), or Col John Boyd
- FW: NEW IBM MAINFRAMES / OS / ETC.(HOT OFF THE PRESS)
- I'll Be! Al Gore DID Invent the Internet After All ! NOT
- I'll Be! Al Gore DID Invent the Internet After All ! NOT
- Why trust root CAs ?
- Why trust root CAs ?
- IBM's Workplace OS (Was: .. Pink)
- Why trust root CAs ?
- Why trust root CAs ?
- IBM's Workplace OS (Was: .. Pink)
- Where are they now : Taligent and Pink
- Why trust root CAs ?
- Where are they now : Taligent and Pink
- How did Oracle get started?
- Why trust root CAs ?
- Why trust root CAs ?
- Why not an IBM zSeries workstation?
- Why not an IBM zSeries workstation?
- VLIW at IBM Research
- Why not an IBM zSeries workstation?
- Why not an IBM zSeries workstation?
- Why not an IBM zSeries workstation?
- Why not an IBM zSeries workstation?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What good and old text formatter are there ?
Newsgroups: alt.folklore.computers
Date: 12 Sep 2000 17:30:03 -0600
jones@cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
Groff is, of course, gnu's implementation of the UNIX standard troff,
which is the CAT phototypesetter extension of nroff, which is the UNIX
port of roff (from the GECOS system) which was a reimplementation of
RUNOFF from CTSS. J. E. Saltzer wrote RUNOFF prior to 1965.
M. D. McIlroy is responsible for both ROFF and NROFF. Does the source
for any of these older systems still exist.
& Stu Madnick (MIT & CSC, 545 tech sq) did "script" for CMS ... which
might be considered port of RUNOFF to CP/67/CMS ... this was about
1967 or so (some of the CTSS people showed up at Multics in 545 tech
sq & other CTSS people showed up at CSC also 545 tech sq).
Then "G". "M", & "L" (also all at CSC, 545 tech sq) ... added GML to
"script" a couple years later. This was standardized later as SGML.
We have since seen it show up in HTML, XML, etc.
Claim has been made that the original CSC script was also ported to
Tandy and misc. other PCs in the early '80s.
misc. refs (i think still good):
http://www.sgmlsource.com/history/roots.htm
random refs:
http://www.garlic.com/~lynn/97.html#9
http://www.garlic.com/~lynn/99.html#42
http://www.garlic.com/~lynn/99.html#43
http://www.garlic.com/~lynn/99.html#67
http://www.garlic.com/~lynn/99.html#197
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What good and old text formatter are there ?
Newsgroups: alt.folklore.computers
Date: 12 Sep 2000 19:41:01 -0600
SGML Users' Group History moved, updated URL
http://www.oasis-open.org/cover/sgmlhist0.html
that is in addition to Goldfarb's history at:
http://www.sgmlsource.com/history/roots.htm
with respect to 6670 output device (recent showed up in different
thread in this same newsgrup), 3800 support had been put into "script"
... and was supported both with GML "tags" and "runoff?" tags for
formating. The 3800 supported then was modified to support 6670.
minor refs:
http://www.garlic.com/~lynn/2000d.html#81
correction in the above 6670 ref, OPD (? office products by whatever name)
had added the computer interface; SJR had extended it for postscript &
other types of support.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ridiculous
Newsgroups: comp.arch
Date: 16 Sep 2000 08:34:30 -0600
mash@mash.engr.sgi.com (John R. Mashey) writes:
I don't know any particular name for this, but it's hardly new:
I used to run jobs on an IBM 360/67 that had regular main memory,
plus a big chunk of (LC? Large Core Storage, I think) that was slower.
I think I recall that some PDP-11s could have several different
speeds of memories. in the same machine.
Ampex sold 8msec memory add-ons for 370. Standard 360/65 memory was
.750msec memory and you could get 1mbyte (2mbyte in a duplex, smp
configuration). You could get an extra 8mbytes of ampex 8msec memory.
There were also 360/50 configurations (standard 2msec memory) that had
Ampex add-on memory ... and possibly some 360/75 configurations also.
Some shops had software that would not also execute programs directly
in the slower memory ... but also do things like copy programs down to
higher speed memory before execution.
360/67s were 360/65 with virtual memory hardware added (8-entry fully
associative table look-aside buffer and other stuff). For SMPs there
were other differences between 65 and 67. The 65 duplex was basically
two 65s that had their memory addressing combined and a couple other
things. The 67 duplex had a "channel controller" which supported
hardware configuration of the channels (i/o buses) and memory boxes
... along with tri-ported memory bus (independent memory access for
the two processors and i/o activity). The different memory added
slightly to the memory access latency for cpu-intensive workloads.
However, combined cpu intensive and i/o intensive workload had higher
thruput on a "half-duplex" 360/67 (duplex hardware configured to run
as independant processors) than a "simplex" 360/67.
There was also a custom triplex 360/67 (I think done for Lockheed on a
goverment project) that had a special "channel controller" that was
software configurable. In cases of various kinds of faults ... the
kernel could re-configure the channel controller to fence off the
faulty component.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ridiculous
Newsgroups: comp.arch
Date: 16 Sep 2000 08:40:51 -0600
Anne & Lynn Wheeler writes:
Ampex sold 8msec memory add-ons for 370. Standard 360/65 memory was
^^^
360
There was also a custom triplex 360/67 (I think done for Lockheed on a
the triplex 360/67 was completely different than the triplex 360/50s &
360/65s (90xx?) machines done for the FAA system.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ridiculous
Newsgroups: comp.arch
Date: 16 Sep 2000 14:38:32 -0600
mash@mash.engr.sgi.com (John R. Mashey) writes:
Do you remember: were the MP 360/65's truly hardware-symmetric
(like the 360/67s)? I never used a /65, and I couldn't find 360/65 MP
PMS Diagrams in Bell&Newell.
the standard 360/65MPs just had common memory addressing (with a
little bit extra for signaling) ... but everything else was
independent (i.e. standard single processor 65), like I/O.
In order to have common I/O capability, devices had to be
"twin-tailed", i.e. each device (or the controller for the device) was
connected with two different i/o channels (one for each
processor). For devices that weren't "twin-tailed", I/O requests had
to be queued for the specific processor that owned the I/O channel the
device was connected to.
I believe the os/360 mp software relied primarily on a spin-lock on
the kernel (supervisor state) code.
The 360/67 duplex channel controller gave each cpu access to all I/O
channels in the configuration.
There was a lot of early fine-grain locking work done using the 360/67
duplex configuration at CSC ... cummulating in the compare&swap work
that eventually showed in 370s.
random refs:
http://www.garlic.com/~lynn/93.html#22
http://www.garlic.com/~lynn/94.html#02
http://www.garlic.com/~lynn/98.html#16
http://www.garlic.com/~lynn/99.html#88
http://www.garlic.com/~lynn/99.html#89
http://www.garlic.com/~lynn/99.html#102
http://www.garlic.com/~lynn/99.html#103
http://www.garlic.com/~lynn/99.html#139
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is Al Gore The Father of the Internet?^
Newsgroups: alt.folklore.computers,talk.politics.misc
Date: 17 Sep 2000 12:45:13 -0600
I don't know any specific reference there. There is the stuff from
1994
http://www.garlic.com/~lynn/2000d.html#75
At the time of Interop '88 ... there was a lot of migration of tcp/ip
into commercial sector and many of the networks had "acceptable use
policies" that allowed various commercial activities.
In the era of NSFNET1 about that time (& Interop '88) .... there was
the NSFNET1 contract funding the NSFNET1 backbone with a dozen or so
sites ... but using lots of commercial products (i.e. the service was
NSF funded, and used the contract to buy commercial products to
implement the service). There was also a lot of commerically "donated"
stuff for NSFNET1 (rumours that value exceeded the funding from
NSF). A complicating factor is that the commerical companies probably
took a non-profit "donation" tax write-off for the stuff donated to
NSFNET1. Possibly as much as anything else, NSFNET needed to have
"non-commercial" acceptable use policy in order to maintain non-profit
tax-write-off status(?).
Many of the tcp/ip implementations & products in the Interop '88 &
NSFNET1 era were based on BSD tcp/ip software. A lot of the
consideration at the time was about the BSD code being free from the
AT&T licensing (not government licensing). I remember the BSD "free"
code ... which may or may not have had NSF &/or gov. funding (possibly
also the Cornell domain name system stuff?, UofTenn SNMP stuff?, etc)
.... were more along the lines of the GNU licensing issues i.e. the
base code is "free" univ & gov. licensed stuff (developed with
gov. &/or nonprofit funding support) .... you have to charge for some
other added value ... like packaging & support.
At the time of Interop '88, commercial TCP/IP products and services
were well established. One of the "big" items that I remember from
Interop '88 was the guy that was responsible for a lot of the SNMP
stuff done at a University was moving into
commercializing/productizing the SNMP (not too long before this ... it
wasn't clear whether the heavy weight network monitoring stuff would
win out or whether SNMP would win out).
The commercializing issues regarding HPCC, NREN, etc were more like 6-7
years later.
random refs:
http://www.garlic.com/~lynn/2000d.html#77
http://www.garlic.com/~lynn/2000d.html#71
http://www.garlic.com/~lynn/2000d.html#72
http://www.garlic.com/~lynn/2000d.html#73
http://www.garlic.com/~lynn/2000d.html#74
http://www.garlic.com/~lynn/2000d.html#78
http://www.garlic.com/~lynn/2000d.html#79
http://www.garlic.com/~lynn/2000d.html#80
http://www.garlic.com/~lynn/internet.htm
copyright notice from some bsd tcp/ip software
/
Copyright (c) 1983, 1986 Regents of the University of California.
All rights reserved.
Redistribution and use in source and binary forms are permitted
provided that the above copyright notice and this paragraph are
duplicated in all such forms and that any documentation,
advertising materials, and other materials related to such
distribution and use acknowledge that the software was developed
by the University of California, Berkeley. The name of the
University may not be used to endorse or promote products derived
from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
/
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ridiculous
Newsgroups: comp.arch,alt.folklore.computers
Date: 20 Sep 2000 23:15:44 -0600
Jan Vorbrueggen writes:
I witnessed two: turning VMS from the VAX-11/782 ASMP into a symmetric
multiprocessor OS, and converting Solaris from single processor to single-lock
SMP to fine-grain SMP. The first went pretty smoothly and quickly, the second
was long-drawn and problematic (at least when watching as an interested
bystander). I have always wondered why they were so different.
VAMPS was a five processor smp based on 370/125 ... that I worked on
in the 1975 time-frame.
the 370/115 & 370/125 shared a common 9 position memory bus and a
common microcode engines for dedicated functions. In both systems,
dedicated i/o functions (like disk controller, communication
controller, etc) was implemented on a dedicated microcode engine and
took up one of the nine positions. The 115 implemented the 370
instruction set on the same microcode engine as was used for all the
other dedicated tasks ... which provided about 80kips 370 (i.e. at
about 10:1, the base engine was about 800kips). The 125 used all the
same components as the 115 but used a faster microcode engine for the
370 instruction set yielding about 120 kips 370 (at 10:1 ratio, native
engine about 1.2mips).
VAMPS was a 370/125 configuration that would use up to five of the
nine positions for 125 370 engines (the basic 115 & 125 were 370
uniprocessor, even tho the underlying architecture was multiprocessor
... just with different engines for dedicated functions.
I worked on the VAMPS project concurrently with the ECPS effort ... various
references:
http://www.garlic.com/~lynn/94.html#21
http://www.garlic.com/~lynn/94.html#27
http://www.garlic.com/~lynn/94.html#28
http://www.garlic.com/~lynn/2000.html#12
http://www.garlic.com/~lynn/2000c.html#50
http://www.garlic.com/~lynn/2000c.html#76
The SMP work used a single kernel lock ... but a number of kernel
functions were migratede into microcode and in some cases offloaded
onto dedicated engines (i.e. a lot of paging was offloaded to the disk
controller engine). The optimization resulted in situation where the
majority of the workloads had a 90% non-kernel/10% kernel execution
ratio. Dispatching of tasks and taks queue management was dropped into
the engine microcode and ran with "fine-grain" locking on all "370"
processor microcode.
When a task required kenel services, an attempt was made to obtain the
kernel lock, if the kernel lock was already held (by another
processor), a super lightweight request was queued and the processor
would look for other work to do.
>From the 370 instruction set standpoint, the migration of dispatching
into the processor "hardware" (actually micrcode) resumbled some of
the i432 work done a number of years later. Misc. refs:
http://www.garlic.com/~lynn/2000c.html#68
http://www.garlic.com/~lynn/2000d.html#10
http://www.garlic.com/~lynn/2000d.html#11
Because of various optimization and offloading specific function to
dedicated processors, in a fully comfigured five (370, total of nine
microcode engines) processor system, the normal aggregate time spent
executing kernel instructions (bracketed by the kernel lock) was
normally no more than 50% of a single processor. This mitigated the
restriction that the single kernel lock limited the aggregate kernel
activity thruput to no more than 100% of a single processor.
For various reasons the product never shipped to customers. However,
the work was adapted to standard 370 kernel to support 370/158 &
370/168 SMP multiprocessors. A standard kernel was slightly
re-oganized so that the parts of the kernel that had been dropped into
the microcode (in the VAMPS design) were modified with fine-grain
locking support. The remaining portion of the kernel was bracketed
with a single (sub-)kernel lock. Code operating under fine-grain
locking when it encountered a situation that required transition to
the portion of the kernel with the single lock, would attempt to
obtain the lock. If the processor was unable to obtain the lock, it
queued a super lightweight kernel request and attempted to find other
work. The processor that held the kernel lock, when it finished its
current task would check (& dequeue/execute) pending kernel requests
prior to releasing the kernel lock.
This was a significant enhancement from the earlier os/360 SMP work
that used a single kernel "spin-lock" (i.e. a task running on a
processor needing kernel services would enter a tight "spin-loop" for
however long was necessary for the kernel to become available). The
careful choice of the kernel functions for fine-grain locking resulted
in less than 10% of the kernel being modified for fine-grain locking
but that 10% represented 905 of the time spent executing in the
kernel. Furthermore, rather than adopting the single kernel
"spin-lock" convention that had been common up until then, the
implementation would queue light-weight requests for kernel services
(rather than spinning, waiting for those kernel services to become
available).
The implementation was implemented on an existing kernel release &
deployed on the internal HONE systems in fall '77 (supposedly at the
time, the largest "single system image" configuration in the world,
eight multiprocessor complexes all sharing the same disk pool), misc
hone refs:
http://www.garlic.com/~lynn/2000.html#75
http://www.garlic.com/~lynn/2000c.html#30
http://www.garlic.com/~lynn/2000c.html#49
and then incorporated into a later release for customers in '78
misc/random refs:
http://www.garlic.com/~lynn/2000.html#78
http://www.garlic.com/~lynn/2000b.html#38
http://www.garlic.com/~lynn/2000b.html#65
http://www.garlic.com/~lynn/2000d.html#47
http://www.garlic.com/~lynn/2000d.html#82
http://www.garlic.com/~lynn/2000e.html#4
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ridiculous
Newsgroups: comp.arch,alt.folklore.computers
Date: 21 Sep 2000 07:35:14 -0600
plugh@NO.SPAM.PLEASE (Caveman) writes:
Egregiously switching CPUs causes a huge performance hit in most cases.
Most schedulers for MP systems since the DEC-10 and -20 and the GE 6[34]5
have tried to keep a thread on the same CPU unless some other systemwide
priority took precedence.
in my previous posting on VAMPS and support for switching CPUs for the
370/158 & 370/168, the VAMPS processor (370/125) was a non-cached
machine and switching processors 1) avoided spin-lock and 2) didn't
have cache hit issue.
The 158 & 168 configurations mentioned were 32kbyte & 64kbyte cache,
two processor machines. Queuing request for the processor that already
had the kernel lock: 1) avoided spin lock, 2) the high use portions of
the kernel had fine-grain locking, 3) it tended to preserve "kernel"
cache hit (i.e. interrupts, task switching, & kernel/non-kernel
transitions all tended to create lots of cache misses because of
locality transitions, if processor already had the kernel lock,
queueing a request for that processor tended to re-use kernel code
already in the cache), 4) the kernel lock was against lower-useage,
longer path length operations (once executed would have preserved very
little non-kernel cache lines, 5) processes that tended to make
lower-useage longer-path kernel calls tended to be various i/o
request; the request queueing tended to migrate them to the same
processor ... leaving processes that made few such calls on the other
processor ... tending to improve cache-hit ratios on both processors
(i.e the processor switching implied by the queueing had a slight
tendency to cluster processes with similar characteristics on the same
processor, while at the "micro" level process switching would seem bad
on cache-hits, the clustering effect at the "macro" level actually
improved overall cache-hits and improved thruput, although it was
somewhat a characteristic of the relative cache sizes and kernel
pathlengths involved).
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is a VAX a mainframe?
Newsgroups: alt.folklore.computers
Date: 22 Sep 2000 09:44:38 -0600
jmfbahciv writes:
Nitpik: Having all I/O paths shared by all CPUs is not a
prerequisite to SMP. This is the second time I've seen
this notion.
the IBM 360 SMPs had shared memory ... but not explicitly shared I/O
channels. To simulate shared I/O channels, an installation would
configure devices &/or control units with multiple connections to
different channels (i.e. the channels were processor specific, but
devices had multiple connections to different channels).
The one exception was the 360 model 67s SMPs which had both shared
memory and shared I/O implementations (the 67 was also the only 360
model that supported virtual memory).
The controller/device multiple connections was also what was used to
implement IBM 360 clusters (i.e. multiple 360 processors, not sharing
memory, but sharing I/O devices).
The IBM 370 line came out (eventually) with virtual memory as
standard, but all of the IBM 370 SMP implementations had non-shared
I/O channel. The 370 line also had asymmetric multiprocessing
implementations, multiple processors sharing memory but some
processors with no I/O capability at all.
misc. refs from the Numa/SMP/etc discussion on comp.arch
http://www.garlic.com/~lynn/2000e.html#2
http://www.garlic.com/~lynn/2000e.html#4
http://www.garlic.com/~lynn/2000e.html#6
http://www.garlic.com/~lynn/2000e.html#7
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Checkpointing (was spice on clusters)
Newsgroups: comp.arch
Date: 22 Sep 2000 10:07:43 -0600
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
That was the situation in 1975, too :-)
Non-automatic checkpointing is far easier, and such methods have
been partially successful. As you point out, I/O is a problem,
but there are actually dozens of others even in this case - I/O
is merely the most obvious.
prior to that, at least one of the time-sharing service bureaus with
datacenters in boston and sanfran ... and world-wide customers ... did
process migration ... sanfran (or boston) machines would shutdown for
preventive maintenance ... and the process, state, i/o, etc would not
just be "checkpointed" (to disk) ... but the whole state, process, etc
copied to the other datacenter (disk) ... and restarted.
Simpler variations were restarting on a machine in the same datacenter
and/or on the same machine (after it had been brought back into
service, also could be used for less planned outages, load balancing,
etc).
misc. refs:
http://www.garlic.com/~lynn/99.html#10
http://www.garlic.com/~lynn/2000.html#64
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is Al Gore The Father of the Internet?^
Newsgroups: alt.folklore.computers,talk.politics.misc
Date: 22 Sep 2000 20:33:05 -0600
... misc refs from the '80s.
slightly related prior posts:
http://www.garlic.com/~lynn/2000d.html#70
http://www.garlic.com/~lynn/2000d.html#72
http://www.garlic.com/~lynn/2000d.html#73
http://www.garlic.com/~lynn/2000d.html#76
================================================================
misc. announcement
To: distribution
Date: 4 January 1988, 14:12:35 EST
Subject: NSFNET Technical Review Board Kickoff Meeting 1/7/88
On November 24th, 1987 the National Science Foundation announced that
MERIT, supported by IBM and MCI was selected to develop and operate
the evolving NSF Network and gateways integrating 12 regional
networks. The Computing Systems Department at IBM Research will
design and develop many of the key software components for this
project including the Nodal Switching System, the Network Management
applications for NETVIEW and some of the Information Services Tools.
I am asking you to participate on an IBM NSFNET Technical Review
Board. The purpose of this Board is to both review the technical
direction of the work undertaken by IBM in support of the NSF Network,
and ensure that this work is proceeding in the right direction. Your
participation will also ensure that the work complements our strategic
products and provides benefits to your organization. The NSFNET
project provides us with an opportunity to assume leadership in
national networking, and your participation on this Board will help
achieve this goal.
... snip ... top of post, old email index
=================================
John Markoff, NY Times, 29 December 1988, page D1
In an article titled 'A Supercomputer in Every Pot' a proposal for a
nationwide 'data superhighway' is discussed. The following points
are made:
- The network would link supercomputers at national laboratories (Princeton,
NJ; College Park, MD; Ithaca, NY; Pittsburgh, PA; Chicago, Ill; Lincoln,
Neb; Boulder, Colo; Salt Lake City, Utah; San Diego, CA; Palo Alto, CA;
and Seattle, WA).
- This network would also be at the top of a hierarchy of a number of slower
speed networks operated by a number of government agencies.
- Fiber-optic cable operated at 3 gigabits/sec.
- Previous attempt to meet the need is the two-year old NsfNet research network
which links five of the supercomputer laboratories with 1.5 Mbs lines.
- Feeling among the academic community that a federal funding and coordination
are necessary; with it serving as a model for later commercial efforts.
- Federal legislation for initial financing and construction of a National
Research Network introduced in October, 1988, by Senator Albert Gore.
- Five-year development and implementation period mentioned for protocols,
hardware, etc.
- A proposal for a regional network linking Univ of Pa, Princeton, and IBM's
Watson Research Labs (Hourglass Project) was mentioned as potentially
providing a 'preview of some of the services' of the national network.
=================================================================================
Subject: Paving way for data 'highway'
Carl M Cannon, San Jose Mercury News, 17 Sep 89, pg 1E
National High-Performance Computer Technology Act of 1989
- US Senate Committee on Commerce, Science and Transportation
- $1.8 billion over next 5 years
- Research and development of supercomputer hardware/software/networks
- Senator Albert Gore, Jr and 8 co-sponsors
. "My bill will definitely get out of committee
... pass in this congress
... maybe this year."
- Also introduced in the House of Representatives
- Newly declared allies in George Bush's
Office of Science and Technology Policy
Senator Albert Gore, Jr
- 10 years old when Senator Al Gore Sr planned the nation's interstate
highway system
- "I was impressed ... I noticed how the ride from Carthage Tennessee
to Washington DC got shorter and shorter."
- Al Gore Jr is the main proponent behind the US superhighway of tomorrow
. nationwide network
. transporting billions of pieces of data per second
. among scholars, students, scientists, and even children
- "A fundamental change is taking place ...
no longer rely on ink and paper to record information ...
we count on computer systems to record informational digitally."
- "The concept of a library will have to change with technology ...
new approach .... the 'digital library'"
- Coined the "computer superhighway" 9 years ago
. 1986: shepherded legislation thru Congress while in the House of Rep
- prepare a report on hi-performance computers and networking
. 1987: Report signed by William R Graham, Pres Regan's science adviser
- Urged a coordinated, long-range strategy
- support high performance computer research
- apply the research to the rest of the nation, including industry
. 1989: White House Office of Science and Technology Policy
- followup report was a minor block buster in technology policy
- Senators have received a series of 3 presentations
. a primer on the power of supercomputers
. "Wiring the World"; What's possible thru networks
. "The freight that can be carried on this highway"
- Joe B Wyatt, Vanderbilt University chancellor
. University librarian estimated the world's authors would
produce 1 million new titles per year by the year 2000
. This is the "freight" a national supercomputer network would carry
. Not Vanderbilt's existing library
. "store and transport to those who need it"
- James H Billington, librarian of Congress
. "88 million items in the Library of Congress"
. "Largest collection of recorded information and knowledge
ever assembled in one place here on Capitol Hill"
. "The nation's most important single resource for the information age"
. "establishment of a national research and education network
would give an immense boost to the access of these materials"
. "allow the LofC to provide much more of its unequaled data
and resources than can now be obtained only by visiting Washington"
- John Seely Brown, Xerox PARC vice president
. "power of information technology to help meet the demand for knowledge
is unquestionable"
. But knowledge workers are already overburdened by
- information explosion
- increasing complexity
- ever-accelerating pace of change
- Where networks are already developed, the results can be stunning
. US Geological Survey demonstrated
- instantaneous combination of 15 types of electronic maps
- helps municipalities figure out where they can safely authorize
drilling wells for drinking water
- Computations without the database or high-performance computers
would be impossible
D. Allan Bromley, science advisor to George Bush
- recommended spending the same amount of money Gore is requesting
. supercomputers and supercomputer networks
- Still not a formal budget proposal
- Four agencies are spending $500 million per year on computing research
. Defense Advanced Research Projects Agency
. Department of Energy
. National Aeronautics and Space Administration
. National Science Foundation
- Bromley's recommendation makes it an easier issue for Congress to support
. Either Al Gore's bill, or individual appropriations to the agencies
. Sends a signal to the agencies that they have allies for these projects
Stephen L Squires, DARPA chief scientist for Information, Science, Technology
- "There is a real urgency for this"
- US is in a critical stage in technology development
- "wait 2-3 years ... a lot of people will be starved for resources"
- "enormous demand, not just in computing, but in scientific fields"
- "People can see what would make their dreams come true"
=======================================================================
NATIONAL CENTER FOR SUPERCOMPUTERING APPLICATIONS (NCSA) VISIT
Oct. 26, 1989
NCSA is a part of the University of Illnois and one of the
leading-edge Engineering and Scientific Applications. For,
example, NCSA demonstrated Visualization at Siggraph'89
(Boston) across multiple hardware platforms (Cray-2, SUN,
Alliant FX-80, Ultranet, AT&T) and across long distances
(Urbana----Boston). NCSA work has been cited in numerous
proposal of technology advancement such as Gore's 3-Gigabits
"Data Highway" congressinal bill.
Representing NCSA will be:
Dr. Larry Smarr -Director of NCSA; Prof. of Physics
& Astronomy
Dr. Karl-Heinz Winkler -Deputy Director for Science,
Technology and Education of NCSA;
Professor of Physics, Astronautical
and Aeronautical Engineering,
Mechanical & Industial Engineering
Dr. Melanie Loots -Research Scientist of NCSA,
Computational Chemistry:
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is Al Gore The Father of the Internet?^
Newsgroups: alt.folklore.computers,talk.politics.misc
Date: 23 Sep 2000 10:43:41 -0600
toor@y1.jdyson.net (John S. Dyson) writes:
Nope. He advocated funding for NSFnet at the best... Funding isn't
creation though... There still is no evidence (even per Anne+Lynn Wheeler)
that he had an idea of what was going to happen.
I admit I hadn't paid any attention to any Gore activity at the time
it was happening. I can find old references to what appears to be
advanced technology bills starting in '88 and possibly not passing
until the end of '91 (same bill 3 years later?).
This was during a period of "high technology" gov. sponsorship and
churn. It was time of gov. supporting (univ) supercomputing centers
(in some cases the money went for the buildings, there was some talk
regarding UC system, that it went to the campus that was "due" the
next new building), high-speed gigabit fibernetworks and HDTV.
NSFNET backbone (56kbit, T1, then T3) was coming at a time when there
was a vast explosion in networking ... both non-profit & profit. The
contribution of the prior NSF activity supporting CSNET & gov. support
for various university TCP/IP activities in the early '80s ... along
with the introduction of workstations & PCs ... fueled the explosion
... as well as the online service providers (the internet is as much a
service issue for the public as it is a networking technology issue).
There was hope that the gov. support for high-end projects in HPCC
(supercomputers), NREN (gigabit fiber networks), & HDTV (electronic
component manufacturing) would have a trickle down effect into the US
economy.
There, in fact, seemed to be the reverse happening. Once the low-end
stuff (consumer online access) started hitting critical mass ... the
commercial funding trickled "up" into the high-end stuff (at the time,
more recognized in the HDTV area).
It isn't even clear how much of the NREN funding was actually spent (I
remember various corporations commenting about being asked to donate
commercial products to participate in NIIT "test bed"). Also, HPCC
supercomputers started to shift to being large arrays of workstation
&/or PC processor chips (workstations & PCs enabled the consumer
online market as well as providing basis for todays supercomputers).
This was probably more recognized in the various HDTV gov. activites
... which appeared to be more slanted towards attempting to bias
standards & regulations to help US corporations (as opposed to direct
technology funding). The issue was that TV market (at the time) was
thousands of times bigger than computer market ... and HDTV components
would be as advanced as anything in the computer market .. whoever
dominated the HDTV/TV market possibly would take over the whole
electronic industry (computers, networking, components, etc).
At least in some areas, there started to be shift from direct
gov. technology funding (i.e. fund a university to write TCP/IP code)
to targeted services using of commercial products (aka a NSFNET
backbone). It isn't to say that it was bad to try and continue (in the
80s/90s) the gov. funding of research & strategic technologies ... it
was just that it seemed that commercial market penetration (for some
areas) had reached a point by the mid to late 80s that commercial &
profit operations funding started to dominate (i.e. gov. funding has
tended to be more productive in areas of pure research ... and not as
productive later in technology cycle when it has started to be
commercialized).
If there was any doubt at the time ... Interop '88 was a large
commerical "internet" show ... where significant numbers of univ
researchers started showing up in commerical companies.
INTEROP 88: The 3rd TCP/IP Interoperability Conference and Exhibition
will be held at the Santa Clara Convention Center and Doubletree Hotel
from September 26 through 30th, 1988. The format is 2 days of
tutorials followed by 3 days of technical session (16 in all). For
the first time, there will also be an Interoperability exhibition
where vendors will show TCP/IP systems on a "Show and Tel-Net" which
additionally will be connected to the Internet.
A number of vendors, known as the "Netman" group will be demonstrating
an experimental network management system based on the ISO CMIP/CMIS
protocols.
For more information on the conference contact:
Advanced Computing Environments
480 San Antonio Road, Suite 100
Mountain View, CA 94040
(415) 941-3399
The show had four "backbone" networks with machines in many booths
connected to two or more of the backbone networks. As the machines
were starting to be connected on Sunday ... the networks started to
crash and burn. Early Monday morning (the day the show started) the
problem was identified.
& as usual the random urls:
http://www.garlic.com/~lynn/94.html#34
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/99.html#40
http://www.garlic.com/~lynn/2000c.html#12
http://www.garlic.com/~lynn/2000c.html#21
http://www.garlic.com/~lynn/2000d.html#2
http://www.garlic.com/~lynn/2000d.html#3
http://www.garlic.com/~lynn/2000d.html#70
http://www.garlic.com/~lynn/2000d.html#71
http://www.garlic.com/~lynn/2000d.html#72
http://www.garlic.com/~lynn/2000d.html#73
http://www.garlic.com/~lynn/2000d.html#76
http://www.garlic.com/~lynn/2000d.html#77
http://www.garlic.com/~lynn/2000d.html#78
http://www.garlic.com/~lynn/2000e.html#5
http://www.garlic.com/~lynn/2000e.html#10
http://www.garlic.com/~lynn/internet.htm
--
Anne & Lynn Wheeler | lynn@garlic.com http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Restricted Y-series PL/1 manual? (was Re: Integer overflow exception)
Newsgroups: comp.arch
Date: 23 Sep 2000 16:36:00 -0600
"Rostyslaw J. Lewyckyj" writes:
Eric Smith wrote:
> Why was the Y-series PL/1 manual "restricted"?
Probably to keep from having too many people from taking it
as the real language spec, and then asking why various
things were not implemented in the product compilers.
I assume that Eric meant the language spec manual,
rather than the compiler logic manual for one of the compilers.
--Rostyk.
... there were restricted manuals for PL/1 when it was still in "beta"
test ... i.e. hadn't been released as product yet. however most
y-manuals were various kinds of (internal) system/program/compiler
logic manuals.
I was at a university where IBM did beta installation of PL/1 and
there were all sort of security(?) restrictions. All evidence of its
existance was supposed to have been obliterated after the end of the
trial period ... and there was some incident where there was suspicion
that somebody at the university had made a (unauthorized) copy.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: internet preceeds Gore in office.
Newsgroups: alt.folklore.computers,talk.politics.misc
Date: 24 Sep 2000 09:02:21 -0600
toor@y1.jdyson.net (John S. Dyson) writes:
For 1985 timeframe or so, 2300 nodes was a very impressive number.
That is before ANY of Gore's influence. Technology did make the
internet more practical, and Gore did join in on the bandwagon. By
taking credit for the internet, he is also leveraging technology by
taking political advantage of the co-incedence of technology and his
tenure.
as an aside, the internal network hit 1000 nodes in '83 and 2000 nodes
in '84. These were just about all multi-user time-sharing mainframe
nodes. The internal network started at 545 tech. sq in the same era
that the first nodes became operational on the arpanet ... and until
the internet started seeing massive numbers of workstation & PC nodes
... consistently had more (mainframe) nodes than the internet (had
total nodes).
One of the successes of the internal network was essentially a gateway
layer at each node with heterogeneous networking support (from the
start). While the original arpanet introduced packets ... it was a
homogeneous network. It wasn't until the IP-layer came along that it
got real gateways and heterogeneous network support ... which ... with
BSD TCP/IP support ported to workstations and PCs ... allowed it to
really start to take off.
misc: refs:
http://www.garlic.com/~lynn/99.html#39
http://www.garlic.com/~lynn/99.html#44
http://www.garlic.com/~lynn/99.html#112
http://www.garlic.com/~lynn/2000e.html#5
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: internet preceeds Gore in office.
Newsgroups: alt.folklore.computers,talk.politics.misc
Date: 25 Sep 2000 07:55:33 -0600
jmfbahciv writes:
IIRC, and my dates are real fuzzy these days, it was around that time
that DEC started running out of node numbers (the field definition
was too small). Their solution was to define an area number and
tack it onto the node number. Out of that came our LAN development
group (this is not a claim of creating the LAN).
Similar were the IBM HASP/JES systems that connected into the internal
network (as end-nodes) .... where the internal network machines had
embedded gateways (previously mentioned for heterogeneous support)
that talked HASP/JES protocols and translated to the internal network
protocol.
JES/NJE networking was introduced in the mid-70s with networking
"node" definitions mapped into the HASP/JES 256-entry "psuedo-device"
table (i.e. HASP originall defined psuedo-reader/printer/punch
devices with the table). Typical JES system might have 40-50 defined
psuedo devices (for spool) leaving 200 or so entries available for
defining network nodes.
The internal network was already larger than the JES/NJE limit by the
time the original support was implemented. JES increased the number of
definition slots to 999 (from 256) after the internal network had
exceeded 1000 nodes.
The internal network gateways used an eight-byte alphanumeric field.
The internal network gateways were even used to interconnect different
HASP/JES/NJE systems operating at different release
levels. HASP/JES/NJE had bit-specific header fields that could vary
from release to release (and frequently different releases wouldn't
interoperate, and in some cases a JES/NJE at one release could cause
the operating system in another machine running a different JES/NJE
release to crash). The internal network gateways would have gateway
support for all of the various HASP/JES/NJE protocol flavors and if
necessary do the bit-field conversions from one release to a different
release.
The early IBM HASP/JES methodology suffered from the same vision
limitation as the early ARPANet work ... supporting homogeneous
(bit-specific) networking w/o the concept of gateways. In contrast,
the internal network methodology incorporated the concept of gateways
from just about the original implemenation.
misc. ref:
http://www.garlic.com/~lynn/99.html#113
as an aside, my wife does have a patent (4195351, 3/25/1980) on some
of the early (token passing) LAN technology
http://www.garlic.com/~lynn/2000c.html#53
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: internet preceeds Gore in office.
Newsgroups: alt.folklore.computers,talk.politics.misc
Date: 25 Sep 2000 10:11:24 -0600
some misc. other refs:
http://www.garlic.com/~lynn/97.html#27
http://www.garlic.com/~lynn/99.html#33
http://www.garlic.com/~lynn/2000b.html#61
http://www.garlic.com/~lynn/2000b.html#67
early internal network started out with cpremote on cp/67 ... at 545
tech. sq (including talking to 1130). one of the early distributed
development projects was support and testing of relocation hardware on
the 370/145.
370s were initially delivered w/o virtual addressing enabled (and in
some cases even present). 145s had the hardware support ... even tho
it wasn't enabled. there was even a flap about the "lights" on the 145
front panel (before announcement of relocation on 370 hardware). One of the
lights was labled dlat ... (indicating address translation mode).
there was also a "pentagon papers" type flap where a document on
address translation was leaked. there was a big internal investigation
... and after that all (internal) copiers were modified to have an
identification installed (copies made would have the copier ID printed
on each page copied).
In any case, there was distributed project between 145 plant in
Endicott (NY) and 545 tech sq (cambridge, mass) ... using the network
support. It included having a version of CP/67 (360/67) modified to
simulate 370 relocation architecture (different from the 360/67
relocation architecture) on a 360/67. Then a different CP/67 was
modified so that it "ran" using 370 relocation architecture (in the
simulated 370 virtual machine running on a real 360/67).
This modified CP/67 was operational and running, a year before there
was real 370/145 hardware available. The modified CP/67 "I" ... was
used as the initial test of 370/145 when the hardware became
available. The initial IPL/boot failed ... it turned out that the 145
engineers had implemented part of the relocation architecture
wrong. The modified CP/67 was temporarily pathed to correspond with
the wrong hardware implementation until the engineers were able to
correct the machine.
CPREMOTE was eventually renamed VNET and after several enhancements
and wide deployment internally, was maded available to customers in
the mid-70s (as part of a combined VNET & JES2/NJE offering).
Parts of this was also the basis for BITNET in north america and EARN
in europe (the number of nodes quoted for the internal network ... only
included those machines on the internal corporate network ... and none
of the BITNET or EARN nodes).
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: First OS with 'User' concept?
Newsgroups: alt.folklore.computers
Date: Wed, 27 Sep 2000 15:05:57 GMT
Terry Kennedy writes:
Of course, with timesharing and multiple-stream batch processing, it be-
comes important to distinguish between different users running on the
hardware at the same time, which is probably where your question actually
starts.
i expect cp/40 ('65-'66) & cp/67 ('67) inherited its username & login
from CTSS. The basic CP/67 control block that all resources, etc were
hung off per user was the UTABLE (aka user table).
I'm slowly unpacking stuff that has been in storage for over a year.
Somewhere in all the stuff is a CP/67 program logic manual (PLM).
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.25 lost out to the Internet - Why?
Newsgroups: alt.folklore.computers,comp.dcom.telecom.tech
Date: Wed, 27 Sep 2000 17:10:50 GMT
Lizard Blizzard writes:
When you say Worldcom, don't you mean the predecessor of Worldcom? I
think Worldcom is a newer more recent name for the MCI and UUNet and
whatever else it's now conglomerately called. Perhaps you meant MCI?
from 10/2/97 news
The telecom company may have started out as
small fish, but it's been eating well, gobbling up
about 50 companies in the past five years. Among
its recent acquisitions were UUNET Technologies,
a major Internet backbone company, as well as the
networks formerly held by AOL and CompuServe.
Now WorldCom has launched an unsolicited
takeover bid for MCI, topping an offer from British
Telecom. The deal would make it the nation's
second largest telephone company, put it in
control of about half the Internet backbone and
shake things up on the consumer level.
from 9/17/96 news
Worldcom plus MFS equals global contender
=========================================
Two of the fastest-moving telephone operators in the world, MFS
Communications and WorldCom, are to merge. The two are seen as
exemplary operators who find ways of achieving their goals despite
regulatory and other difficulties that other operators claim are
insurmountable. Both have the further advantage of modern
infrastructure.
WorldCom is the fourth largest long distance carrier in the USA (it
bought out Wiltel in 1994) and is to pay a high price for MFS. It
intends to swap 2.1 of its shares for every MFS share, which values
MFS at around US$14 billion. MFS lost US$277 million last year and is
unlikely to make a profit before 1998.
Over the next five years MFS intends to build its own fibre networks
in 45 financial centres around the world to add to its existing
networks in London, Paris, Frankfurt and Stockholm as well as networks
in 49 US cities it has built since 1987.
WorldCom last year had revenues of US$3.4 billion and a net income of
US$267.7 million. It chiefly leases bandwidth from other operators
which for long distance is both plentiful and cheap. On the other
hand, events in liberalised markets over the last few years have shown
that real competitive telecoms provision needs alternative local loop
infrastructure. The combination of WorldCom's long distance network
and MFS' access networks should make MFS WorldCom a serious global
contender.
The deal will take some months to complete so it would not be
surprising if either party were made an offer they couldn't refuse by
one of their slower-moving but larger fellow operators.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is Al Gore The Father of the Internet?^
Newsgroups: alt.folklore.computers,talk.politics.misc
Date: Wed, 27 Sep 2000 21:03:22 GMT
Anne & Lynn Wheeler writes:
... misc refs from the '80s.
slightly related prior posts:
http://www.garlic.com/~lynn/2000d.html#70
http://www.garlic.com/~lynn/2000d.html#72
http://www.garlic.com/~lynn/2000d.html#73
http://www.garlic.com/~lynn/2000d.html#76
&
http://www.garlic.com/~lynn/2000e.html#10
http://www.garlic.com/~lynn/2000e.html#11
http://www.garlic.com/~lynn/2000e.html#13
announcing the switch-over to TCP/IP and some early comments about the
success of the switch. Note that the "IP" introduced internetworking
and gateways ... easing the integration of a large number of different
networks.
Date: 30 Dec 1982 14:45:34 EST (Thursday)
From: Nancy Mimno <mimno@Bbn-Unix>
Subject: Notice of TCP/IP Transition on ARPANET
To: csnet-liaisons at Udel-Relay
Cc: mimno at Bbn-Unix
Via: Bbn-Unix; 30 Dec 82 16:07-EST
Via: Udel-Relay; 30 Dec 82 13:15-PDT
Via: Rand-Relay; 30 Dec 82 16:30-EST
ARPANET Transition 1 January 1983
Possible Service Disruption
---------------------------------
Dear Liaison,
As many of you may be aware, the ARPANET has been going through
the major transition of shifting the host-host level protocol
from NCP (Network Control Protocol/Program) to TCP-IP
(Transmission Control Protocol - Internet Protocol). These two
host-host level protocols are completely different and are
incompatible. This transition has been planned and carried out
over the past several years, proceeding from initial test
implementations through parallel operation over the last year,
and culminating in a cutover to TCP-IP only 1 January 1983. DCA
and DARPA have provided substantial support for TCP-IP
development throughout this period and are committed to the
cutover date.
The CSNET team has been doing all it can to facilitate its part
in this transition. The change to TCP-IP is complete for all the
CSNET host facilities that use the ARPANET: the CSNET relays at
Delaware and Rand, the CSNET Service Host and Name Server at
Wisconsin, the CSNET CIC at BBN, and the X.25 development system
at Purdue. Some of these systems have been using TCP-IP for
quite a while, and therefore we expect few problems. (Please
note that we say "few", not "NO problems"!) Mail between Phonenet
sites should not be affected by the ARPANET transition. However,
mail between Phonenet sites and ARPANET sites (other than the
CSNET facilities noted above) may be disrupted.
The transition requires a major change in each of the more
than 250 hosts on the ARPANET; as might be expected, not all
hosts will be ready on 1 January 1983. For CSNET, this means
that disruption of mail communication will likely result between
Phonenet users and some ARPANET users. Mail to/from some ARPANET
hosts may be delayed; some host mail service may be unreliable;
some hosts may be completely unreachable. Furthermore, for some
ARPANET hosts this disruption may last a long time, until their
TCP-IP implementations are up and working smoothly. While we
cannot control the actions of ARPANET hosts, please let us know
if we can assist with problems, particularly by clearing up any
confusion. As always, we are or (617)497-2777.
Please pass this information on to your users.
Respectfully yours,
Nancy Mimno
CSNET CIC Liaison
================================================
================================================
some observations about the success of the switch-over
MSG 0001 02/02/83--23:49:45
To: CSNET mailing list
Subject: CSNET headers, CSNET status
You may have noticed that since ARPANET switched to TCP/IP and the
new version of software on top of it, message headers have become
ridiculously long. Some of it is because of tracing information
that has been added to facilitate error isolation and "authentication",
and some of it I think is a bug (the relay adds a 'From' and a 'Date'
header although there already are headers with that information in
the message). This usually doesn't bother people on the ARPANET
because they have smart mail reading programs that understand the
headers and only display the relevant ones. I have proposed a
mail reader/sender program that understands about ARPANET headers
(RFC822) as a summer project, so maybe we will sometime enjoy the
same priviledge.
The file CSNET STATUS1 on the CSNET disk (see instructions below
for how to access it) contains some clarification of the problems
that have been experienced with the TCP/IP conversion. Here is a
summary:
- Nodes that don't yet talk TCP (but the old NCP) can be accessed
through the UDel-Relay. So if you think you have problems reaching
a node because of this, append @Udel-Relay to the ARPANET address.
- You can find out about the status of hosts (e.g., if they run
TCP or not) by sending ANY MESSAGE to Status@UDel-Relay (capitalization
is NOT significant).
- If your messages are undeliverable, you get a notice after two days,
and your messages get returned after 4 days.
- Avoid using any of the fancy address forms allowed by the new
header format (RFC822).
- The TCP transition was a lot more trouble than the ARPANET people had
anticipated.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is Al Gore The Father of the Internet?^
Newsgroups: alt.folklore.computers,talk.politics.misc
Date: Wed, 27 Sep 2000 21:05:21 GMT
Anne & Lynn Wheeler writes:
... misc refs from the '80s.
long re-post warning ... from later in the 80s
From: geoff@FERNWOOD.MPK.CA.US (the terminal of Geoff Goodfellow)
Newsgroups: comp.protocols.tcp-ip
Subject: THE INTERNET CRUCIBLE - Volume 1, Issue 1
Date: 1 Sep 89 03:12:06 GMT
THE CRUCIBLE INTERNET EDITION
an eleemosynary publication of the August, 1989
Anterior Technology IN MODERATION NETWORK(tm) Volume 1 : Issue 1
Geoff Goodfellow
Moderator
In this issue:
A Critical Analysis of the Internet Management Situation
THE CRUCIBLE is an irregularly published, refereed periodical on
the Internet. The charter of the Anterior Technology IN MODERATION
NETWORK is to provide the Internet and Usenet community with
useful, instructive and entertaining information which satisfies
commonly accepted standards of good taste and principled discourse.
All contributions and editorial comments to THE CRUCIBLE are
reviewed and published without attribution. Cogent, cohesive,
objective, frank, polemic submissions are welcomed.
Mail contributions/editorial comments to: crucible@fernwood.mpk.ca.us
--------------------------------------------------------------------------
A Critical Analysis of the Internet Management Situation:
The Internet Lacks Governance
ABSTRACT
At its July 1989 meeting, the Internet Activities Board made some
modifications in the management structure for the Internet. An
outline of the new IAB structure was distributed to the Internet
engineering community by Dr. Robert Braden, Executive Director. In
part, the open letter stated:
"These changes resulted from an appreciation of our successes,
especially as reflected in the growth and vigor of the IETF, and
in rueful acknowledgment of our failures (which I will not
enumerate). Many on these lists are concerned with making the
Internet architecture work in the real world."
In this first issue of THE INTERNET CRUCIBLE we will focus on the
failures and shortcomings in the Internet. Failures contain the
lessons one often needs to achieve success. Success rarely leads to a
search for new solutions. Recommendations are made for short and long
term improvements to the Internet.
A Brief History of Networking
The Internet grew out of the early pioneering work on the ARPANET. This
influence was more than technological, the Internet has also been
significantly influenced by the economic basis of the ARPANET.
The network resources of the ARPANET (and now Internet) are "free".
There are no charges based on usage (unless your Internet connection
is via an X.25 Public Data Network (PDN) in which case you're well
endowed, or better be). Whether a site's Internet connection
transfers 1 packet/day or a 1M packets/day, the "cost" is the same.
Obviously, someone pays for the leased lines, router hardware, and the
like, but this "someone" is, by and large, not the same "someone" who
is sending the packets.
In the context of the Research ARPANET, the "free use" paradigm was an
appropriate strategy, and it has paid handsome dividends in the form
of developing leading edge packet switching technologies.
Unfortunately, there is a significant side-effect with both the
management and technical ramifications of the current Internet
paradigm: there is no accountability, in the formal sense of the word.
In terms of management, it is difficult to determine who exactly is
responsible for a particular component of the Internet. From a
technical side, responsible engineering and efficiency has been
replaced by the purchase of T1 links.
Without an economic basis, further development of short-term Internet
technology has been skewed. The most interesting innovations in
Internet engineering over the last five years have occurred in
resource poor, not resource rich, environments.
Some of the best known examples of innovative Internet efficiency
engineering are John Nagle's tiny-gram avoidance and ICMP
source-quench mechanisms documented in RFC896, Van Jacobsen's
slow-start algorithms and Phil Karn's retransmission timer method.
In the Nagle, Jacobsen and Karn environments, it was not possible or cost
effective to solve the performance and resource problems by simply adding
more bandwidth -- some innovative engineering had to be done.
Interestingly enough, their engineering had a dramatic impact on our
understanding of core Internet technology.
It should be noted that highly efficient networks are important when
dealing with technologies such as radio where there is a finite amount
of bandwidth/spectrum to be had. As in the Nagle, Jacobsen and Karn
cases, there are many environments where adding another T1 link can
not be used to solve the problem. Unless innovation continues in
Internet technology, our less than optimal protocols will perform
poorly in bandwidth or resource constrained environments.
Developing at roughly the same time as Internet technology have been
the "cost-sensitive" technologies and services, such as the various
X.25-based PDNs, the UUCP and CSNET dial-up networks. These
technologies are all based on the notion that bandwidth costs money
and the subscriber pays for the resources used. This has the notable
effect of focusing innovation to control costs and maximize efficiency
of available resources and bandwidth. Higher efficiency is achieved
by concentrating on sending the most amount of information through the
pipe in the most efficient manner thereby making the best use of
available bandwidth/cost ratio.
For example, bandwidth conservation in the UUCP dial-up network has
multiplied by leaps and bounds in the modem market with the innovation
of Paul Baran's (the grandfather of packet switching technology)
company, Telebit, which manufactures a 19.2KB dial-up modem especially
optimized for UUCP and other well known transfer protocols. For
another example, although strictly line-at-a-time terminal sessions
are less "user friendly" than character-oriented sessions, they make
for highly efficient use of X.25 PDN network resources with echoing
and editing performed locally on the PAD.
While few would argue the superiority of X.25 and dial-up CSNET and
UUCP, these technologies have proved themselves both to spur
innovation and to be accountable. The subscribers to such services
appreciate the cost of the services they use, and often such costs
form a well-known "line item" in the subscriber's annual budget.
Nevertheless, the Internet suite of protocols are eminently
successful, based solely on the sheer size and rate of growth of both
the Internet and the numerous private internets, both domestically and
internationally. You can purchase internet technology with a major
credit card from a mail order catalog. Internet technology has
achieved the promise of Open Systems, probably a decade before OSI
will be able to do so.
Failures of the Internet
The evolution and growth of Internet technology have provided the
basis for several failures. We think it is important to examine
failures in detail, so as to learn from them. History often tends to
repeat itself.
Failure 1:- Network Nonmanagement
The question of responsibility in todays proliferated Internet is
completely open. For the last three years, the Internet has been
suffering from non-management. While few would argue that a
centralized czar is necessary (or possible) for the Internet, the fact
remains there is little to be done today besides finger-pointing when
a problem arises.
In the NSFNET, MERIT is in charge of the backbone and each regional
network provider is responsible for its respective area. However,
trying to debug a networking problem across lines of responsibility,
such as intermittent connectivity, is problematic at best. Consider
three all too true refrains actually heard from NOC personal at the
helm:
"You can't ftp from x to y? Try again tomorrow, it will
probably work then."
"If you are not satisfied with the level of [network]
service you are receiving you may have it disconnected."
"The routers for network x are out of table space for routes,
which is why hosts on that network can't reach your new
(three-month old) network. We don't know when the routers will
be upgraded, but it probably won't be for another year."
One might argue that the recent restructuring of the IAB may work
towards bringing the Internet under control and Dr. Vinton G. Cerf's
recent involvement is a step in the right direction. Unfortunately,
from a historical perspective, the new IAB structure is not likely to
be successful in achieving a solution. Now the IAB has two task
forces, the Internet Research Task Force (IRTF) and the Internet
Engineering Task Force (IETF). The IRTF, responsible for long-term
Internet research, is largely composed of the various task forces
which used to sit at the IAB level. The IETF, responsible for the
solution of short-term Internet problems, has retained its
composition.
The IETF is a voluntary organization and its members participate out
of self interest only. The IETF has had past difficulties in solving
some of the Internet's problems (i.e., it has taken the IETF well over
a year to not yet produce RFCs for either a Point-To-Point Serial Line
IP or Network Management enhancements). It is unlikely that the IETF
has the resources to mount a concerted attack against the problems of
today's ever expanding Internet. As one IETF old-timer put it: "No
one's paid to go do these things, I don't see why they (the IETF
management) think they can tell us what to do" and "No one is paying
me, why should I be thinking about the these things?"
Even if the IETF had the technical resources, many of the Internet's
problems are also due to lack of "hands on" management. The IETF
o Bites off more than it can chew;
o Sometimes fails to understand a problem before making a solution;
o Attempts to solve political/marketing problems with technical
solutions;
o Has very little actual power.
The IETF has repeatedly demonstrated the lack of focus necessary to
complete engineering tasks in a timely fashion. Further, the IRTF is
chartered to look at problems on the five-year horizon, so they are
out of the line of responsibility. Finally, the IAB, per se, is not
situated to resolve these problems as they are inherent to the current
structure of nonaccountability.
During this crisis of non-management, the Internet has evolved into a
patch quilt of interconnected networks that depend on lots of
seat-of-the-pants flying to keep interoperating. It is not an unusual
occurrence for an entire partition of the Internet to remain
disconnected for a week because the person responsible for a key
connection went on vacation and no one else knew how to fix it. This
situation is but one example of an endemic problem of the global
Internet.
Failure 2:- Network Management
The current fury over network management protocols for TCP/IP is but a
microcosm of the greater Internet vs. OSI debate going on in the
marketplace. While everyone in the market says they want OSI, anyone
planning on getting any work done today buys Internet technology. So
it is with network management, the old IAB made the CMOT an Internet
standard despite the lack of a single implementation, while the only
non-proprietary network management protocol in use in the Internet is
the SNMP. The dual network management standardization blessings will
no doubt have the effect of confusing end-users of Internet
technology--making it appear there are two choices for network
management, although only one choice, the SNMP has been implemented.
The CMOT choice isn't implemented, doesn't work, or isn't
interoperable.
To compound matters, after spending a year trying to achieve consensus
on the successor to the current Internet standard SMI/MIB, the MIB
working group was disbanded without ever producing anything: the
political climate prevented them from resolving the matter. (Many
congratulatory notes were sent to the chair of the group thanking him
for his time. This is an interesting new trend for the
Internet--congratulating ourselves on our failures.)
Since a common SMI/MIB could not be advanced, an attempt was made to
de-couple the SNMP and the CMOT (RFC1109). The likely result of
RFC1109 will be that the SNMP camp will continue to refine their
experience towards workable network management systems, whilst the
CMOT camp will continue the never-ending journey of tracking OSI while
producing demo systems for trade shows exhibitions. Unfortunately the
end-user will remain ever confused because of the IAB's controversial
(and technically questionable) decision to elevate the CMOT prior to
implementation.
While the network management problem is probably too large for the
SNMP camp to solve by themselves they seem to be the only people who
are making any forward progress.
Failure 3:- Bandwidth Waste
Both the national and regional backbone providers are fascinated with
T1 (and now T3) as the solution towards resource problems. T1/T3
seems to have become the Internet panacea of the late 80's. You never
hear anything from the backbone providers about work being done to get
hosts to implement the latest performance/congestion refinements to
IP, TCP, or above. Instead, you hear about additional T1 links and
plans for T3 links. While T1 links certainly have more "sex and
sizzle" than efficient technology developments like slow-start, tiny
gram avoidance and line mode telnet, the majority of users on the
Internet will probably get much more benefit from properly behaving
hosts running over a stable backbone than the current situation of
misbehaving and semi-behaved hosts over an intermittent catenet.
Failure 4:- Routing
The biggest problem with routing today is that we are still using
phase I (ARPANET) technology, namely EGP. The EGP is playing the role
of routing glue in providing the coupling between the regional IGP and
the backbone routing information. It was designed to only accommodate
a single point of attachment to the catenet (which was all DCA could
afford with the PSNs). However with lower line costs, one can build a
reasonably inexpensive network using redundant links. However the EGP
does not provide enough information nor does the model it is based
upon support multiple connections between autonomous systems. Work is
progressing in the Interconnectivity WG of the IETF to replace EGP.
They are in the process of redefining the model to solve some of the
current needs. BGP or the Border Gateway Protocol (RFC1105) is an
attempt to codify some of the ideas the group is working on.
Other problems with routing are caused by regionals wanting a backdoor
connection to another regional directly. These connections require
some sort of interface between the two routing systems. These
interfaces are built by hand to avoid routing loops. Loops can be
caused when information sent into one regional network is sent back
towards the source. If the source doesn't recognize the information
as its own, packets can flow until their time to live field expires.
Routing problems are caused by the interior routing protocol or IGP.
This is the routing protocol which is used by the regionals to pass
information to and from its users. The users themselves can use a
different IGP than the regional. Depending on the number of
connections a user has to the regional network, routing loops can be
an issue. Some regionals pass around information about all known
networks in the entire catenet to their users. This information
deluge is a problem with some IGPs. Newer IGPs such as the new OSPF
from the IETF and IGRP from cisco attempt to provide some information
hiding by adding hierarchy. OSPF is the internets first attempt at
using a Dykstra type algorithm as an IGP. BBN uses it to route
between their packet switch nodes below the 1822 or X.25 layer.
Unstable routing is caused by hardware or hosts software. Older BSD
software sets the TTL field in the IP header to a small number. The
Internet today is growing and its diameter has exceed the software's
ability to reach the other side. This problem is easily fixed by
knowledgeable systems people, but one must be aware of the problem
before they can fix it.
Routing problems are also perceived when in fact a serial line problem
or hardware problem is the real cause. If a serial line is
intermittent or quickly cycles from the up state into the down state
and back again, routing information will not be supplied in a uniform
or smooth manner. Most current IGPs are Bellman-Ford based and employ
some stabilizing techniques to stem the flow of routing oscillations
due to "flapping" lines. Often when a route to a network disappears,
it may take several seconds for it to reappear. This can occur at the
source router who waits for the route to "decay" from the system.
This pause should be short enough so that active connections persist
but long enough that all routers in the routing system "forget" about
routes to that network. Older host software with over-active TCP
retransmission timers will time out connections instead of persevering
in the face of this problem. Also routers, according to RFC1009, must
be able to send ICMP unreachables when a packet is sent to a route
which is not present in its routing database. Some host products on
the market close down connections when a single ICMP reachable is
received. This bug flies in the face of the Internet parable "be
generous in what you accept and rigorous in what you send".
Many of the perceived routing problems are really complex multiple
interactions of differing products.
Causes of the Failures
The Internet failures and shortcomings can be traced to several sources:
First and foremost, there is little or no incentive for efficiency
and/or economy in the current Internet. As a direct result, the
resources of the Internet and its components are limited by factors
other than economics. When resources wear thin, congestion and poor
performance result. There is little to no incentive to make things
better, if 1 packet out of 10 gets through things "sort of work". It
would appear that Internet technology has found a loophole in the
"Tragedy of The Commons" allegory--things get progressively worse and
worse, but eventually something does get through.
The research community is interested in technology and not economics,
efficiency or free-markets. While this tack has produced the Internet
suite of protocols, the de facto International Standard for Open
Systems, it has also created an atmosphere of intense in-breeding
which is overly sensitive to criticism and quite hardened against
outside influence. Meanwhile, the outside world goes on about
developing economically viable and efficient networking technology
without the benefit of direct participation on the part of the
Internet.
The research community also appears to be spending a lot of its time
trying to hang onto the diminishing number of research dollars
available to it (one problem of being a successful researcher is
eventually your sponsors want you to be successful in other things).
Despite this, the research community actively shuns foreign technology
(e.g., OSI), but, inexplicably has not recently produced much
innovation in new Internet technology. There is also a dearth of new
and nifty innovative applications on the Internet. Business as usual
on the Internet is mostly FTP, SMTP and Telnet or Rlogin as it has
been for many years. The most interesting example of a distributed
application on the Internet today is the Domain Name System, which is
essentially an administrative facility, not an end-user service.
The engineering community must receive equal blame in these matters.
While there have been some successes on the part of the engineering
community, such as those by Nagel, Jacobsen and Karn mentioned above,
the output of the IETF, namely RFCs and corresponding implementations,
has been surprisingly low over its lifetime.
Finally, the Internet has become increasingly dependent on vendors for
providing implementations of Internet technology. While this is no
doubt beneficial in the long-term, the vendor community, rather than
investing "real" resources when building these products, do little
more than shrink-wrap code written primarily by research assistants at
universities. This has lead to cataclysmic consequences (e.g., the
Internet worm incident, where Sendmail with "debug" command and all
was packaged and delivered to customers without proper consideration).
Of course, when problems are found and fixed (either by the vendor's
customers or software sources), the time to market with these fixes is
commonly a year or longer. Thus, while vendors are vital to the
long-term success of Internet technology, they certainly don't receive
high marks in the short-term.
Recommendations
Short-term solutions (should happen by year's end):
In terms of hardware, the vendor community has advanced to the point
where the existing special-purpose technologies (Butterfly, NSSs) can
be replaced by off-the-shelf routers at far less cost and with
superior throughput and reliability. Obvious candidates for upgrade
are both the NSFNET and ARPANET backbones. Given the extended
unreliability of the mailbridges, the ARPA core is an immediate
candidate (even though the days of net 10 are numbered).
In terms of software, ALL devices in the Internet must be network
manageable. This is becoming ever more critical when problems must be
resolved. Since SNMP is the only open network management protocol
functioning in the Internet, all devices must support SNMP and the
Internet standard SMI and MIB.
Host implementations must be made to support the not-so-recent TCP
enhancements (e.g., those by Nagle, Jacobsen and Karn) and the more
recent linemode TELNET.
The national and regional providers must coordinate to share network
management information and tools so that user problems can be dealt
with in a predictable and timely fashion. Network management tools
are a big help, but without the proper personnel support above this,
the benefits can not be fully leveraged.
The Internet needs leadership and hands-on guidance. No one is
seemingly in charge today, and the people who actually care about the
net are pressed into continually fighting the small, immediate
problems.
Long-term solutions:
To promote network efficiency and a free-market system for the
delivery of Internet services, it is proposed to switch the method by
which the network itself is supported. Rather than a top-down
approach where the money goes from funding agencies to the national
backbone or regional providers, it is suggested the money go directly
to end-users (campuses) who can then select from among the network
service providers which among them best satisfies their needs and
costs.
This is a strict economic model: by playing with the full set of the
laws of economics, a lot of the second-order problems of the Internet,
both present and on the horizon, can be brought to heel. The Internet
is no longer a research vehicle, it is a vibrant production facility.
It is time to acknowledge this by using a realistic economic model in
the delivery of Internet services to the community (member base).
When Internet sites can vote with their pocketbooks, some new
regionals will be formed; some, those which are non-performant or
uncompetitive, will go away; and, the existing successful ones will
grow. The existing regionals will then be able to use their economic
power, as any consumer would, to ensure that the service providers
(e.g., the national backbone providers) offer responsive service at
reasonable prices. "The Market" is a powerful forcing function: it
will be in the best interests of the national and regional providers
to innovate, so as to be more competitive. Further, such a scheme
would also allow the traditional telecommunications providers a means
for becoming more involved in the Internet, thus allowing
cross-leverage of technologies and experience.
The transition from top-down to economic model must be handled
carefully, but this is exactly the kind of statesmanship that the
Internet should expect from its leadership.
-------
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is Al Gore The Father of the Internet?^
Newsgroups: alt.folklore.computers,talk.politics.misc
Date: Wed, 27 Sep 2000 21:07:13 GMT
Anne & Lynn Wheeler writes:
... misc refs from the '80s.
not quite from the 80s ... but Oct. 1990. The following is all the .com domains
in the Oct. 1990 domain list
bhp.com.au cpg.com.au jsf.com.au miden.com.au misadl.com.au
mits.com.au telecom.com.au netcom.ubc.ca inrs-telecom.uquebec.ca
hsa.com.world.utoronto.ca 3com.com 3mail.3com.com esd.3com.com 3m.com
a-t.com aaa.com aablue.com aai.com aati.com ab.com abb.com ims.abb.com
abbott.com able.com acadch.com acc.com acci.com accurate.com
accutec.com acd.com acs.com acw.com addamax.com adelie.com adi.com
adobe.com ads.com advansoft.com advsci.com aer.com ag.com agfa.com
ags.com aha.com aic.com aii.com aim.com ais.com ait.com aladdin.com
alc.com alcoa.com al.alcoa.com algorists.com alisa.com alliant.com
allied.com alphacdc.com alphalpha.com altos.com always.com amc.com
amcc.com amd.com amdahl.com ameritech.com amg.com amgen.com ami.com
amis.com cadr.amis.com amix.com amoco.com nap.amoco.com trc.amoco.com
amp.com ams.com amsinc.com mr.ams.com ana.com analytics.com
andersen.com anzus.com aocgl.com apex.com apldbio.com apldmt.com
apollo.com apple.com afsg.apple.com aux.apple.com cambridge.apple.com
support.apple.com applicon.com applix.com aps.com arbortext.com
arco.com ardent.com ariel.com arrent.com arris.com artel.com
artisans.com asa.com asi.com ast.com astrosoft.com astute.com
ateng.com athenanet.com atherton.com athsys.com ati.com atpal.com
att.com astro.att.com homer.att.com attmail.com mercury.att.com
astro.nj.att.com homer.nj.att.com mercury.nj.att.com phone.nj.att.com
tempo.nj.att.com zoo.nj.att.com phone.att.com tempo.att.com
uso.att.com zoo.att.com audiofax.com auratek.com aurora.com auspex.com
auto-trol.com autodesk.com autoex.com autosys.com avatar.com avco.com
aware.com axecore.com bally.com balr.com bang.com banyan.com barn.com
barton.com basis.com bbc.com bbn.com bct.com bd.com bdb.com bdm.com
bdt.com beartrack.com bec.com beckman.com bedrock.com bell-atl.com
bellcore.com bae.bellcore.com base.bellcore.com cc.bellcore.com
ctsd.bellcore.com ctt.bellcore.com wif.ctt.bellcore.com
facs.bellcore.com garden.bellcore.com hmslab.bellcore.com
leis.bellcore.com nps.bellcore.com osn.bellcore.com picst.bellcore.com
bendix.com bfm.com bigsur.com binky.com biocad.com biogfx.com
bioimage.com bis.com bison.com bitblocks.com bitstream.com bli.com
bma.com boeing.com cfd.boeing.com bohica.com bony.com bostech.com
boxhill.com bp.com brs.com bruker.com bse.com bsg.com bss.com bsw.com
bti.com btr.com bull.com atpc.bull.com az05.bull.com cr.bull.com
ladc.bull.com ma02.bull.com ma30.bull.com phx.bull.com pws.bull.com
test.pws.bull.com uk22.bull.com bungi.com byte.com c3.com cac.com
cadence.com cadnetix.com cadzooks.com cai.com calcomp.com camb.com
camex.com capitol.com capmkt.com cayman.com ccc.com ccs.com ccur.com
ocpt.ccur.com sdc.ccur.com tinton.ccur.com westford.ccur.com cdc.com
ahse.cdc.com aqeng.cdc.com arh.cdc.com cdl.cdc.com cpg.cdc.com
css.cdc.com dayfac.cdc.com dms.cdc.com eta.cdc.com iis.cdc.com
svl.cdc.com teg.cdc.com udev.cdc.com cds.com ce.com ceco.com cei.com
celestial.com cen.com centec.com cfc.com cfg.com cfi.com cgi.com
challenger.com charcoal.com chestnut.com chevron.com chipcom.com
chips.com chron.com ci.com cichlid.com cimage.com cims.com cimtek.com
cinnet.com cirr.com cisco.com citib.com citicorp.com clarinet.com
claris.com clarity.com clear.com clearpoint.com cli.com clsi.com
cmc.com cmi.com cns.com coat.com code3.com codonics.com cogwheel.com
coherent.com commodore.com comp.com compaq.com compass.com
compmail.com compu.com compuserve.com compzrs.com comsat.com
comsys.com conmicro.com consult.com consumers.com contel.com
asc.contel.com asd.contel.com ctc.contel.com fss.contel.com
imsd.contel.com iss.contel.com oasis.contel.com c2.oasis.contel.com
irm.oasis.contel.com lab.oasis.contel.com kirk.lab.oasis.contel.com
nestest3.oasis.contel.com ssar.oasis.contel.com
sstest.oasis.contel.com wtp.contel.com control.com convergent.com
convex.com coral.com corollary.com cos.com cpd.com cps.com cpu.com
cray.com asso24.cray.com craycos.com crj.cray.com cri.com crlabs.com
crsfld.com cs.com csc.com sd.csc.com starlab.csc.com csf.com csi.com
csms.com csps.com cssinc.com cstreet.com cti.com ctron.com cts.com
cummins.com cumulus.com cwi.com cyanamid.com cygnus.com darkside.com
das.com data-io.com datacube.com datagram.com datapoint.com
sat.datapoint.com davidsys.com dawntech.com dbaccess.com dbsoft.com
ddi.com ddmi.com de.com dec.com dco.dec.com decision.com pa.dec.com
deere.com dell.com delta.com deltam.com demott.com desktalk.com dg.com
aos.dg.com apex.dg.com ceo.dg.com dle.dg.com irvine.dg.com mceo.dg.com
oceo.dg.com rockville.dg.com rtp.dg.com sv.dg.com ts.dg.com
webo.dg.com dhbrown.com dhl.com dialogic.com digibd.com dimed.com
dimension.com dis.com disney.com dl.com dlogics.com dmc.com domain.com
dorsai.com dpw.com dra.com draper.com drd.com dri.com dsa.com dsc.com
dsi.com dss.com dtg.com dtseng.com dupont.com ei.dupont.com
fsg.dupont.com wizards.dupont.com ecaard.com eci.com eda.com edg.com
edge.com eds.com eeg.com efc.com efi.com eiffel.com eklektix.com
ekrl.com elan.com electro.com elm.com em.com emulex.com encore.com
marlboro.encore.com b7.marlboro.encore.com energetic.com entity.com
epi.com epic.com episupport.com epoch.com equi.com ere-net.com
ericsson.com es.com escom.com esi.com esl.com esri.com essnjay.com
etg.com etinc.com everexn.com excelan.com execu.com expert.com eye.com
eyring.com fac.com wdl.fac.com fai.com fairfax.com faxon.com fb.com
fenris.com ferranti.com fibercom.com fibermux.com flood.com fluke.com
flying-disk.com fmc.com ctc.fmc.com ford.com srl.ford.com fpr.com
fps.com frame.com franklin.com franz.com frey.com frox.com fsc.com
fsg.com ftp.com ether.ftp.com pro10.ftp.com pro4.ftp.com star1.ftp.com
vines.ftp.com fubarsys.com futures.com fx.com gammalink.com gat.com
gateway.com gaussian.com gca.com gcg.com gcm.com gd.com ge.com
geac.com cho.ge.com crd.ge.com dab.ge.com dnet.ge.com lynn.ge.com
med.ge.com nbc.ge.com gencorp.com gene.com genrad.com gensym.com
geoworks.com syr.ge.com gist.com glaxo.com gli.com gmr.com gnail.com
goldhill.com gordian.com gore.com gould.com grand.com graphon.com
grebyn.com greystone.com grumbly.com grumman.com gryphon.com gsg.com
gsidanet.com gsminc.com gss.com gtc.com gte.com gtech.com gtetele.com
guru.com gvc.com hac.com 1e.hac.com autonet.hac.com cb.hac.com
ccad.hac.com dnet.hac.com edsg.hac.com edsg1.hac.com edsg2.hac.com
gm.hac.com gsg.hac.com gt.hac.com hls.hac.com hns.hac.com hops.hac.com
hrl.hac.com hss.hac.com ieg.hac.com imagen.hac.com hackercorp.com
msg.hac.com profs.hac.com rsg.hac.com scg.hac.com scg1.hac.com
sixpack.hac.com hadron.com hamavnet.com harker.com harris-atd.com
harris.com ccd.harris.com corp.harris.com csd.harris.com
hdw.csd.harris.com mkt.csd.harris.com ssd.csd.harris.com
epg.harris.com ess.harris.com r3com.ess.harris.com ic1z.harris.com
lbp.harris.com sc.harris.com semi.harris.com daq.semi.harris.com
decnet.semi.harris.com joisy.semi.harris.com mis.semi.harris.com
mlb.semi.harris.com mtp.semi.harris.com nj.semi.harris.com
rtp.semi.harris.com ss.harris.com harvardsq.com haus.com hawaii.com
sets.hawaii.com hazeltine.com hcr.com herctec.com heurikon.com
hewm.com hfconsulting.com hitachi.com hls.com hns.com hnsx.com
hollander.com honda.com honeywell.com cfsat.honeywell.com
cfsmo.honeywell.com crl.honeywell.com dasd.honeywell.com
dsg.honeywell.com hi-csc.honeywell.com mavd.honeywell.com
micro.honeywell.com src.honeywell.com ssavd.honeywell.com
ssec.honeywell.com horizon.com hotline.com hp.com an.hp.com
apollo.hp.com ch.apollo.hp.com aso.hp.com atl.hp.com avo.hp.com
bbn.hp.com belgium.hp.com boi.hp.com bpo.hp.com bri.hp.com
calgary.hp.com ce.hp.com cnd.hp.com col.hp.com corp.hp.com cos.hp.com
ctgsc.hp.com cup.hp.com cv.hp.com desk.hp.com dtc.hp.com fc.hp.com
gr.hp.com grenoble.hp.com gva.hp.com hpl.hp.com xpd.hpl.hp.com
youdenpc.hpl.hp.com iag.hp.com lsid.hp.com lvld.hp.com mal.hp.com
mayfield.hp.com mcm.hp.com msr.hp.com neth.hp.com nsr.hp.com
pafc.hp.com ptp.hp.com rose.hp.com sc.hp.com scd.hp.com sdd.hp.com
sde.hp.com sgp.hp.com sid.hp.com spd.hp.com spk.hp.com sqf.hp.com
tky.hp.com uksr.hp.com vcd.hp.com wal.hp.com waterloo.hp.com
yhp.hp.com hrb.com hri.com hsi.com htc.com hyperion.com i-sight.com
i2wash.com iaps.com ibc.com ibm.com austin.ibm.com awdpa.ibm.com
cambridge.ibm.com cary.ibm.com iinus1.ibm.com kingston.ibm.com
fddi.kingston.ibm.com nic.kingston.ibm.com se.ibm.com ctp.se.ibm.com
watson.ibm.com ibuki.com icad.com icc.com ice.com icg.com icl.com
icom.com icon.com ics.com icus.com ide.com ids.com idsila.com idx.com
ie.com iex.com ig.com iii.com ila.com dialnet.ila.com ileaf.com
hq.ileaf.com imagen.com imagesys.com imatron.com imax.com imp.com
imsl.com in.com incsys.com indcomp.com indetech.com indsys.com
inference.com info.com infocomm.com informix.com infoserv.com ingr.com
ingres.com ininx.com inland.com inmet.com inmos.com innovative.com
inset.com instep.com integrity.com intek.com intel.com isc.intel.com
iwarp.intel.com intellicorp.com com.intellicorp.com sc.intel.com
intercon.com interlan.com unixlab.interlan.com interlink.com
hq.interlink.com md.interlink.com intermec.com interop.com intuit.com
intuitive.com ipoint.com iptech.com irby.com ironics.com irvine.com
isa.com isc-br.com isc.com i88.isc.com ico.isc.com ima.isc.com
ism.isc.com itx.isc.com iuk.isc.com ivy.isc.com sos.ivy.isc.com
iscs.com isg.com isi.com island.com ispi.com isx.com itcmn.com
itcorp.com ivc.com jar.com jbsys.com jbx.com jobsoft.com johngalt.com
joiner.com jones.com jsoft.com jts.com jupiter.com jvc.com jyacc.com
kai.com kaman.com kccs.com kenlaw.com kepler.com kesa.com kesmai.com
kevex.com kew.com key.com kfw.com kinetics.com kithrup.com klgai.com
kodak.com btc.kodak.com epps.kodak.com kohala.com kpc.com kroy.com
ksr.com kurz-ai.com kyoto.com lachman.com lakesys.com lantron.com
lawnet.com leedata.com legato.com leids.com lever.com lexicon.com
lgc.com lia.com liant.com lighthouse.com lilink.com link.com litle.com
litwin.com ljr.com llhs.com ln.com lockheed.com austin.lockheed.com
decnet.lockheed.com gelac.lockheed.com laic.lockheed.com
lasc-research.lockheed.com lasc.lockheed.com lisc.lockheed.com
lmsc.lockheed.com profs.lockheed.com rscs.lockheed.com
scf.lockheed.com space.lockheed.com stc.lockheed.com locus.com
logicon.com logitech.com lorentzian.com lotus.com lrw.com ls.com
lsil.com lsmi.com lti.com lucid.com barrnet.net.lucid.com lurnix.com
lvsun.com lynx.com magic.com malamud.com marble.com bos.marble.com
nyc.marble.com sjc.marble.com masa.com maspar.com mathworks.com
matrix.com matrox.com maxim.com maya.com mbf.com mcc.com aca.mcc.com
mccall.com cad.mcc.com cp.mcc.com cyc-west.mcc.com pkg.mcc.com
sw.mcc.com mckee.com mckinsey.com mcs.com mdaeng.com mdc.com
mdcbbs.com mdcgwy.mdc.com mdhc.mdc.com dnc.mdhc.mdc.com sap.mdc.com
sl.mdc.com mdi.com medcom.com medicus.com medtronic.com megalo.com
megasys.com meiko.com mentat.com mentor.com meridian.com
meridiantc.com merit-tech.com merk.com meso.com metaphor.com
metaware.com metrolink.com metron.com metter.com mga.com mgh.com
mgi.com microplex.com microunity.com microvation.com microware.com
migration.com mike.com mil3.com millipore.com mindcraft.com mips.com
cdc.com.mips.com svl.cdc.com.mips.com mitech.com mitek.com mitel.com
mks.com ml.com mmc.com airob.mmc.com bal.mmc.com cap.mmc.com
den.mmc.com mml.mmc.com orl.mmc.com arpa.orl.mmc.com vbg.mmc.com
mmdf.com mmm.com mmmg.com mmc.mmmg.com serc.mmm.com mmsac.com
moldev.com monsanto.com moore.com mop.com morgan.com morningstar.com
moscom.com mot.com aieg.mot.com comm.mot.com corp.mot.com csd.mot.com
ecg.mot.com gss.mot.com mcd.mot.com austin.mcd.mot.com chg.mcd.mot.com
phx.mcd.mot.com sjc.mcd.mot.com urbana.mcd.mot.com mcrc.mot.com
rtsg.mot.com sps.mot.com mps.com mpx.com mq.com msc.com msdc.com
msdrl.com mti.com mtxinu.com murphy.com mv.com myrias.com mystic.com
naitc.com nas.com natinst.com nbi.com ncd.com ncr.com ncube.com
ndl.com nds.com nec.com dl.nec.com bsd.dl.nec.com csl.dl.nec.com
ssd.dl.nec.com sj.nec.com net.com netagw.com netcs.com netlabs.com
netsys.com network.com netx.com neural.com next.com nirvonics.com
nissan.com nixdorf.com nli.com nls.com nma.com northrop.com
cirm.northrop.com dsd.northrop.com nad.northrop.com
cam.nad.northrop.com eng.nad.northrop.com qa.nad.northrop.com
nrtc.northrop.com novell.com npd.novell.com prv.npd.novell.com
router.npd.novell.com slc.npd.novell.com prv.novell.com vms.novell.com
wc.novell.com nrc.com nrc.com.nrc.com nsc.com nsi.com ntdms10.com
nth.com nti.com nw.com nynexst.com mac.nynexst.com nyt.com nytel.com
object.com objy.com ocs.com octel.com octopus.com odb.com odetics.com
odi.com odyssey.com olivetti.com atc.olivetti.com orc.olivetti.com
omnet.com omni.com omnicomp.com omron.com ontek.com ontologic.com
optigfx.com opustech.com ora.com oracle.com ar.oracle.com
at.oracle.com au.oracle.com be.oracle.com ca.oracle.com ch.oracle.com
cl.oracle.com de.oracle.com dk.oracle.com es.oracle.com fi.oracle.com
fr.oracle.com gr.oracle.com hk.oracle.com ie.oracle.com it.oracle.com
jp.oracle.com kr.oracle.com mx.oracle.com my.oracle.com nl.oracle.com
no.oracle.com nz.oracle.com pt.oracle.com se.oracle.com sg.oracle.com
th.oracle.com uk.oracle.com us.oracle.com orainc.com oresoft.com
ori-cal.com os.com osa.com osc.com ox.com aa.ox.com amex.ox.com
cboe.ox.com dwl.ox.com oxford.com ny.ox.com oz.com pacbell.com
dublin.pacbell.com fm.pacbell.com ns.pacbell.com orange.pacbell.com
sf370.pacbell.com smds.pacbell.com srv.pacbell.com sysengr.pacbell.com
pacer.com pacesetter.com pae.com panasonic.com ncrl.panasonic.com
panda.com paradigm.com paradise.com paradyne.com paragon.com
parallax.com parcplace.com parvenu.com pbi.com pcc.com pcr.com pcs.com
pcssc.com pda.com pdi.com pdx.com pegasus.com pei.com peregrine.com
performix.com pergamon.com perot.com persoft.com petra.com pharlap.com
pharmacia.com pharos.com phase2.com philips.com picker.com
pinnacle.com plexus.com plumhall.com plus5.com pm.com pmp.com
point4.com polaroid.com polygen.com pooh.com portal.com posix.com
postimage.com powerminds.com pra.com practic.com prc.com gis.prc.com
prenhall.com prepnet.com pghsun.prepnet.com prime.com prisma.com
prlgx.com probtek.com process.com progcons.com progress.com
propress.com prospect.com protec.com proteon.com pc.proteon.com
proto.com psg.com psi.com ca.psi.com reston.psi.com psitech.com
troy.psi.com psocg.com psp.com pti.com ptl.com pubnet.com pubserv.com
pw.com pwfl.com pyramid.com pzbaum.com qed.com qms.com qti.com
quad.com qualcomm.com quantum.com quest.com quick.com quintus.com
quorum.com quotron.com rabbit.com rac.com radius.com raidernet.com
rasna.com rasterops.com rational.com ray.com rdc.com rdl.com ready.com
eng.ready.com reasoning.com remtech.com resource.com resumix.com
retix.com reuter.com rfengr.com rga.com ricoh.com risc.com
anaheim.risc.com rjl.com robec.com rohmhaas.com rok.com
las.aero.rok.com pro.aero.rok.com cadcam.rok.com cdc.rok.com
cr.rok.com dallas.rok.com nb.rok.com roses.rok.com com.roses.rok.com
ssme.rok.com rosemount.com rosetta.com ross.com rpal.com
rpal.com.rpal.com elements.rpal.com narnia.rpal.com rsa.com rsi.com
rss.com rsw.com rtech.com s3.com sabbagh.com saber.com sadtler.com
sae.com sage.com sagepub.com saic.com ast.saic.com cseic.saic.com
dayton.saic.com sasig.saic.com tucson.saic.com salestech.com
samsung.com solbourne.com.samsung.com sanders.com sarnoff.com sas.com
sbc.com texbell.sbc.com sbi.com sbiny.com sbs.com sc-scicon.com
sca.com scc.com sccsi.com sceard.com sceptre.com sch.com sci.com
sco.com scs.com sctc.com scubed.com scum.com sda.com sdi.com sea.com
segue.com sei.com seiden.com semaphore.com sequent.com sequor.com
sgi.com shearson.com shell.com shiva.com shownet.com si.com sia.com
siemens.com hgs.siemens.com psi.siemens.com sc1.siemens.com
sc2.siemens.com scr.siemens.com scscpg.siemens.com sead.siemens.com
sgi.siemens.com shi.siemens.com sme.siemens.com sml.siemens.com
sigma.com silma.com silvlis.com simpact.com sky.com slb.com
asc.slb.com ase.slb.com asl.slb.com ate.slb.com bl.ate.slb.com
sj.ate.slb.com uk.ate.slb.com cad.slb.com aa.cad.slb.com
bl.cad.slb.com eps.slb.com geco.slb.com st.geco.slb.com hds.slb.com
scr.slb.com sdr.slb.com sinet.slb.com sjo.sinet.slb.com slcs.slb.com
lispm.slcs.slb.com smr.slb.com spar.slb.com spt.slb.com
verisys.slb.com slc.com sli.com slv.com smc.com smithkline.com sms.com
snide.com sns.com sobeco.com softest.com soi.com solbourne.com
solutions.com sony.com sfc.sony.com smsc.sony.com sophia.com
spacesoft.com sparc.com sparta.com spartacus.com spatial.com spdcc.com
specialix.com spectra.com splat.com sprint.com sps.com sq.com sqnt.com
squibb.com sr.com sra.com sri.com ai.sri.com cam.sri.com csl.sri.com
ides.csl.sri.com css.sri.com erg.sri.com gec.sri.com isl.sri.com
istc.sri.com itstd.sri.com nisc.sri.com wdc.sri.com ssc.com ssdl.com
ssesco.com ssi.com ssssc.com ssw.com stardent.com stargate.com
starnet.com starnine.com starstech.com statsci.com std.com steel.com
stellar.com stephsf.com stepstone.com sterling.com stingray.com
stortek.com stratus.com cac.stratus.com diag.stratus.com
hw.stratus.com hwsrv.stratus.com mae.stratus.com mfg.stratus.com
mis.stratus.com mktg.stratus.com pubs.stratus.com sqa.stratus.com
sw.stratus.com swdc.stratus.com test.stratus.com ts.stratus.com
stride.com sts.com stsusa.com stx.com su.com sumitomo.com sun.com
sunquest.com sunrise.com sunriver.com surfsoft.com sware.com
sybase.com symbolics.com scrc.symbolics.com symlab.com symult.com
synaptics.com synchrods.com synnet.com synopsys.com synoptics.com
synthesis.com syntrex.com sysadmin.com syssoft.com t3plus.com
net.t3plus.com tandem.com dsg.tandem.com expand.tandem.com
scpd.tandem.com transfer.tandem.com tandy.com tartan.com tasc.com
taumet.com tcc.com tce.com tcs.com tcsc.com tdi.com teamtech.com
techbook.com technicon.com tegra.com tek.com ens.tek.com
teknowledge.com telebit.com telematics.com teleos.com telesoft.com
tellabs.com teltone.com tera.com teramicro.com teraplex.com tetra.com
tg.com tgs.com tgv.com thalatta.com think.com dialnet.think.com
thomas.com thundercat.com thyrsus.com ti.com tic.com csc.ti.com
tis.com ba.tis.com la.tis.com tmc.com tmmnet.com tnt.com toad.com
tol-ed.com topologix.com touch.com trace.com transact.com transarc.com
trav.com triangle.com tripos.com truevision.com trw.com bmd.trw.com
coyote.trw.com decnet.trw.com demo.trw.com dsd.trw.com emc.trw.com
etdesg.trw.com fp.trw.com inc.trw.com ind.trw.com ulana.ind.trw.com
nafb.trw.com nba.trw.com rc.trw.com applenet.rc.trw.com
decnet.rc.trw.com sdd.trw.com sedd.trw.com spf.trw.com stg.trw.com
test.trw.com ulana.trw.com tsm.com tss.com ttank.com ttc.com tti.com
twg.com twinsun.com twwells.com txt.com tymnet.com archer.tymnet.com
tynan.com ub.com uci.com ueci.com ultimate.com ultra.com unicom.com
uniface.com unifi.com unify.com unipress.com uniscope.com unisoft.com
unisyn.com unisys.com adms-rad.unisys.com bluebell.unisys.com
wwt.bluebell.unisys.com cam.unisys.com dc.cam.unisys.com
nisd.cam.unisys.com sin.cam.unisys.com culv.unisys.com dev.unisys.com
gvl.unisys.com isf.unisys.com ksp.unisys.com mcl.unisys.com
prc.unisys.com reston.unisys.com rtc.reston.unisys.com
stars.reston.unisys.com rmtc.unisys.com rosslyn.unisys.com
stars.rosslyn.unisys.com rsvl.unisys.com slc.unisys.com sm.unisys.com
sp.unisys.com elric.sp.unisys.com planet8.sp.unisys.com
tredydev.unisys.com unocal.com ur-guh.com usi.com uss.com uswest.com
utc.com utoday.com uucom.com uujobs.com val.com validgh.com vcg.com
velvet.com verbatim.com verdix.com verifone.com veritas.com verity.com
versatec.com versoft.com viar.com vicom.com vicor.com vicorp.com
viewlogic.com vine.com visix.com visoftware.com vista.com vistanm.com
vistatech.com visus.com vitalink.com vitec.com vmp.com volt.com
vortex.com vpharm.com vpl.com vse.com vsg.com vsi.com wa.com waii.com
wallich.com walney.com wang.com warburg.com wcscnet.com wdi.com
wds.com wec.com weitek.com wellfleet.com wesco.com westmark.com
wgate.com wingman.com wj.com wlk.com worlds.com worldspan.com wpg.com
wri.com wrkgrp.com wrq.com wrs.com wsg.com ww.com wyse.com xanadu.com
xavax.com xed.com xei.com xerox.com xeroxep.com europarc.xerox.com
osbunorth.xerox.com parc.xerox.com wrc.xerox.com xait.xerox.com
xsis.xerox.com xidak.com xlnt.com xopusw.com xtech.com xwind.com
xylogics.com i.xylogics.com xyplex.com zds.com zehntel.com zipcode.com
zone1.com zst.com incom.de softcom.dk dycom.fi salcom.fi intracom.gr
sixcom.it oucom.osaka-u.ac.jp hanscom.af.mil centcom.mil eucom.mil
j6.eucom.mil pacom.mil socom.mil parcom.nl casecom.co.nz telecom.co.nz
corp.telecom.co.nz paccom.net.nz waikato.paccom.net.nz incomsec.org
manchester-computing-centre.ac.uk
cms.manchester-computing-centre.ac.uk
graphics.manchester-computing-centre.ac.uk
local-service.manchester-computing-centre.ac.uk british-telecom.co.uk
te.british-telecom.co.uk national-computing-centre.co.uk
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Competitors to SABRE? Big Iron
Newsgroups: alt.folklore.computers
Date: Thu, 28 Sep 2000 04:24:03 GMT
"David C. Barber" writes:
One thing about SABRE, they were known for having the fastest big iron
available. Though when they went to IIRC S/360 mod 91 and S/360 mod 195, I
wonder how much they had to reprogram to use those machines properly.
Anyone know what the big reservation systems are running on today?
In the late '60s they moved to PARS ... which became ACP (airline
control program) ... which morphed into TPF (transaction processing
facility). Besides airlines there are also a number of financial
operations implemented on TPF (see the ibm web pages below).
misc. ref:
http://www.garlic.com/~lynn/96.html#29
http://www.garlic.com/~lynn/99.html#24
http://www.garlic.com/~lynn/99.html#103
http://www.garlic.com/~lynn/99.html#152
http://www.sebek.co.uk/whatis.htm
http://www.s390.ibm.com/products/tpf/tpflnks.htm
http://www.tpfug.org/
http://smtp.vsoftsys.com/Vssiprod.htm
http://www.webtravelnews.com/344.htm
http://www.amdahl.com/doc/products/asg/links.htm
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is a VAX a mainframe?
Newsgroups: alt.folklore.computers
Date: Thu, 28 Sep 2000 15:06:06 GMT
Lars Poulsen writes:
A cluster is quite a different beast from a multiprocessor. When
we say multi-processor, we generally mean a tightly coupled system
where two or more processors share the same physical memory, and in
the classical case run a single operating system image, with each
processor grabbing ready-to-run processes from the same scheduler
run queue. Such systems have been around for many years, as you note
in the paragraph that I have omitted. But a cluster is something else,
and I first encountered it in VAX/VMS around 1984: A loosely coupled
group of machines, running separate system images, but often
sharing file systems through dual-access disk controllers.
the 360 disk controllers started out "twin-tailed". Various OS
components took advantage of it for loosely-coupled
(non-shared-memory) configurations. It was also used for OS/360 MP
configurations since the standard 360 SMP ... which only had
integrated shared memory and integrated I/O had to be simulated by
having devices connected to 360 channels specific to each processor.
It was also used by PARS/ACP ... for the airline control program
(recent discussion in this NG on sabre)
The disk controller in the 370 line (3830) expanded this support so
that disks could be accessed via eight different paths. The 360
loosely-coupled support utilized reserve/release ... i.e. the whole
device was reserved for a period and then released.
For ACP there was an enhancement to the 3830 disk controller that
supported fine-grain locking semantics in the controller itself (early
to mid-70s) ... supporting eight machine clusters.
For "HONE" ( http://www.garlic.com/~lynn/2000c.html#30 ) a simulated
compare&swap CCW sequence was used. Standard disk I/O sequence were
non-interruptable on a device. IBM "CKD" disk devices included I/O
operations that compared equal/high/low/etc on disk and did
conditional "branches" (TICs) in the I/O program (CCWs). HONE used the
compare&swap sequence to build large "single-system-image" complex in
the '78 time-frame supporting the field (salesman, support, etc).
When TPF (ACP follow-on) finally supported SMP multiprocessing, it
broke its eight processor limitation. These days, TPF can be found
with eight machine clusters where each machine might be a ten (or
more) processor SMP (yielding 80 or more processors in the cluster).
In the late '70s, my wife also spent a year in POK in charge of
mainframe "loosely-coupled" architecture. In the late '80s, my
wife and I ran a skunk-works that resulted in the HA/CMP
(high-availability, cluster multiprocessing) product
( http://www.garlic.com/~lynn/95.html#13 )
misc. refs:
http://www.garlic.com/~lynn/2000e.html#21
http://www.garlic.com/~lynn/2000e.html#6
http://www.garlic.com/~lynn/2000c.html#21
http://www.garlic.com/~lynn/2000c.html#30
http://www.garlic.com/~lynn/2000c.html#45
http://www.garlic.com/~lynn/2000c.html#47
http://www.garlic.com/~lynn/2000b.html#38
http://www.garlic.com/~lynn/2000.html#31
http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/99.html#88
http://www.garlic.com/~lynn/99.html#89
http://www.garlic.com/~lynn/99.html#149
http://www.garlic.com/~lynn/98.html#35a
http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/93.html#26
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is Tim Berners-Lee the inventor of the web?
Newsgroups: alt.folklore.computers
Date: Fri, 29 Sep 2000 15:27:02 GMT
jones@cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
So, he invented the web, but without him, the web would have happened
anyway, except without homage to SGML. Perhaps we'd all be writing
our web pages in a TeX or Troff based enhancement of gopher's index
notation.
and its precursor GML ...originally implemented in CMS' "script" text
processor ... and as an aside, note that CERN (where he worked) was a
long-time CMS shop ...since the early '70s (i.e. extensive use of GML
in the shop for possibly 20 years or more at the time the work
happened)
misc. ref:
http://www.garlic.com/~lynn/2000e.html#0
http://www.garlic.com/~lynn/2000e.html#1
http://www.garlic.com/~lynn/2000d.html#30
http://www.garlic.com/~lynn/99.html#28