List of Archived Posts
2002 Newsgroup Postings (1/12 - 2/17)
- Microcode?
- Microcode? (& index searching)
- Microcode? (& index searching)
- Microcode? (& index searching)
- Microcode? (& index searching)
- Microcode? (& index searching)
- Microcode?
- Microcode? (& index searching)
- Microcode? (& index searching)
- hollow files in unix filesystems?
- Microcode? (& index searching)
- Infiniband's impact was Re: Intel's 64-bit strategy
- Infiniband's impact was Re: Intel's 64-bit strategy
- Infiniband's impact was Re: Intel's 64-bit strategy
- Infiniband's impact was Re: Intel's 64-bit strategy
- hollow files in unix filesystems?
- index searching
- Infiniband's impact was Re: Intel's 64-bit strategy
- hollow files in unix filesystems?
- index searching
- AOL buys Redhat and ... (link to article on eweek)
- Infiniband's impact was Re: Intel's 64-bit strategy
- Infiniband's impact was Re: Intel's 64-bit strategy
- Infiniband's impact was Re: Intel's 64-bit strategy
- Question about root CA authorities
- IBM SHRINKS by 10 percent
- IBM SHRINKS by 10 percent
- First DESKTOP Unix Box?
- windows XP and HAL: The CP/M way still works in 2002
- windows XP and HAL: The CP/M way still works in 2002
- bzip2 vs gzip (was Re: PDP-10 Archive migration plan)
- First DESKTOP Unix Box?
- Does it support "Journaling"?
- Does it support "Journaling"?
- bzip2 vs gzip (was Re: PDP-10 Archive migration plan)
- windows XP and HAL: The CP/M way still works in 2002
- Poor Man's clustering idea
- "war-dialing" etymology?
- IBM 5100 [Was: First DESKTOP Unix Box?]
- Poor Man's clustering idea
- "war-dialing" etymology?
- Infiniband's impact was Re: Intel's 64-bit strategy
- IBM 5100 [Was: First DESKTOP Unix Box?]
- PDP-10 Archive migration plan
- IBM 5100 [Was: First DESKTOP Unix Box?]
- ... the need for a Museum of Computer Software
- IBM 5100 [Was: First DESKTOP Unix Box?]
- ... the need for a Museum of Computer Software
- Grieving and loss was Re: Infiniband's impact was Re: Intel's 64-bit strategy
- Wylbur?
- "Have to make your bones" mentality
- ... the need for a Museum of Computer Software
- Computer Naming Conventions
- Computer Naming Conventions
- "Fair Share" scheduling
- Computer Naming Conventions
- Computer Naming Conventions
- ibm vnet : Computer Naming Conventions
- Computer Naming Conventions
- Filesystem namespaces (was Re: Serving non-MS-word .doc files (wasRe: PDP-10 Archive migrationplan))
- Filesystem namespaces (was Re: Serving non-MS-word .doc files (wasRe: PDP-10 Archive migrationplan))
- TOPS-10 logins (Was Re: HP-2000F - want to know more about it)
- Filesystem namespaces (was Re: Serving non-MS-word .doc files (was Re: PDP-10 Archive migrationplan))
- ... the need for a Museum of Computer Software
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microcode?
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Sun, 13 Jan 2002 06:53:12 GMT
Anne & Lynn Wheeler writes:
chip technology. A 3031 was faster than a 158 in large part because
the engine wasn't being shared between 370 and channel functions
(there were two dedicated engines one for each function)
a little comparison
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.
random refs:
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2002.html#14 index searching
http://www.garlic.com/~lynn/2002.html#48 Microcode?
http://www.garlic.com/~lynn/2002.html#50 Microcode?
http://www.garlic.com/~lynn/2002.html#51 Microcode?
http://www.garlic.com/~lynn/2002.html#52 Microcode?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microcode? (& index searching)
Newsgroups: alt.folklore.computers,comp.arch,comp.lang.asm370
Date: Sun, 13 Jan 2002 15:30:21 GMT
ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
And Rotational Position Sensing (RPS) for 3330 disks. This was
written up in a Systems Journal, (which is lost or buried in my
library), as a major step to reducing the I/O bottleneck in days
of yore, when 2314's still ruled. An -85 with 2 Mb core running MVT
in a service bureau would have been severely constipated without that
feature.
under heavy load, RPS wasn't totally "free" ... there was some
degradation because of RPS-miss ... i.e. multiple concurrent
operations ... and some other disk was transferring data (connected)
at the moment an RPS connection was attempted ... and the disk would
have to do an extra complete revolution and try again.
in slightly earlier thread (index searching) here in a.f.c. the
memory/IO trade-off of CKD (count-key-data) architecture was
discussed. Basically, the I/O subsystem could be instructed to search
for a record of particular characteristic. This operation saved a lot
of memory ... at the extreme expense of I/O subsystem resource.
RPS was a feature introduced with 3330 disks (and block multiplexor
channel achitecture) that tried to alleviate a little of the problem.
Basically a disk drive was configured with a extra platter and head
that had rotational positioning information. Effectively a new channel
command was introduced that outboarded an operation in the disk drive
which would suspend I/O channel connection until a specific rotational
position arrived. The 3330 had 20 surfaces and 20 heads, 19 for data,
and a 20th that contained the positioning information. Typically a
"set sector" operation (susped channel connection and search for
position) was positioned just prior to a "search" command aka
seek
> set-sector
search
tic -8
read/write
ref:
http://www.garlic.com/~lynn/2002.html#10 index searching
If the operating system "knew" the approximate rotational position
("sector") of the desired record ... it could reduce the amount of I/O
hardware busy time spent in "searching" unnecessary records.
The problem was that if the I/O hardware was busy with other
operations at the moment the desired sector came aound ... there would
be a "RPS-miss" and the device would have to make a complete
revolution and try again.
random refs:
http://www.garlic.com/~lynn/2002.html#0 index searching
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002.html#6 index searching
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002.html#14 index searching
http://www.garlic.com/~lynn/2002.html#15 index searching
http://www.garlic.com/~lynn/2002.html#16 index searching
http://www.garlic.com/~lynn/2002.html#17 index searching
http://www.garlic.com/~lynn/2002.html#22 index searching
http://www.garlic.com/~lynn/2002.html#31 index searching
The IBM channel cables are a half duplex (parallel copper) I/O
configuration that had a synchronous end-to-end hand-shake on every
byte. The standard "high-speed" selector channel was rated at max
1.5mbytes/sec and length resriction of about 200' (aggregate length,
typically a number of hardware boxes were "daisy-chained" on the same
"channel"). The "block multiplexor" channel introduced support for
"set-sector" (allowed higher number of concurrent operations using the
channel), max 3mbyte/sec transfer and increased the aggregate length
to about 400' (the increase in max data-rate and aggregate length was
due to a new internal channel cable hand-shaking protocol that would
transfer 8bytes of data in a single hand-shake ... rather than a
single byte), although there wasn't actually a 3mbyte transfer device
until the 3380 ... misc. ref:
http://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
In the following posting discussing a little run-in that I had with
some disk division "architects" ... over my rough swag that disk
relative system performance had degraded by a factor of ten times over
15-year period.
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
after a detailed study, they finally concluded that I had
underestimated the degradation by not taking into account RPS-miss in
the rough swag.
misc RPS-miss refs:
http://www.garlic.com/~lynn/96.html#5 360 "channels" and "multiplexers"?
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#46 MVS History (all parts)
random other disk & channel refs:
http://www.garlic.com/~lynn/subtopic.html#disk
http://www.garlic.com/~lynn/subtopic.html#360pcm
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microcode? (& index searching)
Newsgroups: alt.folklore.computers,comp.lang.asm370
Date: Sun, 13 Jan 2002 17:57:45 GMT
Anne & Lynn Wheeler writes:
transfer 8bytes of data in a single hand-shake ... rather than a
single byte), although there wasn't actually a 3mbyte transfer device
until the 3380 ... misc. ref:
http://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
to go along with the new 3380 disk drive & 3mbyte/sec transfer was the
3880 disk controller replacing the 3830 disk controller (used with
3330s)
while the 3880 disk controller handled the 3mbyte/sec transfer it was
actually significantly slower than the 3830. The 3830 was a horizontal
m'code engine. The 3880 was a jib-prime, a vertical m'coded engine
(similar to standard minicomputer) with hardware bypass/assist for
data transfer (but control functions and commands were hanlded by the
the m'code).
The initial product acceptance criteria for 3880 was that it had to be
no worse than 5percent slower than the 3830 disk controller. The
initial acceptance test was performed using a two disk VS1
configuration. The problem with this was that there was little or no
concurrent disk activity.
I had worked on a special bullet proof IO supervisor for the disk
engineering and product test lab (standard MVS system had 15 minute
MTBF when operating with single test cell).
One monday morning, I got a call from the product test lab (bldg. 15)
saying that the operating system performance had just gone totally
south (and there were no hardware changes). After some investigation,
it turned out that somebody had replaced a 3830 controller with 16
3330 drives over the weekend with a 3880 controller (with the
availability of doing work under an operating system ... the product
test lab was running an internal time-sharing service on a 3033 test
machine in addition to all the product test work).
After a lot more investigation, it turned out that the 3880 m'coders
in order to make performance criteria had fudged things a little. At
the end of an operation, there was some amount of controller work that
needed to be done. With the 3830 controller, this work was totally
completed before the conttroller signalged the channel (and processor)
end of operation. The 3880 was sufficiently slower that waiting until
all the cammand termination work was completed before signaling the
channel resutled in the 3880 missing the performance acceptance
criteria. To compensate, they fudged things a little and signaled the
channel/processor that the operation had end before all of the control
business was complete.
Now, on a lightly loaded system, the processor/kernel would take the
interrupt and go off and do a bunch of work before initiating another
I/O operation. On a system with a heavier load, there are typically
queued requests for disk drives ... so that when one operation
completes, the kernel will immediately redrive the device with a
queued requests. What was happening with the 3880 under heavy load,
was the redrives were being rejected with "control unit busy" status;
the kernel then had to requeue the operation and wait until the
control unit signaled control unit available. This not only
significantly reduced the disk I/O thrput (compared to 3830) but also
significantly increased the kernel processor busy/pathlengths
(effectively doubled the number of I/O initiation and I/O interrupts).
Fortunately this was six months before 3880s were shipped to customers
so they had time to work out other mechanisms to compensate for the
jib-prime being so slow
random refs:
http://www.garlic.com/~lynn/96.html#18 IBM 4381 (finger-check)
http://www.garlic.com/~lynn/96.html#19 IBM 4381 (finger-check)
http://www.garlic.com/~lynn/2000.html#16 Computer of the century
http://www.garlic.com/~lynn/2000b.html#38 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000c.html#75 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000e.html#54 VLIW at IBM Research
http://www.garlic.com/~lynn/2000f.html#42 IBM 3340 help
http://www.garlic.com/~lynn/2001.html#12 Small IBM shops
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001b.html#61 Disks size growing while disk count shrinking = bad performance
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#49 VTOC position
http://www.garlic.com/~lynn/2001d.html#68 I/O contention
http://www.garlic.com/~lynn/2001g.html#46 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001h.html#28 checking some myths.
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2001l.html#54 mainframe question
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
http://www.garlic.com/~lynn/subtopic.html#disk
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microcode? (& index searching)
Newsgroups: alt.folklore.computers,comp.lang.asm370
Date: Sun, 13 Jan 2002 18:30:51 GMT
Anne & Lynn Wheeler writes:
Fortunately this was six months before 3880s were shipped to customers
so they had time to work out other mechanisms to compensate for the
jib-prime being so slow
The other side-effect (going from 3830 to 3880) was that channel busy
was noticably increased (even after fixes) for channel handshaking
opertaions
The channel busy increase was so significant that the 3090 was revised
to ship with more total channels (than originally planned) in order to
meet various aggregate I/O system thru-put criteria. The increase in
the number of 3090 channels then resulted in needing an additional
3090 TCM ... which noticeably increased the 3090 manufacturing costs.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microcode? (& index searching)
Newsgroups: alt.folklore.computers,comp.arch,comp.lang.asm370
Date: Sun, 13 Jan 2002 19:42:54 GMT
Bill B writes:
The knee of the curve was at 35% channel utilization. A classic
mu=rho/(1-rho) plot. This is where degradation started to escalate and any
subsequent I/O request was highly likely to be queued and redriven. It is
similar in concept to ethernet's ability to rarely get over 50% utilization
because of the collisions. (Doing FDR dumps doesn't count, they typically
drove channels to 90%, but there was usually no contention for the drive.)
slight aside with respect to e'net ... we had to fight (both the
16mbit t/r as well as saa people) this when we where doing 3-tier
architecture stuff ... vis-a-vis claims regarding 16mbit t/r. At least
some of the "models" used by the 16mbit t/r people was original
3mbit/sec thick=net that didn't do listen before transmit.
typical 10mbit (with standard listen before transmit) with thin-net in
similar star-wiring configuration (even using t/r cat5 plant wiring)
in local lan configuration did quite well. Part of the reason was that
worst case in star configuration was the propagation delay of the two
longest "arms" ... as opposed to aggregate length of a thicknet daisy
chain.
In any case, a 30-node network with all machines in a solic low-level
device driver loop transmitting minimum sized enet packs would see 85
percent effective thruput of media bandwidth (aka 8.5mbit) initial
results i saw were in 88? or 89? sigcomm ... same issue that had the
paper showing slow-start was non-stable.
turned out that we found that typical 10mbit/sec enet configurations
were getting higher efective thruput than typical 16mbit/sec t/r
configurations.
random refs:
http://www.garlic.com/~lynn/96.html#5 360 "channels" and "multiplexers"?
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/96.html#17 middle layer
http://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#124 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#201 Middleware - where did that come from?
http://www.garlic.com/~lynn/99.html#202 Middleware - where did that come from?
http://www.garlic.com/~lynn/2000b.html#45 OSA-Express Gigabit Ethernet card planning
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000b.html#70 Maximum Length of an URL
http://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#84 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#2 IBM's "ASCI White" and "Big Blue" architecture?
http://www.garlic.com/~lynn/2000e.html#42 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2000f.html#38 Ethernet efficiency (was Re: Ms employees begging for food)
http://www.garlic.com/~lynn/2000f.html#44 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2000f.html#45 Al Gore and the Internet (Part 2 of 2)
http://www.garlic.com/~lynn/2001.html#3 First video terminal?
http://www.garlic.com/~lynn/2001.html#4 Sv: First video terminal?
http://www.garlic.com/~lynn/2001.html#16 Sv: IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001.html#49 Options for Delivering Mainframe Reports to Outside Organizat ions
http://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#33 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001h.html#28 checking some myths.
http://www.garlic.com/~lynn/2001j.html#4 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001j.html#22 Title Inflation
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#19 HP Compaq merger, here we go again.
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2001l.html#19 mainframe question
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#46 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#62 ASR33/35 Controls
http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#5 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#10 mainframe question
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic: facts vs. FUD
http://www.garlic.com/~lynn/2001n.html#34 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#55 9-track tapes (by the armful)
http://www.garlic.com/~lynn/2002.html#2 The demise of compaq
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microcode? (& index searching)
Newsgroups: alt.folklore.computers
Date: Sun, 13 Jan 2002 19:52:57 GMT
ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
TCM = Thermal Conduction Module, right? (They were written up in the
<mumble> edition of Scientific American.
Although the details of construction are dim in my memory, they had
complexity approaching LSI to VLSI, hence the increased cost comment.
basically (lots of) chips inside custom heat transfer housing.
some past refs:
http://www.garlic.com/~lynn/2001k.html#7 hot chips and nuclear reactors
http://www.garlic.com/~lynn/2000b.html#36 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000b.html#37 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000b.html#38 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000d.html#61 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2000d.html#64 "all-out" vs less aggressive designs
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microcode?
Newsgroups: alt.folklore.computers
Date: Mon, 14 Jan 2002 03:42:13 GMT
"Phil Weldon" writes:
Virtual memory? I worked at an IBM Field Systems Service Center which had
one or more of each of the common business machines of the late sixties, all
in one computer room, along most of the possible peripherals. The System
360/ 15, 20,25,30,40, and 50. I never saw a System 360 44, but my guess of
Virtual Memory is based on the RCA model names for their System 360
compatible computers, the Spectra 70 line. RCA picked a number between each
System 360 number as a marketing ploy. They were not very successful, and I
only know of three models: the Spectra 70/ 35, 45, and 55 plus a 46 or 47
I'm not sure which.) The Spectra 70/ 46 or 47 was a virtual memory machine
with 256 Kbytes main memory and an 8 Mbyte, head per track, drum for paging.
So on that thin thread I suggest the System 360/44 was a virtual memory
machine.
Phil Weldon, pweldon@mindspring.com
from:
http://www.beagle-ears.com/lars/engineer/comphist/model360.htm
360/44 - the oddest model. It could be described as a 40 with a
hardware floating point processor and faster memory. Had a variable
precision floating point unit that could operate on 4, 5, 6, 7,
and 8 byte operands. A rotary switch on the front panel could select
between 2 different floating point formats. It had only 1/2 word and 1
word instructions and could therefore use a one word memory width
without any speed penalty. Due to the odd instruction set, it had its
own operating system, PS/44.
=================================
cambridge modified a standard 360/40 and added virtual memory to it
and developed cp/40 on it. Later when "official" virtual memory 360/67
became available ... CP/40 was ported to the 67 for CP/67
from melinda's paper at
http://www.princeton.edu/~melinda/
In the Fall of 1964, the folks in Cambridge suddenly found themselves
in the position of having to cast about for something to do next. A
few months earlier, before Project MAC was lost to GE, they had been
expecting to be in the center of IBM's time-sharing activities. Now,
inside IBM, ``time-sharing'' meant TSS, and that was being developed
in New York State. However, Rasmussen was very dubious about the
prospects for TSS and knew that IBM must have a credible time-sharing
system for the S/360. He decided to go ahead with his plan to build a
time-sharing system, with Bob Creasy leading what became known as the
CP-40 Project. The official objectives of the CP-40 Project were the
following:
1. The development of means for obtaining data on the operational
characteristics of both systems and application programs;
2. The analysis of this data with a view toward more efficient machine
structures and programming techniques, particularly for use in
interactive systems;
3. The provision of a multiple-console computer system for the
Center's computing requirements; and
4. The investigation of the use of associative memories in the control
of multi-user systems.
The project's real purpose was to build a time-sharing system, but the
other objectives were genuine, too, and they were always emphasized in
order to disguise the project's ``counter-strategic'' aspects.
Rasmussen consistently portrayed CP-40 as a research project to ``help
the troops in Poughkeepsie'' by studying the behavior of programs and
systems in a virtual memory environment. In fact, for some members of
the CP-40 team, this was the most interesting part of the project,
because they were concerned about the unknowns in the path IBM was
taking. TSS was to be a virtual memory system, but not much was really
known about virtual memory systems. Les Comeau has written: Since the
early time-sharing experiments used base and limit registers for
relocation, they had to roll in and roll out entire programs when
switching users....Virtual memory, with its paging technique, was
expected to reduce significantly the time spent waiting for an
exchange of user programs.
Virtual memory on the 360/40 was achieved by placing a 64-word
associative array between the CPU address generation circuits and the
memory addressing logic. The array was activated via mode-switch logic
in the PSW and was turned off whenever a hardware interrupt occurred.
The 64 words were designed to give us a relocate mechanism for each 4K
bytes of our 256K-byte memory. Relocation was achieved by loading a
user number into the search argument register of the associative
array, turning on relocate mode, and presenting a CPU address. The
match with user number and address would result in a word selected in
the associative array. The position of the word (0-63) would yield the
high-order 6 bits of a memory address. Because of a rather loose cycle
time, this was accomplished on the 360/40 with no degradation of the
overall memory cycle. The modifications to the 360/40 would prove to
be quite successful, but it would be more than a year before they were
complete.
The Center actually wanted a 360/50, but all the Model 50s that IBM
was producing were needed for the Federal Aviation Administration's
new air traffic control system.
One of the fun memories of the CP-40 Project was getting involved in
debugging the 360/40 microcode, which had been modified not only to
add special codes to handle the associative memory, but also had
additional microcode steps added in each instruction decoding to
ensure that the page(s) required for the operation's successful
completion were in memory (otherwise generating a page fault). The
microcode of the 360/40 comprised stacks of IBM punch card-sized Mylar
sheets with embedded wiring. Selected wires were ``punched'' to
indicate 1's or 0's. Midnight corrections were made by removing the
appropriate stack, finding the sheet corresponding to the word that
needed modification, and ``patching'' it by punching a new hole or by
``duping'' it on a modified keypunch with the corrections.
==============================
random cp/40 references:
http://www.garlic.com/~lynn/93.html#0 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
http://www.garlic.com/~lynn/94.html#37 SIE instruction (S/390)
http://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/94.html#54 How Do the Old Mainframes
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/98.html#28 Drive letters
http://www.garlic.com/~lynn/98.html#45 Why can't more CPUs virtualize themselves?
http://www.garlic.com/~lynn/99.html#139 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/99.html#142 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/99.html#174 S/360 history
http://www.garlic.com/~lynn/99.html#237 I can't believe this newsgroup still exists
http://www.garlic.com/~lynn/2000.html#52 Correct usage of "Image" ???
http://www.garlic.com/~lynn/2000.html#81 Ux's good points.
http://www.garlic.com/~lynn/2000.html#82 Ux's good points.
http://www.garlic.com/~lynn/2000c.html#42 Domainatrix - the final word
http://www.garlic.com/~lynn/2000c.html#79 Unisys vs IBM mainframe comparisons
http://www.garlic.com/~lynn/2000e.html#16 First OS with 'User' concept?
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2000f.html#63 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001b.html#29 z900 and Virtual Machine Theory
http://www.garlic.com/~lynn/2001h.html#9 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#46 Whom Do Programmers Admire Now???
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
http://www.garlic.com/~lynn/2001m.html#47 TSS/360
http://www.garlic.com/~lynn/2001m.html#49 TSS/360
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microcode? (& index searching)
Newsgroups: alt.folklore.computers,comp.arch,comp.lang.asm370
Date: Mon, 14 Jan 2002 12:36:49 GMT
gah@ugcs.caltech.edu (glen herrmannsfeldt) writes:
I thought the 2305 was 3MB/s. Mostly used for paging, transfer
rate was pretty important.
2305s were limited capacity ... and were 3mb/sec (I short cut and was
referring to majority of of disk activity ... and lots of
configuration that didn't have 2305s). the big issue for paging was
more latency ... fixed head per track ... than paging rate. The 2301s
did pretty good at 1.5mbyte/sec. table of device comparisons
http://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
http://www.garlic.com/~lynn/99.html#6 3330 Disk Drives
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
table of system comparisons
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#5 index searching
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microcode? (& index searching)
Newsgroups: alt.folklore.computers,comp.arch,comp.lang.asm370
Date: Mon, 14 Jan 2002 12:41:40 GMT
gah@ugcs.caltech.edu (glen herrmannsfeldt) writes:
A commonly discussed case is a TCP stream between two fast machines.
(Fast relative to when 10Mb ethernet came out.) Such machines can
get the ACK packets out fast enough to signal a collision with the
next data packet coming in. Numbers like 90% or 95% are seen.
turned out that we found that typical 10mbit/sec enet configurations
were getting higher efective thruput than typical 16mbit/sec t/r
configurations.
That is the ethernet newsgroup consensus, too. Though the TR people
then like to argue that TR is more deterministic.
the sigcomm report table showed 95% for nominal conditions ... but
graph/table showed effective thruput degrading to worst case of 85%
effective thruput of media bandwidth ... with 30 machines all in tight
loop constantly transmitting minimum sized packets (which would apply
to ACKs also). The worst case scenario would be situation where there
would be highest probability of multiple stations attempting to
transmit simultaneously when current packet transmission ended
(highest probability that two or more stations listening for the
current end of transmission and were to immediately start simultaneous
transmission resulting in collisions).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: hollow files in unix filesystems?
Newsgroups: alt.folklore.computers
Date: Fri, 18 Jan 2002 00:56:26 GMT
Steve O'Hara-Smith writes:
As you see this will not work in UNIX, in fact delaying action as
long as possible is a common UNIX technique. On many modern UNIX systems
even malloc calls (which allocate memory from the system to a process
dynamically) are rigged to always succeed and not actually allocate the
memory at all until an attempt to access it causes a fault. They call this
technique overcommit, I call it a pain in the arse. It is possible to
allocate more memory to a process than the system has virtual memory and
nothing will go wrong unless you actually use it. AIUI this technique was
introduced to protect the system against applications that requested vast
chunks of memory 'just in case', to me it makes debugging harder than it
need be.
there are two possible ways of treating this ... which is starting to
make more & more difference with large real storage machines. I've
referred to the algorithm in the past as "dup" & "no-dup" (i.e. dup
.... for duplicate).
basically, backing disk page slots can be allocated for every possible
virtual memory page. In a "dup" (aka duplicate) implementation ... if
you have 1gbyte real storage and 2gbyte swap/page file .... then it
typically allows up to 2gbyte of virtual memory.
In a no-dup (no duplicate) implementation .... any time a page is in
real memory, there is no corresponding slot reserved on disk. Anytime
a page is brought into real memory from disk ... the corresponding
disk slot is made available (aka a virtual memory page only exists in
one unique place at a time ... either on disk or in real storage ...
aka no-duplicate). In the 1gbyte real storage plust 2gbyte swap/page
file, the total amount of virtual memory pages can approach 3gbytes.
Some unix systems have implemented a part-way fudge on this .... the
first time a page is created in real stoarge ... there is no immediate
disk slot allocation ... until the page actually gets written out (aka
lazy allocation). This looks a little like a no-dup implementation on
the initial (lazy) allocation ... but frequently then switches to a
"duplicate" implementation once the initial allocation has been made
(i.e. any subsequent time the page is brought in from disk to real
storage, the corresponding disk slot isn't automatically released and
made available).
It is possible to also build an implementation that dynamically
switches between "dup" & "no-dup" based on virtual memory exceeding
disk space. A "dup" alogrithm has the advantage that if a virtual
memory page has been selected for replacement and has not been changed
during its current stay in real storage ... then the real storage copy
and the disk duplicate are still identical and it isn't necessary to
perform the write to disk. A "no-dup" implementation never has a
duplicate saved on disk so all pages selected fro replacement have to
be written to disk.
misc. page replacement postings:
http://www.garlic.com/~lynn/subtopic.html#wsclock
random dup/no-dup postings:
http://www.garlic.com/~lynn/93.html#12 managing large amounts of vm
http://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
http://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
http://www.garlic.com/~lynn/2001n.html#78 Swap partition no bigger than 128MB?????
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microcode? (& index searching)
Newsgroups: alt.folklore.computers
Date: Fri, 18 Jan 2002 01:17:51 GMT
nospam@nowhere.com (Steve Myers) writes:
Actually, I think there were 2 2305s: one model that transferred at
at 3 meg / second, and another model with twice the storage that
tramsferred at 1 1/2 meg / second.
there was 2301 and 2303 on the 360 ... a fixed head drum
the 2301 was a 2303 that read/wrote data from 4 heads in parallel
... and got (four times transfer rate of 2303, 1/4th the number of
"tracks", and each track four times the capacity)) at less than
1.5mbytes/sec transfer
there were two 2305s ... both at 3mbyte/sec.
one had half the capacity and half the rotational delay .... aka half
the disk heads were off-set 180 degrees so that either head could
start read/write.
in the following comparison from
http://www.garlic.com/~lynn/95.html#10
machine 360/67 3081K change
mips .3 14 47*
pageable pages 105 7000 66*
users 80 320 4*
channels 6 24 4*
drums 12meg 72meg 6*
page I/O 150 600 4*
user I/O 100 300 3*
disk arms 45 32 4*?perform.
bytes/arm 29meg 630meg 23*
avg. arm access 60mill 16mill 3.7*
transfer rate .3meg 3meg 10*
total data 1.2gig 20.1gig 18*
Comparison of 3.1L 67 and HPO 3081k
====================================
the '67 configuration had three 2301s (4mbyte each) on one
channel. Peak capacity was 300pages/sec ... 1.2mbyte/sec (avg. load
was 50 percent of peak)
the 3081k configuration had six 12mbyte 2305s split 3 & 3 on two
different channels. Peak thruput per channel was about 600 pages/sec
(2.4mbyte/sec) for a total of 1200 pages/sec across two channels.
(4.8mbyte/sec). peak thruput was less than 3mbyte/sec in part because
of record layout on the track ... there were gaps in the spacing (&
therefor transfer) as the track rotated. avg. loading tended to be 50
percent of peak (paging was frequently very bursty).
the other 2305 had about 6mbyte capacity (1/2 the capacity) but it
also had 1/2 the latency because of the track offset (the two devices
revolved at the same speed ... but rather than avg. being 1/2
revolution to come under a head, it only need 1/4 revolution on the
avg. to come under a head). I never saw or heard of anybody that had
one of the "low latency" 2305s.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband's impact was Re: Intel's 64-bit strategy
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 19 Jan 2002 00:36:47 GMT
"Bill Todd" writes:
I don't think they're at all the same. In Brook's case, the typical issues
are difficulty and/or added overhead in parallelizing the problem, neither
of which applies to the overtime case.
Indeed, if you can solve 50% of the problem in 8 hours you can solve 100%
in 16 hours - as long as they're comparable in quality. The problem with
overtime involves the decrease in per-hour work quality typically associated
with increasing the number of hours worked in a given time period (above
some lower limit where set-up overheads can be ignored) - and this can vary
a great deal among individuals (and with their motivation).
i always thot the overtime hrs were the most productive .... the
standard 8 hr day was consumed with phone calls, meetings,
discussions, etc. It wasn't until everybody left and went home that
any real work got done. The case could be made that 10% (or less) of
the problem is solved in 8hrs ... and after that is when the real work
and the other 90+ percent gets done.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband's impact was Re: Intel's 64-bit strategy
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 19 Jan 2002 01:04:54 GMT
Anne & Lynn Wheeler writes:
i always thot the overtime hrs were the most productive .... the
standard 8 hr day was consumed with phone calls, meetings,
discussions, etc. It wasn't until everybody left and went home that
any real work got done. The case could be made that 10% (or less) of
the problem is solved in 8hrs ... and after that is when the real work
and the other 90+ percent gets done.
when I was an undergraduate, I got a key to the computing center
machine room and would have it all to myself from 8am sat. until 8am
monday. Initially when I started they had a 709 and a 360/30 (that
spent a lot of time in 1401-mode running MPIO, ur<->tape front-end for
the 709) and later was replaced with 360/67. I always thot I was
extremely productive in those 48 hrs ... nobody to bother or distract
me. It was the monday classes that were a little problem ... not
having slept since friday night.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband's impact was Re: Intel's 64-bit strategy
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 19 Jan 2002 02:33:41 GMT
Bruce Hoult writes:
No, that makes the case that the eight hours that you work should have
only minimal overlap with everyone else's eight hours.
problem is that many believe that is the "work" ... going to meetings,
taking phone calls, etc. .... in which case, they insist on the
overlap.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband's impact was Re: Intel's 64-bit strategy
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 19 Jan 2002 02:40:27 GMT
Anne & Lynn Wheeler writes:
when I was an undergraduate, I got a key to the computing center
machine room and would have it all to myself from 8am sat. until 8am
monday. Initially when I started they had a 709 and a 360/30 (that
spent a lot of time in 1401-mode running MPIO, ur<->tape front-end for
the 709) and later was replaced with 360/67. I always thot I was
extremely productive in those 48 hrs ... nobody to bother or distract
me. It was the monday classes that were a little problem ... not
having slept since friday night.
old postings to three shift work day (1st shift in bldg. 28, 2nd
shift in bldg 14&15, and 3rd shift in bldg. 90)
http://www.garlic.com/~lynn/2001e.html#64 Design (Was Re: Server found behind drywall)
http://www.garlic.com/~lynn/2001h.html#29 checking some myths.
http://www.garlic.com/~lynn/2002.html#10 index searching
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: hollow files in unix filesystems?
Newsgroups: alt.folklore.computers
Date: Sat, 19 Jan 2002 09:44:26 GMT
Juha Laiho writes:
Hmm.. so, in this case, the disk space acts as a kind of cache?
If there's room on the paging space, also pages that are active in the
memory will reside on disk, and if space becomes short, the on-disk
copies of active pages can be reused -- and also, if the on-disk
versions are not stale, the active memory page can simply be freed
for use?
in the duplicate case ... the disk "cache" contains copies of
everything that is also in real storage (modulo some of the lazy
allocation algorithms that don't allocate disk space until the first
page-out operation after initial creations). If the most recent copy
of a page in memory has not been modified ... then the memory and disk
copies are the same (i.e. disk copies are not stale) and the memory
copy does not need to be written when selected for replacement. Lots
of program executables would regularly fall into this category.
in the no-duplicate case ... say because wanting to conserve disk
space, the implementation immediately releases/frees the disk slot
anytime a page is brought into memory. there is no longer duplicate
pages in memory and on disk; so anytime a page in memory has been
selected for replacement, it always has to be written (to a new disk
slot). From the implementation stand-point, the no-duplicate case is a
much more general implementation of some of the lazy allocation
implementations (which don't actually allocate a disk slot until a
page is selected for replacement and must be written out; which is
exactly what the no-duplicate implementation has to do ... but also
releases disk slots when pages are read into memory).
A specific implementation could also dynamically switch back & forth
between the "no-dup" and the "dup" operation ... say because of
reaching some disk space constraint (dynamically deciding about
releasing disk slots when pages are brought into memory).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: index searching
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 19 Jan 2002 18:35:22 GMT
Brian Inglis writes:
VM/HPO recommended that only the first 9 of 10 4K pages per track
on 3380 systems be used for multiple page reads/writes, to
eliminate that problem.
Another classic time/space tradeoff most people made happily.
there was a lot of issue with regard being able to switch heads
between platters within a track ... not at just end-of-track. The
controller and channel had latency issues being able to fetch
necessary commands and parameters from memory and execute the
necessary commands while the platter is spinning.
On 3330s there was enuf room to format a short dummy block of 110
bytes between each 4k record. For some machines and some controllers
and some disks ... the 110-byte filler block was sufficient for all
the switch operations to be performed before the next data block was
under the head (but on numerous configurations the latency was too
long and the start of the record had rotated under the head which
resulted in having to make a complete revolution).
On 3380 there wasn't enuf room to put dummy block between every one of
the 9 4k pages in order to induce delay before the next record had
come under the head prior to finish head switch operations. So 3380
had more complex operations ... it had a dummy block large enuf for
the head switch operation inserted between every three 4k records, i.e.
4kblk, 4kblk, 4kblk, dummy blk, 4kblk, 4kblk, 4kblk, dummy blk, 4kblk, 4kblk, 4kblk
was formated on each track ... and HPO could perform a head switch
either because it wasn't attempted to do it between i/os for adjacent
blocks or when there was a dummy block between i/os for adjacent
blocks.
random refs;
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband's impact was Re: Intel's 64-bit strategy
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 19 Jan 2002 19:57:49 GMT
CBFalconer writes:
Never could keep that resolve. Sooner or later I just had to
point out some of the imbecilities that came up, especially if
they would impact me.
i got blamed for doing it on much grander scale.
http://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
http://www.garlic.com/~lynn/2001g.html#6 New IBM history book out
http://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
http://www.garlic.com/~lynn/2001j.html#31 Title Inflation
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: hollow files in unix filesystems?
Newsgroups: alt.folklore.computers
Date: Sat, 19 Jan 2002 21:16:47 GMT
Anne & Lynn Wheeler writes:
slot). From the implementation stand-point, the no-duplicate case is a
much more general implementation of some of the lazy allocation
implementations (which don't actually allocate a disk slot until a
page is selected for replacement and must be written out; which is
exactly what the no-duplicate implementation has to do ... but also
releases disk slots when pages are read into memory).
i also noticed a number of unixes in the early '90s having an adverse
operation interaction where they had implemented lazy allocate but not
no-dup; basically a daemon or something would get started on run
completely out of memory for some period of time. At some undetermined
point in the future (possibly an hour) something would happen to
select the daemon pages for (initial) page out ... requiring disk slot
allocation. At this time, it would be discovered that there were no
more available disk slots and the deamon would be aborted.
If the lazy allocation had been implemented as part of a full no-dup
policy, then (modulo a couple reserved memory pages held for doing
worst case scenario for page exchange between memory and disk) if the page
could be created ... then there would be a disk slot.
The page out was being required because
1) new page was being created or
2) request to bring a page in from disk.
If it is #2 and a "no-dup" implementation, then as soon as a page is
in from disk ... the slot can be made available for the page to go
out.
If it is #1 and there is no disk slots, abort the creation of the new
page (and the corresponding task).
There is slight advantage to aborted tasks that are in the process of
being created as opposed to aborted tasks that have been around for a
long time (at least at the micro-level). That doesn't say that there
might not be a more global policy that looks at importance of tasks
for ranking as to selecting tasks to abort in order to make space
available.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: index searching
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 19 Jan 2002 21:46:06 GMT
Brian Inglis writes:
VM/HPO recommended that only the first 9 of 10 4K pages per track
on 3380 systems be used for multiple page reads/writes, to
eliminate that problem.
Another classic time/space tradeoff most people made happily.
hpo had a later special implementation that did use 10 4k pages per
track called "big pages". As an attempt to address the relative disk
"system" performance degradation (i.e. rest of system resources
increasing much faster than disks were getting faster), an attempt was
made to do larger transfer per disk I/O i.e.
http://www.garlic.com/~lynn/95.html#10
system 3.1L HPO change
machine 360/67 3081K
mips .3 14 47*
pageable pages 105 7000 66*
users 80 320 4*
channels 6 24 4*
drums 12meg 72meg 6*
page I/O 150 600 4*
user I/O 100 300 3*
disk arms 45 32 4*?perform.
bytes/arm 29meg 630meg 23*
avg. arm access 60mill 16mill 3.7*
transfer rate .3meg 3meg 10*
total data 1.2gig 20.1gig 18*
aka disk transfer speed had increase much faster than disk access
times. "Big pages" guarenteed that page operations were done ten
(i.e. full track) at a time.
On page out, ten virtual pages for the same address space were found
and scheduled as a single page-out to a full-track area as a single
full-track write. Then if any virtual page member of a "big page"
later had a fault and needed to be brought in, all ten pages on the
track were fetched in a full track i/o operation. Members of a
specific "big page" could change over time depending on whether they
were all viewed as having been referenced during same stay in memory.
Since the members of big pages would change over time ... by
definition a full-track big page on disk became stale (it could be
different every time it was written out) and so effectively a "no-dup"
implementation was used ... recent dup/no-dup implementation discussion
http://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#16 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#19 hollow files in unix filesystems?
The big page also implemented a moving cursor write algorithm (similar
to some of the log structured filesystems) ... it was desirable to
have contiguous space on disk that was five to tens time larger than
needed. As the arm moved across the space, multiple big page writes
tended to be queued up and they would try and write to all the same
cylinder w/o having to move the arm. If the contiguous space became
too full, then the probability increased that at any specific arm
position there was already allocated big pages on disk. The big page
cursor sweep write algorithm like to have lots of available space for
doing multiple write operations w/o having to move the arm.
There is one final optimization that I don't believe that the big-page
implementation used ... which is akin to the immedate full-track
transfer of some of the disk caches. Since you know that you are going
to perform a full-track operation ... it would be desirable to start
data transfer as soon as the head settled ... w/o having to wait for
rotation for a sepcific starting record. Some of the full-track
implementations would key each record not with simple CCHHR ... but
with an "id" as to what virtual page was located their. The starting
CKD search operation would accept any key value (as opposed to search
for a specific key value) ... and then it would do a chain-data read
for count, key & data. The keys would go to one set of buffers and the
(ten) virtual pages would go into normal memory slots. After the
operation was complete, the keys would be examined to determine which
record was read first and then update all the tables accordingly.
some past big page discussions:
http://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
http://www.garlic.com/~lynn/2000d.html#9 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#19 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#49 VTOC position
http://www.garlic.com/~lynn/2001d.html#68 I/O contention
http://www.garlic.com/~lynn/2001k.html#60 Defrag in linux? - Newbie question
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
some disk comparison discussions
http://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
http://www.garlic.com/~lynn/99.html#6 3330 Disk Drives
http://www.garlic.com/~lynn/2001b.html#61 Disks size growing while disk count shrinking = bad performance
http://www.garlic.com/~lynn/2001l.html#41 mainframe question
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
2305 2314 3310 3330 3350 3370 3380
data
cap, mb 11.2 29 64 200 317 285 630
avg. arm
acc, ms 0 60 27 30 25 20 16
avg. rot
del. ms 5 12.5 9.6 8.4 8.4 10.1 8.3
data
rate mb 1.5 .3 1 .8 1.2 1.8 3
4k blk
acc, ms 7.67 85.8 40.6 43.4 36.7 32.3 25.6
4k acc.
per sec 130 11.6 24.6 23 27 31 39
40k acc
per sec 31.6 4.9 13. 11.3 15. 19.1 26.6
4k acc
per sec
per meg 11.6 .4 .38 .11 .08 .11 .06
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AOL buys Redhat and ... (link to article on eweek)
Newsgroups: linux.redhat
Date: Tue, 22 Jan 2002 23:06:17 GMT
"Kevin Morenski" writes:
We cannot forget the Coca Cola or coffee. In my case, Coca Cola AND Coffee
i was at a conference ... where they brought in a truckload of jolt
and used the conference as beta test for the product .... possibly the
same year that 60 minutes did a (real) number on the conference (my
wife calls it greybeards up in the santa cruz mountains).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband's impact was Re: Intel's 64-bit strategy
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 22 Jan 2002 23:20:17 GMT
"del cecchi" writes:
Some of us are less willing to put in massive amounts of free overtime
to remedy poor
planning by management. "A lack of planning on your part does not
constitute an emergency
on my part."
i'm not sure i ever put any free overtime because of direct poor
planning by management. I put in a lot of free overtime because of
possibly poor planning by the infrastructure ... but it was on
projects that I wanted to do ... not management. It did complicate
matters if I had con'ed random other organizations into letting me
work on their problems ... things that my management had nothing at
all to do with (you typically don't get raises or promotions for
solving other peoples' problems).
If direct management got too frequently into "poor planning"
situations ... it typically became time to revise the paradigm of the
problem they were trying to address and apply a lot of KISS.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband's impact was Re: Intel's 64-bit strategy
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 22 Jan 2002 23:29:29 GMT
Anne & Lynn Wheeler writes:
i'm not sure i ever put any free overtime because of direct poor
planning by management. I put in a lot of free overtime because of
possibly poor planning by the infrastructure ... but it was on
projects that I wanted to do ... not management. It did complicate
matters if I had con'ed random other organizations into letting me
work on their problems ... things that my management had nothing at
all to do with (you typically don't get raises or promotions for
solving other peoples' problems).
ok, i did it once. I was an undergraduate and the computer center
director and the ibm branch manager were playing politics. One
afternoon as part of politics, the director told the branch office
that they had to remove the 2301 the next day. I had to spend all of
2nd and 3rd shift rebuilding the the os/360 system to get sys1.svclib
off the device.
I then really made myself a pain, i called a meeting in the director's
office with the branch manager and told them that whatever their
differences ... i would never do that again ... I needed at least two
weeks notice for any future system rebuilds.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Infiniband's impact was Re: Intel's 64-bit strategy
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 23 Jan 2002 00:10:51 GMT
Anne & Lynn Wheeler writes:
ok, i did it once. I was an undergraduate and the computer center
director and the ibm branch manager were playing politics. One
afternoon as part of politics, the director told the branch office
that they had to remove the 2301 the next day. I had to spend all of
2nd and 3rd shift rebuilding the the os/360 system to get sys1.svclib
off the device.
it was a standard release 9.5 build using the starter system. I was
already somewhat miffed because the system build had been done by an
ibm advisory se and one of the senior comp center staff using standard
dedicated time over part of the weekend. Normally, I had the machine
room all to myself for 48 hours straight from sat. 8am until mon. 8am
.... but their system rebuild cut into one of my weekends.
When it came time to do the release 11 system build ... I tore apart
the stage I & stage II sysgen process and rebuilt it so that i could
do it during the day in the standard operational production system
rather than having to do it using dedicated time off-shift (with the
starter system; leaving the weekends free to do stuff I wanted to
do). This also gave me a chance to re-organize the order of the build
so that I could have optimal placement of files & members to reduce
avg. arm seek operation.
random refs:
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/97.html#28 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/99.html#93 MVS vs HASP vs JES (was 2821)
http://www.garlic.com/~lynn/2000c.html#10 IBM 1460
http://www.garlic.com/~lynn/2000d.html#50 Navy orders supercomputer
http://www.garlic.com/~lynn/2001.html#26 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001d.html#48 VTOC position
http://www.garlic.com/~lynn/2001f.html#2 Mysterious Prefixes
http://www.garlic.com/~lynn/2001f.html#26 Price of core memory
http://www.garlic.com/~lynn/2001g.html#22 Golden Era of Compilers
http://www.garlic.com/~lynn/2001g.html#29 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001h.html#12 checking some myths.
http://www.garlic.com/~lynn/2001h.html#60 Whom Do Programmers Admire Now???
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001k.html#37 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001l.html#36 History
http://www.garlic.com/~lynn/2001l.html#39 is this correct ? OS/360 became MVS and MVS >> OS/390
http://www.garlic.com/~lynn/2002.html#5 index searching
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Question about root CA authorities
Newsgroups: sci.crypt
Date: Wed, 23 Jan 2002 05:02:27 GMT
Erwann ABALEA writes:
Once you got to this point, why not going further? Since the CA is
compromised, why should the CRL be valid? After all, the CRL is only valid
until the CA gets compromised...
Since the trust attached to the CA doesn't come from a digital signature,
then there's no mean to remove this trust with another digital signature.
That's precisely what David wrote (if I understood it correctly). The
trust attached to the root key has to come from an off-band way.
note that the credit card industry has coped with this problem before.
basically the design point for the whole certificate infrastructure is
an "offline" environment where the relying parties had no
online/neartime access to the certification authority and therefor
must trust the "credentials". The analogous solution in the '60s
credit card world was the monthly booklets of invalid "credentials"
(the identifying numbers on those little pieces of plastic).
Note that in the '70s, the credit card business recognized that the
offline solution didn't translate to the online world and went with
online/neartime transactions .... and eliminated trying to force fit
an offline paradigm into an online infrastructure ... aka rather than
trying to distribute tens of millions of electronic invalid account
number booklets everyday ... perpetrating the offline paradigm analogy
... they instead went to online transactions.
The (credential) pieces of plastic still looked the same ... but the
embossed number (as a credential) was augmented with the magnetic
stripe for doing real online transactions in an online paradigm
... rather than trying to force fit an offline paradigm into an online
world (which has been the CA, CRL scenario ... attempting to make a
basically offline design point contorted into a poor semblance of an
online operation).
random refs:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM SHRINKS by 10 percent
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 23 Jan 2002 17:35:01 GMT
bblack@FDRINNOVATION.COM (Bruce Black) writes:
Lets be fair, it is hard to find a company today that has the kind of loyality
to its employees that used to be common 30 years ago (I happen to work for one,
but Innovation is exceptional). I understand that even a lot of Japanese
companies, who used to be famous for "jobs for life", no longer have that
attitude.
i believe ibm had hit a peak world-wide employment approaching 500k.
I had done a simple spreadsheet circa 1981 that showed that given the
trends commoditizing various aspects of the computing industry that
IBM would have to shrink to at least half that size. I believe that
the year after IBM went into the red ... they were down around 200k
(they have since been some ups & down in the number with various
acquisitions, spin-offs and other programs).
In the mid '80s there was enormous investment in plant expansions
... apparently anticipating that the companies growth could continue
to double almost indefinitely (aka there was no possibility that the
computing industry was anywhere close to market saturation).
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM SHRINKS by 10 percent
Newsgroups: alt.folklore.computers
Date: Thu, 24 Jan 2002 20:12:11 GMT
lwinson@bbs.cpcn.com (lwin) writes:
IBM's strength from day one has been in effective utilization of
machines to solve problems. While its army of support personnel
were called "salesmen", they were in reality highly trained and
competent systems experts.
Prior to june 23, 1969 ... there tended to large arrays of "system
engineers" at customer accounts helping with all sorts of things (and
also helping the sales people keep on top of the customer requirements
and needs). june 23, 1969 was unbundling where services and people and
hardware all had to be separately priced.
As a result, a large amount of the ubiquitous presense of the system
engineers started to evaporate since customers got billed for time
system engineers spent doing stuff for the customers. this also
lowered the number of system engineers in the ranks (lower demand) but
also the quality of the system engineers. A significant percentage of
system engineer training was based on being part of a (large) team at
customer sites ... effectively learning the real world "on the job".
I remember as an undergraduate that for a couple years, IBM would
rotate a crop of new system engineers through our shop every six
months and I got to teach them some of the things that I had
developed.
This had significant long term downside effects on skills and
solutions. For instance, in the '60s a large number of applications
solutions were developed in customer shops in response to real live
customer needs. After June 23, 1969 the tight coupling between large
body of skilled people looking to satisfy customer requirements in
daily close proximity with real world customer situations dried up.
Many of these "in situ" solutions evolved into major significant
products and are still around today. At one time it seemed like nearly
every major application solution had evolved out of some customer (or
internal) data processing shop. The joke became that the customer
shops were the development environment and the corporate
organizations that were called "development" groups were in fact,
maintenance organizations (a little name inflation). These
origanizations were frequently "catchers" for applications developed
in customer environments and became responsible for maintaining these
applications (but never participated in the original development).
The skill downgrading started on june 23, 1969 continued until most
system engineers were little more than glorified telephone number
lookup ... i.e. the system engineer listen to the customer's question
and then could find the number to call to get the answer.
i helped support HONE ... which all the (mainframe related and various
other) "field" personel used (sales people, system engineers, field
engineers, etc). basically online system access for every branch
office in the US and eventually the world. Starting with the 370
115/125, ordering mainframes was so complex that the sales people were
required to use a HONE application to generate the order.
misc. past comments on june 23rd
http://www.garlic.com/~lynn/98.html#42 early (1950s & 1960s) IBM mainframe software
http://www.garlic.com/~lynn/99.html#29 You count as an old-timer if (was Re: origin of the phrase
http://www.garlic.com/~lynn/99.html#30 You count as an old-timer if (was Re: origin of the phrase
http://www.garlic.com/~lynn/99.html#58 When did IBM go object only
http://www.garlic.com/~lynn/2001c.html#18 On RC4 in C
http://www.garlic.com/~lynn/2001e.html#6 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001l.html#30 mainframe question
misc. hone (& apl) references:
http://www.garlic.com/~lynn/subtopic.html#hone
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: First DESKTOP Unix Box?
Newsgroups: alt.folklore.computers
Date: Sat, 26 Jan 2002 20:23:41 GMT
Pete Fenelon writes:
(I think the SUSE distro we bought to install a couple of servers at
work was six CDs or a fairly full DVD. Shocking. My first Linux system
(0.12 with Poe's IGL and pretty much everything that had been
ported) sat comfortably in 30MBytes at the end of an old 85 meg IDE
disc. and had room to work in. Oh, and it ran in 4 meg!) -- which was of
course twice (or was it four times) the RAM of the VAX-11/750 that
could support 30 of us at once a few years before :/
or CP/67 running in 768k real storage (104 4k pages for paging after
fixed kernel requirements), 75 users, mix-mode operation, interactive,
program development, test, apl modeling (sort of stuff frequently done
w/spreedsheets today) and various kinds of batch, 95 percentile
subsecond response time for trivial interactive operations (and I
believe possibly somewhat slower processor than 750?).
random refs:
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager
http://www.garlic.com/~lynn/2001f.html#47 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2001l.html#6 mainframe question
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: windows XP and HAL: The CP/M way still works in 2002
Newsgroups: alt.folklore.computers
Date: Sun, 27 Jan 2002 11:53:53 GMT
Brian Inglis writes:
IBM uses HAL in AIX and OS/2, from which MS copied it into WIndows NT, which ran
on x86, Alpha, PPC -- you should know better than to credit MS with ideas -- MS
has never had an original idea in its entire existence.
AFAIK the HAL abstracts the low level kernel layers for CPU startup, memory
management, interrupt and task handling, whereas the BIOS abstracts the handling
of I/O devices.
As CP/M was written in Z80 assembler, there was not much point in a HAL, but
with all HLL OSes, there are always a few machine dependent functions that need
to be redone for each architecture in assembler.
PC/RT was originally going to be a office products offering as a
displaywriter following. It was going to run the CPr operating system
and everything was written in PL.8. The 801 used for this target was
designed with a number of hardware/language/system trade-offs. The
operating system ran with no protection domains all the program
protection checking being done at compile and bind. One of the
trade-offs were extremely limited number of different virtual shared
objects concurrently in the same virtual address space. The
justification was that inline application code could switch the
"segment" registers as trivially as any general register contents
could be switched (no need to need protection domains and
authorization checking for performing virtual address pointer
operations).
To some extent that resulted in the claim that the PC/RT (and later
RS/6000) were 40-bit (and later 56-bit) virtual address
machines. Applications addressing is typically
address-register+displayment. The PC/RT sort-of prefixed the 12-bit
segment register id to the virtual address for a "real virtual
address" ... and since the application could as trivially change a
segment register as they could change an address register ... then the
total virtual address space directly available to the application was
a combination of the segment register ID (bits) and the bits from
address-reg+displacement.
I believe the analysis was that while the max. number of
displaywriter stations that could be connected to the box ... resulted
in a fairly attractive price/seat; the smallest entry level price for
the box was larger than the maximum customer displaywriter
configuration. As a result the project was cancelled and the
organization potentially was going to be disbanded.
Some analysis was done that there was this emerging(?) unix technology
that could be adopted quickly to any platform with minimum of time and
cost, shipping a product to customer. IBM had already contracted for
one such port for the PC (PC/IX).
It was decided to contract with interactive to do a similar port to
this display writer follow-on. However, there was still the question
of what to do with the organization and all the PL.8 programmers. The
solution was to state that all of these PL.8 programmers already knew
the hardware specifics and that they could implement in PL.8 a
virtual machine hardware abstraction layer (the VRM) for Interactive
to port to and that would significantly reduce the elapsed time it
would take to do the port (than if Interactive had to learn the
low-level hardware interface for doing the port). The other, sort of
justification was the CP/67 & VM/370 virtual machine hypervisor
example (originating in the mid'60s) ... however CP/67 & VM/370
conformed to the "real" machine architecture ... while the VRM was a
higher level abstraction.
Note that while the hardware had been designed with a closed operating
system and being able to do inline virtual address segment register
manipulations directly inline application code (as simply as general
registers were manipulated), the unix port required that such things
be moved into the kernel because of the requirement to do security,
access & authorization validation. And of course, since virtual
segment management was now in the kernel and not directly controllable
by the application ... the 40-bit (and later 56-bit) virtual address
claim was even more contrived.
It turns out that the port for the VRM (ignoring the significant
increase in total resources), significantly incrased the elapsed port
time as well as created a whole new non-standard device driver
culture. Special, non-standard unix device drivers had to be written
to the VRM abstraction layer, and then a separate device driver had to
be written for the VRM.
A later port of BSD4.3 to the bare PC/RT hardware (called AOS) was
done in substantially less time than it took to create the original
AIX offering (supporting the statement that the Interactive port to
the VRM abstraction layer took much longer than if they would have
learned the low-level hardware and did that port).
A port of PICK to the PC/RT VRM abstraction layer ... did show that
PICK and AIX could run simultaneously on the same machine using the
VRM as a (abstract) virtual machine hypervisor.
random refs:
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/98.html#25 Merced & compilers (was Re: Effect of speed ... )
http://www.garlic.com/~lynn/98.html#26 Merced & compilers (was Re: Effect of speed ... )
http://www.garlic.com/~lynn/99.html#2 IBM S/360
http://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
http://www.garlic.com/~lynn/99.html#65 Old naked woman ASCII art
http://www.garlic.com/~lynn/99.html#129 High Performance PowerPC
http://www.garlic.com/~lynn/99.html#146 Dispute about Internet's origins
http://www.garlic.com/~lynn/2000.html#49 IBM RT PC (was Re: What does AT stand for ?)
http://www.garlic.com/~lynn/2000e.html#27 OCF, PC/SC and GOP
http://www.garlic.com/~lynn/2000f.html#74 Metric System (was: case sensitivity in file names)
http://www.garlic.com/~lynn/2001.html#4 Sv: First video terminal?
http://www.garlic.com/~lynn/2001e.html#76 Stoopidest Hardware Repair Call?
http://www.garlic.com/~lynn/2001f.html#0 Anybody remember the wonderful PC/IX operating system?
http://www.garlic.com/~lynn/2001f.html#1 Anybody remember the wonderful PC/IX operating system?
http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001f.html#43 Golden Era of Compilers
http://www.garlic.com/~lynn/2001f.html#45 Golden Era of Compilers
http://www.garlic.com/~lynn/2001h.html#74 YKYGOW...
http://www.garlic.com/~lynn/2001i.html#5 YKYGOW...
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001l.html#50 What makes a mainframe?
http://www.garlic.com/~lynn/2001n.html#55 9-track tapes (by the armful)
http://www.garlic.com/~lynn/2002.html#17 index searching
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: windows XP and HAL: The CP/M way still works in 2002
Newsgroups: alt.folklore.computers
Date: Mon, 28 Jan 2002 03:21:29 GMT
"Rupert Pigott" writes:
Looking back on cool ideas which I think were pretty original
and non-obvious, I'd say that Virtual Memory is the best example
I can find. I'm fairly sure you guys have a ton of examples you
can think of. :P
virtual machines?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: bzip2 vs gzip (was Re: PDP-10 Archive migration plan)
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Mon, 28 Jan 2002 15:26:54 GMT
robert writes:
MIME does NOT rely on the 'extension' part of a file-name to determine
processing. the file name, and the 'content type' are explicitly two
entirely separate entities, per the RFC standard. MIME is also concerned,
primarily, with the _current_ use of a file, and how to display it. When
editing, _as_source_, a web-page, the appropriate content-type is "text/plain",
since one does -not- want it "rendered".
misc mime rfcs
goto
http://www.garlic.com/~lynn/rfcietff.htm
and click on Term (term->RFC#)
& scroll down to "MIME" acronym
multipurpose internet mail extensions (MIME )
see also mail
3218 3217 3204 3185 3183 3156 3126 3125 3073 3058 3047 3030 3023 3016
3009 3003 2987 2984 2978 2958 2957 2938 2936 2927 2913 2912 2910 2876
2854 2797 2785 2781 2738 2703 2652 2646 2634 2633 2632 2631 2630 2586
2565 2557 2534 2533 2530 2518 2506 2503 2480 2442 2426 2425 2424 2423
2422 2392 2388 2387 2376 2346 2318 2312 2311 2305 2302 2301 2298 2294
2293 2278 2231 2220 2184 2183 2164 2163 2162 2161 2160 2159 2158 2157
2156 2152 2130 2112 2111 2110 2083 2077 2049 2048 2047 2046 2045 2017
2015 1927 1896 1895 1894 1892 1874 1873 1872 1848 1847 1844 1837 1836
1830 1820 1767 1741 1740 1641 1590 1563 1556 1523 1522 1521 1496 1437
1428 1344 1341 1049
clicking on any of the RFC's puts up summary of that RFC in the lower frame.
clicking on the ".txt" field in the RFC summary, retrieves the actual RFC
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: First DESKTOP Unix Box?
Newsgroups: alt.folklore.computers
Date: Mon, 28 Jan 2002 15:45:18 GMT
ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
VM/370r6 is, too:
The VM shop I last worked closed in May 93. Was r6 pre or post that?
Those version numbers get jumbled as time goes by. VM/CMS had just
been given enhanced file structure beyond F-name, F-type, F-mode but
I never got to use it.
VM/370 R6 was from the late '70s. It lived on a lot longer. It was
chosen as the basis for the 3090 service processor ... first was going
to be a 4331 and then upgraded to a pair of 4361 (for
redundancy). There was a development group working on it that was
larger than the original vm/370 cp&cms development group doing the
enhancements, applications and modifications to support the service
processor functions.
field service required a boot-strappable diagnostic process done in
the field starting with a "scope". The 3090 (& 3081 before it with
uc.5 service processor) wasn't directly "field scope'able" ... while the
4361 was. The idea was field service could bootstrap dianostic by
scoping any problems with the 4361 (if necessary) ... and then using
the 4361 service processor functions (that had lots of probs into all
parts of the 3090) to diagnose the 3090. The original 4331 was
upgraded to pair of 4361s as service processors to make it even less
likely diagnosing 4361 was required.
random refs:
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/96.html#41 IBM 4361 CPU technology
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#61 Living legends
http://www.garlic.com/~lynn/99.html#62 Living legends
http://www.garlic.com/~lynn/99.html#63 System/1 ?
http://www.garlic.com/~lynn/99.html#106 IBM Mainframe Model Numbers--then and now?
http://www.garlic.com/~lynn/99.html#108 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#110 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/99.html#239 IBM UC info
http://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#51 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#66 oddly portable machines
http://www.garlic.com/~lynn/2000b.html#69 oddly portable machines
http://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2001.html#54 FBA History Question (was: RE: What's the meaning of track overfl ow?)
http://www.garlic.com/~lynn/2001b.html#75 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001f.html#44 Golden Era of Compilers
http://www.garlic.com/~lynn/2001h.html#2 Alpha: an invitation to communicate
http://www.garlic.com/~lynn/2001j.html#13 Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#17 3270 protocol
http://www.garlic.com/~lynn/2001n.html#9 NCP
http://www.garlic.com/~lynn/2002.html#45 VM and/or Linux under OS/390?????
http://www.garlic.com/~lynn/2002.html#48 Microcode?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Does it support "Journaling"?
Newsgroups: comp.arch.storage
Date: Mon, 28 Jan 2002 16:32:39 GMT
lindahl@pbm.com (Greg Lindahl) writes:
BTW, the biggest Linux distributions have shipped journaling
filesystems for a short while (ext3 in RedHat), and most commercial
Unixes have shipped journaling filesystems for many years.
I'll avoid speculating about your attitudes; is assuming simple
stupidity better than malice?
the first (control or metadata) journaling unix filesystem (that i
know of) was rs/6000 aix in the late '80s. it was implemented using
rios database memory where all the filesystem metadata was mapped
into region of memory that tracked memory change at the 128(?)byte
line level. Filesystem then had "commit" operations inserted at
appropriate places. The commit call then involved scan of the
filesystem metadata memory region searching for "lines" of storage
marked as changed. All the changed lines where gathered up and written
to the log. Recovery consisted of reading the log and
"rolling-forward" the actual filesystem metadata (and little things
were fixed up like non-logged/commited metadata couldn't be written to
disk).
A portable version of this implementation was done where explicit
calls to logging routine were inserted into all the places that
modified metadata. There was a claim that even on the same rs/6000,
the explicit calls to logging routine was more efficient
implementation than the scan of filesystem metadata memory at commit
time.
in this case, journaling filesystem is somewhat misnomer.
process is log & commit of filesystem metadata.
log records cycle ... when all cached data involved with log records
are known to be written to disk, the log records are made available
for re-use. use of a log "file" tends to be relatively small
... continuely using the same log records.
journals normally are long-term recording of all changes. a database journal
may be able to go back several days and be able to determine who caused
what changes. a log typically fulfills need to write to disk in efficient
manner the necessary information to maintain consistency.
A single logical change might involve changing several records on disk
and it is impossible to reflect the change as a single atomic disk
write.
A roll-forward log will write all the pending changes to a log before
starting the write of the actual records to disk. After all records
have been succesfully written to disk, some kind of marker goes into
the log indicating that operation was succesful. A recovery operation
is done by reading the log, finding all uncompleted changes and
re-updating the corresponding records & writing them back to disk.
A roll-back log will write the unmodified version of data being
changed before beginning the actual writes of records to
disk. Recovery then consists of updating the correspond records
involved in pending operations to return them to their unmodified
state.
A filesystem metadata log doesn't guarentee consistency of file or
database information. A filesystem metadata log can guarentee the
consistency of the filesystem metadata.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Does it support "Journaling"?
Newsgroups: comp.arch.storage
Date: Mon, 28 Jan 2002 16:39:09 GMT
Anne & Lynn Wheeler writes:
the first (control or metadata) journaling unix filesystem (that i
know of) was rs/6000 aix in the late '80s. it was implemented using
rios database memory where all the filesystem metadata was mapped
into region of memory that tracked memory change at the 128(?)byte
line level. Filesystem then had "commit" operations inserted at
appropriate places. The commit call then involved scan of the
it is also what my wife and I depended on for HA/CMP (high availability,
cluster multiprocessor) ... as part of fast recovery/take-over in various
cluster configurations.
misc. ref:
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/subtopic.html#hacmp
you would be surprised at the people that are violent supporters now ... who
at the time were in violent opposition that you could do such clustering
and availability on non-mainframe components.
random refs:
http://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/95.html#13 SSA
http://www.garlic.com/~lynn/96.html#15 tcp/ip
http://www.garlic.com/~lynn/96.html#31 Mainframes & Unix
http://www.garlic.com/~lynn/96.html#33 Mainframes & Unix
http://www.garlic.com/~lynn/96.html#34 Mainframes & Unix
http://www.garlic.com/~lynn/96.html#36 Mainframes & Unix (and TPF)
http://www.garlic.com/~lynn/97.html#5 360/44 (was Re: IBM 1130 (was Re: IBM 7090--used for business or
http://www.garlic.com/~lynn/98.html#35a Drive letters
http://www.garlic.com/~lynn/98.html#37 What is MVS/ESA?
http://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP?
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/98.html#57 Reliability and SMPs
http://www.garlic.com/~lynn/99.html#54 Fault Tolerance
http://www.garlic.com/~lynn/99.html#219 Study says buffer overflow is most common security bug
http://www.garlic.com/~lynn/2000b.html#45 OSA-Express Gigabit Ethernet card planning
http://www.garlic.com/~lynn/2000b.html#80 write rings
http://www.garlic.com/~lynn/2000b.html#85 Mainframe power failure (somehow morphed from Re: write rings)
http://www.garlic.com/~lynn/2000e.html#22 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2000f.html#31 OT?
http://www.garlic.com/~lynn/2000g.html#43 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2000g.html#47 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
http://www.garlic.com/~lynn/2001c.html#69 Wheeler and Wheeler
http://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001e.html#4 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001e.html#41 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001f.html#58 JFSes: are they really needed?
http://www.garlic.com/~lynn/2001f.html#59 JFSes: are they really needed?
http://www.garlic.com/~lynn/2001g.html#23 IA64 Rocks My World
http://www.garlic.com/~lynn/2001g.html#44 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001i.html#41 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001i.html#48 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001j.html#47 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#10 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#13 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001n.html#30 FreeBSD more secure than Linux
http://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
http://www.garlic.com/~lynn/2001n.html#83 CM-5 Thinking Machines, Supercomputers
http://www.garlic.com/~lynn/2002.html#20 Younger recruits versus experienced veterans ( was Re: The demise of compa
http://www.garlic.com/~lynn/2002.html#23 Buffer overflow
http://www.garlic.com/~lynn/2002.html#44 Calculating a Gigalapse
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: bzip2 vs gzip (was Re: PDP-10 Archive migration plan)
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Mon, 28 Jan 2002 20:31:44 GMT
robert writes:
For MIME 'magic' to work, one must carry around some _meta-data_ describing
the file content. In almost every environment I'm familiar with, said
meta-data is external to the file. The exception being Apple's MacOS,
where the meta-data is stored in the 'resource fork' of each file. And,
quite frankly, "damnifiknow" _how_ a Mac-based ftp appliation (client _or_
server) handles the resource-fork info, particularly when talking to a
_non-MacOS_ application.
one of the early things that CSC did was to continuously gather
performance and load data and the first record written to the file was
the "metadata" description (names and field formats of the subsequent
records). These files were archived to tape (or written directly to
tape) and years later it was possible to do multiple year analysis of
various performance issues.
I would claim that philosophy at least partially contributed to GML
(tagged markup language) being invented subsequently at CSC in the
late '60s (spawning the MLs, SGML, HTML, XML, etc).
misc. csc:
http://www.garlic.com/~lynn/subtopic.html#545tech
http://www.garlic.com/~lynn/subtopic.html#fairshare
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: windows XP and HAL: The CP/M way still works in 2002
Newsgroups: alt.folklore.computers
Date: Mon, 28 Jan 2002 23:56:24 GMT
mwojcik@newsguy.com (Michael Wojcik) writes:
There isn't any HAL-like layer for AIX on the RISC System/6000. AIX
for the RT (AIX 2) ran atop a hardware virtualization layer called
the VRM, as Lynn described in another message in this thread.
AIX/370 and AIX/ESA ran under VM (could they run directly on the
hardware, without being hosted by VM?). AIX 1 (for the PS/2) and AIX
3-5 (for the RS/6000) ran directly on the hardware.
aix/370 & aix/ps2 were locus ports to both platforms (supposedly being
sort of the "SAA" for unix, aka network file system, with both partial
and full local file caching, process migration, disimilar
architectures, etc).
aix/370 & aix/esa primarily under VM, I believe was a field service
issue .... vm provided a lot of various kinds of error recovery,
recording, and reports in specific format required by field service
people before they would support the hardware in the field. issue
being the cost/benefit of putting all that stuff into a unix platform
vis-a-vis running under vm.
there were vestiges of vrm laying around in various places in "AIX V3"
(but in general, it was suppose to be all gone).
they are now touting 40,000-plus copies of linux running under vm on
single mainframe.
and the random references:
http://www.garlic.com/~lynn/99.html#2 IBM S/360
http://www.garlic.com/~lynn/99.html#63 System/1 ?
http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
http://www.garlic.com/~lynn/99.html#66 System/1 ?
http://www.garlic.com/~lynn/2000.html#64 distributed locking patents
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#27 OCF, PC/SC and GOP
http://www.garlic.com/~lynn/2001.html#44 Options for Delivering Mainframe Reports to Outside Organizat ions
http://www.garlic.com/~lynn/2001.html#49 Options for Delivering Mainframe Reports to Outside Organizat ions
http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001i.html#21 3745 and SNI
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001l.html#8 mainframe question
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2001l.html#50 What makes a mainframe?
http://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic: facts vs. FUD
http://www.garlic.com/~lynn/2002b.html#29 windows XP and HAL: The CP/M way still works in 2002
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Poor Man's clustering idea
Newsgroups: comp.arch.storage
Date: Tue, 29 Jan 2002 03:26:42 GMT
danco writes:
When are Windows and the various UNIX OS'en out there going to
implement real clustering where all hosts can simultaniously
mount and transparently share all devices with no conflicts?
VMS has had that since, what, 1983?
360s have had clusters since, what, the mid '60s (referred to as
"loosely-coupled", to distinquish from "tightly-coupled" ... typically
shared memory ... or "closely-coupled" ... various other kinds of
specialized coupling hardware).
when my wife and I did ha/cmp we got lots of input from a couple of
the database systems that also ran in vms cluster as to what not to do
(she also did stint in POK responsible for "loosely-coupled", cluster
by any other name). about the same time as she was in pok, I worked on
what was considered the largest "single-system-image" system in the
world (a type of large cluster for its time in the '70s).
a couple specific vax & ha/cmp cluster related posts
http://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001e.html#4 Block oriented I/O over IP
random refs;
http://www.garlic.com/~lynn/93.html#4 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/93.html#5 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/93.html#21 Too much data on an actuator (was: 3.5 inch 9GB )
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#4 Schedulers