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?

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. 1980)

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
 http://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
 http://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: 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
http://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
http://web.archive.org/web/20001021050132/http://www.cineca.it/resources/sp3/index.html
http://www.epcc.ed.ac.uk/direct/newsletter5/node11.html
http://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/
http://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
http://web.archive.org/web/20001205063400/http://clumber.tc.cornell.edu/HyperNews/get/OtherSites.html
http://www.mhpcc.edu/doc/faq/performance_prog.html
http://web.archive.org/web/20010119114200/http://www.mhpcc.edu/doc/faq/performance_prog.html
http://alpha.mhpcc.edu/mhpcc/mhpcc/WW155.html
http://web.archive.org/web/20010226094027/http://alpha.mhpcc.edu/mhpcc/mhpcc/WW155.html
http://www.mhpcc.edu/general/images/machines.jpg
http://web.archive.org/web/20010607215753/http://www.mhpcc.edu/general/images/machines.jpg
http://www.arc.unm.edu/Workshop/libraries/pmatlib/overview.html
http://web.archive.org/web/20000823134543/http://www.arc.unm.edu/Workshop/libraries/pmatlib/overview.html
http://pipeline.mhpcc.edu/research/ab96/ab47.html
http://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
http://web.archive.org/web/20010228075932/http://www-jics.cs.utk.edu/sp2guide/SP2_guideMay96/SP2_guideMay96.html
http://www.cs.utk.edu/~liang/pjct460/nhse2/7.html

some other info:

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

--
Anne & Lynn Wheeler   | lynn@garlic.com
 http://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: Thu, 13 Jul 2000 06:11:30 GMT

...  and some SP2 switch references ....

http://www.tc.cornell.edu/Edu/Talks/SP/switch.html
http://web.archive.org/web/20001008025523/http://www.tc.cornell.edu/Edu/Talks/SP/switch.html
http://www.nd.edu/~msichiti/Goodies/laucomp/comp.htm
http://web.archive.org/web/20011110115346/http://www.nd.edu/~msichiti/Goodies/laucomp/comp.htm
http://www.llnl.gov/sccd/lc/asci/th_images.html
http://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
http://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
 http://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
 http://www.garlic.com/~lynn/

Definition of SHARE & SCIDS Requested

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
 http://www.garlic.com/~lynn/

Definition of SHARE & SCIDS Requested

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:

i alwas thot it was Society for Continous Inebreation During Share
                                ^^^^^^^^^
                                Continuous

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
 http://www.garlic.com/~lynn/

4341 was "Is a VAX a mainframe?"

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 succesfully 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 succesfully 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 succesfully 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:

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

--
Anne & Lynn Wheeler | lynn@garlic.com
 http://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:

http://www.garlic.com/~lynn/2000c.html#61

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

4341 was "Is a VAX a mainframe?"

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:

http://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:

http://www.garlic.com/~lynn/99.html#100
http://www.garlic.com/~lynn/99.html#136a
http://www.garlic.com/~lynn/2000.html#0
http://www.garlic.com/~lynn/2000.html#31
http://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
 http://www.garlic.com/~lynn/

4341 was "Is a VAX a mainframe?"

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:

http://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
 http://www.garlic.com/~lynn/

4341 was "Is a VAX a mainframe?"

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 useage 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 useage & load pattern.

page access file system ref

http://www.garlic.com/~lynn/93.html#31

paging, spooling, page access file system ref

http://www.garlic.com/~lynn/2000.html#75
http://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 occuring
daily, some occuring weekly, and some occuring 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 useable 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:

http://www.garlic.com/~lynn/93.html#31
http://www.garlic.com/~lynn/95.html#8
http://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 syncronized ... 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 syncronized 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:

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

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

4341 was "Is a VAX a mainframe?"

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:

http://www.garlic.com/~lynn/2000c.html#65

in the above ref:

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

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).

http://www.garlic.com/~lynn/2000c.html#64
http://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
 http://www.garlic.com/~lynn/

4341 was "Is a VAX a mainframe?"

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:

http://www.garlic.com/~lynn/93.html#12
http://www.garlic.com/~lynn/93.html#13
http://www.garlic.com/~lynn/94.html#9

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

FW: RS6000 vs IBM Mainframe

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:

http://www.garlic.com/~lynn/2000c.html#56
http://www.garlic.com/~lynn/2000c.html#68

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

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

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:

http://www.garlic.com/~lynn/2000.html#69
http://www.garlic.com/~lynn/2000.html#70

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

The author Ronda Hauben fights for our freedom.

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 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
 http://www.garlic.com/~lynn/

Where's all the VMers?

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
 http://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:

http://www.garlic.com/~lynn/96.html#12
http://www.garlic.com/~lynn/99.html#117

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

Comrade Ronda vs. the Capitalist Netmongers

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:
http://www.garlic.com/~lynn/internet.htm
http://www.garlic.com/~lynn/2000c.html#26
http://www.garlic.com/~lynn/2000c.html#27
http://www.garlic.com/~lynn/2000c.html#28
http://www.garlic.com/~lynn/2000c.html#29
http://www.garlic.com/~lynn/2000c.html#30
http://www.garlic.com/~lynn/2000c.html#31

--
Anne & Lynn Wheeler   | lynn@garlic.com, finger for pgp key
 http://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: 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:

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

--
Anne & Lynn Wheeler   | lynn@garlic.com, finger for pgp key
 http://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: 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:

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

--
Anne & Lynn Wheeler   | lynn@garlic.com, finger for pgp key
 http://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
 http://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
 http://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:

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

--
Anne & Lynn Wheeler   | lynn@garlic.com, finger for pgp key
 http://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:

http://www.garlic.com/~lynn/2000.html#43

