[email protected] (Jon Perryman) writes:
> I meant to say when TCP/IP was publicly available. I think ARPANET was
> only available to the military.

re:
http://www.garlic.com/~lynn/2013n.html#16 z/OS is antique WAS: Aging Sysprogs = 
Aging Farmers
http://www.garlic.com/~lynn/2013n.html#17 z/OS is antique WAS: Aging Sysprogs = 
Aging Farmers

attachment and IMPs required arpa approval ... which limited uptake.
http://en.wikipedia.org/wiki/ARPANET

lots of universities & non-DOD, milnet was the part of the arpanet for
unclassified DOD traffic
http://en.wikipedia.org/wiki/MILNET

note that nsfnet backbone in the late 80s also had AUP (acceptable use
policy) for non-commercial use 
http://en.wikipedia.org/wiki/National_Science_Foundation_Network

... although there was freely available tcp/ip protocol implementations
available on lots of platforms ... and could be used for private
networks ... even if they didn't connect to regional and/or backbone

it was until early 90s and CIX that you have transition to commercial
backbone. 
http://en.wikipedia.org/wiki/Commercial_Internet_eXchange

i've periodically commented that tcp/ip was the technology basis for the
modern internet, nsfnet backbone was the operational basis for the
modern internet and (finally) cix was the business basis for the modern
internet.

RFC standard specifications for both arpanet and tcp/ip were publicly
available and anybody could implement support. my RFC index
http://www.garlic.com/~lynn/rfcietff.htm

trivia, until Postel ("rfc editor") passed, he let me do part of STD1.

as undergraduate in the 60s, I did a lot of operating system changes
... both os/360 and (virtual machine) cp67. cp/67 shipped with 1052 and
2741 terminal support ... but univ. also ascii tty terminals ...  so I
did the work to add ascii tty terminal support. cp/67 did dynamic
terminal type identification for 1052 & 2741s ... so I tried to extend
it for tty support (this was picked up by the science center and shipped
in standard cp67) ... which didn't quite work the way I wanted. leased
lines were fine ... but I wanted a single dialup number ("hunt group")
for all terminals. the problem was IBM had taken short cut in terminal
controller; it was possible to dynamically change the line-scanner for
each port ("SAD" CCW) ... but the line-speed (oscillator) was hard-wired
for each port.

somewhat as a result the univ. started a clone controller project ...
reverse engineer a channel interface board, program an interdata/3
minicomputer to emulate ibm terminal controller (with own channel
interface board) ... supporting both dynamic terminal type and dynamic
terminal line-speed. this later was extended with an interdata/4 for the
channel interface and cluster of interdata/3s for port interfaces.  this
was made available to interdata which marketed it commercially (later
Perkin/Elmer bought Interdata and continued to sell under PE logo).
Four of us got written up for being responsible for some part of the
clone controller business ... some past posts
http://www.garlic.com/~lynn/subtopic.html#360pcm

early 70s, IBM had the Future System project (would completely replace
360/370) ... a major motivation was to significantly raise the bar for
clone controllers (lack of 370 products during this period is credited
with giving clone processors a market foothold). Later when FS imploded
there was mad-rush to get products back into the 370 pipelines. some
past posts 
http://www.garlic.com/~lynn/submain.html#futuresys

there have been claims that the extreme complexity in the PU5/PU4
(VTAM/NCP) interface was attempt to meet the base FS objectives of
significantly raising the bar as countermeasure to clone controllers
(major design point for sna architecture).


-- 
virtualization experience starting Jan1968, online at home since Mar1970

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to