List of Archived Posts

2000 Newsgroup Postings (07/12 - 09/11)

Is a VAX a mainframe?
Is a VAX a mainframe?
IBM's "ASCI White" and "Big Blue" architecture?
IBM's "ASCI White" and "Big Blue" architecture?
Share - lodging (MTA)
Definition of SHARE & SCIDS Requested
Definition of SHARE & SCIDS Requested
4341 was "Is a VAX a mainframe?"
IBM's "ASCI White" and "Big Blue" architecture?
4341 was "Is a VAX a mainframe?"
4341 was "Is a VAX a mainframe?"
4341 was "Is a VAX a mainframe?"
4341 was "Is a VAX a mainframe?"
4341 was "Is a VAX a mainframe?"
FW: RS6000 vs IBM Mainframe
APL version in IBM 5100 (Was: Resurrecting the IBM 1130)
The author Ronda Hauben fights for our freedom.
Where's all the VMers?
S/360 development burnout?
Comrade Ronda vs. the Capitalist Netmongers
S/360 development burnout?
S/360 development burnout?
IBM promotional items?
S/360 development burnout?
Superduper computers--why RISC not 390?
Superduper computers--why RISC not 390?
Superduper computers--why RISC not 390?
Superduper computers--why RISC not 390?
RS/6000 vs. System/390 architecture?
Secure Operating Systems
Secure Operating Systems
RS/6000 vs. System/390 architecture?
S/360 development burnout?
Adventure Games (Was: Navy orders supercomputer)
Assembly language formatting on IBM systems
S/360 development burnout?
Assembly language formatting on IBM systems
S/360 development burnout?
S/360 development burnout?
Future hacks [was Re: RS/6000 ]
360 CPU meters (was Re: Early IBM-PC sales proj..
TCP/IP Suite of Protocols - dumb question ...
360 CPU meters (was Re: Early IBM-PC sales proj..
Al Gore: Inventing the Internet...
Charging for time-share CPU time
Charging for time-share CPU time
Charging for time-share CPU time
Charging for time-share CPU time
Navy orders supercomputer
Navy orders supercomputer
Navy orders supercomputer
Navy orders supercomputer
IBM 650 (was: Re: IBM--old computer manuals)
IBM 650 (was: Re: IBM--old computer manuals)
NCP Help (re (D)ARPANET)
NCP v TCP/IP
Is Al Gore The Father of the Internet?
iAPX-432 (was: 36 to 32 bit transition
Is Al Gore The Father of the Internet?
Is Al Gore The Father of the Internet?
"all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
"all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
iAPX-432 (was: 36 to 32 bit transition
Is Al Gore The Father of the Internet?
"all-out" vs less aggressive designs
"all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
standard BASIC (was: S/360 development burnout?)
Is Al Gore The Father of the Internet?^
"all-out" vs less aggressive designs
"all-out" vs less aggressive designs
When the Internet went private
When the Internet went private
When the Internet went private
When the Internet went private
When the Internet went private
When the Internet went private
When the Internet went private
Is Al Gore The Father of the Internet?^
When the Internet went private
When the Internet went private
When the Internet went private
Coloured IBM DASD
"all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
Closed versus Stealth

Is a VAX a mainframe?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is a VAX a mainframe?
Newsgroups: alt.folklore.computers
Date: Wed, 12 Jul 2000 23:47:00 GMT
misc. other 4341 information .... because 4341 needed to be tested with disks ... the disk engineering labs got 4341s before the endicott performance testing groups (who could initially only get sporadic test shots on engineering machines).

Since I was providing support for the disk engineering & product test labs ... I actually had better access for testing 4341s than most of the endicott groups.

one of the things in the 4341 was significantly improved floating point support ... over the previous "endicott" (lower-end) machines (like the 145).

simple test run that I did for the endicott engineers (circa feb. 1979)

Following are times for floating point fortran job running same fortran


                  158               3031              4341

Rain              45.64 secs       37.03 secs         36.21 secs
Rain4             43.90 secs       36.61 secs         36.13 secs

also times approx;
                   145                168-3              91
                 145 secs.          9.1 secs          6.77 secs

rain/rain4 was from Lawrence Radiation lab ... and ran on cdc6600 in 35.77 secs.

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Is a VAX a mainframe?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is a VAX a mainframe?
Newsgroups: alt.folklore.computers
Date: Wed, 12 Jul 2000 23:50:17 GMT
Anne & Lynn Wheeler writes:
simple test run that I did for the endicott engineers (circa feb. 1980)
^^^^
oops, should be:                                                  1979

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

IBM's "ASCI White" and "Big Blue" architecture?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM's "ASCI White" and "Big Blue" architecture?
Newsgroups: alt.folklore.computers
Date: Thu, 13 Jul 2000 04:46:33 GMT
lwinson@bbs.cpcn.com (lwin) writes:
Ok, so what's _under_ the hood--is it the S/390 instruction set, or something unique to this machine?

following from:
http://www.llnl.gov/asci/news/white_news.html
https://web.archive.org/web/20010124100500/http://www.llnl.gov/asci/news/white_news.html

Today's system is the third step of a planned dramatic increase in computing power. The large systems are not the end but the means to drive extremely complex computer simulations. ASCI's goal is to develop the capability to simulate nuclear weapons' behavior to ensure their safety and reliability over the long term. This requires the ability to calculate what happens to billions of data points in small fractions of a second. The 10 TeraOps supercomputer at Livermore will consist of more than 8,000 of IBM's newest and fastest RS/6000 processors. Future plans call for acquisition of a 30 and a 100 TeraOps system.

........................

they mention 512 cabinets, which at 16 power3/cabinet = 8192 nodes

from:
http://www.cineca.it/resources/sp3/index.html
https://web.archive.org/web/20001021050132/http://www.cineca.it/resources/sp3/index.html
http://www.epcc.ed.ac.uk/direct/newsletter5/node11.html
https://web.archive.org/web/20000823134548/http://www.epcc.ed.ac.uk/direct/newsletter5/node11.html
800mflops peak per 200mhz power3 for 8192 cpus gives about 6.5tflop

announcement for 144 node / 1,152 375MHZ Power3-II chips:
http://www8.zdnet.com/eweek/stories/general/0,11011,2435011,00.html

just using simple scaling of Mhz (375/200)800mflops gives 1.5gflops times 8192 nodes 12.2tflops ... which possibly yieds the statement regarding 10 teraops?

misc asci refs:
http://www.llnl.gov/asci/
https://web.archive.org/web/20000815204903/http://www.llnl.gov/asci/
http://www.ibm.com/ibm/publicaffairs/gp/asci.html
http://www.rs6000.ibm.com/resource/features/1998/asci_oct/asci_fact.html
http://www.rs6000.ibm.com/resource/features/1998/asci_oct/

misc sp1/sp2 refs:
http://www.rs6000.ibm.com/software/sp_products/pssp.html
http://www.rs6000.ibm.com/resource/pressreleases/1999/May/sp_trillionpr.html
http://www.rs6000.ibm.com/hardware/largescale/
http://clumber.tc.cornell.edu/HyperNews/get/OtherSites.html
https://web.archive.org/web/20001205063400/http://clumber.tc.cornell.edu/HyperNews/get/OtherSites.html
http://www.mhpcc.edu/doc/faq/performance_prog.html
https://web.archive.org/web/20010119114200/http://www.mhpcc.edu/doc/faq/performance_prog.html
http://alpha.mhpcc.edu/mhpcc/mhpcc/WW155.html
https://web.archive.org/web/20010226094027/http://alpha.mhpcc.edu/mhpcc/mhpcc/WW155.html
http://www.mhpcc.edu/general/images/machines.jpg
https://web.archive.org/web/20010607215753/http://www.mhpcc.edu/general/images/machines.jpg
http://www.arc.unm.edu/Workshop/libraries/pmatlib/overview.html
https://web.archive.org/web/20000823134543/http://www.arc.unm.edu/Workshop/libraries/pmatlib/overview.html
http://pipeline.mhpcc.edu/research/ab96/ab47.html
https://web.archive.org/web/20010803043825/http://pipeline.mhpcc.edu/research/ab96/ab47.html
http://www-jics.cs.utk.edu/sp2guide/SP2_guideMay96/SP2_guideMay96.html
https://web.archive.org/web/20010228075932/http://www-jics.cs.utk.edu/sp2guide/SP2_guideMay96/SP2_guideMay96.html
http://web.eecs.utk.edu/~liang/pjct460/nhse2/7.html

some other info:
http://www.performance-computing.com/features/99091.shtml

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

IBM's "ASCI White" and "Big Blue" architecture?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM's "ASCI White" and "Big Blue" architecture?
Newsgroups: alt.folklore.computers
Date: Thu, 13 Jul 2000 06:11:30 GMT
... and some SP2 switch references ....
http://www.tc.cornell.edu/Edu/Talks/SP/switch.html
https://web.archive.org/web/20001008025523/http://www.tc.cornell.edu/Edu/Talks/SP/switch.html
http://www.nd.edu/~msichiti/Goodies/laucomp/comp.htm
https://web.archive.org/web/20011110115346/http://www.nd.edu/~msichiti/Goodies/laucomp/comp.htm
http://www.llnl.gov/sccd/lc/asci/th_images.html
https://web.archive.org/web/20021026234740/www.llnl.gov/icc/lc/asci/th_images.html

misc. other references ...
http://csep1.phy.ornl.gov/CSEP/SP2/SP2.html
https://web.archive.org/web/20011114100943/http://csep1.phy.ornl.gov/CSEP/SP2/SP2.html
http://www.lysator.liu.se/~oscar/sp2/
http://www.research.ibm.com/journal/sj/agerw/agerw.html

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Share - lodging (MTA)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Share - lodging (MTA)
Newsgroups: bit.listserv.ibm-main
Date: Thu, 13 Jul 2000 23:43:56 GMT
efinnell@SEEBECK.UA.EDU (Edward J. Finnell, III , Ed) writes:
She walked down to Scully Square station and handed Charlie a sandwitch.....

.......

(To the dune of "Everglades" and "The MTA", and with apologies to the
Kingston Trio, which does not necessarily include IBM.)

(sparkling guitar intro)

I was born and raised around Poughkeepsie,
A programmer is what I had to be;
But IBM and its programming team
Have turned me into a debugging machine.

Running all my jobs under MVT.

Where a job can run and never be found,
And all you see are discs goin' 'round;
And when you get your output the results are nil:
If the JCL don't get you then the systems will.

I put my job in the input queue.
And watched in awe as the system blew.
When I reran the job, I felt really crushed;
I saw on my listing: INPUT STREAM DATA FLUSHED.

Running all my jobs under MVT.

                                CHORUS

I reran the job and ran out of space;
I reran the job with a step out of place;
I reran the job with priority 10 ... (pause)

  "Will it ever return, no, it'll never return,
And its fate is still unlearned,
  It may hide forever in SYS1.LINKLIB..."
(pause)

Running all my jobs under MVT.

CHORUS

Well, I couldn't get a job past the JCL hump,
So I never got a chance to read an ABEND dump,
If I could get one through, I'd have debugging fun,
'Cause the job was in the language known as PL/I.

                                CHORUS

Getting lots of grief from this MVT.
Running like a thief 'way from MVT.
Getting round this mess via DOS.

                       (rousing guitar finale)

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

Definition of SHARE & SCIDS Requested

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Definition of SHARE & SCIDS Requested
Newsgroups: bit.listserv.ibm-main
Date: Fri, 14 Jul 2000 04:16:37 GMT
Steve Samson writes:
IIRC, SCIDS is Share Conference Informal Discussion Session. Share is NOT an acronym, it's a verb. As the current slogan says: "SHARE--It's what we do"

i alwas thot it was Society for Continous Inebreation During Share

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

Definition of SHARE & SCIDS Requested

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Definition of SHARE & SCIDS Requested
Newsgroups: bit.listserv.ibm-main
Date: Fri, 14 Jul 2000 19:17:19 GMT
Anne & Lynn Wheeler writes:
finger slip; Continous->Continuous
i alwas thot it was Society for Continuous Inebreation During Share


back in the early days when you had to go to the president's suite in the very early AM of friday to help finish off the bottles left over from the open bar

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

4341 was "Is a VAX a mainframe?"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: 4341 was "Is a VAX a mainframe?"
Newsgroups: alt.folklore.computers
Date: Fri, 14 Jul 2000 21:35:45 GMT
Anne & Lynn Wheeler writes:
158 3031 4341 Rain 45.64 secs 37.03 secs 36.21 secs

the 4341 & 3031 were contemporaries ... but the 4341 was faster, less expensive, smaller, and had lower cooling requirements. Also, 4-5 4341s had about the same thruput as a 3033, were less expensive, smaller and had much lower cooling requirements (as well as 3033 typically having only 15 high speed channels while 4-5 4341s had 20-25 high speed channels aggregate ... in an era when more & more things were becoming significantly i/o limited; 3033 started out with only 16mbytes real memory max ... and 4-5 4341s could have 64mbytes to 80mbytes real memory aggregate)

The other factor was that the 4341 channels were "faster" than the 303x channel directors.

The 3330 disk drives were typically access with count-key-data CCW sequence consisting of seek, search id-equal, tic-8, read/write . For paging and 4kblock file access the tracks were formated with 4k-byte blocks with dummy blocks inserted between the data blocks. The 3330 track had enuf room for three 4k data blocks plus 101-byte dummy blocks.

The 3330 had 19 tracks per "cylinder" (or arm position). It was possible to block "chain" transfer requests by inserting "tic" (channel program branch requests) from the end of one block transfer (read/write) to the start of the next seek request.

The mainframe transfer process has the CCWs located in main memory with the channel "fetching" a copy of the next CCW after the previous CCW had completed. The channel then passes the CCW to the control unit which decodes the operation and sends the appropriate request to the device (disk drive).

The 3330 specification called for a minimum of 110-byte "dummy" blocks in order to successfully perform a head switch and read the next record on a different track (and not incure a rotational "miss" ... i.e. the search id-equal CCW is processed after the start of the next data block). The 110-byte "dummy" block has the 3330 drive rotating while the channel is processing the tic (to the next request) CCW and the following SEEK CCW (select different head/track on the same cylinder; no actual arm motion is required).

145 (and 4341) channels were able to process the sequence (tic to next block of CCWs and seek) 100% when a 3330 was formated 101-byte dummy blocks ... and successfully transfer the next data block on a different track (w/o requiring an additional rotational delay) ... i.e. the search request for the next record ... got to the disk device before the start of data record had rotated past the head (if the start of record rotates past the head ... then the disk rotates around until the desired record comes to the head again).

158 channels would only successfully do the head switch and transfer 20%-30% of the time (70%-80% of the time, the selection would "miss" and the 3330 did an additional rotation).

All the 303x channel directors were essentially 158 channels in a different package. They tried to compensate for the problem by allowing the 303x channel director to perform limited CCW "prefetch". The mainframe channel CCW processing was defined as synchronous, sequential process ... which allowd a previous CCW to do data transfer and modify the following CCW. Any sort of prefetch would have watch carefully for CCWs being modified after the prefetch.

In any case, even with the 303x channel directors doing limited prefetch, attempting to do the head switch & read next record on any of the 3031, 3032, or 3033 models would result in 70%-80% rotational miss (the same characteristic as on the 158).

The latency problem in processing is similar but different to the increase CCW processing latency introduced in the 3830->3880 transition.

Another problem we saw on the 158 was with fixed-head disks (2505 paging "drums"). It was possible to organizing operations for 4k transfers with head-switch between record transfers ... in much the same way as with 3330s ... except in this case ... there was never any arm motion since every track on the device also had a read/write head. We had a 158 configuration with 2305 controller on the end of a 15' cable and everything worked fine. One weekend they re-organized the machine room and the 2305 controller was placed on a 75' cable (within max. specification) and performance on monday went thru the floor. It turns out that things were right at the border line and the it was starting to miss on every head switch.

Back to the 303x/4341 saga ... there was a rumor at the time that the executive responsible for 303xs attempted to address the opportunity by getting the chip fabrication plant to cut the allocation to the 4341 group by 50%.

misc. ref:
https://www.garlic.com/~lynn/95.html#8
https://www.garlic.com/~lynn/99.html#6
https://www.garlic.com/~lynn/99.html#74
https://www.garlic.com/~lynn/99.html#75
https://www.garlic.com/~lynn/99.html#209
https://www.garlic.com/~lynn/2000b.html#38
https://www.garlic.com/~lynn/2000c.html#34
https://www.garlic.com/~lynn/2000c.html#75
https://www.garlic.com/~lynn/2000c.html#76
https://www.garlic.com/~lynn/2000c.html#83

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

IBM's "ASCI White" and "Big Blue" architecture?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM's "ASCI White" and "Big Blue" architecture?
Newsgroups: alt.folklore.computers
Date: Fri, 14 Jul 2000 21:56:32 GMT
Anne & Lynn Wheeler writes:
announcement for 144 node / 1,152 375MHZ Power3-II chips:

http://www8.zdnet.com/eweek/stories/general/0,11011,2435011,00.html

just using simple scaling of Mhz (375/200)800mflops gives 1.5gflops times 8192 nodes 12.2tflops ... which possibly yieds the statement regarding 10 teraops?


note that any 1.5gflops for a 375mhz power3-ii chip is the same as the kingston engineering and technology center in 1985.

misc. ref:
https://www.garlic.com/~lynn/2000c.html#61

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

4341 was "Is a VAX a mainframe?"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 4341 was "Is a VAX a mainframe?"
Newsgroups: alt.folklore.computers
Date: Sat, 15 Jul 2000 00:23:02 GMT
Terry Kennedy writes:
Couldn't the control unit have been modified (with a "-II" suffix or as a RPQ) to include a track buffer or two? 32KB was certainly do-able in the 370 era and would have allowed read-ahead.

Of course, all of the systems I used had "Integrated <mumble> Adapter" logic for the disks, where the strings attached directly to a dedicated spot on the processor (3340's on assorted low-end 370's and a 4331).


there were 19 tracks in 3330 "cylinder" ... there wasn't a rotational miss reading the next record on the same track ... it was a problem if you had to switch heads to a different track (at the same arm position) and read the next record (from a rotational position standpoint). To allow switching to any head ... would have required full-track buffering for each head ... with either (19) track buffers in the device or a similar set of buffers in the controller for each device (track buffer would have been about 14kbytes, 19tracks would be about 266kbytes at the device level ... or 4256kbytes at the control level with 16 devices or double that with 32 devices).

Putting the buffer back in the controller would have also required 19 parallel data paths between each device and the controller (or a data path that ran something like 20 the head transfer rate). For a string of 32 devices ... it would have to handle something like 3220(3330 head transfer rate) ... 640(3330 head transfer rate). When I looked at the problem for high speed disk transfer ... (actually being able to transfer data in parallel on multiple heads) there was also some problem with the head positioning servo feedback loop.

Things got even more complex with "string switch". It was possible to connect a string of devices to two different controllers ... and each controller to hook to four different channels ... allowing access to any specific device from up to eight different processor complexes ... an example was:
https://www.garlic.com/~lynn/2000c.html#30

the above involved two processors per complex (total of 16 processors in the single system image complex accessing a couple hundred disks).

there were other 8-way disk configurations ... but they were single processor operations (in fact, because the software .. PARS/ACP/TPF lacked multiprocessor support was the reason that the single processor 3083 came out ... the 3081 originally was only going to be two processor ... with the 3084 as a pair of 3081 for four processors) ... misc. ref:
https://www.garlic.com/~lynn/99.html#100
https://www.garlic.com/~lynn/99.html#136a
https://www.garlic.com/~lynn/2000.html#0
https://www.garlic.com/~lynn/2000.html#31
https://www.garlic.com/~lynn/2000.html#61

in any case ... string switch & track buffers in the controller would have required the track read ahead be propagated to buffers in both controllers.

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

4341 was "Is a VAX a mainframe?"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 4341 was "Is a VAX a mainframe?"
Newsgroups: alt.folklore.computers
Date: Sat, 15 Jul 2000 00:30:26 GMT
Terry Kennedy writes:
Of course, all of the systems I used had "Integrated <mumble> Adapter" logic for the disks, where the strings attached directly to a dedicated spot on the processor (3340's on assorted low-end 370's and a 4331).

in this situation did look at something with fancy queueing with VAMPS (multiprocessor 125) project because the disk controller "IOP" ... sat directly on the memory bus

ref:
https://www.garlic.com/~lynn/2000c.html#68

the design had high-speed queued i/o where the disk controller had some latitude in dynamically choosen what requests to serve next ... based in part on having access to near real-time input as to rotation position.

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

4341 was "Is a VAX a mainframe?"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 4341 was "Is a VAX a mainframe?"
Newsgroups: alt.folklore.computers
Date: Sat, 15 Jul 2000 04:01:01 GMT
Terry Kennedy writes:
But we're talking about the special case of paging I/O, doing consec- utive sectors. So only the next track would have to be read (the control-

in that case, the controller (& channel) would need to have CCW pre-fetch ... a much more complex version than the simple one tried for the 303x channel director (or what I did for VAMPS/125 where the controller was actually attached to the memory bus and it was possible to do high speed queued i/o) ... in order to actually know ahead of time which track would be switched to. However, if you were able to do CCW prefetch and know ahead of time what track would be switched to ... then, in fact, there would be no latency problem with not knowing ahead of time which record was going to be read (until it had just passed by the read head and would result in a rotational miss), and it wouldn't be a problem (in the 145, 148, 4341 cases, there was much lower latency and it knew which track it would be switching to ... in time to catch the record before it passed under the head).
But how common was it to be doing paging on all 32 drives? I'd think there could be some sort of opcode modifier (like "read with buffering")

I had done page formated file system ... which i was trying to get out in the product (which never really happened except for a limited special case) ... and at least for some number of installation ... all 32 drives could be using the same page logic.

However, singleton page transfers were the ones that really exhibited the problem. I had also done prepaging ... for multiple page transfers... and a lot went into the file system logic to also do block transfers ... so things tended to be much more contiguous transfers (with head switches tending to occur between end of track and start of track) ... even tho everything was passing thru the same low-level page i/o logic.

there was also the idea of doing load balancing across all drives ... potentially getting a little bit of single page tranfer space allocation, multi-page transfer space allocation, file system allocation and misc. other system usage on every drive ("spool", aka unit record & networking temp space also used same disk format & low level i/o queuing routines ... and it was even possible to mix page "overflow" in spooling areas) according to usage & load pattern.

page access file system ref
https://www.garlic.com/~lynn/93.html#31

paging, spooling, page access file system ref
https://www.garlic.com/~lynn/2000.html#75
https://www.garlic.com/~lynn/2000b.html#43

we actually did some more detailed investigation on the load balancing, track buffering and caching that involved detailed record activity traces for production systems (there may have even been a patent or two regarding being able to reduce trace information in real time and do various types of system re-organizations on the fly).

Two notable projects involved looking at 1) large system configurations movement from 3330 drives to 3380 drives and 2) optimal use of memory chips for caches.

For the first use ... the detailed traces should a variety of activities: relatively uniform activity, very low level sporadic activity, and very high level, but bursty activity (some occurring daily, some occurring weekly, and some occurring monthly ... with little or not activity inbetween bursts). It was possible in the migration from 3330 to 3380 to re-org relatively statically allocated high activity and low activity for load balancing across all 3380 drives and at the same time to order placement within 3380 to minimize arm travel (tending to allocate from middle of the disk in bands out towards the edges). The analysis also showed that to maintain the same level of service (access rate/per megabyte of data/per second) on the 3380s as on the 3330s ... only something like 3/4 of the 3380 would contain usable data (i.e. while 3380 thruput improvement increased over the 3330, the amount of data stored on 3380 increased by a larger factor than the improvement in thruput ... filling a 3380 completely full with 3330 data resulted in lower access rate per megabyte of data per second).

misc. refs:
https://www.garlic.com/~lynn/93.html#31
https://www.garlic.com/~lynn/95.html#8
https://www.garlic.com/~lynn/99.html#6

the other use of the detailed trace data was for I/O cache modeling. Various configurations of caches were modeled for head, arm, device, controller, channel, channel group, and system. Except for full track buffer for handling particular kind of rotational miss, the models alwas showed that allocation of memory chips for caching at the system level was alwas the most efficient use of the chips. This is basically the same as the local LRU vis-a-vis global LRU argument. On the average, over all sorts of activity, it is more efficient to manage the information at the highest level than at a low level fragmented level.

The exception is for arm motion plus transfer operations. When the arm is in motion, rotational positioning information was lost. It was therefor possible to arrive at the designated arm position just after the desired record had passed under the head. If there was a full track buffer that could immediately start reading the requested track as soon as the head was synchronized ... then it was potentially possible to catch most of the desired record in cache and only have to read a few dribbles on the subsequent revolution. In part, this was possible since the seek CCW specified both the cylinder and track/head in the same operation ... so the disk knew the desired track before the arm was in position and the head had synchronized for data transfer.

The problem with global LRU caches, in a multiprogramming or multitasking environment is that misbehaving operations can "run-over" the data of well behaved operations. As a result, global LRU caches need some method for fencing off ill-behaved operations. Other than that, with all other things being equal, a global LRU strategy outperforms local LRU strategies. It then follows that using memory chips for caching at a global level is more efficient than the same number of chips distributed across local devices (full track caching isn't a "use the data again" cache ... but instead mask disk rotational latency operational caracteristics).

misc. cache/lru refs:
https://www.garlic.com/~lynn/93.html#0
https://www.garlic.com/~lynn/94.html#1
https://www.garlic.com/~lynn/94.html#14
https://www.garlic.com/~lynn/94.html#20
https://www.garlic.com/~lynn/94.html#46
https://www.garlic.com/~lynn/94.html#49
https://www.garlic.com/~lynn/94.html#51
https://www.garlic.com/~lynn/94.html#54
https://www.garlic.com/~lynn/96.html#0a
https://www.garlic.com/~lynn/96.html#0b
https://www.garlic.com/~lynn/96.html#10
https://www.garlic.com/~lynn/96.html#11
https://www.garlic.com/~lynn/98.html#6
https://www.garlic.com/~lynn/99.html#18
https://www.garlic.com/~lynn/99.html#20
https://www.garlic.com/~lynn/99.html#104
https://www.garlic.com/~lynn/99.html#237

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

4341 was "Is a VAX a mainframe?"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 4341 was "Is a VAX a mainframe?"
Newsgroups: alt.folklore.computers
Date: Sat, 15 Jul 2000 17:19:25 GMT
Anne & Lynn Wheeler writes:
The other factor was that the 4341 channels were "faster" than the 303x channel directors.

a side note ... while 145, 148, 4341, etc had (inboard) integrated channels and were able to do the head-switch using 101-byte dummy "spacer" blocks ... the 168 with outboard channels was also able to do the head-switch reliably with 101-byte spacer blocks.

the 158 with its inboard integrated channels missed the head-switch 70-80% of the time because of timing issues in the 158 integrated channels and the (outboard) 303x channel directors had the same characteristic.

the 303x channel director was effectively a 158 somewhat repackaged w/o the microcode support for 370 instruction set. The 158 & a channel director supported up to six channels. To get sixteen channels on a 3033 required three channel directors (two directors configured with six channels and one director configured with four channels).

misc. other channel timing issue:
https://www.garlic.com/~lynn/2000c.html#65

in the above ref; to->no

removed from directly attachment to the real 370 channels ... the thruput of the overall mainframe system increased by approx. 10% (in addition to showing no measurable degradation in system response). It

i.e. no measurable degradation in system response.

refs to system response studies that were used to justify hyperchannel & local 3270s for the IMS group (as opposed to remote 3270s which drove response up to second).
https://www.garlic.com/~lynn/2000c.html#64
https://www.garlic.com/~lynn/2000c.html#66

i recently ran across a reference that evaluated original 3278 against 3277. a big complaint was with a dense screen rewrite of 3278 (even at 24x80) ... took one second before screen phospher persistance cleared.

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

4341 was "Is a VAX a mainframe?"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 4341 was "Is a VAX a mainframe?"
Newsgroups: alt.folklore.computers
Date: Tue, 18 Jul 2000 11:55:54 GMT
Terry Kennedy writes:
Couldn't the control unit have been modified (with a "-II" suffix or as a RPQ) to include a track buffer or two? 32KB was certainly do-able in the 370 era and would have allowed read-ahead.

there was later a 3880-11 control unit (ironwood) with 8mbytes of cache used with 3380 drives (not 3330 drives) that was specific for paging device (i.e. cached 4k byte records, later there was -13 for full-track and eventually follow-on larger caches).

the -11 violated the global LRU ... since it was partitioned (if there were multiple 3880-11 in a configuration). It also suffered from a boundary condition problem. a standard ironwood configuration was a 16mbyte mainframe with one or two 3880-11 controllers.

The normal algorithm would fault on a page and then read it into main memory from 3380 ... as it was coming in off disk a copy would be left in the 3880-11. Eventually main memory would fill up with pages. At this point there are nearly 16mbytes of virtual pages in main memory and the same 16mbytes of virtual pages in 3880-11 cache (assuming some randomness about page allocation across two controllers).

At this point the next page fault would have to replace something in main memory and read the replacement off of disk. Since there was a high probability that every page in real memory was also in the disk cache (since it had been read thru the disk cache into main computer memory) ... the converse is also true ... there was a high probabilty that every page not in real memory is also not in disk cache (because the disk cache was about the same size or smaller than main memory, used similar LRU algorithms for management ... and a copy placed in real memory was also placed in disk cache).

That was where "no-dup" came in ... for this type of configuration ... for the cache to be effective ... needed to switch from a duplicate algorithm (i.e. pages in real memory were also in cache) to a no-dup algorithm (pages in real memory were not in cache). For ironwood it was possible to use a different CCW and the read would eliminate any copy that was in cache (and/or not place a new copy in cache if it had to read from disk). In this sort of boundary condition, a "no-dup" algorithm eliminated the problem where every page in main memory had also filled up the cache ... so there was very low probability that a page not in main memory would actually be in the cache (since the cache was full off pages also in main memory).

misc. dup/no-dup refs:
https://www.garlic.com/~lynn/93.html#12
https://www.garlic.com/~lynn/93.html#13
https://www.garlic.com/~lynn/94.html#9

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

FW: RS6000 vs IBM Mainframe

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FW: RS6000 vs IBM Mainframe
Newsgroups: bit.listserv.ibm-main
Date: Sat, 22 Jul 2000 02:51:21 GMT
rhawkins@SINGNET.COM.SG (Ron & Jenny Hawkins) writes:
Bill,

You are never going to get ESCON to do 12.5MB/sec using 4KB blocks. The best rate I've ever seen on ESCON has been just shy of 15MB/sec, and there is NO WAY ESCON can go over that (too many empty frames). I have run Fibre Channel at 35MB/sec and there are Benchmarks around with Fibre Channel running at 80MB/sec.

A single DASD controller can handle a lot more than 3000 I/O a second. Hitachi and IBM both claim 32000 IO/sec for Mainframe, but Hitachi also have Benchmarks on SUN at 32000 IO/sec. Mainframe disk superiority is a bit of a strawman argument though, when I have customers running OS390, SUN, HP, DG-UX, and NT all out of the same box.

Ron


note that low level fiber channel is dual simplex ... aka capable of 100mbyte/sec simultaneously in both directions.

random refs:
https://www.garlic.com/~lynn/2000c.html#56
https://www.garlic.com/~lynn/2000c.html#68

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

APL version in IBM 5100 (Was: Resurrecting the IBM 1130)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: APL version in IBM 5100 (Was: Resurrecting the IBM 1130)
Newsgroups: alt.folklore.computers
Date: Mon, 24 Jul 2000 13:58:47 GMT
Charles Richmond writes:
It is generally agreed that the IBM 5100 (their first personal computer, except for the price) had a two-level APL interpreter. The hardware had a program to emulate another CPU (either 360 or 1130) and then the APL interpreter was laid on top of that. The question I have is: Was it the 360 or the 1130 machine that was emulated???

misc. refs:
https://www.garlic.com/~lynn/2000.html#69
https://www.garlic.com/~lynn/2000.html#70

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/

The author Ronda Hauben fights for our freedom.

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The author Ronda Hauben fights for our freedom.
Newsgroups: soc.rights.human,comp.protocols.tcp-ip.domains,comp.society.futures,k12.ed.comp.literacy,alt.folklore.computers
Date: Mon, 24 Jul 2000 14:05:06 GMT
Bernie Cosell writes:
She and I have argued at length in the past about this distortion of the history of it all. The gov't didn't "create the Internet" -- by and large the gov't paid for a LOT of research in communications and systems and protocols ALLOFWHICH is in the public domain and which the public has free access to [and indeed, is making HUGE use of]. Nothing that the [US] gov't was involved in looked ANYTHING like today's Internet.

in fact, if the gov't had its way ... we would have had something based on GOSIP ... the gov't was actually trying to force something other than the internet.

NSF did provide funding for nsfnet portion of the backbone ... but there were significant other contributors to the backbone ... larger than that provided by NSF ... and the success of the current internet was much more based on the lack of restrictions for those other portions of the backbone ... than the nsfnet portion of the backbone with its various restrictions.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

Where's all the VMers?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where's all the VMers?
Newsgroups: bit.listserv.ibm-main
Date: Thu, 27 Jul 2000 05:35:12 GMT
Frank Clarke writes:
Once upon a time, Captain Tools (Tom McSloy) and I got into it about "XEDIT v. ISPF" and we fenced for quite some time until, exhausted, we each agreed to admit that (1) within each's sphere of expertise both XEDIT and ISPF were the best there is, and

there is also the folklore about the rather large ISPF development and support group acquiring the VM Performance Tools products (with 2-3 people) and the revenue from those products being used to underwrite the overall group's activities (i.e. P&L was done for the group as a whole ... not the individual products).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

S/360 development burnout?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 development burnout?
Newsgroups: alt.folklore.computers
Date: Sat, 29 Jul 2000 10:54:33 GMT
William Lynch writes:
Hats & starched shirts were required for salesmen well past when I left IBM in 1970, as well as gathering at 8:15 to sing songs from the IBM songbook at sales school (i.e., before the regular day started at 8:30).

misc. ref:
https://www.garlic.com/~lynn/96.html#12
https://www.garlic.com/~lynn/99.html#117

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

Comrade Ronda vs. the Capitalist Netmongers

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Comrade Ronda vs. the Capitalist Netmongers
Newsgroups: alt.folklore.computers
Date: Sat, 29 Jul 2000 11:10:32 GMT
"Jack Peacock" writes:
My guess is Ronda is a frustrated Che Guevara wannabe. And just as Che ran out of people to "liberate" so Ronda is finding apathy and indifference to her rallying cry against the evils of big business.

however, note that gov. regulated had ran out of gas ... vis-a-vis the internet ... even the nsfnet structure was heavily subsidized by big business (even with the nsfnet policy & practices statements) along with the contemparary backbones w/o nsfnet funding & nsfnet policy restrictions.

i also remember doing some work in the mid-80s in conjunction with large telescope development project (today possibly the largest land-based astronomy telescopes & university related) for remote viewing. they had a very strong policy of never accepting NSF money because of the related gov. problems & restrictions that would be introduced. they had a concerted program to obtain private funding only.

misc. refs:
https://www.garlic.com/~lynn/internet.htm
https://www.garlic.com/~lynn/2000c.html#26
https://www.garlic.com/~lynn/2000c.html#27
https://www.garlic.com/~lynn/2000c.html#28
https://www.garlic.com/~lynn/2000c.html#29
https://www.garlic.com/~lynn/2000c.html#30
https://www.garlic.com/~lynn/2000c.html#31

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

S/360 development burnout?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 development burnout?
Newsgroups: alt.folklore.computers
Date: Sun, 30 Jul 2000 14:12:12 GMT
Terry Kennedy writes:
The next guy after that I only met once - a much older guy in a suit that would have been popular in the 50's/60's, patchy skin. A very strange guy (I related it here some time ago). Apparently he was one of the designers of the processor (370/138).

as i remember it

115/125, 135, 138, 4331, & 4361 were boeblingen germany machines

&

145, 148, 4341, 4381 were endicott ny machines

(although both lines of machines were manufactured in both countries)

various other pieces of either machines may have been designed in other places (I don't know).

I worked with various people in endicott on the microcode accelerators on 148 ... which was also made available on other machines.

misc. refs:
https://www.garlic.com/~lynn/94.html#21
https://www.garlic.com/~lynn/2000c.html#50
https://www.garlic.com/~lynn/2000c.html#76

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

S/360 development burnout?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 development burnout?
Newsgroups: alt.folklore.computers
Date: Tue, 01 Aug 2000 02:38:40 GMT
well pok did 165/168 ... and kingston did 155/158

then there was 3031, 3032, & 3033 (3031 & 3032 were sort of 158s & 168s with channel director) ... 3033 was sorta 168 mapped to new chip technology and then some enhancements. channel director for 303xs was 158 integrated channel w/o 370 instruction set.

then 811/308x ... was kingston (158) technology for next generation

then trout1.5/3090 ... was pok (3033) technology for next generation.

kingston technology tended to be closer to the knee of the price/performance curve.

pok technology tended to be further away from the knee of the curve going more for straight performance.

random refs:
https://www.garlic.com/~lynn/93.html#14
https://www.garlic.com/~lynn/95.html#3
https://www.garlic.com/~lynn/97.html#20
https://www.garlic.com/~lynn/98.html#34
https://www.garlic.com/~lynn/98.html#50
https://www.garlic.com/~lynn/99.html#7
https://www.garlic.com/~lynn/99.html#61
https://www.garlic.com/~lynn/99.html#74
https://www.garlic.com/~lynn/99.html#103
https://www.garlic.com/~lynn/99.html#108
https://www.garlic.com/~lynn/99.html#181
https://www.garlic.com/~lynn/99.html#187
https://www.garlic.com/~lynn/99.html#190

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

IBM promotional items?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM promotional items?
Newsgroups: alt.folklore.computers
Date: Tue, 01 Aug 2000 12:22:23 GMT
Ned Holbrook writes:
This has happened to all of my best coffee mugs, too. The last one to disappear featured the name and address of the computer store that sold me my Apple II on one side, and a large six-color Apple logo on the other. I'll be damned if I didn't just leave it in the office dishwasher overnight only to find it gone the next morning.

my brother ... a regional apple rep at the time (3-4 states) ... would see "non-apple" mugs from other vendors at customer shops and fawn over them ... telling the customer how great the cup was and would they possibly part with the cup in trade for an apple mug. it worked a large percentage of the time.

i've had some really great mugs disappear off my desk at work ... and not to be found anywhere in the building. it got so i stopped bringing really good mugs to work.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

S/360 development burnout?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 development burnout?
Newsgroups: alt.folklore.computers
Date: Thu, 03 Aug 2000 03:51:03 GMT
jata@aepiax.net (Julian Thomas) writes:
Not true. Both happened in Poughkeepsie. (I know - I was part of the 155 project).

sorry, my incomplete memory ... although i seem to remember when we were working on 16way using 158 processors ... i thot the 158 engineers we were working with were in kingston (although there was one or two former 165/168 engineers that were pok). this would have been '76 or so.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

Superduper computers--why RISC not 390?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Superduper computers--why RISC not 390?
Newsgroups: alt.folklore.computers
Date: Fri, 04 Aug 2000 12:33:13 GMT
In article <8maju6$85l@netaxs.com>, lwin wrote:
I understand IBM's superduper computers use RS/6000 architecture. Why was that preferred over the S/390 architecture?

misc. refs:
https://www.garlic.com/~lynn/99.html#136a
https://www.garlic.com/~lynn/2000c.html#6
https://www.garlic.com/~lynn/2000c.html#21
https://www.garlic.com/~lynn/2000c.html#22
https://www.garlic.com/~lynn/2000c.html#56
https://www.garlic.com/~lynn/2000d.html#2
https://www.garlic.com/~lynn/2000d.html#3

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/

Superduper computers--why RISC not 390?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Superduper computers--why RISC not 390?
Newsgroups: alt.folklore.computers
Date: Sat, 05 Aug 2000 16:38:39 GMT
jmfbahciv writes:
It may be a scarey thought, but you have no concept of how these sources get lost. If really very easy to lose sources of software that isn't under continuous change no matter how many backup schemes are put into place.

misc. ref:
https://www.garlic.com/~lynn/2000.html#43

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

Superduper computers--why RISC not 390?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Superduper computers--why RISC not 390?
Newsgroups: alt.folklore.computers
Date: Sat, 05 Aug 2000 19:01:45 GMT
glass2 writes:
I've known several groups who have kept back level versions of operating systems around, just so they could rebuild their code.

the group that used VM/370 Release 6 for the basis of the mainframe service processor (i.e. put a mini-mainframe inside the mainframe. the mini-mainframe acts as the service processor for the mainframe and runs a modified version of a mainframe operating system). they made a concerted effort to gather all pieces of the infrastructure so that they could continue to build & enhance service processors on that base ... possibly long after VM/370 release 6 and its associated components were readily available.

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

Superduper computers--why RISC not 390?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Superduper computers--why RISC not 390?
Newsgroups: alt.folklore.computers
Date: Sat, 05 Aug 2000 19:05:57 GMT
eugene@cse.ucsc.edu (Eugene Miya) writes:
(before Almaden) and hearing Greg give a presentation on the IBM RP3 which was unusual because it was open (and I remember the DEC guys were in the audience). This was about 1986.

shortly after that ... my wife was asked to do a technical audit of the RP3 project with regard to continuing to fund the effort.

the decision was made to not to provide the funding.

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

RS/6000 vs. System/390 architecture?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RS/6000 vs. System/390 architecture?
Newsgroups: comp.sys.super,comp.arch
Date: Sun, 06 Aug 2000 17:54:03 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
My point was that there is a belief (amounting almost to a dogma) in some quarters that there should be a single instruction architecture, with hardware on one side and fiendishly complex compilers on the other. This does not strike me as necessarily correct, and none of the arguments thrown at me for its merit held water.

the way i remember the activity in the '70s was that the RISC activity was attempting to build reduced cost computing devices and that various hardware/software trade-offs could be made in achieving that reduction in cost ... part of that was reducing the circuit count in order to achieve single (or reduced number) chip implementation. Some of the phases this has gone thru (depending on state-of-the-art) is very reduced instruction sets and instructions that execute in a single cycle.

some of the trade-offs were enhanced smarts in compiler and binder (some belief that there had been technology advances that would support such trade-offs). early 801 targets even had single protection domain and that compile and bind/load could perform various verification checks to assure integrity w/o requiring runtime protection (one specially was inline application software could directly swap address-space access registers as easily as it could change address registers ... thus compensating for small number of virtual address space objects ... all of this w/o incurring the overhead of kernel calls to maintain permissions).

RISC still seems to have objective of optimizing priace/performance including use of hardware/software trade-offs ... although advances in circuits per chip have shifted where some of those trade-offs are made.

random refs:
https://www.garlic.com/~lynn/2000.html#16
https://www.garlic.com/~lynn/2000.html#59
https://www.garlic.com/~lynn/2000b.html#54
https://www.garlic.com/~lynn/2000c.html#3
https://www.garlic.com/~lynn/2000c.html#4
https://www.garlic.com/~lynn/2000c.html#6
https://www.garlic.com/~lynn/2000c.html#9
https://www.garlic.com/~lynn/2000d.html#24

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Secure Operating Systems

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure Operating Systems
Newsgroups: sci.crypt
Date: Sun, 06 Aug 2000 18:02:03 GMT
macckone@aol.comnjunk123 (Mack) writes:
The higher the level, the less 'User Friendly' the system becomes.

Example:

Certain systems will forbid printing without supervisory approval. Good for security, bad for your typical home user.

Certain other systems allow remote users to use printers without even a login. Bad for security, very convienent for users.


some of this has had to do with where the security perimeter and policies are established. in some cases the computers lay totally within a security perimeter. once thru a physical security perimeter, those computers could be more user friendly since the policies are established via other techniques.

in other situations the security perimeter and policies are supposed to be implemented and maintained by the computer, its operating system and applications.

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Secure Operating Systems

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure Operating Systems
Newsgroups: sci.crypt
Date: Mon, 07 Aug 2000 02:20:35 GMT
Eric Lee Green writes:
between hitting the ENTER key and something happening). By comparison, IBM mainframes of the same generation in the same price range (around $6M in 1975 dollars, when that was real money) would support several hundred users with reasonable response times.

same bldg. as multics originated ... 545 tech. sq. ... IBM CSC developed CP/67 and vm/370 (as well as the internal network, GML ... precursor to SGML, HTML, early work in capacity planning and performance modeling, misc other things). In '71-'72 time-frame IBM CSC ran nearly 80 users with mix-mode workload (batch, compiles, interactive, etc) having 90th percentile interactive response under second ... on a single processor 360/67 ... i.e. about the same generation machine as GE used by multics for original development. To some extent multics and the cp/67 shared a common heritage to CTSS.

Note however, IBM also developed TSS/360 for the 360/67 and early versions had about the same response characteristics for four users as you mentioned for early multics with eight users.

vm/370 on 370/168 in the mid-70s would typically support several hundred users.

vm/370s implementation of isolation resulted in it be used in a large number of high security installations.

random refs:
https://www.garlic.com/~lynn/2000.html#1
https://www.garlic.com/~lynn/2000.html#81
https://www.garlic.com/~lynn/2000b.html#77
https://www.garlic.com/~lynn/2000c.html#27
https://www.garlic.com/~lynn/2000c.html#30

multics home page
http://www.multicians.org/

see site histories section in the above

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

RS/6000 vs. System/390 architecture?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RS/6000 vs. System/390 architecture?
Newsgroups: comp.sys.super,comp.arch
Date: Mon, 07 Aug 2000 15:27:24 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
>the way i remember the activity in the '70s was that the RISC activity >was attempting to build reduced cost computing devices and that >various hardware/software trade-offs could be made in achieving that >reduction in cost ... part of that was reducing the circuit count in >order to achieve single (or reduced number) chip implementation. Some >of the phases this has gone thru (depending on state-of-the-art) is >very reduced instruction sets and instructions that execute in a >single cycle.

No, no, no! Definitely the objectives of the RISC development, and it was clearly (a) well worth investigating and (b) successful. No argument there.


I'm not sure what the no, no, no, refers to. Possibly you were dealing with different people in the RISC community than I was??

I argued in the '70s about the protection domain trade-off and the small number of virtual address objects. The reply was a combination of compiler, loader/binder, and new "closed" operating system targeted for small single task/user environments. The ancilliary discussion about reduced instruction count/complexity to fit in small silicon foot-print.

In the late '80s the discussion revolved around not supporting cache consistency for multiple processor applications and simple single cycle instructions ... which would also somewhat simplify the job of the compiler in achieving hardware/software trade-offs. Even tho we had done a lot of SMP work ... the lack of availability of cache consistency was one of the things that forced my wife and I into doing cluster-based work with the chips (as opposed to variouus SMP things).

The 801 people seemed to feel very strongly about it at the time ... at least in the discussions i participated in.

misc. refs:
https://www.garlic.com/~lynn/95.html#5
https://www.garlic.com/~lynn/2000c.html#4
https://www.garlic.com/~lynn/2000c.html#21

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

S/360 development burnout?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 development burnout?
Newsgroups: alt.folklore.computers
Date: Mon, 07 Aug 2000 16:03:36 GMT
Anne & Lynn Wheeler writes:
jata@aepiax.net (Julian Thomas) writes: > Not true. Both happened in Poughkeepsie. (I know - I was part of the 155 > project).

sorry, my incomplete memory ... although i seem to remember when we were working on 16way using 158 processors ... i thot the 158 engineers we were working with were in kingston (although there was one or two former 165/168 engineers that were pok). this would have been '76 or so.


doing a little refreshing. kingston would have still been scd/cpd at that time ... before they moved to raleigh. after they moved to raleigh (mid-70s?) some amount of POK, i believe overflowed into Kingston(?).

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Adventure Games (Was: Navy orders supercomputer)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Adventure Games (Was: Navy orders supercomputer)
Newsgroups: alt.folklore.computers
Date: Wed, 09 Aug 2000 14:44:22 GMT
Charles Richmond writes:
Actually, IIRC the Micro$oft version of Adventure was the same as the 350 point original Adventure, except Micro$oft added one room that had something M$ specific in it. I do not remember what the room was about, but I have seen it discussed in the Colossal Cave Adventure Forum of off the Colossal Cave Adventure Page at:

original adventure i remember getting was 300

misc. ref:
https://www.garlic.com/~lynn/99.html#52
https://www.garlic.com/~lynn/99.html#83
https://www.garlic.com/~lynn/99.html#84
https://www.garlic.com/~lynn/99.html#169

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/

Assembly language formatting on IBM systems

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Assembly language formatting on IBM systems
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Wed, 09 Aug 2000 15:00:10 GMT
my sophomore year at wsu ... i got hired to write a 360 version of a 1401 "MPIO" that did the front-end tape<->reader/punch/printer for 709.

it was eventually 2000 cards ... maybe 1600 assembler statements. it took 30 minutes to assemble on 64kbyte 360m30 under ospcp6 ... using my own monitor, interrupt handler, input/output supervisor, storage allocation, etc.

version down with os supervisor services (dcb macros, get/put, etc) took over an hour to assemble. in the supervisor services version ... there were five DCB macros ... and you could tell by the flashing lite pattern when the assembler hit a DCB macro ... which took six minutes elapsed time per DCB macro (56 - 30 minutes just for five dcb macros).

somebody told me later that the person doing the mnemonic lookup (assembler code to instruction) had been given a spec that said they only had 256bytes to implement the lookup. Since the mnemonic codes & the code wouldn't fit in 256bytes ... the table went out on disk ... and every mnemonic decode required disk accesses.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/

S/360 development burnout?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 development burnout?
Newsgroups: alt.folklore.computers
Date: Wed, 09 Aug 2000 15:03:55 GMT
jata@aepiax.net (Julian Thomas) writes:
Very true - but that was later than the 155-158 timeframes, and it was the larger systems stuff (16x and above) that went up the river.

i remember going bike riding with the trout1.5 cpu engineers (on thursdays?) when i happened to be in town. they were all in POK and worked in POK.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

Assembly language formatting on IBM systems

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Assembly language formatting on IBM systems
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Thu, 10 Aug 2000 14:08:32 GMT
jcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
ASMG also put 5-digit line numbers in the output listing where ASMF ffered only four digits; apparently the ASMF designers never considered the possibility of a source file longer than 9999 cards. HASP easily passed that limit since it its earlier releases the entire product was a single assembly module.

Joe Morris


in the early '70s i had developed a PLI program that analyzed an assembler listing. it couldn't catch things like branch tables or arbritrary register branching ... but it attempted to reconstruct the logic flow of the program ... and then within each code block determine register use & modification. It identified potential dead-code and also register value dependencies in path flow thru the program. It then attempted to reconstruct the machine language into a PLI-like psuedo code ... using if/then/else/do-until/etc structures.

the thing it didn't do well was handle csect/dsect information. I found later when working on a detailed analysis of TSS code structure vis-a-vis VM/370 code structure ... that one of the things the TSS assembler spit-out was the csect/dsect number for each storage reference (i.e. start of listing somewhere had the csect & dsect names mapped to an "ID" ... and each displacement field on the left-side of the listing had the csect/dsect ID prefixing the storage displacement. For dsects ... it allowed generation of variable names with structure qualifiers in an unambiguous manner.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/

S/360 development burnout?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 development burnout?
Newsgroups: alt.folklore.computers
Date: Fri, 11 Aug 2000 15:39:31 GMT
Eric Fischer writes:
publication, and then co-wrote the first-generation "EPL" Multics PL/I compiler. The details are, I think, in both Jean Sammet's _Programming Languages: History and Fundamentals_ book and in the proceedings of the second ACM History of Programming Languages Conference, but I don't have either of those at hand. I can look

... off topic

random piece of info ... jean worked at ibm boston programming center (also in 545 tech sq, with cambridge science center, multics etc). BPC produced an online pli-based interactive product that ran under os/360 (somewhat akin to the original apl/360 ... but pli instead of apl). BPC was eventually shutdown and some number of the people attached/housed with CSC.

I would sometimes bring my kids in when i stopped by work on weekends ... frequently jean was the only other person at the offices on the weekend ... and she would come looking for me to complain about the kids because they were yelling & laughing chasing each other up & down the halls

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

S/360 development burnout?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 development burnout?
Newsgroups: alt.folklore.computers
Date: Sat, 12 Aug 2000 22:38:11 GMT
jata@aepiax.net (Julian Thomas) writes:
Henry Brandt - and who else?

brain check at the moment ... who was the guy that had the pencils that said: elect ... lab director, raises or promotions, but not both.

henry went on to kingston to work on hippi tied into the page store bus.
Were those the days when Andy Heller periodically blew into town?

possibly ... but it was before I spent much of any time with andy.

it was period around some kind of memos ... i think starting with a T?

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

Future hacks [was Re: RS/6000 ]

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Future hacks [was Re: RS/6000 ]
Newsgroups: comp.arch
Date: Mon, 14 Aug 2000 15:02:01 GMT
Ketil Z Malde writes:
Well, if you've seen "War Games", then you know how dangerous computers can be, even the chess playing ones...

extraneous bits of info ..... in war games ... the ferry scenes were actually the steilicom (puget sound mainland between tacoma and olympia) and anderson island (with a different name covering up the real ferry name). that ferry is now refurbished and is now a tourist boat on lake washington that runs out of kirkland.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

360 CPU meters (was Re: Early IBM-PC sales proj..

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 CPU meters (was Re: Early IBM-PC sales proj..
Newsgroups: alt.folklore.computers,comp.sys.ibm.pc.hardware.systems
Date: Mon, 21 Aug 2000 17:55:35 GMT
jata@aepiax.net (Julian Thomas) writes:
360 mod 50 engineers decided that the way to determine "doing anything" was to monitor main memory usage. This all worked fine in the lab until one fine day someone enabled the location 80 timer and someone else noticed that the meter never stopped running.

slightly related to both the 360 cpu meter as well as the (a.f.c) time-sharing charging (thread)
https://www.garlic.com/~lynn/2000b.html#77

getting the cpu meter to stop running when nobody was using the system ... but the system was still available for use was important part of being able to offer 24x7 time-sharing services.

also, i noticed that there was some software versions that put in timer-interrupts to wake-up at regular sub-second intervals ... approx. what the meter coasting interval was
https://www.garlic.com/~lynn/99.html#86

when we were doing the first 360 plug-compatible control unit ... we ran into a problem with the location 80 timer (on the '67) when we held the cpu bus for too long a period
https://www.garlic.com/~lynn/93.html#16
https://www.garlic.com/~lynn/96.html#30

random refs:
https://www.garlic.com/~lynn/93.html#31
https://www.garlic.com/~lynn/94.html#15
https://www.garlic.com/~lynn/97.html#7
https://www.garlic.com/~lynn/99.html#76
https://www.garlic.com/~lynn/99.html#195
https://www.garlic.com/~lynn/2000.html#81
https://www.garlic.com/~lynn/2000b.html#61
https://www.garlic.com/~lynn/2000c.html#48

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

TCP/IP Suite of Protocols - dumb question ...

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TCP/IP Suite of Protocols - dumb question ...
Newsgroups: comp.protocols.tcp-ip
Date: Mon, 21 Aug 2000 18:52:29 GMT
gibboncore writes:
Am I correct in understanding that the TCP/IP protocols are a series of source codes (to perform different internet functions), not a programme, and that any person could use this to write their own comms programme (as long as it complied to the protocol). I know roughly what TCP/IP is meant to do, but what puzzles me is how ... I know that it comes embedded in many other programmes and operating systems and that in particular it's inclusion in early versions of Unix lead to it being adopted as a defacto standard. Any explanations graciously received

Micky Mc


in large part TCP/IP protocols define a set of message or bit formats and some specific associated services that are suppose to operate on those messages. there is no explicit requirement as to how those messages get generated or processed (kernel services, application programs, user software, etc).

random references:
https://www.garlic.com/~lynn/internet.htm
https://www.garlic.com/~lynn/rfcietff.htm
https://www.garlic.com/~lynn/2000b.html#0
https://www.garlic.com/~lynn/2000b.html#1
https://www.garlic.com/~lynn/2000b.html#6
https://www.garlic.com/~lynn/2000b.html#9
https://www.garlic.com/~lynn/2000c.html#26
https://www.garlic.com/~lynn/2000c.html#27
https://www.garlic.com/~lynn/2000d.html#16

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

360 CPU meters (was Re: Early IBM-PC sales proj..

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360 CPU meters (was Re: Early IBM-PC sales proj..
Newsgroups: alt.folklore.computers,comp.sys.ibm.pc.hardware.systems
Date: Mon, 21 Aug 2000 19:31:48 GMT
mostly offtopic, very slightly related ... mailing list discussion related to redefining UTC (specifically with respect to leap seconds):
http://clockdev.usno.navy.mil/archives/leapsecs.html
https://web.archive.org/web/20010206165928/http://clockdev.usno.navy.mil/archives/leapsecs.html

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Al Gore: Inventing the Internet...

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Al Gore: Inventing the Internet...
Newsgroups: alt.folklore.military
Date: 21 Aug 2000 16:19:05 -0700
juergen.nieveler@web.de (Juergen Nieveler) writes:
>I always thought it was Darpanet

That was before ARPA changed it's name to DARPA... a long time ago.

>Respec' to ya Juergen :)

Let's raise our glasses to the tribute of Jon Postel, father of the RfCs.


didn't the agency go thru a couple cycles of darpa->arpa->darpa, etc. (but as far as i know, it was alwas arpanet).

US gov. (presumably all agencies) was pushing/specifying GOSIP in the late 80s & early 90s, i.e. specifically not internet and specifically not tcp/ip; in fact, to some extent the internet triumphed despite specific government dictates specifying non-internet & non-tcpip. misc. ("gosip", which was/is not! internet & not! tcp/ip) refs:
https://www.garlic.com/~lynn/2000b.html#0
https://www.garlic.com/~lynn/2000b.html#1
https://www.garlic.com/~lynn/2000b.html#4
https://www.garlic.com/~lynn/2000b.html#5
https://www.garlic.com/~lynn/2000b.html#10
https://www.garlic.com/~lynn/2000d.html#19

misc. Postel reference
http://wwwvms.utexas.edu/~glen/postel/
https://web.archive.org/web/20020202134046/http://wwwvms.utexas.edu/~glen/postel/

some discussions on arpanet, nsfnet, internet, etc:
https://www.garlic.com/~lynn/internet.htm

references on the internal network being larger than the arpa/nsf/inter up until the mid-80s
https://www.garlic.com/~lynn/2000c.html#29

random other refs:
https://www.garlic.com/~lynn/99.html#33
https://www.garlic.com/~lynn/99.html#39
https://www.garlic.com/~lynn/99.html#112
https://www.garlic.com/~lynn/2000c.html#30
https://www.garlic.com/~lynn/2000c.html#31

discussion of some of the networking activities going on about same time as nsfnet & early "internet"
https://www.garlic.com/~lynn/2000c.html#26

other misc. refs:
https://www.garlic.com/~lynn/rfcietff.htm

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

Charging for time-share CPU time

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Charging for time-share CPU time
Newsgroups: alt.folklore.computers
Date: Tue, 22 Aug 2000 13:47:27 GMT
Lars Poulsen writes:
Even on OS/360, the normal procedure was to specify the time limit on the job card; then OS would kill the job with ABEND S222 when it hit the limit. However, I seem to remember that OS had trouble completing even a trivial FORTGCLG macro in less than 15 seconds (on a 360/65).

a standard fortgclg of dummy return/end was more like 30 seconds elapsed time ... almost all of it job scheduler (just reading & processing the jcl).

following reference
https://www.garlic.com/~lynn/94.html#18

I had built an MFT (w/hasp) that got it down from about 30 seconds to 12.9 seconds elapsed time.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/

Charging for time-share CPU time

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Charging for time-share CPU time
Newsgroups: alt.folklore.computers
Date: Tue, 22 Aug 2000 13:58:10 GMT
Lars Poulsen writes:
compete with the other academic computer center (IBM OS/360-HASP based) where they had WATFIV FORTRAN jobs that bypassed the accounting system.

big win with WATFOR/WATFIV was that it did its own job scheduling ... typically watfor/watfiv was loaded as a single job step (5-15 seconds elapsed) and then it would batch process a tray of student jobs (2000-3000 cards at 50-100 cards per). Typical sutdent job would take small fractions of second ... so total elapsed run time might be 30 seconds.

Before watfor & hasp, it would be on the order of minute elapsed time per student job. watfor/watfiv w/hasp system could avg. under a second elapsed time per student job ... even including the job schedule up front time ... something like a 100 improvement in thruput

misc. refs:
https://www.garlic.com/~lynn/99.html#93

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

Charging for time-share CPU time

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Charging for time-share CPU time
Newsgroups: alt.folklore.computers
Date: Wed, 23 Aug 2000 17:36:03 GMT
jcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
One nice hack that surfaced midway through the life of OS/360 was Addison Fischer's "Executor" that he wrote at West Virginia University. This was a hack of the job scheduler code that supported the majority of the job scheduling functions that student jobs would need, keeping the major job step and allocation management code in memory. This allowed compliant jobs with normal JCL to run with essentially zero wall clock time spent in the job scheduler.

we had an ibm advisery SE doing something similar. One weekend (they typically let me have the machine room from 8am sat. to 8am monday ... & I will pull the full 48hr shift ... before getting ready for 10am class) ... i copied his card deck (it was stored in a card cabinet in the machine room) and started "fixing" it. Sometime the next week ... I told him all the stuff I was fixing in his program .. which caused a nuumber of people to get really upset.

when we got watfor ... the project was dropped.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

Charging for time-share CPU time

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Charging for time-share CPU time
Newsgroups: alt.folklore.computers
Date: Mon, 28 Aug 2000 02:59:28 GMT
rea@bofh.org.uk (Robert Allison) writes:
[1] As I remember it, he did some traffic analysis through GETMAIN and found that some large fraction of all requests was for some relatively small amount of memory (the size of an RB?). So he got a chunk of memory at IPL time, chopped it up into fixed sized pieces that would fit the most common requests, then handled those requests from there.

Lincoln Labs ... had a "search list" instruction RPQ on their 360/67. It was used to speed up searching the CP/67 free storage pool for matching storage request. The problem was that even in "hardware" there was still at least one storage fetch for each block in the chain (and there easily could be several hundred blocks on the join on loaded system).

Early CP/67 kernel had a number of areas that consumed excess CPU utilization. As these areas were addressed, free storage management became a major remaining factor ... frequently accounting for 20% of kernel pathlenght.

Release 3 of CP/67 introduced "subpool" storage management logic. Detailed traces of the system was made and subpool logic created pools for the most common sizes (in some cases ... similar storage sizes were rounded up to the closest defined subpool size). Subpool block sizes were managed LIFO (push/pop). On allocation, a block would be allocated from the top of the list for the corresponding storage size. On de-allocation a block would be placed on the head of the list for the corresponding storage size. If block of the corresponding size wasn't on the subpool list, a block would be allocated from the standard structure.

The subpool structure started out empty ... but as blocks of stroage (of the appropriate size) were returned and made available, they would be placed in the appropriate subpool list. This required that all allocation requests (in the subpool size ranges) were rounded up to the next subpool size (in order that generally allocated blocks could be returned to subpools). There was also a cleaning/reset process that took all available blocks from all subpools and merged them back into the standard storage allocation infrastructure.

Subpool allocation could be done in 12-14 instructions and in typical system would be used for 90-95% of storage allocation requests. This reduced the storage allocation/deallocation on typical systems from 20% of kernel cpu utilization to about 2% of kernel cpu utilization.

The subpool introduction in CP/67 Release 3 negated much of the purpose of the SLT RPQ instruction ... since there was little use of extensive searching in the system.

There was a later enhancement to the subpool logic for the two-processor 3081 ... so that storage was allocated on cache lines and in cache line increments. This represented a measurable reduction in inter-cache chatter (and corresponding improvement in performance).

random refs:
https://www.garlic.com/~lynn/93.html#0
https://www.garlic.com/~lynn/93.html#4
https://www.garlic.com/~lynn/93.html#26
https://www.garlic.com/~lynn/94.html#1
https://www.garlic.com/~lynn/94.html#2
https://www.garlic.com/~lynn/94.html#4
https://www.garlic.com/~lynn/94.html#7
https://www.garlic.com/~lynn/98.html#19
http://www.leeandmelindavarian.com/Melinda#VMHist

&

Analysis of Free-storage Algorithms, B. Margolin, IBM Systems Journal 10, 283-304, 1971

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Navy orders supercomputer

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Navy orders supercomputer
Newsgroups: alt.folklore.computers
Date: Mon, 28 Aug 2000 04:08:30 GMT
"Charlie Gibbs" writes:
For me, realizing that a compiler was just another program was one of those epiphanies where one discovers that one's gods have feet of clay. I put the nails in the coffin of that belief when I started writing my own system utilities, and the gods truly became mortal when my utilities started outperforming the ones that came with the system.

i realized early on that there was graduation of system ... as well as the stand alone "sysgen" was actually a fancy application program that I redid to run in the standard jobstream. Normally i would get the machine room all week-end (from 8am sat to 8am mon). However when there was a new OS/360 release ... the ibm'ers would get a couple shifts of dedicated machine time (over the weekend) to do a new system build/generation ... & I would have to work around them.

One time this happened ... they had taken a "break" for dinner because something had gone wrong. While they were gone ... I did a card copy of all their stuff and started analyzing it to figure out 1) why they would need stand-alone time ... and 2) what was making things go wrong.

I figured out a way that I could do most of the system build/generation procedure with current production system ... splitting it into multiple job steps ... so that if something went wrong ... rather than restarting one 8-10 hr job ... only needed to restart a 10-20 minute job. Also figured out how to re-organize the system build process to optimize placement of datasets and members to improve system thruput.

random refs:
https://www.garlic.com/~lynn/94.html#18
https://www.garlic.com/~lynn/94.html#53

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

Navy orders supercomputer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Navy orders supercomputer
Newsgroups: alt.folklore.computers
Date: Mon, 28 Aug 2000 04:33:39 GMT
minor addition ref regarding separation of system & application
https://www.garlic.com/~lynn/2000.html#63

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Navy orders supercomputer

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Navy orders supercomputer
Newsgroups: alt.folklore.computers
Date: Mon, 28 Aug 2000 14:28:55 GMT
jmfbahciv writes:
<chuckle> That was one of my full time jobs :-). Did you offer your solution? If you did, how did they take it. That was one of my most difficult tasks. Getting the solutions implemented.

The IBMers had been doing SYSGEN fo OS/360 release 9.5, by OS/360 release 11, university turned the responsibility over to me ... from from presentation I made at fall '68 share in Atlantic City (also posted here a couple years ago):
https://www.garlic.com/~lynn/94.html#18

I had started doing hand-built "in-queue" SYSGENs starting with MFT11. I would manually break all the stage2 SYSGEN steps into individual components, provide "JOB" cards for each step and then effectively run the "stand-alone" stage2 SYSGEN in the standard, production job-queue.

I would also carefully reorder the steps/jobs in stage2 (as well as reordering MOVE/COPY statements for PDS member order/placement) so as to appropriately place data on disk for optimal disk arm-seek performance.

In the following report, the "bare-machine" times of 12.9 sec/job was typically over 30 seconds/job for a MFT14 built using standard "stand-alone" SYSGEN process (effectively increase in arm-seek elapsed time). Also, the standard OS "fix/maintenance" process involved replacing PDS-members which resulted in destroying careful member placement. Even with an optimally built system, "six months" of OS maintenance would resort in performance degrading to over 20 secs/job.


--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

Navy orders supercomputer

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Navy orders supercomputer
Newsgroups: alt.folklore.computers
Date: Mon, 28 Aug 2000 14:52:57 GMT
Anne & Lynn Wheeler writes:
The IBMers had been doing SYSGEN fo OS/360 release 9.5, by OS/360 release 11, university turned the responsibility over to me ... from from presentation I made at fall '68 share in Atlantic City (also posted here a couple years ago):

https://www.garlic.com/~lynn/94.html#18


while very little of the OS/360 work was adopted by ibm for inclusion in the standard product ... nearly all of the cp/67 work described in the above reference was eventually adopted for ibm distributed product (in part because i eventually graduated and went to work at ibm csc in cambridge).

random references:
https://www.garlic.com/~lynn/93.html#0
https://www.garlic.com/~lynn/93.html#1
https://www.garlic.com/~lynn/93.html#2
https://www.garlic.com/~lynn/93.html#4
https://www.garlic.com/~lynn/93.html#5
https://www.garlic.com/~lynn/93.html#28
https://www.garlic.com/~lynn/93.html#29
https://www.garlic.com/~lynn/94.html#01
https://www.garlic.com/~lynn/94.html#0
https://www.garlic.com/~lynn/94.html#1
https://www.garlic.com/~lynn/94.html#2
https://www.garlic.com/~lynn/94.html#4
https://www.garlic.com/~lynn/94.html#5
https://www.garlic.com/~lynn/94.html#7
https://www.garlic.com/~lynn/94.html#9
https://www.garlic.com/~lynn/94.html#14
https://www.garlic.com/~lynn/94.html#15
https://www.garlic.com/~lynn/94.html#21
https://www.garlic.com/~lynn/94.html#22

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

IBM 650 (was: Re: IBM--old computer manuals)

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 650 (was: Re: IBM--old computer manuals)
Newsgroups: alt.folklore.computers
Date: 30 Aug 2000 16:26:35 -0600
ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
At the start of the 70's the 2305 was much cheaper than core. I recall that a pair of those beasts were attached to the 360-85 2 Mb machine in a dedicated mode for a huge linear programming run (MPS ? MPSX ?) for swap storage before the days of MVS. Can't recall if they were head per track, but they were swifter than 2314s or even 3330s with RPS.

head per track on 2305 ... misc. ref:
https://www.garlic.com/~lynn/95.html#8

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

IBM 650 (was: Re: IBM--old computer manuals)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 650 (was: Re: IBM--old computer manuals)
Newsgroups: alt.folklore.computers
Date: 30 Aug 2000 16:53:45 -0600
jsaum@world.std.com (Jim Saum) writes:
RPS doesn't increase the transfer rate of disks, it just makes it possible for a drive to disconnect from the channel until it rotates to a certain point. The effect is to get more throughput out of a lot of drives on one channel, not increase the performance of any one drive.

2305 had eight different logical I/O addresses that could be used by the mainframe for i/o initiation.

normally there was a one-to-one mapping between a physical device and a i/o address.

Doing one i/o operation at a time (even on a 2305) ... between the end of one operation and the time the CPU started the next operation ... you tended to loose a half revolution. A 2305 setup for 4k pages would have three 4k pages per track where the starting position of each page/record was at the same rotational position on each track.

With RPS and (2305) multiple exposures .... it was possible to schedule requests such that the page transfer thruput of the 2305 was near media transfer speed (300 pages/sec) instead of 130 page transfer per second (because of lost rotational delay).

I had a battle to try and get multiple exposure support for the 3350 fixed-heads ... which would have allowed the 3350 to do data transfer from a fixed head track overlapped with disk arm motion (i.e. with only a single address per physical 3350 device ... it wasn't possible to initiate a new operation until the previous had finished ... and if the device was in the process of moving the arm, it wouldn't be possible to start a fixed head data transfer until the arm motion had completed).

The feature was billed as enhanced paging support ... however there was a competing project (called Vulcan) to deploy an electronic drum paging device. The Vulcan project managed to get the multiple exposuure support for 3350 killed. Along the way, there was a huge upsurge in the orders for processor memory ... so much so that it totally saturated the memory chip producing fabs' capacity ... which totally dried up availability of memory components for a vulcan product (at which point the vulcan project was disbanded but it was too late to revive 3350 multiple exposuure support)

misc. refs:
https://www.garlic.com/~lynn/99.html#8
https://www.garlic.com/~lynn/95.html#8

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

NCP Help (re (D)ARPANET)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: NCP Help (re (D)ARPANET)
Newsgroups: comp.protocols.tcp-ip
Date: 30 Aug 2000 17:09:12 -0600
Art Berggreen writes:
NCP was "layered", but the layers had different functions than what we are familiar with in TCP/IP. Also, be aware that the DARPA research also predates the ISO Open Systems Interconnect (AKA 7-layer) model for networking. In NCP/ARPANet, reliability was provided for in the network and the hosts just assumed and used that service. The NCP model is similar to that used by X.25 (which was really inspired by the ARPANet) in which an intelligent network provides a "reliable" service used by the client hosts. The physical interface between a host and an IMP was also defined by 1822. NCP used the physical interface to exchange Host-to-IMP protocol packets with the IMP (and indirectly with other hosts).

discussion on some of this from earlier this year:
https://www.garlic.com/~lynn/internet.htm#26
https://www.garlic.com/~lynn/internet.htm#27
https://www.garlic.com/~lynn/internet.htm#28
https://www.garlic.com/~lynn/internet.htm#29
https://www.garlic.com/~lynn/internet.htm#31

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

NCP v TCP/IP

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: NCP   v  TCP/IP
Newsgroups: comp.protocols.tcp-ip
Date: 30 Aug 2000 17:12:15 -0600
from discussion on NCP v TCP/IP earlier this year:
https://www.garlic.com/~lynn/2000.html#67
https://www.garlic.com/~lynn/2000.html#72
https://www.garlic.com/~lynn/2000.html#73
https://www.garlic.com/~lynn/2000.html#74
https://www.garlic.com/~lynn/2000.html#85

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

Is Al Gore The Father of the Internet?

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,alt.os.linux
Date: 04 Sep 2000 10:22:07 -0600
Lars Poulsen writes:
The transition from that "infrastructure for research and education" to ONE GLOBAL INTERNET is almost entirely Gore's doing. Yes, the researchers called their network "the Internet" and yes, in some sense it is the same network, but the difference is still astounding to those of us who lived through it and helped to push.

there were a large number of other backbones at the time of NSFNET backbone that didn't have the restrictions of the NSFNET backbone

misc. refs:
https://www.garlic.com/~lynn/internet.htm#7
https://www.garlic.com/~lynn/2000c.html#26
https://www.garlic.com/~lynn/2000d.html#43

EARN was the major educational & R&D network outside of the US at the time of NSFNET1 ... and as far as I know was all corporate funded.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

iAPX-432 (was: 36 to 32 bit transition

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: iAPX-432 (was: 36 to 32 bit transition
Newsgroups: alt.folklore.computers,comp.arch
Date: 04 Sep 2000 15:34:10 -0600
if i remember right from a intel presentation at sigops (before it starting moving around and was at asilomar) ... one of the hardest problems they had was with the 432 having so much function in hardware ... finding bugs wasn't so bad ... but testing fixes was a real hard problem.

Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:
Seriously, though, there's no reason why debugging the OS for a capability machine is any harder than for a conventional machine. You're looking at it the wrong way around. Rather than viewing it as having a single wall between system and user code, view it as having such walls at every interface between domains.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

Is Al Gore The Father of the Internet?

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,alt.os.linux
Date: 04 Sep 2000 15:52:24 -0600
Floyd Davidson writes:
He was basically responsible for introducing key legislation and guiding Internet projects through the US Congress. He did that at a time when most Congress critters had no idea what the significance was. He did that at a time when virtually the entire telecommunications industry had no idea what the Internet was. Well actually, he did that at a time when hardly anyone had any idea what it was! (Al Gore's legislation is what changed the ARPANET to the NFSnet and caused it to become known as The Internet too.)

extract from email note dated 10/82

CSNET (Computer Science NETwork) is funded by NSF, and is an attempt to connect all computer science research institutions in the U.S. It does not have a physical network of its own, but rather is a set of common protocols used on top of the ARPANET (Department of Defense), TeleNet (GTE), and PhoneNet (the regular phone system). The lowest-cost entry is through PhoneNet, which only requires the addition of a modem to an existing computer system. PhoneNet offers only message transfer (off-line, queued, files). TeleNet and ARPANET in allow higher-speed connections and on-line network capabilities such as remote file lookup and transfer on-line, and remote login.

NSFNET1 backbone ... i believe was a contract for $11.2m for a faster backbone to interconnect a number of specific locations. I've heard rumors that the contract only covered 1/4th to 1/10th of the cost of what corporations were actually putting into NSFNET1 to make it a success. That was aside from all the other networks that were deploying at the time.

random refs:
https://www.garlic.com/~lynn/internet.htm
https://www.garlic.com/~lynn/2000c.html#26
https://www.garlic.com/~lynn/2000d.html#43
https://www.garlic.com/~lynn/internet.htm#22
https://www.garlic.com/~lynn/99.html#40

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/

Is Al Gore The Father of the Internet?

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,alt.os.linux
Date: 04 Sep 2000 16:00:29 -0600
Lars Poulsen writes:
It may have been all corporate funded (mostly, maybe completely by IBM) but it was not for use by commercial entities (such as intercontinental telecommuters. In other words, it was encumbered with exactly same the kind of acceptable use restrictions as the NSF network(s).

What was your point?


question of whether or/not internet/nsfnet was the basis of all networking during the 80s ... a large part of which was devoted to various kinds of email (regardless of whether the network itself was realtime or not).

in the same message there was references to other entities (in the 80s and 90s) that used internet protocol and didn't have the same AUPs as
https://www.garlic.com/~lynn/2000c.html#26

the above reference lists some of the AUPs from the period from different networks and i've included some of the text of those AUPs.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

"all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super
Date: 05 Sep 2000 09:41:21 -0600
"Dik T. Winter" writes:
Yup, IBM at it again. If I remember right they coined it after RISC became reasonably wide-spread. But of course the definition of RISC isn't clear either. John Mashey has posted more than once an article where he compared different processors to some meanings you might assign to the term RISC.

i had contact with the ibm 801/risc group around '76 ... so that they had been doing RISC for some time prior to that time. I believe that John Cocke from that group is credited with originating the term risc.

the next time was the 801/risc was going to be used in a project called Fort Knox. Most of the low-end 360-370 processors were microcoded engines of one sort or another. Fort Knox was going to replace all of these microcoded engines with a common 801/risc engine. The 370 instruction set would then be emulated on the 801. This program was eventually canceled (although one might cliam that the current AS/400 implementation using power/pc is some sense a fort knox outcome).

There were misc. other 801/risc chip projects ... in this era most of them never shipped as product; things like blue iliad, etc.

The next 801/risc that i encountered was ROMP ... which was going to be used in an office machine, displaywriter follow-on product. This product got conceled but the project morphed into deliverying the hardware as a unix platform ... which came out as the PC/RT.

The power was the 801/RIOS chip set as a follow-on UNIX product to the PC/RT.

There has been a number of generations of 801/rios ... current i believe is power3.

Somewhat in parallel with power2 ... there began a joint project, somerset, with various other companies to produce a power/pc ... which begat 601, 603, 604, 620(?), 630, etc.

misc. refs:
https://www.garlic.com/~lynn/98.html#26
https://www.garlic.com/~lynn/2000.html#16

random refs:
https://www.garlic.com/~lynn/94.html#22
https://www.garlic.com/~lynn/94.html#47
https://www.garlic.com/~lynn/95.html#5
https://www.garlic.com/~lynn/95.html#6
https://www.garlic.com/~lynn/95.html#9
https://www.garlic.com/~lynn/95.html#11
https://www.garlic.com/~lynn/97.html#5
https://www.garlic.com/~lynn/98.html#25
https://www.garlic.com/~lynn/98.html#42
https://www.garlic.com/~lynn/99.html#64
https://www.garlic.com/~lynn/99.html#66
https://www.garlic.com/~lynn/99.html#136a
https://www.garlic.com/~lynn/2000.html#59
https://www.garlic.com/~lynn/2000b.html#54
https://www.garlic.com/~lynn/2000c.html#3
https://www.garlic.com/~lynn/2000c.html#4
https://www.garlic.com/~lynn/2000c.html#9
https://www.garlic.com/~lynn/2000c.html#12
https://www.garlic.com/~lynn/2000c.html#21
https://www.garlic.com/~lynn/2000d.html#2

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

"all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super
Date: 05 Sep 2000 09:52:03 -0600
pontius@btv.MBI.com.invalid (Dale Pontius) writes:
The 3033 was the last top-line non-TCM machine. I read a performance comparison with an Amdahl machine in Datamation(?) which indicated that the Amdahl was physically as big as it could get without losing its timing, while the 3033 could be almost twice as big. IBM has a habit of tweaking down the cycle time, over time. I suspect the 3033 was designed for this, but it never happened because the 308X series came out.

I was also under the impression that the 3033 was architecturally quite sophisticated, for the time. IIRC, the cycle time was 51nS, but that one's very fuzzy.

On the other hand, the 3081 was supposed to be VERY simple, because it was the first attempt to marked a TCM-based machine. Because the packaging was SO dense, both on the TCMs and on the Clark boards, and because of their build times,there was a lot of work done on the EC process, so the design could be yellow-wired. They didn't want to bite off too much the first time. The packaging certainly worked. IIRC, the cycle time out of the chute was either 33 or 27nS, but that one's even fuzzier for me.


370/165 & 370/168 were 80ns machines. 165 avg. something like 2.1 machine cycles per 370 instruction. 168 had bigger/faster memory/cache and engineers got it down to about 1.6 machine cycles per 370 instruction. 168 used 4circuit/chip technology.

3033 started out as remap of 168 design to faster chip technology ... which also had about ten times the circuit density per chip. However, the straight forward remap wouldn't have used the higher circuit density and would have only resulted in only about a 20% performance increase over the 168. Work then began on redoing selected portions of the 168 design to take advantage of intra-chip performance ... which resulted in the 3033 being nearly a 4.5-5mip machine (compared to 3.5mip or so for the 168-3).

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/

iAPX-432 (was: 36 to 32 bit transition

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: iAPX-432 (was: 36 to 32 bit transition
Newsgroups: alt.folklore.computers,comp.arch
Date: 05 Sep 2000 10:47:23 -0600
"Alan T. Bowler" writes:
My experience is that testing fixes is no harder or easier, since this is a matter of sofware management, ease of rebuilding test software and scheduling of machine time. However, in general detecting bugs in the OS is easier and more thorough on a capability architecture, since the hardware allows (even encourages) assists the user program and the OS to treat each other in an equally paranoid manner, and so the hardware detects OS bugs earlier in the cycle. If you wrap a hardware enforced segment arround the data buffer you pass to the OS, it makes it much harder for an OS bug in addressing that buffer to go unnoticed.

their point was since so much of the function was in hardware ... generating a fix frequently required redesigning & fab'ing a new chip (it was "hard" as in hardware) before something could be tested. it wasn't so much the testing of a fix that was hard ... it was generating the fix (in hardware) that was the difficult part.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/

Is Al Gore The Father of the Internet?

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,alt.os.linux
Date: 05 Sep 2000 11:11:14 -0600
seebs@plethora.net (Peter Seebach) writes:
AOL made the internet what it is today. If Al Gore had never done anything, we would still have roughly the same network, with roughly the same kinds of things on it.

Now, I'm not a big fan of AOL's level of user education, but it was companies like AOL, or UUNet, that made the internet change. If the government had refused to pass any laws, the companies would have done it anyway.


also note that during the late '80s and early '90s ... the government had switched to and was dictating OSI (GOSIP) ... not TCP/IP. The government was attempting to replace use of TCP/IP with OSI implementations which didn't have an internet layer and would have stopped internet growth dead in its tracks.

randoms refs:
https://www.garlic.com/~lynn/2000b.html#0
https://www.garlic.com/~lynn/2000b.html#59
https://www.garlic.com/~lynn/2000d.html#16
https://www.garlic.com/~lynn/2000d.html#43
https://www.garlic.com/~lynn/internet.htm

also most of the internet growth in the 80s was the availability of LANs and the tcp/ip stack on workstations and PCs. Prior to that point, internet had been mainframes and minicomputers with point-to-point connections. The number of workstations and PCs far outnumbered the number of mainframes and minicomputers that had been the networking nodes.

random refs:
https://www.garlic.com/~lynn/99.html#38c

the internal corporate network (all mainframes) reached 1000 nodes at least a year before the "internet":
https://www.garlic.com/~lynn/99.html#110

The internal corporate network (distinct from bitnet, earn, etc) reached 2000 nodes about the same time the "internet" reached 1000 nodes.

After that there was an explosive growth in internet nodes ... not because of the NSFNET1 backbone (which only directly interconnected a rather trivial number of nodes), but because of LANs, workstations, and PCs all showing in the internet configuration.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/

"all-out" vs less aggressive designs

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "all-out" vs less aggressive designs
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super
Date: 05 Sep 2000 19:54:32 -0600
eugene@george.arc.nasa.gov (Eugene Miya) writes:
TCM: Occasionally confused with TMC (Thinking Machines Corp) and TMI (Three Mile Island).

i was walking by when a guy started prying the letters TMC off the building ... I stood and watched until they were all off. I thot of asking if I could have the letters ... but had a meeting I needed to get to ... and resumed walking.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

"all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super
Date: 05 Sep 2000 20:15:06 -0600
"Dik T. Winter" writes:
We had some of those and, indeed, they did very well. But my benchmark shows that the compilers were not really well done. Optimizing some bits in assembler helped quite a lot. 72% improvement on the PC/RT, the MIPS R2000 gave only 45% improvement. (These figures are very atypical. They give information on only one kind of program, integer arithmetic with many multiplies. However, because on both machines the integer multiply was not hardware but software, something can be told from the figures.) If I remember right, the biggest problem was the RT/PC's data addressing part. Offsets from a base register with only limited offsets. Echo's from the 360?

there were two completely sets of software for the PC/RT .... "AIX" and "AOS".

AIX was a port of system V version 3 done on top of the "VRM". The displaywriter group had done a lot of code in PL.8 (the original risc programming language from the 70s) and in the morph to PC/RT built something called the VRM (written in pl.8) with a virtual machine abstraction layer.

The company that had earlier done the port of system V for IBM to the IBM/PC was hired to do a similar port (using version 3) to the PC/RT ... but instead of porting to the bare hardware ... they were tasked to port to the VRM abstraction layer. That is one of the reasons that all of the AIX device drivers were non-standard.

The other offering for universities was AOS ... a port of BSD4.3 to the PC/RT.

The two systems had totally different compilers.

random refs:
https://www.garlic.com/~lynn/99.html#64
https://www.garlic.com/~lynn/99.html#65
https://www.garlic.com/~lynn/99.html#129

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

standard BASIC (was: S/360 development burnout?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: standard BASIC (was: S/360 development burnout?)
Newsgroups: alt.folklore.computers
Date: 06 Sep 2000 09:27:03 -0600
Arargh! writes:
I kinda vaguely remember that. It's been 25 years since I played with a 360. But, it was an 80 byte record, wasn't it?

it could be anything ... but the data placed into storage was 24 bytes at location zero ... an 8 byte program status word (PSW) and two 8-byte channel command words (CCWs).

The IPL I/O sequence would then tic/branch to the first CCW. Frequently the first CCW was something that read additional CCWs to some location and the 2nd CCW would tic/branch to those CCWs. Eventually the sequence of CCWs would finish and the IPL sequence would load the PSW that had been read originally.

The CCW sequence would have read some set of instructions/program into some storage location. The PSW contained the various processor state information and the instruction counter/pointer.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key https://www.garlic.com/~lynn/

Is Al Gore The Father of the Internet?^

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,alt.os.linux
Date: 06 Sep 2000 09:46:25 -0600
Floyd Davidson writes:
Where else was TCP/IP going to be developed??? Name one research lab that was even close to competing with DARPA in that area. Name major contributions that were funded otherwise!

the arpanet protocol was a traditional homogeneous networking protocol with IMPs providing the fabric interconnect. Along the way TCP was developed to ride on top of HCP/NCP infrastruction.

The development of IP was done later ... by a number of university people. While it is clear that the original work was arpa funded ... it isn't clear to what extent arpa was providing funding for the later IP work (or even the TCP work).

misc. refs:
https://www.garlic.com/~lynn/internet.htm#1
https://www.garlic.com/~lynn/internet.htm#3
https://www.garlic.com/~lynn/internet.htm#5
https://www.garlic.com/~lynn/internet.htm#6
https://www.garlic.com/~lynn/internet.htm#11
https://www.garlic.com/~lynn/internet.htm#26
https://www.garlic.com/~lynn/internet.htm#27
https://www.garlic.com/~lynn/internet.htm#28
https://www.garlic.com/~lynn/internet.htm#29

although from the following it is clear that DARPA at the time recognized the need for being able to interconnect ARPANET and the other networks.

excerpt from some 1980 email at
https://www.garlic.com/~lynn/internet.htm#31

Sunshine, Carl A., "Interconnection of computer networks," Computer Networks 1, North-Holland Publishing Company, 1977, pp. 175-195.

It took some time for me to read and understand it, but I think it was worth the effort and I recommend it. At roughly the same time that paper was published, DARPA and their associates began work on a specific approach for coherent interconnection of the myriad nets surrounding ARPANET. One result of their work is a large volume of documentation recording the design options that were taken and the reasons for taking them. If you're interested I can send you some of the pertinent documentation (most of which I have in soft copy), but there's a lot of it.


--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

"all-out" vs less aggressive designs

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "all-out" vs less aggressive designs
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super
Date: 06 Sep 2000 13:26:28 -0600
eugene@cse.ucsc.edu (Eugene Miya) writes:
In Boston?

We caught evidence of a Museum guest trying to pry off the IBM sticker logo from one of our artifacts during one of our events.


in cambridge ... i was walking from the hotel ... originally was the chart house (back in the '60s) ... now something else (? end of the science museum bridge, locus bldgs are just up river from it) to kendall sq. takes you right by TMC bldg. .... openmarket (and others) had already moved into the bldg by the time they got around to taking thinking machine letters off the bldg.

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

"all-out" vs less aggressive designs

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "all-out" vs less aggressive designs
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.super
Date: 06 Sep 2000 16:59:39 -0600
Anne & Lynn Wheeler writes:
science museum bridge, locus bldgs are just up river from it) to ^ lotus

--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
https://www.garlic.com/~lynn/

When the Internet went private

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When the Internet went private
Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux
Date: 07 Sep 2000 12:50:05 -0600
I think that at least some amount of NREN eventually devolved into the government going to vendors and asking them to design and build a demonstration on their own nickle.

About that time, I had just come back from giving some talks in singapore ... and a group of vendors were going over.

The singapore government had invited every vendor that participated in the US high speed networking initiative to singapore to duplicate the US installation ... the big difference (that wasn't lost on any of the vendors) was the singapore government was paying the vendors (instead of asking that it be donated for free) for all the equipment and setup. The vendors may have actually recovered enuf on the singapore initiative to not only cover that cost but the cost of participating in the US initiative as well

anyway misc. from the archives:


Subject: "Bush administration, Gore spar over U.S. gigbit net"
Source:  Network World, 3/11/91, pg 6, Ellen Messemer

The congressional hearing debate was on the federal role in NREN
o the Nat'l Education and Research Network will be the Interstate of the 1990s
  - to revolutionize communications like the Interstate system of roads
did for transportation
- NREN will have gigabit capacity (a billion bits/second and more)
o Allan Bromley, White House science adviser, testified last week
  - government will pay for the research
- the private sector should pay for the building of it
  - he asked Congress for $658M for a new computer research project
"Grand Challenges: High Performance Computing and Communications"
. $92M would be used for an NREN prototype
- Gore's proposals inappropriate because it's inflexible
    . it locks in funding levels
. rapid change in technology dictate changes in plans
o Sen. Albert Gore has sponsored the High Performance Computing Act
- it calls for the gov't to fund NREN over 5 years
- he sidestepped a direct confrontation with Bromley
. his bill needs White House and bipartisan support
  - but he says the administration:
. is trying to avoid Congressional participation
      "<They're> saying just allocate the money and get out of the way"
. may not have the dedication to see the project through
"Irrational things could happen" to derail the program
- a 5-year program
    "sends an unmistakable signal to industry of the program's seriousness"
o Bromley:  although the Administration makes no promises on future funds
  "I can guarantee you <we are> committed to this as an initiative"
- as much as a billion may be committed over the next 5 years
- participants in the initiative would include:
. DARPA - Defense Advanced Research Projects Agency (research)
    . Department of Energy  (research)
. NASA - Nat'l Aeronautics and Space Administration
    . NIST - Nat'l Institute of Standards and Technology
. NIH  - Nat'l Institutes of Health
. EPA  - Environmental Protection Agency
o the Gore bill calls for:
  - $988M over 5 years
- NSF, DARPA, Energy Dept., NIST and NASA participation
o agrees of agreement include that NREN should:
- evolve from todays NSFnet
. the National Science Foundation Network has a top speed of 45M bps
- be available to education, gov't, and the private sector
o testimony on the need for NREN came from:
. Cornell Univ. Theory Center, Apple, Eli Lilly, MIT, US Sprint

...

Source:  Network World, 12/9/91, pg 4, Ellen Messemer

'CEOs push Bush to broaden goals of program'
- the CEOs were from AT&T, Data General, Apple, DEC, IBM, Sun, H-P
- they're members of Computer Systems Policy Project - CSPP
o chief executive officers from 12 US corporations asked for broadening
- the NREN program should be expanded to support commercial applications
    and distributed computing
- there's currently too much emphasis on technology useful to science
and not enough on that for businesses
"We're challenging the government to go beyond what they've proposed"
                                                   Apple's John Sculley
o National Research and Education Network is a planned gigabit network
  - both the White House and Congress have put forth funding proposals
- Sen. Gore's bill was passed recently and awaits Bushs signature
- the White House proposal spends too much on hardware development
. when software is the real challenge:  CEOs
  - make NREN a nationwide commercial and consumer network
. and use client/server technology
o the initiative is "well-conceived" but "esoteric":  H-Ps John Young
- create a complex net of distributed systems
- enabling access to distributed government and industry databases
- and tackle security issues which are already a problem on Internet


Other non-technical issues need to be addressed as well - copyrights on database information - billing and accounting via multiple providers o "We're talking about extending the notion of clients and servers across a broad base" Joel Birnbaum, H-P VP of R&D - network management might have to be decentralized and distributed o the CEOs don't expect the government to build NREN "The private sector is perfectly capable of building the products. But the design of NREN and the issue of where the government decides to spend its $1 billion in seed money will influence industrys willingness to invest" Sculley o CSPP has concerns also about government involvement - current plans are that NSF involve Dept. of Energy, NASA and others - the Nat'l Science Foundation has responsibility for Internet & NREN - CSPP doubts gov't ability to manage both agencies and private sector activities
readme on the NREN implementation plan mid-92

--------
README:
           --------

This describes the files containing the DRAFT NSF Interagency Interim
NREN Implementation Plan. Since the Interagency Interim NREN is based
on the evolution of the existing Federal Agencies' research and
education networks (e.g. ESnet, NSI, NSFNET, and TWBnet) this document
may prove to be valuable background reading when contemplating NSF's
next NSFNET Backbone services solicitation in addition to the NSFNET -
NREN realtionship and subsequent plans. The original set of these
documents can be acquired via FTP from EXPRES.CISE.NSF.GOV.  For the
FTP session please log in as anonymous and use your e-mail address for
the password. Once logged in change directory to recompete ("cd
recompete").  We have included three versions of the Plan: a postscript
version with embeded figures (which doesn't work on many Apple
LaserWriters), an ascii version (we strongly recommend the
postscript version), and a postscript version without the figures
embedded (they are found in the directory as separate postscript
files).  Please direct all questions and/or comments to one of the
authors (Bob Aiken = raiken@nsf.gov, Peter Ford = peter@goshawk.lanl.gov,
Hans-Werner Braun = HWB@sdsc.edu or Steve Wolff = steve@nsf.gov).

"  FTP   EXPRES.CISE.NSF.GOV"
"   cd   recompete"
"  get ...."

Plan Versions:

impl.ps       -- postscript version of the implementation plan with figures
impl.nofig.ps -- postscript version of the implementation plan without
figures  (Figures for document in separate postscript files)
impl.ascii    -- ascii version (using dvi2tty)

Figures:

net.num.ps    -- graph of number of networks on NSFNET backbone
newlevel.ps   -- toplogy diagram showing the existing heirarchy of networks
nex.ps        -- Network access point based internetwork diagram
nsfnet.ps     -- 1991 NSF backbone map, provided by ANS

Thanks
Bob Aiken

Note:  It may be possible to print the impl.ps file on a LaserWriter
II if you submit it as the first job after restarting the printer.

note the DOD transition from TCP/IP to ISO international protocols in the attached.

[ netinfo/nic-pubs.txt ]                                    [ 4/93 ]

PUBLICATIONS OF INTEREST TO
INTERNET USERS

When the DDN Network Information Center (DDN NIC) contract moved from
SRI Network Information Systems Center to GSI/Network Solutions, Inc.,
the responsibility of housing and making available, some files and
documents moved too.  The purpose of this file is to clarify what each
site currently has.  Sometimes, both sites have provide an online copy
of a file or type of file.

DDN NIC FILES AND DOCUMENTS:

These documents are available on-line for anonymous FTP from the NIC
host.  The NIC host is nic.ddn.mil at 192.112.36.5.

1.  DDN NEW USER GUIDE

A "how-to" guide to the DDN for network users, including use of
network tools such as electronic mail and file transfer.   Published
by the former NIC, December 1985, and revised (DRAFT) September 1991.
     Online filename -- netinfo/nug.doc.

     Should be available in hardcopy from Defense Technical Information Center
(DTIC) when the final version is approved by Defense Information
Systems Agency (DISA) in 1992.

2. DDN PROTOCOL IMPLEMENTATIONS AND VENDORS GUIDE

     A list of vendor-supplied software and hardware DDN protocol
implementations, including TCP/IP, X.25, and OSI implementations.
Published by the former NIC, August 1990.  Online filename --
netinfo/vendors-guide.doc.

3. GOVERNMENT OPEN SYSTEMS INTERCONNECTION PROFILE (GOSIP)

The Federal Information Processing Standard (FIPS) describing the
Federal government's policy, including the DoD transition from TCP/IP
to ISO international protocols.

The package contains the Federal Register announcement of the FIPS,
     the GOSIP profile itself, the OSD directive to proceed with the policy
within DoD, and the GOSIP FIPS draft.
Online filenames --

     protocols/gosip-fips-draft.txt     FIPS PUB GOSIP draft
protocols/gosip-fedreg.txt         Federal Register Announcement
     protocols/gosip-v1.docs            The most recent version of the
GOSIP document
protocols/osdir-7-87.txt           OSD Directive to adopt OSI protocols

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

When the Internet went private

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When the Internet went private
Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux
Date: 07 Sep 2000 12:57:26 -0600
... another (partial) file from the archives ... severely edited to get the size down ... only small part of the ISP listing.

host: ftp.nisc.sri.com
directory: netinfo
file: internet-access-providers-us.txt
date: December 1992

This file is Chapter 4 of the book "Internet: Getting Started," a book
that tells what the Internet is and how to join it.  "Internet:
Getting Started" (ISBN 0-13-327933-2) is published by Prentice-Hall.
It can be ordered directly from Prentice-Hall by calling 515-284-6751,
and is also available in many bookstores.

                                 CHAPTER 4
SERVICE PROVIDERS

Advanced Network and Services, Inc. (ANS) and ANS CO+RE
800 456 8267
+1 313 663 2482
     info@ans.net
Services: Network connections.  ANS CO+RE is a wholly owned, taxable
     subsidiary of ANS.  ANS is a not-for-profit organization.

AlterNet
800 488 6384
     +1 703 204 8000
alternet-info@uunet.uu.net
     Services: Network connections; a product of UUNET Technologies.

Infolan
George Abe
     +1 310 335 2600
abe@infonet.com
     Services: Network connections.

MSEN, Inc.
Owen Scott Medd
     +1 313 998 4562
info@msen.com
     Services: Network connections, dialup IP, dialup e-mail.

NSFNET:
Referrals available from:
     NSF Network Services Center
+1 617 873 3400
     nnsc@nnsc.nsf.net
or
Merit Network, Inc.
+1 313 936 3000
     nsfnet-info@merit.edu

Performance Systems International, Inc. (PSI)
800 827 7482
+1 703 620 6651
info@psi.com
     Services: Network connections; dialup IP; dialup e-mail.

SprintLink
Bob Doyle
+1 703 904 2167
rdoyle@icm1.icp.net
     Services: Network connections.

4.2. Providers of Dialup Services

America Online, Inc.
800 827 6364
     +1 703 8933 6288
info@aol.com
     Area Served: US and Canada
Services: Dialup e-mail.

Anterior Technology
     +1 415 328 5615
info@radiomail.net
     Area Served: San Francisco bay area
Services: Dialup e-mail; RadioMail.

Big Sky Telegraph
     800 982 6668 (in Montana only)
+1 406 683 7338
     jrobin@csn.org
Area Served: Montana
Services: Dialup e-mail.

BIX   800 695 4775
+1 617 354 4137
     TJL@mhis.bix.com
Area Served: Area code 617; local dialup connections outside 617
available through TYMNET.
Services: Dialup e-mail.

CERFnet
     800 876 2373
+1 619 455 3900
help@cerf.net
Services: Network connections, national dialup IP, dialup e-mail.

Channel 1
     +1 617 864 0100
whitehrn@channel1.com         DRAFT                                  4
Area Served: Massachusetts
Services: Dialup e-mail.

CLASS
     Cooperative Agency for Library Systems and Services
800 488 4559
class@class.org
Area Served: US
     Services: Dialup access for libraries in the US.

Community News Service
+1 719 579 9120
klaus@cscns.com
Area Served: Colorado Springs, CO (719 area code)
     Services: Dialup e-mail.

CompuServe Information System
800 848 8990
+1 614 457 0802
postmaster@csi.compuserve.com
     Services: Dialup e-mail.

The Cyberspace Station
+1 619 944 9498 ext. 626
help@cyber.net
Area Served: San Diego, CA
     Services: Dialup e-mail

Express Access Online Communications Service
+1 301 220 2020
info@digex.com
Services: Dialup e-mail in the Northern VA,
     Baltimore MD, Washington DC areas
(area codes 202, 310, 410, 703).

EZ-E-Mail
+1 603 672 0736
info@lemuria.sai.com
     Area Served: US and Canada
Services: Dialup e-mail.

Halcyon
+1 206 426 9298
info@remote.halcyon.com
     Area Served: Seattle, WA
Services: Dialup e-mail.

HoloNet
+1 510 704 0160
info@holonet.net
     Area Served: Berkeley, CA (area code 510)
Services: Dialup e-mail.

Institute for Global Communications (IGC)
+1 415 442 0220
support@igc.apc.org
     Services: Dialup e-mail; affiliated with PeaceNet, EcoNet, and
ConflictNet; member of the Association for Progressive Communications
     (APC).

IDS World Network
+1 401 884 7856
     sysadmin@ids.net
Area Served: East Greenwich, RI; northern RI
     Services: Dialup e-mail.

JvNCnet
Sergio F. Heker
     Allison Pihl
800 358 4437
     +1 609 258 2400
market@jvnc.net
Services: Network connections, national dialup IP, dialup e-mail.

MCI Mail Engineering
800 444 6245
     +1 202 833 8484
2671163@mcimail.com
3248333@mcimail.com
Services: Dialup e-mail.

MindVox
     +1 212 988 5987
info@phantom.com
Area Served: New York City (area codes 212, 718)
Services: Dialup e-mail.

MSEN, Inc.
     Owen Scott Medd
+1 313 998 4562
info@msen.com
Area Served: U.S.
     Services: Network connections, dialup IP, dialup e-mail.

New Mexico Technet
+1 505 345 6555
reynolds@technet.nm.org
Area Served: New Mexico
     Services: Dialup e-mail.

Old Colorado City Communications
+1 719 632 4848
dave@oldcolo.com
Area Served: Colorado
     Services: Dialup e-mail.

Seattle Online
+1 206 328 2412
bruceki@online.com
Area Served: Seattle, WA
     Services: Dialup e-mail.

Panix Public Access Unix
Alexis Rosen
alexis@panix.com
+1 212 877 4854
     or
Jim Baumbach
     jsb@panix.com
+1 718 965 3768
Area Served:New York City, NY (area codes 212, 718)
Services: Dialup e-mail.

Performance Systems International, Inc. (PSI)
     800 827 7482
+1 703 620 6651
info@psi.com Services: Network connections, dialup IP, dialup e-mail.

Portal Communications, Inc.
+1 408 973 9111
     cs@cup.portal.com
info@portal.com
Area Served: Northern California (area codes 408, 415)
Services: Dialup e-mail.

Sugar Land Unix
     +1 713 438 4964
info@NeoSoft.com
Area Served: Texas (Houston metro area)
Services: Dialup e-mail.

UUNET Technologies, Inc.
     800 488 6384
+1 703 204 8000
info@uunet.uu.net
Services: Network connections, dialup e-mail; Alternet is a product of
     UUNET Technologies.

Whole Earth 'Lectronic Link (WELL)
+1 415 332 4335
info@well.sf.ca.us
Area Served: San Francisco Bay Area (area code 415)
     Services: Dialup e-mail.

The World
+1 617 739 0202
office@world.std.com
Area Served: Boston, MA (area code 617)
     Services: Dialup e-mail.

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

When the Internet went private

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When the Internet went private
Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux
Date: 07 Sep 2000 16:23:17 -0600
... part of another document from the archives ... severely abridged
& two other networking projects

ISOC-ANNOUNCEMENT                                               1/27/92

                       The Internet Society

                             Abstract

The purpose of this document is to provide a brief description of the Internet Society and its goals and objectives. It will function as a professional society to facilitate, support and promote the evolution and growth of the Internet as a global research communications infrastructure. The suggestions and recommendations of all parties interested in the Internet are solicited to assist in making the Internet Society robust, productive and structured to meet the needs of its members.

The Internet Society

The Internet, is a collection of cooperating, interconnected, multiprotocol networks which supports international collaboration among thousands of organizations. Because of its current scope and rapid rate of growth, the Internet will benefit from a more organized framework to support its objectives. To this end, an Internet Society is being formed to foster the voluntary interconnection of computer networks into a global research and development communications and information infrastructure. The Internet Society will not operate the Internet. Internet operation will continue to be a collaborative activity which the Society will seek to facilitate. The Society will provide assistance and support to groups and organizations involved in the use, operation and evolution of the Internet. It will provide support for forums in which technical and operational questions can be discussed and provide mechanisms through which interested parties can be informed and educated about the Internet, its function, use, operation and the interests of its constituents.

APPENDIX

A Brief History of the Internet and Related Networks

Introduction

In 1973, the U.S. Defense Advanced Research Projects Agency (DARPA) initiated a research program to investigate techniques and technologies for interlinking packet networks of various kinds. The objective was to develop communication protocols which would allow networked computers to communicate transparently across multiple, linked packet networks. This was called the Internetting project and the system of networks which emerged from the research was known as the "Internet". The system of protocols which was developed over the course of this research effort became known as the TCP/IP Protocol Suite, after the two initial protocols developed: Transmission Control Protocol (TCP) and Internet Protocol (IP).

In 1986, the U.S. National Science Foundation (NSF) initiated the development of the NSFNET which, today, provides a major backbone communication service for the Internet. With its 45 megabit per second facilities, the NSFNET carries on the order of 7 billion packets per month between the networks it links. The National Aeronautics and Space Administration (NASA) and the U.S. Department of Energy contributed additional backbone facilities in the form of the NSINET and ESNET respectively. In Europe, major international backbones such as NORDUNET and others provide connectivity to tens of thousands of computers on a large number of networks. Commercial network providers in the U.S. and Europe are beginning to offer Internet backbone and access support on a competitive basis to any interested parties.

"Regional" support for the Internet is provided by various consortium networks and "local" support is provided through each of the research and educational institutions. Within the United States, much of this support has come from the federal and state governments, but a considerable contribution has been made by industry. In Europe and elsewhere, support arises from cooperative international efforts and through national research organizations. During the course of its evolution, particularly after 1989, the Internet system began to integrate support for other protocol suites into its basic networking fabric. The present emphasis in the system is on multiprotocol interworking, and in particular, with the integration of the Open Systems Interconnection (OSI) protocols into the architecture.

Both public domain and commercial implementations of the roughly 100 protocols of TCP/IP protocol suite became available in the 1980's. During the early 1990's, OSI protocol implementations also became available and, by the end of 1991, the Internet has grown to include some 5,000 networks in over three dozen countries, serving over 600,000 host computers used by as many as 4,000,000 people.

Much of the support for the Internet community has come from the U.S. Federal Government, since the Internet was originally part of a federally-funded research program and, subsequently, has become a major part of the U.S. research infrastructure. During the late 1980s, however, the population of Internet users and network constituents expanded internationally and began to include commercial facilities. Indeed, the bulk of the system today is made up of private networking facilities in educational and research institutions, businesses and in government organizations across the globe.

The Coordinating Committee for Intercontinental Networks (CCIRN), which was organized by the U.S. Federal Networking Council (FNC) and the European Reseaux Associees pour la Recherche Europeenne (RARE), plays an important role in the coordination of plans for government- sponsored research networking. CCIRN efforts have been a stimulus for the support of international cooperation in the Internet environment.

Internet Technical Evolution

Over its fifteen year history, the Internet has functioned as a collaboration among cooperating parties. Certain key functions have been critical for its operation, not the least of which is the specification of the protocols by which the components of the system operate. These were originally developed in the DARPA research program mentioned above, but in the last five or six years, this work has been undertaken on a wider basis with support from Government agencies in many countries, industry and the academic community. The Internet Activities Board (IAB) was created in 1983 to guide the evolution of the TCP/IP Protocol Suite and to provide research advice to the Internet community.

During the course of its existence, the IAB has reorganized several times. It now has two primary components: the Internet Engineering Task Force and the Internet Research Task Force. The former has primary responsibility for further evolution of the TCP/IP protocol suite, its standardization with the concurrence of the IAB, and the integration of other protocols into Internet operation (e.g. the Open Systems Interconnection protocols). The Internet Research Task Force continues to organize and explore advanced concepts in networking under the guidance of the Internet Activities Board and with support from various government agencies.

A secretariat has been created to manage the day-to-day function of the Internet Activities Board and Internet Engineering Task Force. IETF meets three times a year in plenary and its approximately 50 working groups convene at intermediate times by electronic mail, teleconferencing and at face-to-face meetings. The IAB meets quarterly face- to-face or by videoconference and at intervening times by telephone, electronic mail and computer-mediated conferences.

Two other functions are critical to IAB operation: publication of documents describing the Internet and the assignment and recording of various identifiers needed for protocol operation. Throughout the development of the Internet, its protocols and other aspects of its operation have been documented first in a series of documents called Internet Experiment Notes and, later, in a series of documents called Requests for Comment (RFCs). The latter were used initially to document the protocols of the first packet switching network developed by DARPA, the ARPANET, beginning in 1969, and have become the principal archive of information about the Internet. At present, the publication function is provided by an RFC editor.

The recording of identifiers is provided by the Internet Assigned Numbers Authority (IANA) who has delegated one part of this responsibility to an Internet Registry which acts as a central repository for Internet information and which provides central allocation of network and autonomous system identifiers, in some cases to subsidiary registries located in various countries. The Internet Registry (IR) also provides central maintenance of the Domain Name System (DNS) root database which points to subsidiary distributed DNS servers replicated throughout the Internet. The DNS distributed database is used, inter alia, to associate host and network names with their Internet addresses and is critical to the operation of the higher level TCP/IP protocols including electronic mail.

There are a number of Network Information Centers (NICs) located throughout the Internet to serve its users with documentation, guidance, advice and assistance. As the Internet continues to grow internationally, the need for high quality NIC functions increases. Although the initial community of users of the Internet were drawn from the ranks of computer science and engineering, its users now comprise a wide range of disciplines in the sciences, arts, letters, business, military and government administration.

Related Networks

In 1980-81, two other networking projects, BITNET and CSNET, were initiated. BITNET adopted the IBM RSCS protocol suite and featured direct leased line connections between participating sites. Most of the original BITNET connections linked IBM mainframes in university data centers. This rapidly changed as protocol implementations became available for other machines. From the beginning, BITNET has been multi-disciplinary in nature with users in all academic areas. It has also provided a number of unique services to its users (e.g., LISTSERV). Today, BITNET and its parallel networks in other parts of the world (e.g., EARN in Europe) have several thousand participating sites. In recent years, BITNET has established a backbone which uses the TCP/IP protocols with RSCS-based applications running above TCP.

CSNET was initially funded by the National Science Foundation (NSF) to provide networking for university, industry and government computer science research groups. CSNET used the Phonenet MMDF protocol for telephone-based electronic mail relaying and, in addition, pioneered the first use of TCP/IP over X.25 using commercial public data networks. The CSNET name server provided an early example of a white pages directory service and is still in use at numerous sites. At its peak, CSNET had approximately 200 participating sites and international connections to approximately fifteen countries. Today, CSNET still provides services to a number of industrial sites and small colleges.

In 1987, BITNET and CSNET merged to form the Corporation for Research and Educational Networking (CREN). A key feature of CREN and its predecessors is that they were entirely dependent on voluntary user fees; BITNET from the beginning and CSNET after the expiration of its initial five year NSF grant.

misc. posts mentioning bitnet &/or EARN
https://www.garlic.com/~lynn/subnetwork.html#bitnet

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

When the Internet went private

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When the Internet went private
Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux
Date: 07 Sep 2000 17:16:26 -0600
following is the list of NSFNET sites ... the sites funded by NSF for NSFNET.

Request: nsfnet
Topic:   sites
Updated: 9 January 1992
Subject: NSFNET sites

NSFNET BACKBONE SITES

On-line now
(November 1991)

Argonne Nat'l Lab
Cornell Nat'l Supercomputer Facility
Georgia Inst. of Tech.
U. of Maryland
Massachusetts Inst. of Tech.
U. of Michigan
Nat'l Ctr. for Atmospheric Res.
Nat'l Ctr. for Supercomputing Appl.
U. of Nebraska
Pittsburgh Supercomputing Ctr.
Princeton U.
Rice U.
San Diego Supercomputer Ctr.
Stanford U.
U. of Utah
U. of Washington

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

When the Internet went private

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When the Internet went private
Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux
Date: 07 Sep 2000 17:17:44 -0600
again from the archives the first part of the bill ... i can post the whole thing if anybody is interested

NIS.NSF.NET> [NSFNET] NRENBILL.TXT

The House-Senate compromise version of S. 272, the High-Performance Computing Act, passed the House on November 20, 1991, the Senate on November 22, 1991, and was signed by the President on December 9, 1991.


A bill to provide for a coordinated Federal program to ensure continued United States leadership in high-performance computing

SECTION 1. SHORT TITLE.
This Act may be cited as the "High-Performance Computing Act of 1991".
SEC. 2. FINDINGS
The Congress finds the following:
(1) Advances in computer science and technology are vital to the Nation's prosperity, national and economic security, industrial production, engineering, and scientific advancement
(2) The United States currently leads the world in the development and use of high-performance computing for national security, industrial productivity, science and engineering, but that lead is being challenged by foreign competitors.
(3) Further research and development, expanded educational programs, improved computer research networks, and more effective technology transfer from government to industry are necessary for the United States to reap fully the benefits of high-performance computing.
(4) A high-capacity and high speed national research and education computer network would provide researchers and educators with access to computer and information resources and act as a test bed for further research and development of high-capacity and high-speed computer networks.
(5) Several Federal agencies have ongoing high performance computing programs, but improved long-term interagency coordination, cooperation, and planning would enhance the effectiveness of these programs.
(6) A 1991 report entitled "Grand Challenges: High- Performance Computing and Communications" by the Office of Science and Technology Policy, outlining a research and development strategy for high-performance computing, provides a framework for a multiagency high-performance computing program. Such a program would provide American researchers and educators with the computer and information resources they need, and demonstrate how advanced computers, high-capacity and high-speed networks, and electronic data bases can improve the national information infrastructure for use by all Americans.

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

When the Internet went private

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When the Internet went private
Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux
Date: 07 Sep 2000 17:19:10 -0600
recognizing the realities of what was going in the commercial internet world

FILIBUSTER ON NATIONAL COMPETITIVENESS ACT ENDED
Prior Proposed Restrictions on Purposes of NREN Removed

Washington, DC By unanimous consent order issued at 2:59 p.m., Mar 15, the filibuster to defeat S.4, the National Competitiveness Act of 1994, led by Ranking Member of the Senate Committee on Commerce, Science, and Transportation, Sen. John C. Danforth, was terminated. The terms of the consent order did not affect any matter pertaining to title VI of the Committee modification introduced by Sen. Hollings Mar 7, 1993.

As the bill now stands, title VI, Information Technology Applications, removes restrictions on the purposes of the National Research and Education Network (Network Program) previously contained in the bill (S.4) reported by the full Committee last summer. Those restrictions prohibited network capabilities in the experimental test bed networks that were available from commercial networks operated by the private sector (Sec. 611(a)(2)(B). They also eliminated restrictions intended to take effect within 18-months on the use of test bed networks to provide commercial network services that could be provided by using commercially available network services (Sec. 611(d)).

The substitute amendment now includes language amending sec. 102 of the High-Performance Computing Act of 1991 to require that program funds "shall develop, provide access to, or use communications networks through the acquisition of commercially available network services or through contracting for customized services when such acquisition cannot satisfy agency requirements." (Sec. 102(g)). Sen. Hollings explained at the time of introducing the substitute amendment that the bill "includes language on one key provision--the section ensuring that Federal support for computer networks does not create unfair competition to commercial phone companies, while still providing that Federal agencies remain free to operate their own internal mission networks."

A vote on the bill was scheduled for Wednesday morning, Mar 16, 1994.

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

When the Internet went private

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When the Internet went private
Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux
Date: 07 Sep 2000 18:29:55 -0600
... here is NREN description from 1996 ... a source of funds for institutions to pay for (commercial) Internet connectivity.

NREN will use the Internet to provide information resource connection not only to universities, research centers and government agencies, but also to secondary and elementary schools. The bill provides $2.9 billion over a five year period towards the NREN. The High-Performance Computing and High Speed Networking Applications Act of 1993, sponsored by Rep. Richard Bouche, expands the Gore bill to also include access to health care facilities and schools at all levels.

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

Is Al Gore The Father of the Internet?^

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,alt.os.linux
Date: 07 Sep 2000 20:46:57 -0600
Floyd Davidson writes:
And the success of each and every one of them is directly attributable to connecting to The Internet. (Notice what happened to each and every competitor that did not embrace the Internet...) You've demonstrated my point rather nicely.

In part, by early 90s, the "Internet" was the commercial TCP/IP networks that had grown up ... in addition to any BITNET, CSNET, NFSNET, etc. ref:
https://www.garlic.com/~lynn/2000d.html#71
https://www.garlic.com/~lynn/2000d.html#72

NFSNET was a "backbone" with a dozen or so locations. Ref:
https://www.garlic.com/~lynn/2000d.html#73

Original NSFNET1 RFP was for a T1 speed backbone interconnecting those locations. In the following the reference to the NSF technical audit was at the time the bids had been submitted for NSFNET1.
https://www.garlic.com/~lynn/internet.htm#0

NSFNET2 was for an upgrade of the backbone from T1 to T3. My wife and I were the red-team for the technology bake-off for NSFNET2. The blue team had 20 or so people from at least seven locations around the world. At the final evaluation (maybe 35-45 people in the room), I presented first for about an hour. Then the representative for the blue team got to present. About 10 minutes into the blue team presentation it became so evident that their solution wasn't very competitive, the executive running the show (who apparently had pre-decided on the outcome based on non-technical issues) ... pounded the table and told everybody in the run that he would lay down in front of a garbage truck before he would allow any but the blue team proposal to go forward. At that point my wife and I (and a couple others) got up and left the meeting.

Gore's NREN bill
https://www.garlic.com/~lynn/2000d.html#74

was supposedly to pump additional money into computing (HPCC) and communication (NREN) R&D.

It isn't clear that a whole lot of NREN money was actually spent for other than funding gov, education, etc. access to "the internet".
https://www.garlic.com/~lynn/2000d.html#75
https://www.garlic.com/~lynn/2000d.html#70

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

When the Internet went private

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When the Internet went private
Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux
Date: 07 Sep 2000 22:02:16 -0600
misc NIIT from the archives, it would be classed a NREN thing ... but commercially funded

NEW NETWORK ALLOWS MASS DATA GATHERING By DAVID BANK Mercury News Staff Writer

A consortium of computing and communications companies eager to show off practical applications for the emerging ''information superhighway'' unveiled a new network Tuesday to allow far-flung computer users to instantly collect vast reams of data and then work on it together as if they were sitting side-by-side. The demonstration was the first part of a plan by the National Information Infrastructure Testbed, or NIIT, to create specialty networks in the environmental, health care and education fields -- prototypes of the superhighway that eventually can be sold to private industry or government agencies. In each field, computer users will be able to quickly retrieve information from data bases spread across the country, sort and analyze it according to their needs and share it with other users around the country, using voice and video as well as data. The goal is to move the information superhighway from the potential to reality by proving it can meet pressing social needs -- and make money. ''This is definitely a commercial venture,'' said Jim Lewis, marketing manager at Synoptics Communications Inc. in Santa Clara, who showed off the new network at the Supercomputing '93 trade show in Portland, Ore. Scientists claim the first application, the Earth Data System, would make it easier for researchers to study global climate change, deforestation, world agricultural production and the effects of floods, hurricanes and other natural calamities. The consortium, formed last September and funded by the companies, is one of many efforts to catch the wave of enthusiasm for the superhighway concept. The companies, including American Telephone & Telegraph Co., Hewlett-Packard Co., Digital Equipment Corp., Pacific Bell and Sun Microsystems Inc. in addition to Synoptics, set aside competition to develop common standards for the new information networks. Next year, the consortium plans to create a medical information system to store patient records and allow doctors in different hospitals to share such things as X-rays. After that, the group plans an interactive educational network. The Earth Data System provides virtually instant access to Landsat satellite images of the Earth in a variety of forms. Then, researchers could add a variety of related data, such as photographs of the same area taken on the ground, field notes by researchers on the ground and voice recordings of local information. The data also includes weather statistics, salinity levels and fishing yields. Its designers claim the network is able to move the equivalent of 1,900 pages of text per second, fast enough for researchers to quickly share large computer files, such as satellite photos. The idea is to allow researchers to work together by simultaneously moving voice, video and data. In addition to solving real-life problems, the demonstrations also are designed to work out the technical, financial and legal snags facing the information superhighway. For example, the Earth Data System combines information that is free to the public with archives that must be purchased. Lewis said security and the integration of data from differing formats also present challenges.

MERCURY CENTER ID: me46571i Transmitted: 93-11-17 06:07:19 EST

...


NATIONAL INFORMATION INFRASTRUCTURE TESTBED
(NIIT)

                  invites you to a discussion on
Applying Information Technologies To Improving Healthcare Delivery

WHEN:  Wednesday, September 28, 1994  (7:30 am - 8:30 am)
WHERE: Information Superhighway Summit, Red Lion Inn,
San Jose, Califoria

BREAKFAST WILL BE SERVED

On September 20, 1994, NIIT will unveil the first nationwide
medical information network to demonstrate how information
technologies can provide tangible healthcare benefits today.  This
first demonstration will take place in Washington, D. C., in front
of the U.S. Congress, the Federal Administration, Healthcare
Industry and Members of the Media.  NIIT would like to share:

-lessons learned in building the nationwide
high speed network using ATM

-healthcare benefits achievable today by applying
              information technologies

Gues speakers will inclue Dr. Dominic Orr, Vice President of
Technology for SynOptics Communication, and Leslie Sandberg,
Executive Director for the Institute for Telemedicine, Center for
the New West.  Both SynOptics and Ms. Sandberg, as Chair of the
NIIT Healthcare Working Group, were instrumental in the deployment
of the nationwide medical network.

Please RSVP to 800-299-9973 by September 23, 1994, as space is
limited.

--
Anne & Lynn Wheeler | lynn@garlic.com https://www.garlic.com/~lynn/

When the Internet went private

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When the Internet went private
Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux
Date: 08 Sep 2000 10:02:14 -0600
from 5/29/94 "Kahaner" report regarding Singapore's NII

An essential ingredient in IT2000 is a National Information Infrastructure, which hopes, by 2005, to interconnect computers in virtually every home, office, school, and factory, and Singapore will probably be the first country to be fully fiber to the home. Many aspects of Singapore's NII will appear similar to those stated in US plans, a high capacity backbone, adherence to standards for networks as well as interfaces and environments, system management and security, distributed computing services, layers of services, and a few significant initial application products. In the case of Singapore these applications include personalized electronic newspaper, media marketplace, distance learning, etc., and others are mentioned, as well as applications of direct value to commercial customers such as a network for procurement, construction, legal network, electronic road pricing, intelligent job placement, on-line income tax info, computerized patenting, geographical information, etc. Many other applications are in the planning or prototype stage. For example, while I was there, an article appeared stating that the NCB and the National University will develop a digital audio archiving/retrieval system to convert Singapore's National Archives 14,000 oral history recordings into digital form. Other projects include communication protocols and software to link pen-based mobile computers on ambulances with computer systems in hospitals.

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

When the Internet went private

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When the Internet went private
Newsgroups: alt.folklore.computers,talk.politics.misc,alt.os.linux
Date: 08 Sep 2000 10:03:02 -0600
another except from a later "Kahaner" report (severely edited)

Building Japan's Information Superhighway
By Joel West (for CRITO)
February 1995

If you want to know about U.S. plans for an "information superhighway," one of the best places to find out is Japan. Seemingly obscure U.S. proposals that are little-noticed here are cited in Japanese newspapers, magazines, books and speeches on Japan's own plans to build a nationwide digital communications network.

Such a network -- usually referred to as a National Information Infrastructure (NII) -- would be Japan's largest public works project since the construction of the shinkansen in the 1960's, so the possibilities are being debated by leading industrial companies, corporate think tanks, academia and several government ministries. The debate seems to have little to do with the questions of how or why such a network would be used, but instead-largely reacting to the recent U.S. NII plans -- is driven by technological competitiveness and a desire by electronics manufacturers to find new large and as yet untapped markets.

As with all important issues involving national policy in Japan, bureaucratic rivalry is central to both the process and likely end result of the NII debate. Also involved is the mutual dependence and rivalry between ministries and industry as they seek to gain both support and wrest leadership from each other.

This brief paper summarizes the policy-making processes at work in the contemporary Japanese NII debate. Because much of the debate is an explicit reaction to U.S. NII plans, it also highlights a few of the major contrasts between those plans.

Key Elements of the Process
===========================

The discussion of Japan's digital communications future is actually framed in terms of three inseparable code phrases: multimedia, information infrastructure and fiber optics. At one end, "multimedia"- the anticipated convergence of audio, video and computing-has been the great anticipated growth market for Japan's large electronics companies for many years. They have developed both new products- such as Sony's handheld Data Discman and Fujitsu's home PC series FM Towns-and hyped existing products as part of an anticipated "multimedia revolution."

The link from multimedia to an information infrastructure is straightforward. Only multimedia content- home movies (video on demand), interactive video games, interactive education, and so on-requires the bandwidth to justify a nationwide digital telecommunications network supplanting the existing telephone network. Such a network is the cornerstone of the plans of Japan (and other nations) for an "information society" in which information is conveyed digitally between citizens, business and government, rather than via mail, fax, telephone or television.

Meanwhile, Japan has already decided that this multimedia system will be delivered via a fiber optic network. In the U.S., current plans call for a hybrid system for itself based on fiber optics and coaxial cable, because existing coaxial cable TV lines serve the vast majority of U.S. homes.

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Coloured IBM DASD

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Coloured IBM DASD
Newsgroups: alt.folklore.computers
Date: 09 Sep 2000 11:20:37 -0600
jcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
I've always been convinced that the above idea is the reason that the IBM 6670 printer was burdened with the obscene magnetic-card interface, apparently because some janitor forgot to throw the readers out into the Dumpster when the MCST (Magnetic Card Selectric Typewriter) was finally given a merciful death, and the engineers at the OPD facility at Boulder were forced to find some other device to use up the inventory.

the 6670 started out as ibm copier3 that IBM San Jose Research added a computer interface for. They then worked with boulder to get it out as a product. I don't remember any reason for the magnetic-card interface ... other than if the copier3 already had one ... or if it was needed to load any sort of information offline.

random refs:
https://www.garlic.com/~lynn/99.html#42
https://www.garlic.com/~lynn/99.html#43
https://www.garlic.com/~lynn/99.html#52

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

"all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
Newsgroups: comp.arch,comp.sys.super,alt.folklore.computers
Date: 10 Sep 2000 09:13:31 -0600
The 3033 64mbyte gave rise to the 16mbyte constrained memory problem. Various kinds of operations (like I/O CCWs) had to be below the 16mbyte line. Some of the early (3033) implementations managing virtual storage ... tended to severely aggravate the 16mbyte constrained memory performance problem ... because of the way they selected virtual memory pages "below" and "above" the (16mbyte) line for replacement (severely reducing the real performance effectiveness of the additional real storage, sometimes almost page-thrashing below the line with very light paging activity above the line).

There were lots of situations where pages above the line had to be moved to below the line ... leading to games where the "above" the line area could have pages pushed into it, almost as a kind of paging device.

misc. other 3033-related refs:
https://www.garlic.com/~lynn/2000c.html#35
https://www.garlic.com/~lynn/2000c.html#83
https://www.garlic.com/~lynn/2000c.html#84

some related problem is that during that period there were operating system "microcode assists" being built for the mid-range machines (4341, 4381, etc). The mid-range machines frequently had a 10:1 emulation ration (between microcode instructions and 370 instructions). Dropping operating system code into microcode was close to a 1:1 mapping (much of the operating system code that got dropped into microcode was status test&update with branching ... which maps easily into the microcode engine instruction set ... and would give a 10:1 performance improvement).

The higher-end horizontal microcode machines with lots of hard-wiring for running 370 instructions ... and things usually expressed in machine cycles per 370 instructions. The 165 was 2.1 machine cycles per 370 instructions and the 168 was 1.6 cycles per 370 instructions.

The bare-bones remapping of 168 to new chip technology would have just been 20% improvement because of the faster chips (and would have had the same number of cycles per 370 instruction). I don't ratio the eventual 3033 ratio ... but I would expect it to have been less that the 1.6:1 168 ratio (which would have added to the 3033 mip rate).

Effectively, most of the operating system microcode assists that were seen on the mid-range machines would see little if any performance improvement on the high-end machines (because they were effectively already running 370 instructions at machine speed, & might even in some cases be slower). This was even more aggravated on 3081 with pageable microcode (i.e. the bare-bones 370 instructions ran at machine cycle speed ... but the more complex "microcode operations" actually might have to be "paged" in&out of microcode store).
https://www.garlic.com/~lynn/94.html#21
https://www.garlic.com/~lynn/2000d.html#7
https://www.garlic.com/~lynn/2000d.html#20
https://www.garlic.com/~lynn/2000d.html#31
https://www.garlic.com/~lynn/2000d.html#61

--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/

Closed versus Stealth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Closed versus Stealth
Newsgroups: comp.security.firewalls
Date: 10 Sep 2000 17:48:52 -0600
"Kevin OMeara" writes:
Can anyone update me on "closed" versus "stealth". If I have a few "closed" ports, is this a big issue??

Kevin


a host will give back an ICMP "port unreachable" .... presumably the "closed" comes from software shutting down &/or closing a port ... and then there isn't anything to respond to something addressed to that port.

stealth is when nothing comes back ...

index/refs for RFCs can be found at
https://www.garlic.com/~lynn/rfcietff.htm

ref: rfc1122.txt, pg 39, section 3.2.2.1 (see "3" below).

3.2.2.1 Destination Unreachable: RFC-792

The following additional codes are hereby defined:

6 = destination network unknown

7 = destination host unknown

8 = source host isolated

9 = communication with destination network administratively prohibited

10 = communication with destination host administratively prohibited

11 = network unreachable for type of service

12 = host unreachable for type of service

A host SHOULD generate Destination Unreachable messages with code:

2 (Protocol Unreachable), when the designated transport protocol is not supported; or

3 (Port Unreachable), when the designated transport protocol (e.g., UDP) is unable to demultiplex the datagram but has no protocol mechanism to inform the sender.


--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/


next, previous, subject index - home