--
Anne & Lynn Wheeler   | lynn@garlic.com
 http://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 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
 http://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 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
 http://www.garlic.com/~lynn/

RS/6000 vs. System/390 architecture?

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:

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

--
Anne & Lynn Wheeler   | lynn@garlic.com
 http://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
 http://www.garlic.com/~lynn/

Secure Operating Systems

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:

http://www.garlic.com/~lynn/2000.html#1
http://www.garlic.com/~lynn/2000.html#81
http://www.garlic.com/~lynn/2000b.html#77
http://www.garlic.com/~lynn/2000c.html#27
http://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
 http://www.garlic.com/~lynn/

RS/6000 vs. System/390 architecture?

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:

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

--
Anne & Lynn Wheeler   | lynn@garlic.com
 http://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
 http://www.garlic.com/~lynn/

Adventure Games (Was: Navy orders supercomputer)

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:

http://www.garlic.com/~lynn/99.html#52
http://www.garlic.com/~lynn/99.html#83
http://www.garlic.com/~lynn/99.html#84
http://www.garlic.com/~lynn/99.html#169

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

Assembly language formatting on IBM systems

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 sophmore 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
 http://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
 http://www.garlic.com/~lynn/

Assembly language formatting on IBM systems

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
 http://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: 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
 http://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, 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
 http://www.garlic.com/~lynn/

Future hacks [was Re: RS/6000 ]

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
 http://www.garlic.com/~lynn/

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

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)

http://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

http://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

http://www.garlic.com/~lynn/93.html#16
http://www.garlic.com/~lynn/96.html#30

random refs:

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

--
Anne & Lynn Wheeler   | lynn@garlic.com
 http://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:

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

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

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

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
http://web.archive.org/web/20010206165928/http://clockdev.usno.navy.mil/archives/leapsecs.html

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

Al Gore: Inventing the Internet...

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:

http://www.garlic.com/~lynn/2000b.html#0
http://www.garlic.com/~lynn/2000b.html#1
http://www.garlic.com/~lynn/2000b.html#4
http://www.garlic.com/~lynn/2000b.html#5
http://www.garlic.com/~lynn/2000b.html#10
http://www.garlic.com/~lynn/2000d.html#19

misc. Postel reference

http://wwwvms.utexas.edu/~glen/postel/
http://web.archive.org/web/20020202134046/http://wwwvms.utexas.edu/~glen/postel/

some discussions on arpanet, nsfnet, internet, etc:

http://www.garlic.com/~lynn/internet.htm

references on the internal network being larger than the
arpa/nsf/inter up until the mid-80s

http://www.garlic.com/~lynn/2000c.html#29

random other refs:

http://www.garlic.com/~lynn/99.html#33
http://www.garlic.com/~lynn/99.html#39
http://www.garlic.com/~lynn/99.html#112
http://www.garlic.com/~lynn/2000c.html#30
http://www.garlic.com/~lynn/2000c.html#31

discussion of some of the networking activities going on about same
time as nsfnet & early "internet"

http://www.garlic.com/~lynn/2000c.html#26

other misc. refs:

http://www.garlic.com/~lynn/rfcietff.htm

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

Charging for time-share CPU time

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

http://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
 http://www.garlic.com/~lynn/

Charging for time-share CPU time

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:

http://www.garlic.com/~lynn/99.html#93

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

Charging for time-share CPU time

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 advisory 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
 http://www.garlic.com/~lynn/

Charging for time-share CPU time

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:

http://www.garlic.com/~lynn/93.html#0
http://www.garlic.com/~lynn/93.html#4
http://www.garlic.com/~lynn/93.html#26
http://www.garlic.com/~lynn/94.html#1
http://www.garlic.com/~lynn/94.html#2
http://www.garlic.com/~lynn/94.html#4
http://www.garlic.com/~lynn/94.html#7
http://www.garlic.com/~lynn/98.html#19

http://www.princeton.edu/~melinda/

&

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

--
Anne & Lynn Wheeler   | lynn@garlic.com
 http://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: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:

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

--
Anne & Lynn Wheeler   | lynn@garlic.com
 http://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

http://www.garlic.com/~lynn/2000.html#63

--
Anne & Lynn Wheeler   | lynn@garlic.com
 http://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 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 boston (also posted here
a couple years ago):

http://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
 http://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 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 boston (also posted here
a couple years ago):

http://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:

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

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

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

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:

http://www.garlic.com/~lynn/95.html#8

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

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

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:

http://www.garlic.com/~lynn/99.html#8
http://www.garlic.com/~lynn/95.html#8

--
Anne & Lynn Wheeler   | lynn@garlic.com, finger for pgp key
 http://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:

http://www.garlic.com/~lynn/internet.htm#26
http://www.garlic.com/~lynn/internet.htm#27
http://www.garlic.com/~lynn/internet.htm#28
http://www.garlic.com/~lynn/internet.htm#29
http://www.garlic.com/~lynn/internet.htm#31

--
Anne & Lynn Wheeler   | lynn@garlic.com, finger for pgp key
 http://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:

http://www.garlic.com/~lynn/2000.html#67
http://www.garlic.com/~lynn/2000.html#72
http://www.garlic.com/~lynn/2000.html#73
http://www.garlic.com/~lynn/2000.html#74
http://www.garlic.com/~lynn/2000.html#85

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

Is Al Gore The Father of the Internet?

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:

http://www.garlic.com/~lynn/internet.htm#7
http://www.garlic.com/~lynn/2000c.html#26
http://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
 http://www.garlic.com/~lynn/

iAPX-432 (was: 36 to 32 bit transition

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
 http://www.garlic.com/~lynn/

Is Al Gore The Father of the Internet?

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:

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

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

Is Al Gore The Father of the Internet?

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
th