List of Archived Posts
2006 Newsgroup Postings (9/23 - 10/3)
- Cray-1 Anniversary Event - September 21st
- Greatest Software Ever Written?
- Was FORTRAN buggy?
- Trying to design low level hard disk manipulation program
- Was FORTRAN buggy?
- Was FORTRAN buggy?
- Was FORTRAN buggy?
- Was FORTRAN buggy?
- should program call stack grow upward or downwards?
- Was FORTRAN buggy?
- Was FORTRAN buggy?
- Was FORTRAN buggy?
- Trying to design low level hard disk manipulation program
- Was FORTRAN buggy?
- 50th Anniversary of invention of disk drives
- 50th Anniversary of invention of disk drives
- Was FORTRAN buggy?
- Greatest Software Ever Written?
- 50th Anniversary of invention of disk drives
- Greatest Software Ever Written?
- 50th Anniversary of invention of disk drives
- 50th Anniversary of invention of disk drives
- Was FORTRAN buggy?
- 50th Anniversary of invention of disk drives
- A Day For Surprises (Astounding Itanium Tricks)
- Computer Artifacts
- A Day For Surprises (Astounding Itanium Tricks)
- A Day For Surprises (Astounding Itanium Tricks)
- Greatest Software Ever Written?
- Intel abandons USEnet news
- 50th Anniversary of invention of disk drives
- 50th Anniversary of invention of disk drives
- MIPS architecture question - Supervisor mode & who is using it?
- 50th Anniversary of invention of disk drives
- REAL memory column in SDSF
- REAL memory column in SDSF
- REAL memory column in SDSF
- REAL memory column in SDSF
- Trying to underdtand 2-factor authentication
- REAL memory column in SDSF
- REAL memory column in SDSF
- Very slow booting and running and brain-dead OS's?
- REAL memory column in SDSF
- REAL memory column in SDSF
- Was FORTRAN buggy?
- Was FORTRAN buggy?
- Trying to design low level hard disk manipulation program
- Mickey and friends
- cold war again
- Seeking info on HP FOCUS (HP 9000 Series 500) and IBM ROMP CPUs from early 80's
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cray-1 Anniversary Event - September 21st
Newsgroups: alt.folklore.computers
Date: Sat, 23 Sep 2006 09:22:16 -0600
Morten Reistad <first@last.name> writes:
This is a welcome development in the "aid industry". They are
so used to public monies where accountability for actual results
is abysmal. This is a field where mr Gates can contribute a lot
just by being his normal self. I wish him all the best.
from thread earlier this year ... reference to similar comment
in a talk by the comptroller general
http://www.garlic.com/~lynn/2006f.html#44 The Pankian Metaphor
other posts mentioning the same talk
http://www.garlic.com/~lynn/2006f.html#41 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#9 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#14 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#27 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#2 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#3 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#4 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#17 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#19 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor
http://www.garlic.com/~lynn/2006o.html#61 Health Care
http://www.garlic.com/~lynn/2006p.html#17 Health Care
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Greatest Software Ever Written?
Newsgroups: alt.folklore.computers
Date: Sat, 23 Sep 2006 10:03:07 -0600
Morten Reistad <first@last.name> writes:
No, not "will have computer chips"; "have had computer chips for a
year or two". They are called RFID tags. They are tags that can be
read at 2-200 ft range (depending on sophistication of equipment).
there is contactless/proximity ... like the wash. dc metro (cubic)
... or the HK octopus card (iso 14443, sony chip, distributed by
mitsubishi, erg). these typically have the transit gate reading the
contents, decrypting the contents (with derived symmetric key),
updating the contents, encrypting the contents, and writing back the
updated encrypted contents.
http://www.smartcardalliance.org/newsletter/september_04/feature_0904.html
these can be purely memory with no on-chip intelligence or processing.
old post mentioning iso 14443 (and other stuff)
http://www.garlic.com/~lynn/2004h.html#30 ECC Encryption
i had a weird experience with a wash dc metro card a couple years ago
... where I had left a metro station with something like (positive)
$10 still on the card ... and the next time I tried to use the card,
the reader claimed there was a negative $5 balance (while outside the
transit system, card had lost $15 and actually $5 negative w/o being
used)
a lot of RFID started out being next generation barcode; just read the
number ... a lot more digits allowing unique chip identification down
to individual item level (rather than just vendor and product) and
being able to inventory w/o having to manually count each individual
item. big driver recently has been walmart mandating them from
suppliers. they would like to get these chips/technology into the
penny range (or even less; along with new & less expensive methods
of producing RFID signal w/o necessarily being traditional chip
fabrication process)
with (pure barcode) RFID technology becoming more prevalent, there is
other applications trying to leverage it.
a post with a lot of news URLs regarding RFID and passports
http://www.garlic.com/~lynn/aadsm25.htm#11 And another cloning tale
one of the objectives for the aads chip strawman was to be able to
do ecdsa processing within transit gate iso 14443 requirements
http://www.garlic.com/~lynn/x959.html#aadsstraw
other references to aads technology and patents
http://www.garlic.com/~lynn/x959.html#aads
some other posts mentioning contactless/proximity
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#28 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#8 smart cards with displays - at last!
http://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address the UK Chip&Pin woes
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Sat, 23 Sep 2006 10:43:30 -0600
Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
I don't think that applies: modern desktop CPUs have all the features
of high end mainframes and some supercomputer features; some
instructions execute in 0.25ns, they support GB memory so need 3 level
cache, Gb/s networking and I/O; hardware multi-threading because they
can't keep the CPUs busy; and multi-CPUs per die because faster clocks
aren't giving enough thruput increase.
the other issue with faster clocks is that latency across the chip is
becoming significant. with multiple CPUs on the same chip ... you can
reduce the distance (and therefor time) that a synchronous signal has
to travel.
also as the chip sizes remained somewhat the same ... while the
circuit sizes shrank ... you also had significantly more circuits per
chip. you could use the additional circuits for multiple cores ... but
you could also use the circuits for on-chip caches. you could have
dedicated on-chip "L1" caches per cpu core ... and shared on-chip "L2"
caches for all cpu cores on the same chip. That means that any
off-chip cache becomes "L3".
the modern out-of-order execution is at least equivalent of anything
that 370/195 (supercomputer) had ... and there is also branch
prediction, speculative execution (down predicted branch path) and
instruction nullification/abrogation (when prediction is wrong)
... which 370/195 didn't have.
the out-of-order execution helps with latency compensation (i.e. when
one instruction is stalled on some fetch operation ... execution of
other instructions may proceed somewhat independently).
multi-threaded operation was also a form of latency compensation
... trying to keep the execution units filled with independent
work/instructions.
370/195 did allow concurrent execution of instructions in the pipeline
... but branches would drain/stall processing. i had gotten involved
in a program to add multi-threading to a 370/195, i.e. dual
instruction stream; registers and instructions in the pipeline having
one bit tag identifying which instruction stream they belong to (but
not otherwise increasing the hardware or executable units). however,
this project never shipped a product.
this was based on the peak thruput of 370/195 was around ten mips ...
but that required careful management of branches ... most codes ran at
five mips (because of the frequent branches that drained the
pipeline). dual i-streams (running at five mips per) had a chance of
keeping the "ten mip" peak executing units busy.
misc. past post mentioning 370/195 dual i-stream effort:
http://www.garlic.com/~lynn/94.html#38 IBM 370/195
http://www.garlic.com/~lynn/99.html#73 The Chronology
http://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die?
http://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001j.html#27 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2001n.html#63 Hyper-Threading Technology - Intel information.
http://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#76 Pipelining in the past
http://www.garlic.com/~lynn/2003l.html#48 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003m.html#60 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
http://www.garlic.com/~lynn/2004.html#27 dual processors: not just for breakfast anymore?
http://www.garlic.com/~lynn/2004e.html#1 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#19 The Soul of Barb's New Machine (was Re: creat)
http://www.garlic.com/~lynn/2005f.html#22 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design
http://www.garlic.com/~lynn/2005p.html#14 Multicores
http://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#29 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#10 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006m.html#51 The System/360 Model 20 Wasn't As Bad As All That
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Trying to design low level hard disk manipulation program
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 23 Sep 2006 13:13:37 -0600
Bill Todd <billtodd@metrocast.net> writes:
Many industrial-strength file systems (including the major Unix
variants, NTFS, VMS's ODS-2/5...) have a level of indirection between
a file's directory entry and the file's data that FAT lacks: the
on-disk inode in Unix, the MFT entry in NTFS, the index file entry in
ODS2/5). Thus at each stage of a path look-up (directory ->
subdirectory > subdirectory... -> file), there's an extra disk access
(unless the inode-like structure happens to be cached) before you can
get to the data at the next level.
MFD from mid-60s cms filesystem ... which had some number of
incremental improvements and then saw the enhanced/extended (EDF)
filesystem in the mid-70s.
the original mid-60s implementation supported sparse files ... so
there were various null pointers for indirect hyperblocks and
datablocks that didn't actually exist.
one of the unofficial early 70s incremental improvements to the cms
filesystem was the directory file block pointer would point directly
at the data block ... instead of an indirect hyperblock ... for file
that had only one data block (for small files, instead of having a
minimum of two blocks, one indirect hyperblock and one data block, it
would just have the single data block). another unofficial early/mid
70s incremental improvements was various kinds of data compression. I
think both of these were originally done by perkin-elmer and made
available on the share waterloo tape. there was some performance
measurement for the p/e compression changes ... that the filesystem
overhead to compress/decompress the data in the file was frequently
more than offset by reduction in cpu overhead reading/writing the
physical blocks to/from disk.
one of the things that the mid-70s EDF extensions brought to the cms
filesystem was multiple logical block size (1k, 2k, & 4k) and more
levels of indirect hyperblocks ... supporting up to five levels of
indirection for large files ... i.e. a 4k filesystem with single
hyperblock supported up to 1024 four byte data block pointers. a two
level hyperblock had the first level pointing to up to 1024
first-level hyperblocks which each then would point to up to 1024 4k
data blocks. As a file grew, the filesystem could transition to higher
levels of hyperblock indirection.
in the early 70s, i had did a page-mapped layer for the original
(cp67) cms filesystem ... and then later upgraded the EDF filesystem
(by that time morphed into vm370) to also support page-mapped layer
construct
http://www.garlic.com/~lynn/subtopic.html#mmap
there is some folklore that various pieces of ibm/pc and os2
filesystem characteristics were taken from cms. note also that both
unix and cms trace some common heritage back to ctss.
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Sun, 24 Sep 2006 10:27:31 -0600
krw <krw@att.bizzzz> writes:
Yeah, right. That must be why IBM's internal network was bigger
than the ARPAnet until '85 or so (queue LynnW).
:)
part of the issue was that the official/strategic communication
product was SNA ... which had effectively large master/slave paradigm
in support of mainframe controlling tens of thousands of (dumb)
terminals (there were jokes about sna not being a system, not being a
network, and not being an architecture).
the internal network was not SNA ...
http://www.garlic.com/~lynn/subnetwork.html#internalnet
misc. recent threads discussing the announcement of the 1000th
node on the internal network
http://www.garlic.com/~lynn/2006e.html#35 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
http://www.garlic.com/~lynn/2006k.html#43 Arpa address
and reference to the approx size of the internet/arpanet in the same
timefame (possibly as low as 100 to possibly a high of 250)
http://www.garlic.com/~lynn/2006k.html#40 Arpa address
in the very early sna days, my wife had co-authored a (competitive)
peer-to-peer architecture (AWP39). she then went on to do a stint in
POK responsible for loosely-coupled architecture (aka mainframe
cluster) where she created peer-coupled shared data architecture
... except for IMS hot-standby, didn't see a lot of uptake until
parallel sysplex
http://www.garlic.com/~lynn/subtopic.html#shareddata
there were some number of battles between the communication group
attempting to enforce the "strategic" communication solution for all
environments (even as things started to move away from the traditional
tens of thousands of dumb terminals controlled by a single mainframe).
san jose research had a eight-way 4341 cluster project using
trotter/3088 (effectively eight channel processor-to-processor switch)
that they wanted to release. in the research version using non-sna
protocol ... to do a full cluster syncronization function took
something under a second elapsed time. they were forced to migrate to
sna (vtam) based implementation which inflated the elapsed time to
over half a minute. recent reference to early days of the project
http://www.garlic.com/~lynn/2006p.html#39 "25th Anniversary of the Personal Computer"
another situation was that terminal emulation contributed to early
heavy uptake of PCs in the business environment. you could get a PC
with dumb terminal emulation AND some local computing capability in a
single desktop footprint and for about the same price as a 327x
terminal that it would replace. later as PC programming became more
sophisticated, there were numerous efforts to significantly improve
the protocol paradigm between the desktop and the glasshouse. however,
all of these bypassed the communication sna infrastructure and
installed terminal controller product base.
http://www.garlic.com/~lynn/subnetwork.html#emulation
the limitations of terminal emulation later contributed heavily to
data from the glasshouse being copied out to local harddisks (either
on local servers or on the desktop itself). this continued leakage was
the basis of some significant infighting between the disk product
group and the communication product group. the disk product group had
come up with a number of products that went a long way to correcting
the terminal emulation limitations ... but the communicaton product
group continually blocked their introduction (claiming that they had
strategic product responsibility for anything that crossed the
boundary between the glasshouse and the external world).
at one point (in the late 80s) a senior person from the disk product
group got a talk accepted at the communication product group's
worldwide, annual internal conference. his opening deviated from what
was listed for the talk by starting out stating that the head of the
communication product group was going to be responsible for the demise
of the (mainframe) disk product group. somewhat unrelated topic drift,
misc. collected posts mentioning work with blg14 (disk engineering)
and blg15 (disk product test)
http://www.garlic.com/~lynn/subtopic.html#disk
we were also doing high-speed data transport project (starting
in the early 80s)
http://www.garlic.com/~lynn/subnetwork.html#hsdt
a recent posting somewhat contrasting hsdt and sna
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
the late 80s was also in the period were we had started pitching
3-tier to customer executives.
http://www.garlic.com/~lynn/subnetwork.html#3tier
we had sort of melded work that had been going on for 2-tier
mainframe/PC and for 2-tier glasshouse/departmental computing (4341).
a few recent postings
http://www.garlic.com/~lynn/2006p.html#34 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#35 Metroliner telephone article
http://www.garlic.com/~lynn/2006p.html#36 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#39 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#40 "25th Anniversary of the Personal Computer"
however, this was also during the period that the communication
product group was attempting to stem the tide away from terminal
emulation with SAA (and we would take some amount of heat from the SAA
forces).
part of our 3-tier effort we then forked off into ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp
and oft repeated specific posting
http://www.garlic.com/~lynn/95.html#13
for other drift ... a side effort for hsdt in the mid-80s ... was
attempting to take some technology that had originally been developed
at one of the baby bells and ship it as an official product. this had
a lot of SNA emulation stuff at boundaries talking to mainframes. SNA
had evolved something called cross-domain ... where a mainframe that
didn't directly control a specific terminal ... still could interact
with a terminal ("owned" by some other mainframe). the technology
would tell all the boundary mainframes that (all) the terminals were
owned some other mainframe. In actuallity, the internal infrastructure
implemented a highly redundant peer-to-peer infrastructure ... and
then just regressed to SNA emulation talking to boundary mainframes.
http://www.garlic.com/~lynn/99.html#66 System/1 ?
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Sun, 24 Sep 2006 11:11:00 -0600
Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
IBM VM systems never had problems talking to each other, other IBM
systems, the ARPAnet, or Internet. AFAIK DEC systems only supported
RJE not NJE, and unlikely ever supported NJE over SNA. NJE was the
JES-JES (JES2/HASP, JES3/ASP) internode protocol for file transfer
which could cause system crashes if either end was improperly
configured.
re:
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
it was worse than that ... NJE grew up out of HASP networking, some
amount of it had been done at TUCC. HASP had a one byte index for
table of 255 psuedo (spooled) devices that it implemented local
spooling. the original networking support scavenged unused entries
from that table to define networking nodes. a typical HASP node might
have 60-80 psuedo devices defined ... leaving a maximum of 170-190
entries for defining networking nodes. hasp/jes also would trash any
traffic where either the originating node or the destination node
wasn't defined in the local table. the internal network fairly quickly
exceeded 255 nodes
http://www.garlic.com/~lynn/subnetwork.html#internalnet
limiting hasp/jes to anything other than a boundary node (pretty
useless as an intermediate node that would trash some percent of
traffic flowing through). at some point, NJE increased maximum network
size to 999 ... but that was after the internal network was over 1000
nodes (again creating network operational problems if JES was used for
other than purely boundary nodes).
the other problem was that NJE protocol confused the header fields
... intermingling networking stuff with purely local stuff. not only
would misconfigured hasp/jes systems crash other hasp/jes systems
... but it was possible for two different systems (properly
configured) at slightly different release levels (with slightly
different header formats) to crash each other. there was an infamous
scenario where a system in san jose was causing systems in hursley to
crash.
as a result, there was a body of technology that grew up in VM
networking nodes for simulating NJE. there were a whole library of NJE
drivers for various versions and releases of hasp/jes. A VM simulated
NJE driver would be started for the specific boundary hasp/JES that it
was talking to.
incoming traffic from a boundary NJE node would be taken and
effectively translated into a generalized connonical format. outgoing
traffic to boundary NJE node would have header formated for the
specific hasp/jes release/version. all of this was countermeasure to
keep the wide variety of different hasp/jes systems around the world
from crashing each other.
misc. other hasp/jes related posts
http://www.garlic.com/~lynn/subtopic.html#hasp
another characteristic was that the native VM drivers tended to have
much higher thruput and efficiency than the NJE protocol. however, at
some point (possibly for strategic corporate compatibility purposes)
they stopped shipping the native VM drivers ... and only shipped NJE
drivers for VM networking.
at some point I believe that bitnet/earn network was also larger than
arpanet/internet
http://www.garlic.com/~lynn/subnetwork.html#bitnet
bitnet was US educational network using the vm networking technology
(however, as mentioned, eventually only NJE drivers were shipping in
the vm product). while the internal network and bitnet used similar
technologies ... the sizes of the respective networks were totally
independent.
earn was the european flavor of bitnet. for some drift, old post
mentioning founding/running earn
http://www.garlic.com/~lynn/2001h.html#65 UUCP email
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Sun, 24 Sep 2006 11:28:42 -0600
re:
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#5 Was FORTRAN buggy?
as mentioned before, we put up a HSDT high-speed backbone
http://www.garlic.com/~lynn/subnetwork.html#hsdt
and i had done mainframe tcp/ip drivers supporting RFC1044.
http://www.garlic.com/~lynn/subnetwork.html#1044
at the time, the standard mainframe tcp/ip driver supported about
44kbytes/sec aggregate thruput using burning approx. a full 3090
processor. in some rfc 1044 tuning testing at cray research, was
seeing 1mbyte/sec sustained thrutput between a cray and a 4341-clone
... using only a modest amount the 4341-clone process (nearly two
order magnitude improvement in bytes per cpu second).
also for the original NSFNET backbone RFP (effectively the operational
networking precusor to the modern internet), we weren't allowed to
bid. However, my wife went to the director of NSF and got a technical
audit of what we were running. one of the conclusions was effectively
that what we already had running was at least five years ahead of all
bid submissions (to build something new).
random past reference
http://www.garlic.com/~lynn/internet.htm#0
reference to the nsfnet backbone rfp
http://www.garlic.com/~lynn/internet.htm#nsfnet
copy of NSFNET backbone RFP announcement
http://www.garlic.com/~lynn/2002k.html#12
reference to award announcement
http://www.garlic.com/~lynn/2000e.html#10
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Sun, 24 Sep 2006 14:31:09 -0600
vjp2.at writes:
I didn't see networked IBM big iron before the late 80s.
I saw DEC ethernet/telnet as early as 79.
If someone sent me a tape, I sent it back and told them
to send me punched cards. Tapes were never compatible.
There was always something different about each one.
We had a hard enough time moving stuff between VM
and Wylbur on the same IBM mainframe.
Then again the control freaky DP dudes would ban full screen
editors on production machines because they slowed them down.
re:
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#5 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#6 Was FORTRAN buggy?
recent post
http://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"
with respect to the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
repeat from the recent post:
one of the rex historical references:
http://www.computinghistorymuseum.org/ieee/af_forum/read.cfm?forum=10&id=21&thread=7
from above:
By far the most important influence on the development of Rexx was the
availability of the IBM electronic network, called VNET. In 1979, more
than three hundred of IBM's mainframe computers, mostly running the
Virtual Machine/370 (VM) operating system, were linked by VNET. This
store-and-forward network allowed very rapid exchange of messages
(chat) and e-mail, and reliable distribution of software. It made it
possible to design, develop, and distribute Rexx and its first
implementation from one country (the UK) even though most of its users
were five to eight time zones distant, in the USA.
... snip ...
and from earlier post:
http://www.garlic.com/~lynn/2006k.html#40 Arpa address
repeat from the above post ... in mid-1980, arpanet was hoping to have
100 nodes by 1983 (the year that the internal network hit the
1000th node mark):
ARPANET newsletter
ftp://ftp.rfc-editor.org/in-notes/museum/ARPANET_News.mail
from above:
NEWS-1 DCA Code 531
1 July 1980 (DCACODE535@ISI)
(202) 692-6175
ARPANET NEWSLETTER
---------------------------------------------------------------------
Over the past eleven years, the ARPANET has grown considerably and has
become the major U. S. Government research and development
communications network. The ARPANET liaisons have made significant
contributions to the network's success. Your efforts are voluntary,
but are critical to successful operation of each Host, IMP, and TIP.
Your continued support of the ARPANET is greatly appreciated and will
facilitate continued smooth ARPANET operation.
To aid you in performance of your duties, DCA will attempt to provide
you with the latest information in network improvements. This
information is grouped into two major areas: management and technical
improvements. However, a brief discussion of where we are going with
the ARPANET is in order.
The ARPANET is still a rapidly growing network. It provides a service
which is both cost and operationally effective. We predict the
ARPANET will grow to approximately 100 nodes by 1983, when we
will begin transferring some of the subscribers to DOD's AUTODIN II
network.
... snip ...
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: should program call stack grow upward or downwards?
Newsgroups: comp.arch,comp.lang.c,alt.folklore.computers
Date: Sun, 24 Sep 2006 15:24:41 -0600
gordonb.6hiy2@burditt.org (Gordon Burditt) writes:
OS/360 used a linked list of "save areas" containing saved registers,
return addresses, and if desired, local variables. (Now, granted,
when I was working with it, C didn't exist yet, or at least it
wasn't available outside Bell Labs.) Reentrant functions (required
in C unless the compiler could prove it wasn't necessary) would
allocate a new save area with GETMAIN and free it with FREEMAIN.
Non-reentrant functions would allocate a single static save area.
minor note ... the savearea allocation was the responsibility of
the calling program ... but the saving of registers were the
responsibility of the called program ... i.e. on program entry,
the instruction sequence was typically:
STM 14,12,12(13)
i.e. "store multiple" registers 14,15,0,...,12 ... starting at
(decimal) 12 offset from location pointed to by register 13.
for more detailed discussion ... i've done a q&d conversion of the old
ios3270 green card to html ... and more detailed discussion of
call/save/return conventions can be found at:
http://www.garlic.com/~lynn/gcard.html#50
the called program only needed a new save area if it would, in turn
call some other program. non-reentrant programs (that called other
programs) could allocate a single static savearea. only when you had
reentrant programs that also called other programs ... was there an
issue regarding dynamic save area allocations.
the original cp67 kernel had a convention that was somewhat more like
a stack. it had a contiguous subpool of 100 save areas. all module
call/return linkages were via supervisor call. it was the
responsibility of the supervisor call routine to allocate/deallocate
savearea for the call.
an aside, cp67 and unix can trace somewhat common heritage back to
ctss, i.e. cp67 work was done at the science center on the 4th flr
of 545 tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech
including some people that had worked on ctss. multics was on the 5th
flr of 545 tech sq ... and also included some people that had worked
on ctss.
as i was doing various performance and scale-up work on cp67 ... i
made a number of changes to the cp67 calling conventions.
for some number of high-use non-reentrant routines (that didn't call
any other routines), i changed the calling sequence from supervisor
call to simple "branch and link register" ... and then used a static
area for saving registers. for some number of high-use common library
routines ... the supervisor call linkage scenario had higher
pathlength that the function called ... so the switch to BALR call
convention for these routings significantly improved performance.
the other problem found with increasing load ... was that it became
more and more frequent that the system would exhaust the pool of 100
kernel save areas (which caused it to abort). i redid the logic so that it
could dynamically increase and decrease the pool of save areas
... significantly reducing system failures under heavy load.
there was subsequent generalized subpool enhancement for cp67 kernel
dynamic storage management ... which also significantly contributed to
descreasing kernel overhead.
article from that work
Analysis of Free-storage Algorithms, B. Margolin, et all, IBM Systems
Journal v10n4, 283-304, 1971
and from the citation site:
http://citeseer.ist.psu.edu/context/418230/0
misc. past postings mentioning cp67 kernel generalized subpool work:
http://www.garlic.com/~lynn/93.html#26 MTS & LLMPS?
http://www.garlic.com/~lynn/98.html#19 S/360 operating systems geneaology
http://www.garlic.com/~lynn/2000d.html#47 Charging for time-share CPU time
http://www.garlic.com/~lynn/2002.html#14 index searching
http://www.garlic.com/~lynn/2002h.html#87 Atomic operations redux
http://www.garlic.com/~lynn/2004g.html#57 Adventure game (was:PL/? History (was Hercules))
http://www.garlic.com/~lynn/2004h.html#0 Adventure game (was:PL/? History (was Hercules))
http://www.garlic.com/~lynn/2004m.html#22 Lock-free algorithms
http://www.garlic.com/~lynn/2006e.html#40 transputers again was: The demise of Commodore
http://www.garlic.com/~lynn/2006j.html#21 virtual memory
http://www.garlic.com/~lynn/2006p.html#11 What part of z/OS is the OS?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Sun, 24 Sep 2006 17:11:08 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
part of the issue was that the official/strategic communication
product was SNA ... which had effectively large master/slave
paradigm in support of mainframe controlling tens of thousands of
(dumb) terminals (there were jokes about sna not being a system, not
being a network, and not being an architecture).
re:
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
oh and some of the dumb terminals weren't necessarily so dumb
... there were also things like huge numbers of ATM (automatic teller,
aka cash) machines
for other drift ... recent post mentioning early work at los gatos lab
on cash machines
http://www.garlic.com/~lynn/2006q.html#5 Materiel and graft
for sna dumb terminal drift
http://www.enterasys.com/solutions/success/commercial/unitedairlines.pdf
from above:
The original United network environment consisted of approximately
20,000 dumb terminals connected to three separate networks: an
SNA-based network connecting into IBM mainframes for business
applications; a Unisys-based network whose processors did all of the
operational types of programs for the airline such as crew and flight
schedules and aircraft weights and balance; and the Apollo network,
which connected users to the airline's reservation system for all
passenger information, seat assignments, etc. That meant that for
every airport that United flew into, it had to have three separate
telephone circuits--one for each network. According to Ken Cieszynski,
United's senior engineer in Networking Services, it was a very costly,
cumbersome and labor-intensive system for operating and maintaining a
business.
... snip ...
my wife was in conflict with the SNA group from early on ... having
co-authored (competitive) AWP39 peer-to-peer networking architecture
during the early days of SNA, did battle with them when she was
in POK responsible for loosely-coupled (cluster mainframe) architecture,
http://www.garlic.com/~lynn/subtopic.html#shareddata
and then later when we were out pushing 3-tier architecture
http://www.garlic.com/~lynn/subnetwork.html#3tier
along the way she also did a short stint as chief architect for
amadeus ... where she got into trouble backing x.25 based network
design as an alternate to SNA based network implementation.
misc. past post mentioning amadeus
http://www.garlic.com/~lynn/2001g.html#49 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#50 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2003d.html#67 unix
http://www.garlic.com/~lynn/2003n.html#47 What makes a mainframe a mainframe?
http://www.garlic.com/~lynn/2004b.html#6 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004b.html#7 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004m.html#27 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#23 Demo: Things in Hierarchies (w/o RM/SQL)
http://www.garlic.com/~lynn/2004o.html#29 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005f.html#22 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back
http://www.garlic.com/~lynn/2006o.html#4 How Many 360/195s and 370/195s were shipped?
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Sun, 24 Sep 2006 18:35:20 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
for sna dumb terminal drift
http://www.enterasys.com/solutions/success/commercial/unitedairlines.pdf
from above:
The original United network environment consisted of approximately
20,000 dumb terminals connected to three separate networks: an
SNA-based network connecting into IBM mainframes for business
applications; a Unisys-based network whose processors did all of the
operational types of programs for the airline such as crew and flight
schedules and aircraft weights and balance; and the Apollo network,
which connected users to the airline's reservation system for all
passenger information, seat assignments, etc. That meant that for
every airport that United flew into, it had to have three separate
telephone circuits--one for each network. According to Ken Cieszynski,
United's senior engineer in Networking Services, it was a very costly,
cumbersome and labor-intensive system for operating and maintaining a
business.
... snip ...
and of course apollo system was also ibm mainframe ... acp (airline
control program) that morphed into TPF (transaction processing system)
a few references
http://www.blackbeard.com/tpf/tpfscoop.htm
http://en.wikipedia.org/wiki/Computer_reservations_system
http://www.eastmangroup.com/otwc/otwc~jun2006.html
http://www.prnewswire.com/cgi-bin/micro_stories.pl?ACCT=121034&TICK=GAL&STORY=/www/story/04-04-2000/0001181634&EDATE=Apr+4,+2000
http://www.answers.com/topic/sabre-computer-system
http://www.everything2.com/index.pl?node=GRS
http://www.cwhonors.org/laureates/Business/20055186.pdf
http://www.intervistas.com/4/presentations/orbitzfinalbook1.pdf
and
http://www.computerworld.com/managementtopics/outsourcing/story/0,10801,63472,00.html
from above:
IBM helped build the transaction processing facility (TPF) for
American Airlines Inc. in the late 1950s and early 1960s that would
become the Sabre global distribution system (GDS). IBM built a similar
TPF system for Chicago-based United Air Lines Inc. That system later
became the Apollo GDS.
... snip ...
galileo/apollo history
http://www.galileo.com/galileo/en-gb/about/History/
for other drift about airline systems
http://www.garlic.com/~lynn/2006j.html#6 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#7 Impossible Database Design?
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006n.html#16 On the 370/165 and the 360/85
http://www.garlic.com/~lynn/2006o.html#4 How Many 360/195s and 370/195s were shipped?
http://www.garlic.com/~lynn/2006o.html#18 RAMAC 305(?)
http://www.garlic.com/~lynn/2006q.html#22 3 value logic. Why is SQL so special?
http://www.garlic.com/~lynn/2006q.html#23 3 value logic. Why is SQL so special?
http://www.garlic.com/~lynn/2006q.html#29 3 value logic. Why is SQL so special?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Mon, 25 Sep 2006 09:25:18 -0600
KR Williams <krw@att.bizzzz> writes:
You were blind. We were "widebanding" tape images for ICs and
circuit cards by the time I got there in the mid '70s. They were
called RITs (Release Interface Tapes), though they never existed as
mag tapes. Lynn talked about VNET before that. By the early '80s
conferencing (similar function as the USENET) appeared. The IBMPC
conferencing disk opened in '81, IIRC.
one of the uses of hsdt high-speed backbone
http://www.garlic.com/~lynn/subnetwork.html#hsdt
was shipping chip design off to LSM (losgatos state machine or the
logic simulation machine for publication, san jose bldg. 29) and EVE
(endicott validation engine, there was one in san jose bldg. 86, disk
engineering had been moved to offsite location while bldg. 14 was
getting its seismic retrofit) for logic verification. there was claim that
this helped contribute to bringing in the RIOS chipset (power) a year
early.
i got blamed for some of that early conferencing ... doing a lot of
the stuff semi-automated. there was even an article in datamation.
there were then some number of internal corporate task forces to
investigate the phenomena. hiltz and turoff (network nation,
addison-wesley, 1978) were brought in as consultants for at least one
of the task force investigations. then a consultant was paid to sit in
the back of my office for nine months, taking notes on how i
communicated ... also had access to all my incoming and outgoing email
as well as logs of all my instant messaging activity. besides an
internal research report, (with some sanitizing) it also turned into a
stanford phd thesis (joint between language and computer ai) ... some
number of past posts mentioning computer mediated conversation (and/or
the stanford phd thesis on how i communicate)
http://www.garlic.com/~lynn/subnetwork.html#cmc
the ibmvm conferencing "disk" opened first ... followed by the ibmpc
conferencing "disk". the facility (TOOLSRUN) was somewhat cross
between usenet and listserv (recipient could specify configuration
that worked either way). you could specify recipient options that
worked like listserv. however, you could also install a copy of
TOOLSRUN on your local machine ... and setup an environment that
operated more like usenet (with local respository).
this discussions somewhat mirrored the (purely) online conferencing
that tymshare was providing to the IBM SHARE user group organization
with online vmshare (and later) pcshare (typical access via tymshare's
tymnet). ... misc. posts about (vm based) commercial timesharing
services (including tymshare)
http://www.garlic.com/~lynn/subtopic.html#timeshare
vmshare archive:
http://vm.marist.edu/~vmshare/
misc. past references to "tandem memos" (the referenced early computer
conferencing incident)
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
http://www.garlic.com/~lynn/2002k.html#39 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002o.html#73 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2002q.html#16 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2002q.html#38 ibm time machine in new york times?
http://www.garlic.com/~lynn/2004k.html#66 Question About VM List
http://www.garlic.com/~lynn/2005c.html#50 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#37 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005q.html#5 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006h.html#9 It's official: "nuke" infected Windows PCs instead of fixing them
http://www.garlic.com/~lynn/2006l.html#24 Google Architecture
http://www.garlic.com/~lynn/2006l.html#51 the new math: old battle of the sexes was: PDP-1
...
misc. past posts mentioning "TOOLSRUN":
http://www.garlic.com/~lynn/2001c.html#5 what makes a cpu fast
http://www.garlic.com/~lynn/2002d.html#33 LISTSERV(r) on mainframes
http://www.garlic.com/~lynn/2003i.html#18 MVS 3.8
http://www.garlic.com/~lynn/2004o.html#48 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005q.html#5 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005r.html#22 z/VM Listserv?
http://www.garlic.com/~lynn/2006h.html#9 It's official: "nuke" infected Windows PCs instead of fixing them
...
misc. past posts mentioning LSM, EVE (and/or YSE)
http://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2003.html#31 asynchronous CPUs
http://www.garlic.com/~lynn/2003k.html#3 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003o.html#38 When nerds were nerds
http://www.garlic.com/~lynn/2004j.html#16 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#65 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#33 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005q.html#17 Ethernet, Aloha and CSMA/CD -
http://www.garlic.com/~lynn/2006.html#29 IBM microwave application--early data communications
http://www.garlic.com/~lynn/2006q.html#42 Was FORTRAN buggy?
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Trying to design low level hard disk manipulation program
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 25 Sep 2006 09:52:55 -0600
Bill Todd <billtodd@metrocast.net> writes:
But it is indeed a gray area as soon as one introduces the idea of a
CopyFile() operation (that clearly needs to include network copying
to be of general use). The recent introduction of 'bundles'
('files' that are actually more like directories in terms of
containing a hierarchical multitude of parts - considerably richer
IIRC than IBM's old 'partitioned data sets') as a means of handling
multi-'fork' and/or attribute-enriched files in a manner that simple
file systems can at least store (though applications then need to
understand that form of storage to handle it effectively) may be
applicable here.
re:
http://www.garlic.com/~lynn/2006r.html#3 Trying to design low level hard disk manipulation program
we had somewhat stumbled across file bundles (based on use, not
necessarily any filesystem structure organization) in the work that
started out doing traces of all record accesses for i/o cache
simulation (circa 1980).
the strict cache simulation work showed that partitioned caches (aka
"local LRU") was always lower performance than global cache (aka
global LRU). for a fixed amount of electronic storage, a single
global system i/o cache always had better thruput than partitioning
the same amount of electronic storage between i/o channels, disk
controllers, and/or individual disks (modulo a track cache for
rotational delay compensation).
further work on the full record access traces started to show up some
amount of repeated patterns that tended to access the same collection
of files. for this collection of data access patterns, rather than
disk arm motion with various kinds of distribution ... there was very
strong bursty locality. this led down the path of maintaining more
detailed information about files and their useage for optimizing
thruput (and layout).
earlier at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
we had done detailed page reference traces and cluster analysis in
support of semi-automated program reorganization ... which was
eventually released as VS/REPACK product. the disk record i/o traces
started down the path of doing something similar for filesystem
organization/optimization.
i had done a backup/archive system that was used internally at a
number of locations. this eventually morphed into product called
workstation datasave facility and then adsm. it was later renamed tsm
(tivoli storage manager). this now supports bundles/containers for
file storage management (i.e. collections of files that tend to have
bursty locality of reference patterns)
http://www.garlic.com/~lynn/subtopic.html#backup
some number of other backup/archive and/or (hierarchical) storage
management systems now also have similar constructs.
some recent posts that mention that i/o cache simulation work
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#0 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#18 how much swap size did you take?
http://www.garlic.com/~lynn/2006i.html#36 virtual memory
http://www.garlic.com/~lynn/2006i.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#7 virtual memory
http://www.garlic.com/~lynn/2006j.html#14 virtual memory
http://www.garlic.com/~lynn/2006j.html#27 virtual memory
http://www.garlic.com/~lynn/2006l.html#43 One or two CPUs - the pros & cons
http://www.garlic.com/~lynn/2006o.html#27 oops
http://www.garlic.com/~lynn/2006o.html#68 DASD Response Time (on antique 3390?)
http://www.garlic.com/~lynn/2006p.html#0 DASD Response Time (on antique 3390?)
some recent posts mentioning vs/repack activity
http://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Re: Expanded Storage
http://www.garlic.com/~lynn/2006b.html#23 Seeking Info on XDS Sigma 7 APL
http://www.garlic.com/~lynn/2006e.html#20 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006i.html#37 virtual memory
http://www.garlic.com/~lynn/2006j.html#18 virtual memory
http://www.garlic.com/~lynn/2006j.html#22 virtual memory
http://www.garlic.com/~lynn/2006j.html#24 virtual memory
http://www.garlic.com/~lynn/2006l.html#11 virtual memory
http://www.garlic.com/~lynn/2006o.html#23 Strobe equivalents
http://www.garlic.com/~lynn/2006o.html#26 Cache-Size vs Performance
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Mon, 25 Sep 2006 10:44:35 -0600
vjp2.at writes:
Maybe the problem was the pretentious creeps got drawn to being
"safe" (F.U.D.) on IBM while the innovators were all on DEC.
i've commented before that there were more 4341s sold than vax'es into
the same mid-range market segment (besides the large numbers deployed
internally). there were numerous cases of customer orders in hundreds
at a time for departmental computing type operations. posting giving
example:
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
the mid-range then got hit in the mid-80s as that market segment
started moving to workstations and larger PCs for servers and
departmental computing.
to some extent popular press seemed to focus on the high-end mainframe
iron doing commercial batch operations compared to some of the other
vendors offerings in the mid-range market segment (even tho boxes like
4341 and 4331 were also extremely popular in that midrange market in
the late 70s and early 80s).
a few old posts given domestic and world-wide vax shipments:
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction
http://www.garlic.com/~lynn/2006k.html#31 PDP-1
various recent posts mentioning 2-tier/3-tier evoluation in the
mid-range market segment.
http://www.garlic.com/~lynn/2006.html#16 Would multi-core replace SMPs?
http://www.garlic.com/~lynn/2006c.html#11 Mainframe Jobs Going Away
http://www.garlic.com/~lynn/2006c.html#26 Change in computers as a hobbiest
http://www.garlic.com/~lynn/2006i.html#21 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006j.html#31 virtual memory
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
http://www.garlic.com/~lynn/2006k.html#25 Can anythink kill x86-64?
http://www.garlic.com/~lynn/2006k.html#42 Arpa address
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006l.html#7 Google Architecture
http://www.garlic.com/~lynn/2006l.html#35 Token-ring vs Ethernet - 10 years later
http://www.garlic.com/~lynn/2006l.html#38 Token-ring vs Ethernet - 10 years later
http://www.garlic.com/~lynn/2006o.html#62 Greatest Software, System R
http://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#34 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#35 Metroliner telephone article
http://www.garlic.com/~lynn/2006p.html#36 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#39 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#40 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006q.html#4 Another BIG Mainframe Bites the Dust
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#9 Was FORTRAN buggy?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 50th Anniversary of invention of disk drives
Newsgroups: alt.folklore.computers
Date: Mon, 25 Sep 2006 11:11:12 -0600
hancock4 writes:
IBM announced the first disk drive 50 years ago. Modern computing
would not exist without the economical random access memory afforded by
the disk drive. Could you imagine loading a separate cassette tape
every time you wanted to run a program or access a file? All on-line
processing wouldn't exist since there'd be no way to locate and store
information in real time.
Apparently this anniversary is a yawner. The 40th Anniv of S/360 got
attention.
note that the san jose plant site, where all of this was done ... now
belongs to hitachi. there used to be all sorts of stuff on various ibm
san jose web sites about early activity ... but a lot of that seemed
to go missing when the location changed hands.
can you imagine holding big festivities on the plant site that no
longer belongs to you.
misc. posts mentioning san jose plant site is now hitachi
http://www.garlic.com/~lynn/2003d.html#9 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003i.html#25 TGV in the USA?
http://www.garlic.com/~lynn/2003n.html#39 DASD history
http://www.garlic.com/~lynn/2004e.html#12 Pre-relational, post-relational, 1968 CODASYL "Survey of Data Base Systems"
http://www.garlic.com/~lynn/2006.html#21 IBM up for grabs?
http://www.garlic.com/~lynn/2006o.html#18 RAMAC 305(?)
not 50 years ago ... but some amount of postings related to activity
on the plant site 25-30 years ago
http://www.garlic.com/~lynn/subtopic.html#disk
during the early 80s there was some amount of friendly competition
between san jose storage business and the pok large mainframe business
on which location was contributing the most to the bottom line (which
had traditional been pok, but there was a period where they were neck
& neck ... and even quarters were san jose passed pok).
a lot of that has since all gone by the wayside ... recent post
mentioning a couple of the issues
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 50th Anniversary of invention of disk drives
Newsgroups: alt.folklore.computers
Date: Mon, 25 Sep 2006 16:52:31 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
note that the san jose plant site, where all of this was done ... now
belongs to hitachi. there used to be all sorts of stuff on various ibm
san jose web sites about early activity ... but a lot of that seemed
to go missing when the location changed hands.
can you imagine holding big festivities on the plant site that no
longer belongs to you.
re:
http://www.garlic.com/~lynn/2006r.html#14 50th Anniversary of invention of disk drives
you might find the marketing department from a line of business
possibly taking small part of their budget ... say several million to
drop on gala and press releases ... but since the original line of
business is sold off to somebody else ... it is hard to imagine who is
likely to drop even a couple million on such an activity.
how many remember the "last great dataprocessing IT party" (article in
usatoday)? ... ibm had taken the san jose coliseum ... brought in
jefferson starship and all sorts of other stuff (gala for the rsa
show). between the time the contracting/funding for the event and the
actual event ... the responsible executive got totally different
responsibilities ... but they allowed him to play the greeter (all
dressed up in a tux) at the front door as you went in.
this has copy (scroll to the right quite a bit, pass the 2002 program,
to the "RSA Conference 2000 IBM Gala Program") of the program for that
gala event (if i still have mine someplace, maybe i can scan it)
http://www.joemonica.com/pages/print.html
http://web.archive.org/web/20070206152557/http://www.joemonica.com/pages/print.html
somebody's trip report
http://seclists.org/politech/2000/Jan/0058.html
IBM's gala at rsa '99 wasn't even remotely as extravagant (and only
$250k) ... somebody's pictures:
http://pix.paip.net/Party/IBM99/
not sure who's budget you could get to drop even a measly $250k on
50th disk anniversary.
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Mon, 25 Sep 2006 18:27:58 -0600
William Hamblen <william.hamblen@earthlink.net> writes:
Banks that issued 30 year mortgages had to think about Y2K 36 years
ago.
in the last half of the last century (as computerized dataprocessing
proliferated), there were still quite a few people that had been born
before 1900.
reference to a old "y2k" like problems somebody posted from the early 80s
http://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese Solve Y2K)
http://www.garlic.com/~lynn/99.html#233 Computer of the century
http://www.garlic.com/~lynn/2000.html#0 2000 = millennium?
http://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...
repeat of somebody's email
Date: 7 December 1984, 14:35:02 CST
1.In 1969, Continental Airlines was the first (insisted on being the
first) customer to install PARS. Rushed things a bit, or so I hear. On
February 29, 1972, ALL of the PARS systems cancelled certain
reservations automatically, but unintentionally. There were (and still
are) creatures called "coverage programmers" who deal with such
situations.
2.A bit of "cute" code I saw once operated on a year by loading a
byte of packed data into a register (using INSERT CHAR), then used LA
R,1(R) to bump the year. Got into a bit of trouble when the year 196A
followed 1969. I guess the problem is not everyone is aware of the odd
math in calendars. People even set up new religions when they discover
new calendars (sometimes).
3.We have an interesting calendar problem in Houston. The Shuttle
Orbiter carries a box called an MTU (Master Timing Unit). The MTU gives
yyyyddd for the date. That's ok, but it runs out to ddd=400 before it
rolls over. Mainly to keep the ongoing orbit calculations smooth. Our
simulator (hardware part) handles a date out to ddd=999. Our simulator
(software part) handles a date out to ddd=399. What we need to do, I
guess, is not ever have any 5-week long missions that start on New
Year's Eve. I wrote a requirements change once to try to straighten
this out, but chickened out when I started getting odd looks and
snickers (and enormous cost estimates).
... snip ... top of post, old email index
this was computer conferencing supported with TOOLSRUN technology
mentioned in recent post
http://www.garlic.com/~lynn/2006r.html#11 Was FORTRAN buggy?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Greatest Software Ever Written?
Newsgroups: alt.folklore.computers
Date: Mon, 25 Sep 2006 20:48:07 -0600
re:
http://www.garlic.com/~lynn/2006r.html#1 Greatest Software Ever Written?
recent eletronic product code (EPC) news item ... aka next
generation product barcodes ...
Pfizer to Use RFID to Combat Fake Viagra
http://www.technewsworld.com/story/53218.html
from above ...
Pfizer claims it is the first pharmaceutical company with a program of
this type, focused on EPC authentication as a means of deterring
counterfeiting. However, Wal-Mart now requires its top 300 suppliers
to tag cases and pallets of select goods, and over 24 drug providers
tag bulk containers of Schedule II drugs, prescription painkillers and
drugs of abuse.
... snip ...
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 50th Anniversary of invention of disk drives
Newsgroups: alt.folklore.computers
Date: Mon, 25 Sep 2006 21:37:08 -0600
et472@FreeNet.Carleton.CA (Michael Black) writes:
Or, the hard drive would be invented, but later. I'm less certain
that would have impacted things that much. I got by without a hard
drive until the end of 1993, so while a hard drive likely made things
easier before that, they could be lived without.
you are thinking about your personal use ... but it wasn't originally
invented for personal use ... but for large dataprocessing commercial
operations. all the real-time, online transaction stuff starting in
the 60s were built on hard drives, electronic point-of-sale credit
cards, atm machines, online airline reservation systems, etc, ... the
lack of hard drive would have had enormous impact on large number of
online/realtime things that people were starting to take for granted.
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Greatest Software Ever Written?
Newsgroups: alt.folklore.computers
Date: Mon, 25 Sep 2006 23:21:46 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
one of the objectives for the aads chip strawman was to be able to
do ecdsa processing within transit gate iso 14443 requirements
http://www.garlic.com/~lynn/x959.html#aadsstraw
re:
http://www.garlic.com/~lynn/2006r.html#1 Greatest Software Ever Written?
even more drift ... another recent news item
Identity's biggest guns form Secure ID Coalition to lobby for smart
cards
http://www.secureidnews.com/library/2006/09/25/identitys-biggest-guns-form-secure-id-coalition-to-lobby-for-smart-cards/
some recent related comments
http://www.garlic.com/~lynn/aadsm25.htm#30 On-card displays
and another related recent news item:
The touching story of NFC
http://www.techworld.com/mobility/features/index.cfm?featureID=2828&pagtype=all
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 50th Anniversary of invention of disk drives
Newsgroups: alt.folklore.computers
Date: Tue, 26 Sep 2006 12:32:07 -0600
scott@slp53.sl.home (Scott Lurndal) writes:
Most of the San Jose plant buildings have been torn down or are being
torn down as we speak to make room for 3000 homes and various shopping
and big-box stores. Replacing office and manufacturing space with
homes is pretty damn stupid when the office/manufacturing space is
in a counter-commute area. Those 3000 homes are really going to help
traffic suck on 85, 87 and 101.
... a couple posts from earlier this year about san jose plant site,
hitachi, etc
http://www.garlic.com/~lynn/2006.html#21 IBM up for grabs?
http://www.garlic.com/~lynn/2006.html#22 IBM up for grabs?
above has references to several pages at
http://www.ajnordley.com/
with pictures of the site from the air
http://www.ajnordley.com/IBM/Air/SSD/index.html
also as per the earlier posts, bldg. 50 was part of the massive
manufacturing facility build-out done in the mid to late 80s ... part
of armonk's prediction that world-wide business was going to double
(from $60b/annum to $120b/annum). also as mentioned in the previous
posts, it probably was a career limiting move to take the opposite
position from corporate hdqtrs (that at least the hardware business
wasn't going to be doubling).
past posts mentioning conjecture/comments in the 80s about the
possible demise of mainframe disk business
http://www.garlic.com/~lynn/2003p.html#39 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006k.html#25 Can anythink kill x86-64?
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006l.html#38 Token-ring vs Ethernet - 10 years later
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
earlier posts in this thread:
http://www.garlic.com/~lynn/2006r.html#14 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#15 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#18 50th Anniversary of invention of disk drives
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 50th Anniversary of invention of disk drives
Newsgroups: alt.folklore.computers
Date: Wed, 27 Sep 2006 09:28:30 -0600
hancock4 writes:
I thought there were several "sites" in San Jose. That is, wasn't the
earliest disk work done in a former supermarket building? The actual
nice complex came later?
re:
http://www.garlic.com/~lynn/2006r.html#14 50th Anniversary of invention of disk drives
comment was specifically ... san jose "plant site" ... disk division
where they actually had manufacturing line ... recent reference to
plant site "new" manufacturing bldg. 50 ... also to site with photos
of the plant site from the air
http://www.garlic.com/~lynn/2006r.html#20 50th Anniversary of invention of disk drives
the earlier references in the above
http://www.garlic.com/~lynn/2006.html#21 IBM up for grabs?
http://www.garlic.com/~lynn/2006.html#22 IBM up for grabs?
also has URLs for air photos of almaden research site and silicon
valley lab site.
the "plant site" had bldg. 14 (disk engineering) and bldg. 15 (disk
product test) ... misc. postings
http://www.garlic.com/~lynn/subtopic.html#disk
san jose research had been in "plant site" bldg. 28 until the new
almaden facility was built up the hill in the mid-80s. bldg. 28 was
where the original relational/sql system/r was done
http://www.garlic.com/~lynn/subtopic.html#systemr
bldg. 29, "los gatos lab" ... was in san jose on the other
side of almaden valley. misc. past posts mentioning bldg. 29, los
gatos lab
http://www.garlic.com/~lynn/2000b.html#57 South San Jose (was Tysons Corner, Virginia)
http://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2003k.html#3 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2004f.html#7 The Network Data Model, foundation for Relational Model
http://www.garlic.com/~lynn/2004o.html#17 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
http://www.garlic.com/~lynn/2004q.html#31 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#25 Network databases
http://www.garlic.com/~lynn/2005b.html#14 something like a CTC on a PC
http://www.garlic.com/~lynn/2005c.html#1 4shift schedule
http://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#0 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005n.html#17 Communications Computers - Data communications over telegraph
http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
http://www.garlic.com/~lynn/2006.html#26 IBM microwave application--early data communications
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#5 Materiel and graft
http://www.garlic.com/~lynn/2006r.html#11 Was FORTRAN buggy?
bldg. 90, "santa teresa lab" ... was built in mid-70s ... and
originally was going to be called the coyote lab ... more recently
renamed silicon valley lab. misc. past posts mentioning bldg. 90:
http://www.garlic.com/~lynn/2000b.html#57 South San Jose (was Tysons Corner, Virginia)
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001e.html#64 Design (Was Re: Server found behind drywall)
http://www.garlic.com/~lynn/2001e.html#76 Stoopidest Hardware Repair Call?
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#34 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#29 checking some myths.
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002b.html#15 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002k.html#9 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002o.html#11 Home mainframes
http://www.garlic.com/~lynn/2002o.html#69 So I tried this //vm.marist.edu stuff on a slow Sat. night,
http://www.garlic.com/~lynn/2002q.html#44 System vs. application programming?
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003e.html#9 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003i.html#56 TGV in the USA?
http://www.garlic.com/~lynn/2003k.html#3 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003o.html#2 Orthographical oddities
http://www.garlic.com/~lynn/2004c.html#31 Moribund TSO/E
http://www.garlic.com/~lynn/2004e.html#22 Pre-relational, post-relational, 1968 CODASYL "Survey of Data Base Systems"
http://www.garlic.com/~lynn/2004n.html#18 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#17 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#67 Relational vs network vs hierarchic databases
http://www.garlic.com/~lynn/2004q.html#23 1GB Tables as Classes, or Tables as Types, and all that
http://www.garlic.com/~lynn/2005.html#23 Network databases
http://www.garlic.com/~lynn/2005.html#25 Network databases
http://www.garlic.com/~lynn/2005b.html#1 Foreign key in Oracle Sql
http://www.garlic.com/~lynn/2005c.html#1 4shift schedule
http://www.garlic.com/~lynn/2005c.html#45 History of performance counters
http://www.garlic.com/~lynn/2005c.html#64 Is the solution FBA was Re: FW: Looking for Disk Calc
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2005e.html#21 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005n.html#17 Communications Computers - Data communications over telegraph
http://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005t.html#8 2nd level install - duplicate volsers
http://www.garlic.com/~lynn/2005u.html#22 Channel Distances
http://www.garlic.com/~lynn/2006.html#21 IBM up for grabs?
http://www.garlic.com/~lynn/2006.html#22 IBM up for grabs?
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006n.html#8 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006n.html#35 The very first text editor
http://www.garlic.com/~lynn/2006o.html#22 Cache-Size vs Performance
http://www.garlic.com/~lynn/2006o.html#52 The Fate of VM - was: Re: Baby MVS???
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Wed, 27 Sep 2006 09:11:12 -0600
KR Williams <krw@att.bizzzz> writes:
The only major projects I saw canceled in the '70s were *LOSERS*
(e.g. FS) and were replaced my products that made gazillion$ (303x
and 308x). Maybe IBM was behind DEC in its slide down the MBA
slope. IBM certainly got there, but in the late '80s, not '70s.
some claim that putting in a non-engineering type as head of the disk
division in the late 70s was possible similar. recent post:
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
... and also as a reaction to the failure of FS
http://www.garlic.com/~lynn/subtopic.html#futuresys
where technical types had possibly been given too much latitude.
however, the person credited with leading the 3033 thru to its success
(3031 and 3032 were primarily repackaged 158s & 168s to use channel
director ... and even 3033 started out being 168 wiring diagram
remapped to newer chips) ... was then brought in as replacement
to head up disk division.
part of all this was that significant resources and time were diverted
into FS ... and after it was killed, there was a lot of making up
for lost time
we sort of got our hands slapped in the middle of pulling off 3033
success.
i previously had mentioned working on 5-way smp VAMPS
http://www.garlic.com/~lynn/subtopic.html#bounce
and after that was killed ... there was a 16-way smp project started
called "logical machines" ... that had 16 370 (158) engines all ganged
together with extremely limited memory/cache consistency. we had
diverted the attention of some of the processor engineers that were
dedicated to 3033 ... to spending a little time on "logical machine"
effort. when the person driving 3033 eventually found out that we were
meddling with some of his people ... there was some amount of attidude
readjustment (and suggestion that maybe certain people shouldn't be
seen in pok for awhile). during 3033, there were stories about him
being in admin office running pok during first shift and being down on
the line with the engineers second shift
other past posts mentioning "logical machine" effort:
http://www.garlic.com/~lynn/2002i.html#82 HONE
http://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004f.html#26 command line switches [Re: [REALLY OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2006l.html#30 One or two CPUs - the pros & cons
these activities (and a couple others that I was involved in) were
going on concurrently to turning out my resource manager ... another
one of the reasons previously mentioned about resource manager was
something of a hobby ... as opposed to full time, dedicated effort:
http://www.garlic.com/~lynn/2006q.html#34 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#46 Was FORTRAN buggy?
the other part of the late 80s was that some amount of dataprocessing
was shifting out of the glass house ... and communication group had
their barb wire around the glass house perimeter. recent refernce
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#20 Was FORTRAN buggy?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 50th Anniversary of invention of disk drives
Newsgroups: alt.folklore.computers
Date: Wed, 27 Sep 2006 14:56:08 -0600
hancock4 writes:
By the standards of the 1950s and 1960s, main memory was measured in
thousands while disk space was measured in millions. The first disk
drive had [only] 5 meg but that was enormous compared to main memory of
those days, maybe 80K. In a few years they got the disk up to 50 Meg.
I don't think the drums of that era could get anywhere near that.
360 had fixed head 2303 & 2301 drums (2301 effectively a 2303 but
read/write four heads in parallel) and 4mbytes capacity in the era of
2311 (7mbytes) and 2314 (29mbytes) disks.
in the early 70s with 370 came 3330-1 (100 mybytes) and then 3330-11
(200 mbytes) and the fixed-head disk 2305 (12mbytes) was replacement
for 2301/2303 drums.
after that, electronic store was becaming plentiful enuf to start
doing caching (somewhat mitigating requirement for fixed head disks).
when cp67 originally showed up at the univ. its disk i/o strategy was
strictly FIFO and paging operations were done with a different/unique
i/o operation per 4k page transfer.
one of the performance changes i did as an undergradudate at the
univ. was put in ordered arm seek queueing ... and where possible
whould (try and optimally) chain all queued page transfers into single
i/o (for the same device on drums and for same cylinder on disk).
the ordered arm seek queueing allowed at least 50percent better
thruput under nominal conditions and system degraded much more
gracefully under heavy load.
the single page transfer per physical i/o would peek around 80 page
transfer per second on 2301 drum (avg. rotational delay for each
page). with chaining, a 2301 would peak around 300 page transfers per
second.
later i did page mapped interface for the cms filesystem in which i
could do all sorts of fancy i/o optimizations (that was a lot more
difficult and/or not possible using the standard i/o interface
paradigm). post this year about some old performance stuff with
paged mapped interface
http://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux
misc. posts mentioning paged mapped interface work
http://www.garlic.com/~lynn/subtopic.html#mmap
various past postings mentioning 2301s and/or 2305s
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#8 3330 Disk Drives
http://www.garlic.com/~lynn/95.html#12 slot chaining
http://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology
http://www.garlic.com/~lynn/98.html#17 S/360 operating systems geneaology
http://www.garlic.com/~lynn/99.html#6 3330 Disk Drives
http://www.garlic.com/~lynn/99.html#104 Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
http://www.garlic.com/~lynn/2000.html#92 Ux's good points.
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#52 IBM 650 (was: Re: IBM--old computer manuals)
http://www.garlic.com/~lynn/2000d.html#53 IBM 650 (was: Re: IBM--old computer manuals)
http://www.garlic.com/~lynn/2000g.html#42 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2000g.html#45 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2001.html#17 IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2001h.html#36 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#37 Credit Card # encryption
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2001l.html#57 mainframe question
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#22 index searching
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002b.html#8 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002b.html#23 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002b.html#24 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002b.html#31 bzip2 vs gzip (was Re: PDP-10 Archive migration plan)
http://www.garlic.com/~lynn/2002c.html#52 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002i.html#42 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#47 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post)
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002m.html#73 VLSI and "the real world"
http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002o.html#3 PLX
http://www.garlic.com/~lynn/2003.html#70 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#6 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#9 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#10 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#18 Card Columns
http://www.garlic.com/~lynn/2003c.html#36 "average" DASD Blocksize
http://www.garlic.com/~lynn/2003c.html#37 "average" DASD Blocksize
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#19 Disk prefetching
http://www.garlic.com/~lynn/2003m.html#6 The real history of comp arch: the short form
http://www.garlic.com/~lynn/2003m.html#42 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004.html#6 The BASIC Variations
http://www.garlic.com/~lynn/2004.html#44 OT The First Mouse
http://www.garlic.com/~lynn/2004c.html#61 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
http://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#16 Paging query - progress
http://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004f.html#54 [HTTP/1.0] Content-Type Header
http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004l.html#2 IBM 3090 : Was (and fek that) : Re: new computer kits
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005c.html#3 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005d.html#62 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005h.html#7 IBM 360 channel assignments
http://www.garlic.com/~lynn/2005j.html#51 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005o.html#43 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2005s.html#22 MVCIN instruction
http://www.garlic.com/~lynn/2005s.html#23 winscape?
http://www.garlic.com/~lynn/2005s.html#41 Random Access Tape?
http://www.garlic.com/~lynn/2005t.html#50 non ECC
http://www.garlic.com/~lynn/2006.html#2 Average Seek times are pretty confusing
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006.html#41 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006g.html#0 IBM 3380 and 3880 maintenance docs needed
http://www.garlic.com/~lynn/2006i.html#27 Really BIG disk platters?
http://www.garlic.com/~lynn/2006i.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006m.html#5 Track capacity?
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#32 Very slow booting and running and brain-dead OS's?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A Day For Surprises (Astounding Itanium Tricks)
Newsgroups: alt.folklore.computers,comp.arch
Date: Wed, 27 Sep 2006 15:11:44 -0600
jsavard writes:
As it happens, the technique of "Just-in-Time compilation", recently
discovered, *is* a highly efficient way of emulating other
architectures entirely in software. And some Itanium chips were
claimed to execute x86 code with what was essentially an independent
chip of 486-style design on the die. I'm surprised at that: given
that the Itanium shares data types with the x86, it should have been
possible to have an Itanium control unit and an x86 control unit
share the same ALUs for more equal performance.
there have been various looks at doing 360/370 simulation on itanium
(porting existing i86 simualtors to itanium) going back to the
earliest days of itanium design.
in the late 70s, early 80s ... there was fort knox. the low-end 360 &
370 processors were typically implemented with "vertical" microcoded
processors ... that avg. out something like 10 micro-instructions per
360/370 instruction. the higher end 360/370 used horizontal microcode
engines (being somewhat more similar to itanium).
fort knox was to replace the vast array of microprocessor engines with
801s. this started out that the follow-on to 4341 was going to be an
801/risc engine. this was eventually killed ... i contributed to one
of the analysis that help kill it. part of the issue was that silicon
technology was getting to the point that you could start doing 370
almost completely in silicon.
http://www.garlic.com/~lynn/subtopic.html#801
one of the other efforts was 801/romp that was going to be used in the
opd displaywriter followon. when this was killed, it was retargeted as
a unix workstation and became pc/rt. this then spawned 801/rios
(power) and then somerset and power/pc.
there was also some work in fort knox on a hybrid 370 simulation
effort using 801 ... that involved some JIT activity. i got dragged
into a little of it because i had written a PLI program in the early
70s that processed 360/370 assembler listings ... analyzed what was
going the program and tried to generate a higher level representation
of the program ... a couple recent postings
http://www.garlic.com/~lynn/2006p.html#1 Greatest Software Ever Written?
http://www.garlic.com/~lynn/2006p.html#4 Greatest Software Ever Written?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer Artifacts
Newsgroups: alt.folklore.computers
Date: Wed, 27 Sep 2006 17:18:29 -0600
Steve O'Hara-Smith <steveo@eircom.net> writes:
There were various optical disc arrangements in use. Around 1990 I
saw a large read only store based on a jukebox like affair with (IIRC) 12in
optical WORM discs holding 2GB a piece. Eventually the CD standardised the
physical format of course.
76 sometime, in san jose there was a lathe like arrangement with
something like 200 spinning floppies. the spinning providing some
strength/structure to the floppies but also there was problem with
floppy material stretching with the constant spinning. single head was
on an assembly parallel to the rating "axle" ... it would possition
itself at the floppy it wanted to read/write, small blade parted the
floppies and then compressed air further parted the floppies providing
enuf room for the head to be inserted. the spinning provided enuf
structure for the head/floppy contact for read/write. single head for
all two hundred floppy "platters" is somewhat analogous to early disk
assemblies. i remember john cocke referring to it as some like "tail
dragger" (as a contrast to all the bleading edge stuff that was going
on).
IBM Fellow John Cocke passed away on July 16th
http://domino.watson.ibm.com/comm/pr.nsf/pages/news.20020717_cocke.html
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A Day For Surprises (Astounding Itanium Tricks)
Newsgroups: alt.folklore.computers,comp.arch
Date: Wed, 27 Sep 2006 18:36:25 -0600
re:
http://www.garlic.com/~lynn/2006r.html#24 A Day For Surprises (Astounding Itanium Tricks)
for a little drift ... somebody that was involved in (among other things):
3033 dual-address space
fort knox/801
pa-risc
and itanium
a few posts this year on the subject:
http://www.garlic.com/~lynn/2006.html#39 What happens if CR's are directly changed?
http://www.garlic.com/~lynn/2006b.html#28 Multiple address spaces
http://www.garlic.com/~lynn/2006e.html#1 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006o.html#67 How the Pentium Fell Short of a 360/195
http://www.garlic.com/~lynn/2006p.html#42 old hypervisor email
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A Day For Surprises (Astounding Itanium Tricks)
Newsgroups: alt.folklore.computers,comp.arch
Date: Thu, 28 Sep 2006 08:54:12 -0600
re:
http://www.garlic.com/~lynn/2006r.html#24 A Day For Surprises (Astounding Itanium Tricks)
http://www.garlic.com/~lynn/2006r.html#26 A Day For Surprises (Astounding Itanium Tricks)
.... from long ago and far away
Increasing Circuitry in the 4300s
4331MG1 4331MG2 4341MG1 4341MG2
-------------- -------------- -------------- --------------
| | | | | | | |
| H.L.L. Progs | | H.L.L. Progs | | H.L.L. Progs | | H.L.L. Progs |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|--------------| |--------------| |--------------| |--------------|
| Architecture | | Architecture | | Architecture | | Architecture |
|--------------| |--------------| |--------------| |--------------|
| | | | | | | |
| | | | | --- -| |-- --- -|
| Microcode | | | | | | | | | |___| | | |
| | | ----- | |----- __ | | _ |
| -- | |__| | -| | | | |
|__| |___ --| | |___| | | | | |
| __| | | | | | | |
| Circuitry | | Circuitry | | Circuitry | | Circuitry |
-------------- -------------- -------------- --------------
The Anton design is a step further than the 4341MG2 implementation.
For a significant number of functions the Anton raises the circuitry
interface almost to the architected interface.
Note the circuitry interfaces across the 4300s are not identical. The
4331s are significantly different from the 4341s. Differences do
exist even within model groups. Some of this increased circuitry
expands existing components (a larger cache) and some of it functional
alters the circuitry to microcode interface.
On the 4300s, in fact on all S/370 compatible processors,
compatibility and portability are accomplished at the artificial,
architected machine interface (aka 370 architecture interface)
... snip ...
for other topic drift, originally 3090 was going to use an embedded
4331 as the service processor, running a highly modifed version
of vm370 release 6 and all the panels/menus done in ios3270. 3090 was
eventually shipped with a pair of embedded 4361s as dedicated service
processors (for redundancy and availability).
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Greatest Software Ever Written?
Newsgroups: alt.folklore.computers
Date: Thu, 28 Sep 2006 09:21:34 -0600
re:
http://www.garlic.com/~lynn/2006r.html#1 Greatest Software Ever Written?
http://www.garlic.com/~lynn/2006r.html#17 Greatest Software Ever Written?
http://www.garlic.com/~lynn/2006r.html#19 Greatest Software Ever Written?
continuing the drift with recent news items:
Contactless Cards: Are Privacy Jitters Legit?
http://www.ecommercetimes.com/story/53273.html
recent discussion on the difference between something you have authentication
and something you are authentication.
http://www.garlic.com/~lynn/aadsm25.htm#32 On-card displays
in the yes card vulnerability,
http://www.garlic.com/~lynn/subintegrity.html#yescard
the static data in the chip represents supposedly unique information
as something you have authentication. copying/cloning the
information was sufficient to enable fraudulent transactions.
however, in the passport case, the "static data" in the chip
represents effectively biometric information (picture) about the
individual, requiring a further step of matching the data against the
person for something you are authentication. any copying/cloning of
the information doesn't directly enable fraudulent transactions (as in
the yes card scenario involving static data something you have
authentication). however, as mentioned in the referenced post, there
is other personal information which raises privacy issues.
for rfid/contractless, there is possibly increased ease of
copying/cloning of information compared to some other technologies
(analogous to using the internet can increase exposure of
information). however, there can be radically different treat models
associated with the information that is exposed.
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel abandons USEnet news
Newsgroups: comp.arch
Date: Thu, 28 Sep 2006 10:23:16 -0600
"comp.arch@patten-glew.net" <AndyGlew@gmail.com> writes:
I started hearing about this 4 years ago from somebody at Microsoft.
It appears that some big brokerage company lost a lawsuit, because
customer lists which were stored on an incorrectly configured laptop
computer owned by an employe, were lost. Hypothesis is/was that, if
the computer lost had been company owned and configured, e.g. with hard
disk encryption, the company would have been deemed less negligent. My
Microsoft acquaintance at that time predicted the demise of "dial in
from your own personal computer" telecommuting.
long standing issue ... my oft repeated theme of security proportional
to risk
http://www.garlic.com/~lynn/2001h.html#61
and the swimming pool attractive nuisance scenario. there was civil
litigation claiming several billion around 30 years ago involving
industrial espionage and theft of trade secrets. the judge made
statements effectively that countermeasures & protection
have to be proportional to value (otherwise you can't really blame
people for doing what comes naturally and stealing).
misc. past posts raising the issue:
http://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
http://www.garlic.com/~lynn/2005f.html#60 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005r.html#7 DDJ Article on "Secure" Dongle
http://www.garlic.com/~lynn/2006g.html#41 The Pankian Metaphor
http://www.garlic.com/~lynn/2006q.html#36 Was FORTRAN buggy?
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 50th Anniversary of invention of disk drives
Newsgroups: alt.folklore.computers
Date: Thu, 28 Sep 2006 11:22:09 -0600
hancock4 writes:
I don't think they were very popular. Drums were a "compromise"
between the high capacity of disk and the high speed of core. Since
drums had fixed heads over each track they were faster, indeed, the IBM
650 and other small machines of the 1950s used drums as the sole main
memory. I believe drums were invented by ERA (originally a secret
firm* but then part of Rem Rand Univac**) in the late 1940s and quite
popular in that era.
most 360/67 had 2301 drums for virtual memory paging .... supporting
interactive computing (tss/360 and cp67 ... as well as mts, michigan
terminal system).
there was less of an issue with batch oriented systems, since the
reduced latency (no arm motion) was less of an batch issue (than it
might be in interactive computing environment).
picture of 2301 drum here:
http://www.columbia.edu/acis/history/drum.html
360/67 with picture of 2314 and 2301 in upper right background
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_672/29.html
another picutre of 360/67
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_672/slide07.html
closeup picture of 2301
http://www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_672/slide12.html
the cp67-based (and later vm370-based) commercial timesharing services
http://www.garlic.com/~lynn/subtopic.html#timeshare
tended to have 2301 drums (and later 2305 fixed-head disks w/vm370)
for interactive computing environments where interactive response was
an issue.
again ... it was less of an issue in batch-oriented operations
other posts in this thread:
http://www.garlic.com/~lynn/2006r.html#14 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#15 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#18 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#20 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#21 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#23 50th Anniversary of invention of disk drives
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 50th Anniversary of invention of disk drives
Newsgroups: alt.folklore.computers
Date: Thu, 28 Sep 2006 15:30:50 -0600
hancock4 writes:
I don't think they were very popular. Drums were a "compromise"
between the high capacity of disk and the high speed of core. Since
drums had fixed heads over each track they were faster, indeed, the IBM
650 and other small machines of the 1950s used drums as the sole main
memory. I believe drums were invented by ERA (originally a secret
firm* but then part of Rem Rand Univac**) in the late 1940s and quite
popular in that era.
there was another "compromise/trade-off" between disks and high speed
core for 360s. disks (drums, datacells, etc) were referred to as
"DASD" (direct access storage device) ... more specifically "CKD" DASD
(count-key-data).
the trade-off was extremely scarce real storage vis-a-vis realatively
abundant i/o resources. typically, filesystems have an index of where
things are on the disk. most systems these days, use the relatively
abundant real storage to cache these indexes (in addition to caching
the data itself). however of 360, the indexes were kept on disk
(saving real storage).
CKD allowed for essentially allowed filesystem metadata to be written
along with the data itself. the indexes were kept on disk with
filesystem metadata indexes. rather than reading the indexes into real
storage (and possibly caching them), CKD DASD i/o programming provided
for doing a sequential search of the indexes on disk ... trading off
scarce real storage for abundant i/o capacity.
however, by at least the mid-70s, the trade-off was reversing ... with
real storage starting to become abundant and disk i/o was becoming
more and more of a system bottleneck.
in the late 70s, i was brought in to investigate a severe
throughput/performance problem for a large national retail chain. they
had central dataprocessing facility providing support for all stores
nationally ... with several clustered mainframes sharing common
application library. it turns out that the CKD/PDS program library
dasd/disk search was taking approx. 1/2 second elapsed time (actual
program load took maybe 10-20 milliseconds ..., but the on-disk index
serial search was taking 500 milliseconds) and all retail store
software application program loads were serialized through this
process.
this trade-off left-over from the mid-60s included having the argument
for the on-disk serial search kept in processor real storage (further
optimizing real storage constraint) ... however it required that there
was a dedicated exclusive i/o path between the device and the
processor real storage for the duration of the search. this further
exasherbated the throughput. typically multiple disks (between 8 to
32) might share a common disk controller and i/o channel/bus. not only
was the disk performing the search, busy for the duration ... but
because of the requirement for the dedicated open channel between the
disk and processor storage (for accessing the search argument) busy
for the duration of the search ... it wasn't possible to perform any
operations for any of the other disks (sharing the same controller
and/or i/o channel/bus).
misc. past posts discussing this subject
http://www.garlic.com/~lynn/subtopic.html#dasd
... not the above is a different collection of posts than
http://www.garlic.com/~lynn/subtopic.html#disk
which primarily references working with the people in bldg. 14 (disk
engineering) and bldg. 15 (disk product test) on the san jose plant
site.
in any case, this and other factors prompted my observation that over
a period of ten to fifteen years, disk relative system performance had
declined by an order of magnitude i.e. other system resources
increased by a factor of fifty while disk resources (in terms of
operations per second) increased by possibly only a factor of five.
the initial take was that the disk division assigned their disk
performance and modeling group to refute my statements ... however,
after several weeks they came back and said that I may have actually
slightly understated the issue.
the change in the relative thruput of different system components ... especially
with respect to each other ... results in having to change in various
strategies and trade-offs ...