From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: PowerPC or PARISC? Newsgroups: comp.arch Date: Wed, 06 Sep 2006 14:58:02 -0600nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
long ago and far away ... the original RIOS (power) didn't provide support for any short of cache coherency (in fact, a big deal was made of how much simpler & faster it was because it avoided having any sort of cache coherency) .... things had to go to nearly completely different design (power/pc) to get some cache coherency ....
however there was a four processor smp (oak) ... using rios ".9" (or single chip rios) ... that depended on coherency by software setable virtual memory segment register ... whether associated storage was to be cached or not. some level of smp consistency was achieved by having portions of memory specified as non-cached.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Materiel and graft Newsgroups: alt.folklore.computers Date: Wed, 06 Sep 2006 16:05:09 -0600re:
After success of 360, the technical gurus were really riding high,
and they were given some latitude for FS
http://www.garlic.com/~lynn/submain.html#futuresys
(which i somewhat characterized as the inmates being in charge of the
institution). when FS failed ... the pendulum somewhat started to
swing in the other direction (non-technical, business types taking
over more control of the company). a recent post mentioning FS
http://www.garlic.com/~lynn/2006p.html#50 what's the difference between LF(Line Fee) and NL (New line) ?
for whatever reason, the disk division got a new non-engineer, non-technical president in the late 70s.
The los gatos lab (bldg. 29) had been built in the 60s on 200 acres of undeveloped land and was a award winning showcase location. They later had problems because some amount of the construction was custom ... like custom sized redwood plywood (instead of standard 4x8) ... and it was effectively impossible to get any new replacement.
the new president had a house over near the los gatos lab and decided that his office should be near his house ... rather than over in the hdqtrs building on the san jose plant site. he had the back part of the los gatos lab redone for him and small set of his executive staff; executive area got carpeted floors, the exterior walls and windows were redone with countermeasures for various kinds of evesdropping and snooping, and the corridor that executives might take from their area to the lab lunch room also got carpeting (the lab somewhat taking on dual personality, the engineer and hardware areas retained their tile floors while the executive areas were all differentiated by their carpeted floors). there was also going to be a special executive drive-way, small executive parking area, and special executive entrance (for the executive area).
before the drive-way, parking area, and private executive entrance was constructed (but after the interior changes had been made), the disk division got a new president with hardware background ... who wanted his office to be on the main plant site, in the middle of the business.
This happened about the time I was getting HSDT project going
http://www.garlic.com/~lynn/subnetwork.html#hsdt
and I was able to somewhat take advantage of the situation to acquire much of the vacant "executive" office space in los gatos lab (that never even saw any of its new occupants).
so, how does this all tie-in with the referenced post (mentioning sherpa, apa6670)?
I had first met Pete Sih in the early 70s as part of the cp67 "h" and "i" effort (develop support for 370 virtual memory on cp67 360/67 infrastructure). The cp67i system was designed to run on real 370s (but original run in 370 virtual machine under cp67h running on real 360/67 for the first year of its existance). Pete was one of three people that came out from the san jose disk division ... to add block-mux channel along with 3330 and 2305 device support to the "cp67i" system ... later sometimes referred to as the "cp67sj" system (enabling cp67sj system to run on real 370/145s supporting real 3330 and real 2305 devices).
Later, Pete was (still) living not too far from the los gatos lab ... but having to commute up to the palo alto science center. So a deal was cut for Pete to have one of the vacant "executive" offices (in the back of the los gatos lab) and minimize his having to commute to the palo alto science center.
Even later, Pete, my wife, and I departed the company on the same day. Bldg. 29 was eventually demolished and the 200 acres sold off for housing development.
a few recent posts mentioning cp67h and cp67i systems
http://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
http://www.garlic.com/~lynn/2006d.html#21 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006j.html#21 virtual memory
http://www.garlic.com/~lynn/2006k.html#30 PDP-1
http://www.garlic.com/~lynn/2006m.html#21 The very first text editor
http://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
http://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
http://www.garlic.com/~lynn/2006m.html#41 Why Didn't The Cent Sign or the Exclamation Mark Print?
http://www.garlic.com/~lynn/2006m.html#42 Why Didn't The Cent Sign or the Exclamation Mark Print?
http://www.garlic.com/~lynn/2006n.html#21 The System/360 Model 20 Wasn't As Bad As All That
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Your Mother Saves Data on Eight-Track Tapes Newsgroups: alt.folklore.computers Date: Thu, 07 Sep 2006 06:58:17 -0600Al Kossow writes:
tripped across anecdote about mt. umunhum radar and early stanford sail computer teething problemns (see above url)
also managed to trip across the mitre whirlwind archives
http://www.mitre.org/about/photo_archives/whirlwind_photo.html
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Device Authentication - The answer to attacks lauched using stolen passwords? Newsgroups: alt.computer.security,comp.security.misc,alt.security Date: Thu, 07 Sep 2006 09:58:01 -0600Lassi Hippeläinen writes:
there have been numerous discussions in the past regarding unique authentication tokens per service ... vis-a-vis a single (or small number) of authentication tokens ... where an individual token is used for multiple different services.
frequently this is associated with an institutional-centric paradigm ... where each institution/service provides their own unique token ... w/o even offering the end-user a choice.
however, some number of studies have turned up that in the majority of the institutional centric paradigms ... the end-users are managing their tokens as a unit ... and the most common failure mode will involve all such tokens aka credit cards all in the same wallet/purse (the most common lost/stolen scenario is the wallet/purse involving all such authentication tokens).
various past posts on institutional-centric paradigms vis-a-vis
person-centric paradigm ... where the individual has a choice on how
many tokens they choose to carry ... and which services are bound to
which tokens.
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2004q.html#0 Single User: Password or Certificate
http://www.garlic.com/~lynn/2005g.html#8 On smartcards and card readers
http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005p.html#6 Innovative password security
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
http://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Another BIG Mainframe Bites the Dust Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 07 Sep 2006 11:38:28 -0600Daniel_McLaughlin writes:
some of the other posts in the thread on early evoluation of 2-tier &
3-tier computing
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#36 25th Anniversary of the Personal Computer
http://www.garlic.com/~lynn/2006p.html#39 25th Anniversary of the Personal Computer
semi-related post
http://www.garlic.com/~lynn/2001h.html#64 UUCP email
lots of collected past postings on 3-tier computing
http://www.garlic.com/~lynn/subnetwork.html#3tier
especially during the hey day of SAA when we were out doing customer
executive presentations on 3-tier ... and lots of SAA was much more
oriented towards the preservation of the terminal emulation paradigm
http://www.garlic.com/~lynn/subnetwork.html#emulation
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Materiel and graft Newsgroups: alt.folklore.computers Date: Thu, 07 Sep 2006 12:39:19 -0600Anne & Lynn Wheeler writes:
re:
http://www.garlic.com/~lynn/2006p.html#49 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
a few web references mentioning los gatos lab turned up by search engine
An early microcomputer (Was: Original Origins of Intel 4004)
http://mail.computerhistory.org/pipermail/inforoots/2004-November/000761.html
IBM 3624
https://en.wikipedia.org/wiki/IBM_3624
IBM slices 135 acres from 'bank account'
http://sanjose.bizjournals.com/sanjose/stories/1996/09/02/story3.html?page=2
People Involved with ACS
http://www.cs.clemson.edu/~mark/acs_people.html
which also found a number of my old posts mentioning the los gatos lab (even the wikipedia article has reference to one of my posts).
part of the original land for the los gatos lab was hillside (that had the san jose dump behind it) ... which may or may not have been included in the 135 acres sold off for housing development (that or what I was told in the dark past about it being 200 acres was off, or maybe the hillside was donated to the city or county).
the wikipedia article mentions that 3624 introduced PIN block format
for the transmission of encrypted PINs. which then points at the
entry for PINs:
https://en.wikipedia.org/wiki/Personal_identification_number
the "intel 4004" reference also discusses early 2984 ATM machine work at the lab.
other reference list 1972 for 2984, 1973 for 3614, and 1979 for 3624
the above also discusses a weakness discovered in 2002 in the 3624 PIN block format.
the wikipedia PIN artile also references EMV "Chip and PIN" using
PIN
https://en.wikipedia.org/wiki/Chip_and_PIN
a few recent posts mentioning "Chip and PIN", yes cards, and/or
issues with multi-factor authentication:
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
http://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#25 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#33 Threatwatch - 2-factor tokens attacked by phishers
http://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#16 Fraudwatch - Chip&PIN one-sided story, banks and deception and liability shifts
http://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#4 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006e.html#10 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#30 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006g.html#38 Why are smart cards so dumb?
http://www.garlic.com/~lynn/2006h.html#13 Security
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor
http://www.garlic.com/~lynn/2006i.html#3 Spoofing fingerprint scanners - NEWBIE()
http://www.garlic.com/~lynn/2006k.html#0 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006l.html#27 Google Architecture
http://www.garlic.com/~lynn/2006l.html#33 Google Architecture
http://www.garlic.com/~lynn/2006o.html#40 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006o.html#47 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: SAT Reading and Math Scores Show Decline Newsgroups: alt.folklore.computers Date: Thu, 07 Sep 2006 16:46:18 -0600A new SAT study hot off the presses?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Linux More Secure on System z? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 08 Sep 2006 08:22:37 -0600timothy.sipples@ibm-main.lst (Timothy Sipples) writes:
at one point the majority of exploits (in c language environments)
were length related. attackers would include machine executable
instructions (would be tailored for the victim machine) in various
incoming data ... and manage to contrive the processor to transfer to
those instructions. the problem became so serious on many platforms
that hardware countermeasure was introduced in the past couple years
... somewhat akin to 360 storage protection. however, instead of data
store/fetch protection ... it is i-stream fetch protection. standard
data store/fetch operations work ... but if the processor attempts to
fetch instructions from the protected location there is a fault (as
countermeasure to attackers introducing malicious instructions hidden
in data streams and leverage short comings in data length handling).
a past post mentioning hardware no-execute storage protection
(with some web references)
http://www.garlic.com/~lynn/2005.html#1 Buffer overruns
trivial search engine use looking for references to various kinds of hardware support for no-execute will turn up lots more.
however, the rise in the use of automatic scripting associated with
many application environments has somewhat changed the exploits. this
attack pattern was identified on the internal network in the 70s. lots
of past posts about the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
note that scripting exploits tend to be machine architecture neutral since its tends to involve interpreted code.
as various applications added support for automatic execution of embedded scripts in data files (email, etc) ... the ratio changed. At one point studies found exploits to be broken down: 1/3rd automatic scripting, 1/3rd (still) buffer related, and 1/3rd social engineering (manipulating humans to divulge sensitive information or perform questionable operations). social engineering has since expanded into things like phishing.
recent post on the topic of identifying and categorizing exploits
and vulnerabilities
http://www.garlic.com/~lynn/2006p.html#43 Slow-Going For Next-Generation Threat-Scoring System
older post looking at the categorizing of exploits
http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE
and slightly more recent post discussing the categorizing of exploits
http://www.garlic.com/~lynn/2005b.html#20 Buffer overruns
and lots of collected posts on the subject of exploits, vulnerabilities,
threats and fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is no one reading the article? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 08 Sep 2006 19:55:26 -0600phil@ibm-main.lst (Phil Payne) writes:
pre-itanium
part of the issue had been that HP had acquired Convex. Convex had done the scalable Exemplar using "64-port" sci memory coherent with two hp pa-risc chips/board (128 chips, processor in numa configuration).
my understanding from the hp engineers was that superdome would be somewhat smaller and more efficient (to implement, 32 processors) box that they would move into the (convex) exemplar customer segment ... as well as moving out into the more commercial world.
also from 9/12/2000 (same as the referenced item).
HP thinks big with Superdome servers
http://news.com.com/2100-1001-245591.html
there was some comment about ibm being wary of pushing ibm's competitive unix offerings too hard with commercial customers because it might take market away from traditional mainframes.
initially announced with 32 processors but with promise of 64 processors to come soon. also promised being able to upgrade to itanium ... except itanium hadn't seen any update (late 90s had various of the 370/390 software emulators thinking itanium would offer significant emulation thruput).
one of your articles:
http://www.isham-research.co.uk/platslns4.html
there is possible more progress now going on with itanium-2.
from 7/8/2002 ...
HP touts advantages of Itanium 2
http://news.com.com/HP+touts+advantages+of+Itanium+2/2100-1001_3-942252.html
...
current superdome page
http://www.hp.com/products1/servers/scalableservers/superdome/index.html
various benchmarks
http://www.hp.com/products1/servers/scalableservers/superdome/index.html
64-way pa-risc superdome specint (june 2002)
http://www.spec.org/cpu2000/results/res2002q3/cpu2000-20020715-01481.html
tpc-c
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
above lists superdome as 4th ... with ibm (non-mainframes) holding top three positions.
and a few additional historical oriented posts involving mainframe,
801, risk, and itanium tie-ins (there used to be a joke that
there were actually only 200 people in the business):
http://www.garlic.com/~lynn/2006.html#39 What happens if CR's are directly changed?
http://www.garlic.com/~lynn/2006e.html#1 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006p.html#42 old hypervisor email
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is no one reading the article? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sat, 09 Sep 2006 08:38:37 -0600Anne & Lynn Wheeler writes:
note that in the same time-frame (mid-90s), both dg & sequent also did a "64-port" SCI cache consistent implementation, but using four intel processors on a board (for a 256 processor configuration, instead of the two pa-risc processors on a board done by convex).
the sci design with multiple processors on board are somewhat analogous to current multiple chip implementations with multiple cores in a chip.
ibm inherited one of the implementations (NUMA-Q) when it bought sequent.
minor ref:
http://www.scizzl.com/
a couple other past posts in this n.g. that mention superdome
http://www.garlic.com/~lynn/2003d.html#57 Another light on the map going out
http://www.garlic.com/~lynn/2006l.html#28 Google Architecture
for some other historical, at the time ibm bought sequent, steve chen
was cto and evp of product development at sequent. Steve had
previously worked at cray and then formed chen supercomputers
... which got a lot of funding from ibm.
http://www.taipeitimes.com/News/biz/archives/2004/11/08/2003210211
http://www.ahaventures.net/index.php?option=com_content&task=view&id=17&Itemid=32
one of the people that worked at cray and chen, hired into kingston,
but later transferred to austin. he was behind the four RSC (rios 0.9
or rios single chip) chip machine ... OAK, shared memory but w/o cache
consistency (he later went to HP for superdome).
https://en.wikipedia.org/wiki/RISC_Single_Chip
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: what's the difference between LF(Line Fee) and NL (New line) ? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sun, 10 Sep 2006 07:18:02 -0600jmfbahciv writes:
we had a couple hardware patches for the 3277 ... one was a FIFO box that fit where the keyboard plugged into the displayhead which would buffer keystrokes during the period that the keyboard would normally be locked. another was piggypacking some resisters inside the keyboard that controlled repeat key startup delay and rate of repeat. this was useful for the cursor movement keys, for positioning the cursor on the screen. one problem was that you could increase the rate to higher than the screen update ... so the cursor position would lag ... and then still "coast" after you had released the key. if you had your keyboard modified for very high repeat rate ... it could take some practice getting feel for releasing the key and still have the cursor stop at the desired position.
these fixes were obsoleted in the switch-over from 3272 controller and 3277 terminals to 3274 controllers and 3278/3279/etc terminals ... since much of the 3277 electronics were moved back into the 3274 controller (reducing per terminal manufacturing costs).
misc. past posts mentioning 3272 and/or 3274 terminal cotnrollers
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#28 IBM S/360
http://www.garlic.com/~lynn/99.html#69 System/1 ?
http://www.garlic.com/~lynn/99.html#193 Back to the original mainframe model?
http://www.garlic.com/~lynn/2000c.html#63 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#66 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#67 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000g.html#23 IBM's mess
http://www.garlic.com/~lynn/2001k.html#30 3270 protocol
http://www.garlic.com/~lynn/2001k.html#33 3270 protocol
http://www.garlic.com/~lynn/2001k.html#46 3270 protocol
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2001m.html#17 3270 protocol
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#48 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#50 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2002j.html#74 Itanium2 power limited?
http://www.garlic.com/~lynn/2002j.html#77 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2002k.html#2 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2002k.html#6 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2002q.html#51 windows office xp
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003c.html#69 OT: One for the historians - 360/91
http://www.garlic.com/~lynn/2003c.html#72 OT: One for the historians - 360/91
http://www.garlic.com/~lynn/2003d.html#23 CPU Impact of degraded I/O
http://www.garlic.com/~lynn/2003d.html#24 CPU Impact of degraded I/O
http://www.garlic.com/~lynn/2003e.html#43 IBM 3174
http://www.garlic.com/~lynn/2003h.html#15 Mainframe Tape Drive Usage Metrics
http://www.garlic.com/~lynn/2003i.html#30 A Dark Day
http://www.garlic.com/~lynn/2003j.html#24 Red Phosphor Terminal?
http://www.garlic.com/~lynn/2003k.html#20 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#22 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003o.html#14 When nerds were nerds
http://www.garlic.com/~lynn/2003o.html#36 When nerds were nerds
http://www.garlic.com/~lynn/2003p.html#44 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2004c.html#30 Moribund TSO/E
http://www.garlic.com/~lynn/2004e.html#0 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2004f.html#54 [HTTP/1.0] Content-Type Header
http://www.garlic.com/~lynn/2004g.html#11 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#24 |d|i|g|i|t|a|l| questions
http://www.garlic.com/~lynn/2004g.html#27 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2005h.html#40 Software for IBM 360/30
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#14 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#15 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#17 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#20 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#28 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005s.html#17 winscape?
http://www.garlic.com/~lynn/2005s.html#45 winscape?
http://www.garlic.com/~lynn/2005u.html#22 Channel Distances
http://www.garlic.com/~lynn/2006b.html#21 IBM 3090/VM Humor
http://www.garlic.com/~lynn/2006i.html#34 TOD clock discussion
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: what's the difference between LF(Line Fee) and NL (New line) ? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sun, 10 Sep 2006 07:30:42 -0600Brian Inglis writes:
a large portion of cms retained 1052 line terminal input/output paradigm ... with hypervisor emulating 1052 line operation on 327x terminals (some applications, like various editors, were enhanced for full-screen operation).
in the real line-terminal days ... cms would output a single line at a
time. the hypervisor had some scheduling sensitivity for terminal i/o
in support of "faster" interactive operation. moving to emulated line
terminals on very fast screen terminals (hundreds of kilobytes/sec)
placed some unnecessary overhead on resource scheduling. misc. collected
posts about resource scheduling
http://www.garlic.com/~lynn/subtopic.html#fairshare
so one of the things i did was modifying cms dmscit to perform single
write (batched) operation for all/any queued lines. past post (including
email copy from long ago and far away)
http://www.garlic.com/~lynn/2003c.html#35 difference between itanium and alpha
some other posts mentioning full-screen operation and performance
http://www.garlic.com/~lynn/2001h.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2005h.html#22 Today's mainframe--anything to new?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Another BIG Mainframe Bites the Dust Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sun, 10 Sep 2006 08:04:14 -0600bernd.oppolzer@ibm-main.lst (Bernd Oppolzer) writes:
the future system project was going to have lots of stuff like that
(as well as gobs of other stuff) ... and would have replaced 360 (and
early 370).
http://www.garlic.com/~lynn/submain.html#futuresys
however as repeatedly noted ... FS was canceled (excessively
ambitious?) and there was a lot of effort pushed into getting 370
activities moving again. recent post in another thread with various
other detail
http://www.garlic.com/~lynn/2006p.html#50 what's the difference between LF(Line Fee) and NL (New line) ?
i've frequently commented that the FS example contributed
significantly to the 801/risc philosiphy ... to do the exact opposite
(of what was attempted in FS). much of the 801/risc effort was
whenever there might be hardware/software trade-off ... you could make
perfect software that would do it better than hardware (allowing the
hardware to be made much simpler). cp.r operating system and pl.8
compiler were to provide the basis for that philosiphy.
http://www.garlic.com/~lynn/subtopic.html#801
one such simplification was that there was no hardware protection domains (i.e. supervisor/problem state differentiation). pl.8 compiler would generate perfect software ... and cp.r operating system would guarantee that only correctly compiled pl.8 code would be loaded for execution.
this resulted in a little hiccup. ROMP (16bit 801/risc) was targeted as an austin GSD effort for displaywriter follow-on (implemented on cp.r with pl.8). it was canceled in the early 80s and there was activity looking around to salvage the effort ... and observed that lots of hardware platforms were being shipped with minimal extra effort by leveraging a port of the unix operating system.
a decision to retarget ROMP to unix workstation market forced retrofitting bits & pieces to ROMP to try and compensate for not having an enhanced perfect software environment ... but having to rely on the UNIX/C operational paradigm (like needing hardware privilege/non-privilege execution states).
the company that had been hired to do the AT&T unix port for PC/IX ... was then hired to do a similar AT&T unix port to ROMP. This was announced as AIX (and PC/RT).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Sun, 10 Sep 2006 08:28:16 -0600krw writes:
from above:
Numerous standards and process models apply to the software
development industry. The Systems and Software Consortium has studied
frameworks that are relevant to companies building software-intensive
systems. The Frameworks Quagmire documents the results of this
research.
... snip ...
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Greatest Software Ever Written? Newsgroups: alt.folklore.computers Date: Sun, 10 Sep 2006 08:50:34 -0600Peter Flass writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Fate of VM - was: Re: Baby MVS??? Newsgroups: alt.folklore.computers Date: Sun, 10 Sep 2006 09:44:36 -0600Peter Flass writes:
collected past posts referencing boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
and various URLs from around the web mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
note i just scanned some of boyd's old presentations and trying it out as html background.
I've mentioned before that my wife's father was engineers combat
group. near the end they were frequently first group into enemy
territory ... he had acquired a collection of officer's daggers
... being the ranking officer in various surrenders. he then was
assigned as adviser in the far east. a few past posts:
http://www.garlic.com/~lynn/2004e.html#19 Message To America's Students: The War, The Draft, Your Future
http://www.garlic.com/~lynn/2005r.html#3 The 8008
http://www.garlic.com/~lynn/2006b.html#27 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006b.html#33 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#27 Mount DASD as read-only
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: what's the difference between LF(Line Fee) and NL (New line) ? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sun, 10 Sep 2006 10:24:53 -0600Roger Ivie writes:
it handled a lot of stuff that had been previously been done on 2250 (and even some calma stuff)
a few past posts mentioning 3277ga
http://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
http://www.garlic.com/~lynn/2001i.html#51 DARPA was: Short Watson Biography
http://www.garlic.com/~lynn/2002p.html#29 Vector display systems
http://www.garlic.com/~lynn/2004l.html#27 Shipwrecks
http://www.garlic.com/~lynn/2004l.html#32 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#8 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#28 MCTS
http://www.garlic.com/~lynn/2006n.html#24 sorting was: The System/360 Model 20 Wasn't As Bad As All That
a few past posts mentioning calma:
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2005r.html#24 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005u.html#6 Fast action games on System/360+?
http://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"
http://www.garlic.com/~lynn/2006n.html#41 Tek 4010, info and prices
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Sun, 10 Sep 2006 16:15:53 -0600re:
and a software development/boyd tie-in
What Lessons Can the Agile Community learn from A Maverick Fighter
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?isnumber=34909&arnumber=1667567&count=62&index=18
misc. collected posts mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
and various URL web pages mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
(web pages updated with scans of old presentations as background).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Difference between server and workstation Newsgroups: comp.arch,alt.folklore.computers Date: Mon, 11 Sep 2006 09:27:51 -0600jsavard writes:
the mid-80s still had large component/configuration differentiation between PCs, workstations, and servers. as state-of-the art for commodity PC component/configurations advanced ... the differentiation significantly narrowed.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: virtual memory Newsgroups: comp.arch Date: Mon, 11 Sep 2006 10:25:55 -0600"Eric P." writes:
with any load on the system (i.e. all pages in memory belonged to "in-queue" uses, having quickly swept out pages belonging to users that weren't running) ... algorithm 1 quickly degenerated to FIFO ... since it would always re-search all memory for a non-running user page ... and then select the next page belonging to a running user. Except for typically swift transition when user was descheduled ... the algoritm would sequently move one page at a time around real memory replacing the next encountered page with a newly faulted page. by the time it made one complete circuit of real storage, it would have replaced each page ... and be back to the first/oldest page that it had started with. effectively algorithm would always sweep all of memory, searching for any non-running user page ... and then quickly falls back to effectively FIFO (NOT random) replacement of pages for running users.
Among other things, under any load, the majority of the time, the search for pages for non-running users wouldn't find anything (since non-running user pages were quickly swept from memory under any sort of load) ... resulting in very high-overhead to scan all real memory pages on every fault. then (under any sort of system load), after the overhead of looking at every page in real memory ... it would fall back to FIFO replacement of pages belonging to running users. It was both an extremely high overhead implementation coupled with an extremely poor replacement strategy (i.e. choice of running user page effectively degenerated to the order that they had been fetched into memory).
so i had done global LRU replacement as an undergraduate in the 60s. by the time, the "single" bit replacement code was shipping in cp67 3.1 ... we were investigating 2, 3, 4, ... 8bit ... variations as well as moving the reset of the reference bit offset from the examination of the reference bit.
the cp67 release 3 distributed implementation didn't differ from the release 2 distributed implementation. the implementation that grenoble started with (in release 3) and modified to implement local LRU ... was the same implementation that I started with as an undergraduate in the 60s for cp67 release 2 and modified to implement global LRU. My global LRU implementation existed concurrently with the grenoble local LRU implementation as modification against the same base implementation (both release 2 and release 3).
My global LRU implementation was then selected to ship in cp67 release 3.1 (which was the single reference bit reset at the same time as the examination). However, about the time it started shipping, we were also starting to look at issues like multiple bits and offsetting the reset from the examination. However, on 360/67, the examination of the bit used the ISK instruction and the resetting of the bit used the SSK instruction. For 370, the synchronous examination and reset strategy resulted in the new RRB instruction ... which examined and reset in a single instruction.
past posts in this thread
http://www.garlic.com/~lynn/2006i.html#28 virtual memory
http://www.garlic.com/~lynn/2006i.html#30 virtual memory
http://www.garlic.com/~lynn/2006i.html#31 virtual memory
http://www.garlic.com/~lynn/2006i.html#32 virtual memory
http://www.garlic.com/~lynn/2006i.html#33 virtual memory
http://www.garlic.com/~lynn/2006i.html#36 virtual memory
http://www.garlic.com/~lynn/2006i.html#37 virtual memory
http://www.garlic.com/~lynn/2006i.html#38 virtual memory
http://www.garlic.com/~lynn/2006i.html#39 virtual memory
http://www.garlic.com/~lynn/2006i.html#40 virtual memory
http://www.garlic.com/~lynn/2006j.html#0 virtual memory
http://www.garlic.com/~lynn/2006j.html#1 virtual memory
http://www.garlic.com/~lynn/2006j.html#2 virtual memory
http://www.garlic.com/~lynn/2006j.html#3 virtual memory
http://www.garlic.com/~lynn/2006j.html#4 virtual memory
http://www.garlic.com/~lynn/2006j.html#5 virtual memory
http://www.garlic.com/~lynn/2006j.html#7 virtual memory
http://www.garlic.com/~lynn/2006j.html#13 virtual memory
http://www.garlic.com/~lynn/2006j.html#14 virtual memory
http://www.garlic.com/~lynn/2006j.html#17 virtual memory
http://www.garlic.com/~lynn/2006j.html#18 virtual memory
http://www.garlic.com/~lynn/2006j.html#19 virtual memory
http://www.garlic.com/~lynn/2006j.html#20 virtual memory
http://www.garlic.com/~lynn/2006j.html#21 virtual memory
http://www.garlic.com/~lynn/2006j.html#22 virtual memory
http://www.garlic.com/~lynn/2006j.html#23 virtual memory
http://www.garlic.com/~lynn/2006j.html#24 virtual memory
http://www.garlic.com/~lynn/2006j.html#25 virtual memory
http://www.garlic.com/~lynn/2006j.html#26 virtual memory
http://www.garlic.com/~lynn/2006j.html#27 virtual memory
http://www.garlic.com/~lynn/2006j.html#30 virtual memory
http://www.garlic.com/~lynn/2006j.html#31 virtual memory
http://www.garlic.com/~lynn/2006j.html#37 virtual memory
http://www.garlic.com/~lynn/2006j.html#39 virtual memory
http://www.garlic.com/~lynn/2006j.html#40 virtual memory
http://www.garlic.com/~lynn/2006j.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#43 virtual memory
http://www.garlic.com/~lynn/2006j.html#44 virtual memory
http://www.garlic.com/~lynn/2006k.html#44 virtual memory
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006l.html#2 virtual memory
http://www.garlic.com/~lynn/2006l.html#3 virtual memory
http://www.garlic.com/~lynn/2006l.html#5 virtual memory
http://www.garlic.com/~lynn/2006l.html#9 virtual memory
http://www.garlic.com/~lynn/2006l.html#10 virtual memory
http://www.garlic.com/~lynn/2006l.html#11 virtual memory
http://www.garlic.com/~lynn/2006l.html#12 virtual memory
http://www.garlic.com/~lynn/2006l.html#13 virtual memory
http://www.garlic.com/~lynn/2006l.html#14 virtual memory
http://www.garlic.com/~lynn/2006l.html#15 virtual memory
http://www.garlic.com/~lynn/2006l.html#16 virtual memory
http://www.garlic.com/~lynn/2006l.html#17 virtual memory
http://www.garlic.com/~lynn/2006l.html#18 virtual memory
http://www.garlic.com/~lynn/2006l.html#19 virtual memory
http://www.garlic.com/~lynn/2006l.html#40 virtual memory
http://www.garlic.com/~lynn/2006l.html#48 virtual memory
http://www.garlic.com/~lynn/2006l.html#55 virtual memory
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: virtual memory Newsgroups: comp.arch Date: Mon, 11 Sep 2006 12:05:04 -0600Anne & Lynn Wheeler writes:
while the global LRU stuff that I had done as an undergraduate in the 60s (against release 1 and release 2 cp67 systems), didn't ship in cp67 release 3 ... gobs of other stuff that I had done did ship in release 3 (lots of kernel rewrite, pathlengths, fastpath, etc).
repeat reference to part of an old presentation that i gave at the
fall68 share user group meeting held in Atlantic City
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
a couple more recent references to that presentation ... mostly
concerned large amount of pathlength rewrites for reducing
processor kernel overhead:
http://www.garlic.com/~lynn/2006.html#7 EREP , sense ... manual
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006h.html#57 PDS Directory Question
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: virtual memory Newsgroups: comp.arch,alt.folklore.computers Date: Mon, 11 Sep 2006 12:03:58 -0600Anne & Lynn Wheeler writes:
one of the issues with cycling around real memory for global LRU was that it tended to be naturally adaptive (self-regulating) over a relatively broad range of environments and configurations.
the point of LRU replacement ... is that least recently used is supposedly predictive of future use ... pages used in the recent past have a high probability being used in the near future (than pages that haven't been used in the recent past).
the interval between the reset of the reference bit and the next examination of the reference bit is supposed to represent a "recent interval" that retains the predictive characteristics associated with least recently used observations (pages that have the reference bit off haven't been used in the recent interval and pages that have the reference bit on have been used in the recent interval).
the naturally adaptive characteristics is that if the implementation has cycled memory too quickly (cycled around storage once) ... then there will be a larger precentage of pages with the reference bit off ... which means on the next pass it will take much longer to make one complete cycle through all of memory (increasing the interval that allows pages to have their reference bit set). if the implemenation has cycled memory too slowly ... then there will be a larger percentage of pages with the reference bit on ... which means that it will take much shorter time to make one complete cycle through all of memory (one complete cycle of memory is a function by the rate of page/faults and the percentage of pages with their reference bits off).
so naturally adaptive worked over a fairly broad range ... but not completely. In page thrashing scenario (severe over commitment of real storage), everybody is waiting for page fault and not executing ... so nobody is getting any page reference bit set. majority of reference bits are always off and the algorithm degenerates to pretty much FIFO (as in the case of "alogorithm 1" for cp67 which had effectively assumed all the reference bits were the same and didn't even both to check).
the other situation where the natural adaptive starts to break down is where there was increasing amounts of available real storage and the time it takes to cycle around all storage begins to consistently exceed any common definition of "recent" ... as applied to least recently used algorithms. large percentage of pages may have their reference bit on (because the interval since reset was so long) and there was no differentiation between pages that had been "recently used" and pages that hadn't been used for quite some time.
this is where the "offset reset" started to appear. you can think of the original implementation as having a "offset reset" exactly equal to one complete cycle of all storage. however, with increasing real storage sizes the avg. interval to cycle around all pages (interval between reset and examiniation) was becoming excesively larger and no longer conformed to any reasonable definition of "recent". so a new variation was introduced to offset the resetting the reference bit from the examination of the reference bit. this offset could be adjusted based on reasonable definition and expectation of "recent" having some valid prediction of future page reference behavior. This could possibly be one-half of all memory .... so the pages being reset were effectively "half of real pages" away from the pages being examined (cutting the average interval between reset and examination in half).
re:
http://www.garlic.com/~lynn/subtopic.html#wsclock
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 3 value logic. Why is SQL so special? Newsgroups: comp.databases.theory Date: Mon, 11 Sep 2006 13:02:28 -0600"JOG" writes:
commercial aircraft tend to have scheduled departure times (helps give you an approx idea when to show up at the airport) ... as well as scheduled arrival times.
at one time the FAA didn't interfer with departure times ... and let aircraft circle if weather cut down on capacity of airfield landing rates. at some point the FAA started holding plane departures if there was predictions about reduced capacity to land the plane.
you frequently hear pilots making announcements about particular arrival being ahead of time or late ... which is the difference between the scheduled arrival time and the actual arrival time. both the actual arrival time and the difference (early/late) between the actual arrival time and the scheduled arrival time ... aren't actually known until near to the time that the plane actually arrives.
in the routes database used for scheduling reservations involving connecting flights ... there typically is an attempt to match scheduled arrival time to connecting scheduled departure time (within some fudge factor).
however as anybody who has had a late arrival and missed their connecting flight ... the scheduled arrival time and the actual arrival time may be different. also some carriers when they see that their are a significant connecting passengers ... on a flight that is starting to show a predicted late arrival time ... may attempt to delay the departure of some number of flights as convinience to connecting passengers. however, this can have cascading effects if the connecting departing flight then impacts other passengers that have connecting flights at the next arrival.
lots of flights that have significant, long term differences between scheduled arrival and actual arrival may indicate various loading and capacity issues and reason to update projected schedules. changes in projected specific schedules then can have cascading effects with regard to scheduling departure/arrivals for purposes of route and load planning involving connecting flights.
various past posts mentioning 3-value logic
http://www.garlic.com/~lynn/2003g.html#40 How to cope with missing values - NULLS?
http://www.garlic.com/~lynn/2004f.html#2 Quote of the Week
http://www.garlic.com/~lynn/2004l.html#75 NULL
http://www.garlic.com/~lynn/2005.html#15 Amusing acronym
http://www.garlic.com/~lynn/2005b.html#17 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005i.html#35 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005m.html#19 Implementation of boolean types
http://www.garlic.com/~lynn/2005t.html#20 So what's null then if it's not nothing?
http://www.garlic.com/~lynn/2005t.html#23 So what's null then if it's not nothing?
http://www.garlic.com/~lynn/2005t.html#33 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005u.html#12 3vl 2vl and NULL
http://www.garlic.com/~lynn/2006e.html#34 CJ Date on Missing Information
various past posts mentiong working with OAG database of all
(world-wide) commercial schedule flight segments as part of airline
res system (over 4k airports and over 400k commercial scheduled flight
segments)
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000f.html#20 Competitors to SABRE?
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
http://www.garlic.com/~lynn/2002j.html#83 Summary: Robots of Doom
http://www.garlic.com/~lynn/2003o.html#17 Rationale for Supercomputers
http://www.garlic.com/~lynn/2004b.html#6 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004o.html#23 Demo: Things in Hierarchies (w/o RM/SQL)
http://www.garlic.com/~lynn/2004q.html#85 The TransRelational Model: Performance Concerns
http://www.garlic.com/~lynn/2005o.html#24 is a computer like an airport?
http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back
http://www.garlic.com/~lynn/2006o.html#18 RAMAC 305(?)
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 3 value logic. Why is SQL so special? Newsgroups: comp.databases.theory Date: Mon, 11 Sep 2006 13:19:49 -0600Bob Badour writes:
you have a row entry for a specific flight that has fields for scheduled and actual departures and arrival ... possibly with provision for computed values (difference between scheduled and actual).
or possibly you have two different tables ... one with scheduled flights and another with actual flights. an entry isn't inserted in the table of actual flights until the flight has actually happened.
the absence of a row in the actual flight table takes the place of null value fields (for not yet known information) in the table of specific flights. two tables then possibly involves referential integrity if there is an attempt to match an actual flight against a scheduled flight (in two different tables).
there is also, always the possibility that you might have an unscheduled actual flight ... an unplanned flight for which there hadn't been a (pre-)scheduled departure/arrival ... but for which there is actual departure ... with initially a projected arrival (as opposed to a scheduled arrival) ... and then eventually an actual arrival.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "25th Anniversary of the Personal Computer" Newsgroups: alt.folklore.computers Date: Mon, 11 Sep 2006 23:06:01 -0600Anne & Lynn Wheeler writes:
other recent posts mentioning sci
http://www.garlic.com/~lynn/2006p.html#55 PowerPC or PARISC
http://www.garlic.com/~lynn/2006q.html#8 Is no one reading the article?
http://www.garlic.com/~lynn/2006q.html#9 Is no one reading the article?
harrier mentioned in the following later became ssa (also
mentioned in this thread) ... an old ssa post
http://www.garlic.com/~lynn/95.html#13 SSA
some other sci drift ....
Date: 92/06/30 22:43:04
From: wheeler
Subject: slac sci meeting
The sci meeting at slac today included people from slac, two from hp,
one from apple, ibm branch rep, somebody from IBM Houston, my wife and
I.
The ibm branch rep turns out to really be an ibm "business" partner
that ibm has turned the slac account over to. this guy also mentioned
that he has the nasa/ames account.
Gustavson (SLAC & IEEE SCI committee chairman) gave introduction to
SCI and talked about possible application. He had reprints of the IEEE
Micro article "The Scalable Coherent Interface and Related Standards
Projects".
As an aside, I was recently reviewing cache coherency papers in 19th
proceedings of sigarch ... & had ran across the sci ring paper ... and
brought it along. Nobody at the meeting had been aware that it was
published.
Also it turns out that the ring architecture model (Figure C in the
feb92 IEEE Micro article) is almost identical to the ring insertion
patent that Anne received in '78. Also the dual simplex architecture
is the same as the HSDT work we were doing in the early '80s.
The person that was suppsoed to be there from Convex didn't make it.
It was re-iterated that Convex has signed an agreement with HP to use
the PA-RISC chips for its new "supercomputer" ... and it will be
implemented using SCI for distributed shared memory. The architecture
assumes some sort of relaxed consistency cache protocol (for recent
references also see sigarch proceedings #19, there are three papers in
session 1, also see the DASH prototype paper from session 3).
Gustavson outlined two possible design points for SCI, one using
"low-cost" rings for workstation type environments and the other with
a switch for highly-parallel supercomputers.
There was some discussion with regard to how RAM/SCI implementation
compares to technology like RAMBUS. He mentioned talking to somebody
(that I believe is doing a RAMBUS implementation) that suggested
RAM/SCI access is still a good technology to persue. RAMBUS is pretty
well optimized to the limit supporting just 500mbytes/sec (say with
4-way interleaving: 2gbytes/sec). RAM/SCI starts out at 1gbyte/sec and
has room to grow.
There was also mention that SCI was recently presented to the SCSI
standards committee and a SCSI protocol using 200mbit (maybe 100mbit)
SCI cable looks very promising. This appears to be along the same
limes ase HARRIER-II serial implementation running 80mbits (pushing to
160?). One of the comments was that as the SCSI drives get smaller,
the current SCSI connector is larger than the drive. SCI connector is
significantly smaller and provides for higher-bandwidth.
There was a presentation on SLACs computational and data-storage
requirements over the next 3-5 years ... and how SCI would being to
efficiently address some of the opportunities. They are planning on
experiments that are monitored by some front-end real-time
data-reduction machines. These machines will produce an average of
approximately 100 "events"/sec with about 25kbytes/event
(2.5mbytes/sec). These events then require subsequent process to the
tune of approximately 2500Mips per second. This additional processing
will eventually result adding approximately 10kbytes/event
(35kbytes/event total). Effectively 2.5mbytes/sec input, 2500Mips/sec
processing, 3.5mbytes/sec output. Aggregate yearly storage
requirements is on the order of 15TB/year.
Looks like SLAC is looking for government funding along with a partner
from industry ... possibly something along the lines of the
Kung/CMU/NSC project ... but directed to exploring high, sustained
effective datarates for distributed environment using distributed
shared memory paradigm.
... snip ... top of post, old email index
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: re: garlic.com Newsgroups: bit.listserv.ibm-main Date: Tue, 12 Sep 2006 10:12:07 -0600tony babonas wrote:
much of the website information is maintained in some technology that i
originally worked on about the same time I was doing some system/r stuff
(original relational/sql)
http://www.garlic.com/~lynn/submain.html#systemr
which i've since rewritten from scratch a number of times.
the information is maintained and managed in the technology and then (static) html files are periodically regenerated and changes copied to the garlic web pages.
as i've mentioned a number of times before (and also referenced in the attached comments) most of the html files have an exceptionally high ratio of hrefs to amount of content (as well as attempting to simulate bi-directional links) ... which possibly is the reason that many of the major web crawlers appear to use it for regression case (hits to all the files from the same crawlers several times per day).
the ietf index
http://www.garlic.com/~lynn/rfcietff.htm
and note on the merged taxonomies and glossaries
http://www.garlic.com/~lynn/index.html#glosnote
for instance ... the privacy taxonomy/glossary was done in support of working as co-author of the x9.99 financial standard
i.e. notes on various merged taxonomies and glossaries
Payment
Terms merged from: ACH, FACSNET, FRBC, FRBM, FRBSF, GAO, NSCC, and
misc.
http://www.garlic.com/~lynn/payment.htm
Security
Terms merged from: AFSEC, AJP, CC1, CC2, CC21 (CC site), CIAO,
FCv1, FFIEC, FJC, FTC, IATF V3 (IATF site), IEEE610, ITSEC, Intel,
JTC1/SC27 (SC27 site), KeyAll, MSC, NIST 800-30, 800-33, 800-37, 800-53,
800-61, 800-77, 800-83, FIPS140, NASA, NCSC/TG004, NIAP, NSA Intrusion,
CNSSI 4009, online security study, RFC1983, RFC2504, RFC2647, RFC2828,
TCSEC, TDI, TNI, vulnerability testing and misc. Updated 20060701 with
NIST IR 7298 Glossary containing terms from the following FIPS
documents: 140-2, 181, 185, 188, 191, 196, 197, 198, 200, 201; and the
following 800 documents: 12, 15, 16, 18, 19, 21, 24, 26, 27, 28, 30, 32,
33, 34, 35, 36, 37, 38, 40, 41, 44, 46, 47, 48, 49, 50, 53, 55, 56, 57,
58, 59, 60, 61, 63, 64, 65, 66, 67, 72, 79, 83, 88, 90
http://www.garlic.com/~lynn/secure.htm
Privacy
Privacy terms from merged Security Taxonomy & Glossary combined
with EU-DPD, FTC, GLBA, HIPAA, OECD, and OMB. Updated 20040222 with
terms from OMB. Somewhat related, X9.99, Privacy Impact Assessment
standard is now also available at ANSI X9.99
http://www.garlic.com/~lynn/privacy.htm
X9F
Terms merged from X9F document glossaries: WD15782, X509, X9.8,
X9.24, X9.31, X9.42, X9.45, X9.49, X9.52, X9.62, X9.65, X9.69. Terms
from ABA/ASC X9 TR1-1999 replace terms from X9F TG-16 glossary
(identified by lower case x9 instead of upper-case X9). Original source
documents include: X3.92, X3.106, x9.1, x9.5, x9.6, x9.8, x9.9, x9.17,
x9.19, x9.23, x9.24, x9.26, x9.28, x9.30, x9.31, x9.41, x9.42, x9.44,
x9.45, x9.49, x9.52, x9.55, x9.57, x9.62, x9.69 x9.74, x9.76, x9.78,
x9.80, x9.82, and TG-17.
http://www.garlic.com/~lynn/x9f.htm
Financial
Warning: Not for light of heart, the combined glossary and taxonomy
is over 3.5 megabytes and has been known to lock up some browser
versions on some platforms (more because of the number of links than
size of files). There are >6600 terms, >8500 definitions and >35,500
href links. Terms merged from Payment Taxonomy & Glossary with Bureau of
Economic Analysis, Chicago Board of Trade, Commodity Futures Trading
Commission, C Harvey at Duke (Copyright, for non-commercial use only),
Environmental Protection Agency, Federal Deposit Insurance Corporation,
International Trade Data System, International Trade Resource Center,
MidAmerica Commodity Exchange, New York Merchantile Exchange, New York
Stock Exchange, Office Thrift Supervision, Securities Exchange
Commission, Treasury Management Association of Canada, UN Office on
Drugs and Crime and Western Connecticut State University. Updated
20050320 with FIDC international terms
http://www.garlic.com/~lynn/financial.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: garlic.com Newsgroups: bit.listserv.ibm-main Date: Tue, 12 Sep 2006 10:46:13 -0600re:
oh, and the e-server magazine article
https://web.archive.org/web/20190524015712/http://www.ibmsystemsmag.com/mainframe/stoprun/Stop-Run/Making-History/
as an aside to the comment about having been around ... my wife served
her time also ... worked on FS, was in the gburg JES group (one of the
catchers for ASP turning into JES3 ... and worked on a design for
merging JES2/JES3 into a single product) ... and then was con'ed into
going to POK to be in charge of loosely-coupled architecture. while
there, she did peer-coupled shared data architecture
http://www.garlic.com/~lynn/submain.html#shareddata
except for the IMS hot standby effort ... didn't see a lot of uptake until parallel sysplex.
recent posting of old email in a.f.c newsgroup mentioning patent she got
on token protocol while she was doing her stint in POK
http://www.garlic.com/~lynn/2006q.html#24
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: dcss and page mapped filesystem Newsgroups: bit.listserv.vmesa-l Date: Tue, 12 Sep 2006 23:48:12 -0600Rob van der Heij wrote:
they decided to pickup a very small piece of the cms & cp changes for
vm370 release3 and call it DCSS ... lots of past posts with much more
detailed description
http://www.garlic.com/~lynn/submain.html#mmap
one of the tricks was an added enhancement that i had done for
location free code ... so memory images could be mapped from
filesystem to arbitrary (possibly shared segment) virtual
addresses. lots of past posts discussing some of the issues
http://www.garlic.com/~lynn/submain.html#adcon
later i did an enhancement for the spool file system to operate
similarly ... i needed to speed up the spool system by minimum of
factor of 10 times for VNET participation in HSDT backbone
http://www.garlic.com/~lynn/subnetwork.html#hsdt
recent posts discussing spool file system rewrite
http://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006o.html#64 The Fate of VM - was: Baby MVS???
http://www.garlic.com/~lynn/2006p.html#10 What part of Z/OS is the OS?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: was change headers: The Fate of VM - was: Re: Baby MVS??? Newsgroups: alt.folklore.computers Date: Wed, 13 Sep 2006 11:15:32 -0600CBFalconer writes:
lots of past posts mentioning boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
and misc. URLs from around the web mentioning boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 3 value logic. Why is SQL so special? Newsgroups: comp.databases.theory Date: Wed, 13 Sep 2006 18:37:08 -0600"Cimode" <cimode@hotmail.com> writes:
one approach about information not yet known is to have different tables that don't yet have entries for the unknown values. another possible mechanism is to have fields mean different things depending on other state information ... for instance have a state flag to switch the meaning of the field containing the projected arrival to actual arrival (or other domain knowledge that changes what a field means based on other circumstances).
it may turn out to not only be useful to have different tables ... but possibly even completely different servers and applications. for instance the projected arrival tends to be of relatively short-term use ... and rarely needs to be carried for very long. the table of projected flight departures and arrivals ... may be relatively few flights with lots of inserts, updates, and deletes. people needing real-time information for scheduling and provisioning adjustments tend to have totally concerns (i.e. will the equipment coming in on a different scheduled flight be available in time to turn around for a brand new flight, will the crew arriving on a different flight be available in time for the their new assigned flight, will connecting passengers be able to make their connection, etc) than some of the longer term considerations. Having totally different tables and databases eliminates the requirement for trying to maintain global encompassing information.
an unscheduled flight ... is they are flying some equipment that isn't a "scheduled" flight ... but for which they have to file a flight plan and actually fly ... or not ... possible to file a flight plan and then have it abort because of weather ... and then file a brand new flight plan ... which possibly might be a totally different unscheduled flight (as opposed to a flight plan for a scheduled flight).
res. system with 400k plus flight segments for scheduled flights, scheduled departures, scheduled arrivals ... tends to be close to 400k plus flight segments every day (i.e. a database with 400k plus records) .... slightly less than that because there are re-occurring flights every day ... but there are also re-occurring flight segments specified just for weekdays ... with different re-occurring flight segments specified for saturday and/or sunday.
actual flight departures and arrivals on the order of 400k some per day accumulate and can be kept for months ... tens of millions of records with 400k some inserts everyday for new flights and 400k some deletes everyday for old flights that are aged out (actually this tends to be partitioned into smaller subsets that are carrier specific).
PNR (passenger name record) can be a couple orders larger ... starts when the reservation is made ... possibly a couple months before the actual flight (hundred or so people per flt) and may be kept from a couple months to possibly a couple years. a few tens of millions reservations are made every day, a few tens of millions of updates for flights taken, and a few tens of millions of deletes as reservations are canceled or aged out ... the number of records should hover around the avg. number of reservations made per day (few tens of millions) times how long the records are kept (several hundred days). That can be several billion records ... the total size isn't too bad since PNR record information is fairly condensed and runs around 4k bytes ... frequently has lots of nulls for unknown information since they try and have everything in a single record read/write/update/insert/delete/etc ... so possibly only several terabytes aggregate. another kind of PNR null might be zip code field that is not applicable (as opposed to unknown) ... to get around possible SQL issues ... fill it in with anything as a substitute for actual null ... like the letters N/A. Then any mailing processing would have to know that N/A actually means null when it goes to generate an actual address (as opposed to the zip code: N/A). Not available information could be filled with N/A also (for not available as opposed to not applicable) or possibly UNKN ... which i've also seen used.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: what's the difference between LF (Line Fee) and NL (New line) ? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Wed, 13 Sep 2006 18:43:19 -0600CBFalconer <cbfalconer@yahoo.com> writes:
and thread/posts mentioning school:
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/2000d.html#46 Charging for time-share CPU time
http://www.garlic.com/~lynn/2002o.html#1 Home mainframes
http://www.garlic.com/~lynn/2002o.html#2 Home mainframes
http://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
http://www.garlic.com/~lynn/2004c.html#19 IT jobs move to India
http://www.garlic.com/~lynn/2004e.html#45 going w/o sleep
http://www.garlic.com/~lynn/2004g.html#0 Usenet invented 30 years ago by a Swede?
http://www.garlic.com/~lynn/2004k.html#41 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2006j.html#26 virtual memory
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: VAXen with switchmode power supplies? Newsgroups: comp.sys.dec,alt.folklore.computers Date: Thu, 14 Sep 2006 12:40:58 -0600Rob <intabits@optushome.com.au> writes:
so a 3031 was repackaged 158 with a pair of 158 engines ... one dedicated to 370 operation and one dedicated for channel operation.
a 3032 was a 370/168-3 repackaged to use channel director
a 3033 started out being 168 wiring diragram mapped to newer hardware technology (and using channel directors).
a two-way 3031 smp multiprocessor would have a pair of 158 engines doing 370 instruction set and a second set of 158 engines dedicated as channel director (for total of four 158 engines).
a picture of 3033 mentioning motor generator
http://www.grouchyoldcripple.com/archives/001620.html
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Very slow booting and running and brain-dead OS's? Newsgroups: alt.folklore.computers Date: Fri, 15 Sep 2006 08:18:09 -0600"Ancient_Hacker" <grg2@comcast.net> writes:
the univ. had gotten 360/67 for tss/360 ... but tss/360 only ran on weekends during test/debug sessions. then univ. got cp67 ... there were some A/B tests between tss/360 and cp67 running same fortran edit/compile/execute scripts ... tss/360 with four simulated users and cp67 with 35 simulated users.
another issue was that with the modern benefits of tss/360 one level store ... applications no longer had to worry about memory localities. compilers, applications, etc ... were laid out linearly in virtual memory. 768k real memory with a hog of tss/360 kernel taking maybe 512k ... and almost anything requiring much more than 256k to run decently.
cms remapped os/360 fortran-g ... which ran comfortably in 60k-80k.
there was a tss/360 uniprocessor (360/67, 1mbyte memory) / multiprocessor (two processors, 2mbyte memory) ... where the smp test had 3.8 times the thruput of the uniprocessor on the same workload. this was written up as the tss/360 advanced algorithms being able to scale (twice) multiprocessor at better than linear (more than twice the thruput, lot of hype?). in actual fact, the uniprocessor had less than 512k memory for applications (after fixed kernel) ... while the multiprocessor had a little over 1.5mbytes for applications (after fixed kernel). since tss/360 was actually severely real-storage constrained for those environments ... having nearly four times as much real storage available for applications (between the 1mbyte uniprocessor and the 2mbyte two processor) resulted in nearly four times the thruput.
misc. past mentioning tss/360:
http://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/95.html#1 pathlengths
http://www.garlic.com/~lynn/98.html#11 S/360 operating systems geneaology
http://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology
http://www.garlic.com/~lynn/2000f.html#18 OT?
http://www.garlic.com/~lynn/2000f.html#56 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001f.html#47 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001l.html#6 mainframe question
http://www.garlic.com/~lynn/2001l.html#7 mainframe question
http://www.garlic.com/~lynn/2001l.html#8 mainframe question
http://www.garlic.com/~lynn/2001m.html#49 TSS/360
http://www.garlic.com/~lynn/2002.html#36 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software
http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002d.html#23 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#36 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002f.html#36 Blade architectures
http://www.garlic.com/~lynn/2002f.html#37 Playing Cards was Re: looking for information on the IBM 7090
http://www.garlic.com/~lynn/2002f.html#42 Blade architectures
http://www.garlic.com/~lynn/2002f.html#53 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2002j.html#27 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002n.html#32 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#57 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002n.html#62 PLX
http://www.garlic.com/~lynn/2002n.html#64 PLX
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003d.html#58 POWER hashes vs tree
http://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003f.html#41 SLAC 370 Pascal compiler found
http://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
http://www.garlic.com/~lynn/2003g.html#31 Lisp Machines
http://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
http://www.garlic.com/~lynn/2003l.html#30 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#16 OSI not quite dead yet
http://www.garlic.com/~lynn/2003m.html#31 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003n.html#34 Macros and base register question
http://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
http://www.garlic.com/~lynn/2003p.html#14 64 bits vs non-coherent MPP was: Re: Itanium strikes again
http://www.garlic.com/~lynn/2003p.html#24 Mainframe Training
http://www.garlic.com/~lynn/2004c.html#9 TSS/370 binary distribution now available
http://www.garlic.com/~lynn/2004c.html#26 Moribund TSO/E
http://www.garlic.com/~lynn/2004c.html#47 IBM 360 memory
http://www.garlic.com/~lynn/2004c.html#60 IBM 360 memory
http://www.garlic.com/~lynn/2004c.html#61 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#0 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#5 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#10 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#21 REXX still going strong after 25 years
http://www.garlic.com/~lynn/2004d.html#66 System/360 40 years old today
http://www.garlic.com/~lynn/2004g.html#4 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#15 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#16 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004m.html#5 Tera
http://www.garlic.com/~lynn/2004n.html#3 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#4 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#5 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#25 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#55 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#2 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#5 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#2 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#4 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#9 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#11 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#27 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#41 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#44 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005c.html#18 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005j.html#16 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005k.html#8 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2005n.html#31 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#35 PART 3. Why it seems difficult to make an OOO VAX competitive
http://www.garlic.com/~lynn/2005o.html#43 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
http://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005s.html#17 winscape?
http://www.garlic.com/~lynn/2006.html#13 VM maclib reference
http://www.garlic.com/~lynn/2006.html#41 Is VIO mandatory?
http://www.garlic.com/~lynn/2006b.html#4 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
http://www.garlic.com/~lynn/2006d.html#6 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006e.html#31 MCTS
http://www.garlic.com/~lynn/2006e.html#33 MCTS
http://www.garlic.com/~lynn/2006f.html#19 Over my head in a JES exit
http://www.garlic.com/~lynn/2006g.html#3 The Pankian Metaphor
http://www.garlic.com/~lynn/2006i.html#22 virtual memory
http://www.garlic.com/~lynn/2006j.html#17 virtual memory
http://www.garlic.com/~lynn/2006j.html#38 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#14 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#41 PDP-1
http://www.garlic.com/~lynn/2006l.html#34 Dual Core CPUs are slower than Dual Single core CPUs ??
http://www.garlic.com/~lynn/2006m.html#30 Old Hashing Routine
http://www.garlic.com/~lynn/2006o.html#29 oops, cics
http://www.garlic.com/~lynn/2006o.html#51 The Fate of VM - was: Re: Baby MVS???
http://www.garlic.com/~lynn/2006p.html#22 Admired designs / designs to study
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: SHARE attendance Newsgroups: bit.listserv.ibm-main Date: Fri, 15 Sep 2006 08:25:39 -0600patrick.okeefe@ibm-main.lst (Patrick O'Keefe) writes:
i seem to also remember that some locations had various kinds of labor rules ... resulting in some claim that SHARE would never go back to those places.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Fri, 15 Sep 2006 11:54:50 -0600"Rostyslaw J. Lewyckyj" <urjlew@bellsouth.net> writes:
for resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
but that included a lot of validation of the resource management algorithms and control functions (under broad range of conditions, configurations, and workload ... aka including a lot of dynamic adaptive stuff) ... in addition to various kinds of failure modes.
early heavy stress testing resulted in numerous kernel failures. the result was rewriting the whole kernel serialization/synchronization infrastructure (to eliminate all observed failure modes) ... which was more code and significant more module hits ... than the resource manager itself. in later release, the code other than actual resource management ... was moved into the base system.
the final sequence prior to release involved 2000 benchmarks that took 3 months elapsed time (and the last 1000 involved an alrorithm that was looking for possible anomolous and boundary conditions ... which selected the next benchmark workload/configuration based on results of the benchmarks to date).
the base system process shipped maintenance tapes every month (called PLCs or program level change). initially they wanted resoure manager shipped monthly in sync. with standard PLC. I argued for only every three months. The resource manager was a research project ... releasing it as a product was much more of a hobby activity ... I wasn't part of any development or support organization. I also argued for requiring at a minimum 100 benchmarks for each updated PLC release of the resource manager ... and as a part-time effort, I wasn't prepared to do that every month.
as to the issue of moving (a lot of integrity, serialization,
synchronization and other code, like a bunch of stuff for kernel
organization for supporting smp)
http://www.garlic.com/~lynn/subtopic.html#smp
code out of the resource manager into the base system, there was a separate issue.
the original unbundling and starting to charge for software on 23jun69
(as a result of various gov. and other litigation efforts) argued that
it should only be for application code ... and that kernel code should
continue to be free.
http://www.garlic.com/~lynn/submain.html#unbundle
as things evolved during the 70s, there was beginning to be pressure to start charging for more and more code. the resource manager got chosen to be guinea pig for charging for specific kernel components (which eventually evolved into charging for all kernel components) ... and i got to spend time with business people working on policies for charging for kernel software components.
so in this transition period, the resource manager (and eventually other pieces) were charged for ... while the base kernel was free. moving over half of the code that had been in the initial resource manager into the base system ... wasn't just a packaging issue ... since it also met that the code went from "charged for" to "free".
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Admired designs / designs to study Newsgroups: comp.arch Date: Fri, 15 Sep 2006 12:16:25 -0600eugene@cse.ucsc.edu (Eugene Miya) writes:
might be interpreted as an adverse reaction to the failure of
Future System
http://www.garlic.com/~lynn/submain.html#futuresys
where FS appeared to try and include every admired feature that had ever been thot of ... 801 was trying to do the exact opposite.
a couple recent posts mentioning the subject
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#12 Another BIG Mainframe Bites the Dust
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Sat, 16 Sep 2006 07:20:18 -0600Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
they tended to have their own on-site people that did stuff like that
... sometimes they would even admit who they were at classes. some
past posts making reference to TLA (agency as opposed to acronym)
http://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that rans as slow as today's supercomputers
http://www.garlic.com/~lynn/2004m.html#50 EAL5
also when i did dumprx
http://www.garlic.com/~lynn/submain.html#dumprx
i tried to automate most of the most common examination sequences and categorize/classify what was being looked at and why for signatures of common failure modes (for some common things, dumprx would examine various things and then based on what it found look at certain other things).
i've posted before about locked cages ... but they were totally different
... the "testcells" in the disk engineering labs
http://www.garlic.com/~lynn/subtopic.html#disk
this was somewhat security proportional to risk ... at one point there was some civil litigation (damages for several billion) over theft of industrial information and the judge made some statement that security surrounding that information needed to be proportional to the value/risk ... otherwise it is supposedly something like the swimming pool attractive nuisance, your can be liable if somebody trespasses and drowns in your swimming pool; aka people can't be blamed for being naturally thieves and walking away with valuable stuff.
engineering development hardware and the associated design documents had multiple layers of security (included these heavy gage steal wire-mesh cages with combination locks).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Sat, 16 Sep 2006 08:49:14 -0600Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
in the late 60s, i thot that renton field datacenter might be the
largest in the world ... but Boyd was assigned at one time to run one
in far east that may have been larger. past post referencing
http://www.garlic.com/~lynn/2002j.html#43 Killer Hard Drives - Shrapnel?
http://www.garlic.com/~lynn/2003.html#51 Top Gun
http://www.garlic.com/~lynn/2003d.html#77 'Boyd': A military Strategist's Emphasis on Speed
http://www.garlic.com/~lynn/2004.html#2 The BASIC Variations
http://www.garlic.com/~lynn/2005m.html#22 Old Computers and Moisture don't mix - fairly OT
http://www.garlic.com/~lynn/2005m.html#23 Old Computers and Moisture don't mix - fairly OT
http://www.garlic.com/~lynn/2005m.html#24 Old Computers and Moisture don't mix - fairly OT
http://www.garlic.com/~lynn/2005t.html#1 Dangerous Hardware
http://www.garlic.com/~lynn/2005t.html#2 Dangerous Hardware
http://www.garlic.com/~lynn/2005t.html#5 Dangerous Hardware
one of the above references make mention that the far east nkp datacenter was a $2.5b windfall for ibm.
boyd had mentioned running nkp in his Pattern's of Conflict talk
http://www.garlic.com/~lynn/94.html#8 scheduling & dynamic adaptive ... long posting warning
and lots of other postings mentioning boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
and misc. URLs from around the web mentioning boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
i recently did scan of parts of some of his briefings (from '83) and a couple of the scanned pages I use as background for the subboyd.html file.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Sat, 16 Sep 2006 09:23:13 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
i have some vague recollection of somebody saying renton field datacenter/computer room was somewhere between $200m & $300m worth of ibm equipment. nkp at $2.5b would have been ten times larger?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Sat, 16 Sep 2006 13:17:58 -0600Charlton Wilbur <cwilbur@mithril.chromatico.net> writes:
where other approaches may be somewhat more iterative (and
what can be learned from a Maverick Fighter)
http://www.garlic.com/~lynn/2006q.html#13 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#17 Was FORTRAN buggy?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Sat, 16 Sep 2006 13:23:12 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
re:
http://www.garlic.com/~lynn/2006q.html#13 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#17 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#39 Was FORTRAN buggy?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: was change headers: The Fate of VM - was: Re: Baby MVS??? Newsgroups: alt.folklore.computers Date: Sat, 16 Sep 2006 16:51:05 -0600Larry Elmore <ljelmore@verizon.spammenot.net> writes:
misc. past posts:
http://www.garlic.com/~lynn/99.html#120 atomic History
http://www.garlic.com/~lynn/2001.html#29 Review of Steve McConnell's AFTER THE GOLD RUSH
http://www.garlic.com/~lynn/2001m.html#16 mainframe question
http://www.garlic.com/~lynn/2002d.html#36 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#38 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002q.html#33 Star Trek: TNG reference
http://www.garlic.com/~lynn/2003h.html#51 employee motivation & executive compensation
http://www.garlic.com/~lynn/2003p.html#27 The BASIC Variations
http://www.garlic.com/~lynn/2004k.html#24 Timeless Classics of Software Engineering
http://www.garlic.com/~lynn/2004q.html#86 Organizations with two or more Managers
http://www.garlic.com/~lynn/2006f.html#14 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#9 The Pankian Metaphor
Boyd characterized the German army as being composed of professional soldiers ... he contrasted that with the american army on entry into the war as being mostly inexperienced. the american strategy was then to leverage the relatively little experience by having a heavy, top-down direction of masses of inexperenced troops ... and rely on massive overwhelming resources, logistics and control.
Boyd characterized large US companies in the 80s as reflecting this training for managing large operations that many of the executives were indoctrinated in during the war.
This contrast somewhat permeated his organic design for command
and control briefing.
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
This was also reflected in Boyd's battle plan for desert storm. there was supposedly some comment that a problem going into the most recent conflict that Boyd had died in 1997. During desert storm there was a US news&report article that characterized the new generation of majors and colonels as Boyd's Jedi Knights.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Mon, 18 Sep 2006 12:13:04 -0600Andrew Swallow <am.swallow@btopenworld.com> writes:
the LSM was built at the los gatos lab ... used for circuit design
logic simulation (LSM originally stood for "los gatos state machine"
... but was changed to "logic simulation machine" for outside
publications). many of the logic verification techniques down thru the
years have assumed synchronous block design. LSM provided for clock
specification ... allow simulation of asynchronous clock designs
... as well as digital chips with analog circuits (i.e. was used for
thinfilm/floating disk head designs). post earlier this year
mentioning LSM
http://www.garlic.com/~lynn/2006.html#29 IBM microwave application--early data communications
LSM was rated at running circuit logic simulation 50,000 times faster
than equivalent software on 3033. older post mentioning LSM (compared
to 3033 for logic simulation)
http://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
the disk engineering lab had these "testcells" ... a recent post
mentioning
http://www.garlic.com/~lynn/2006q.html#36 Was FORTRAN buggy?
they had custom hardware boxes that would do numerous kinds of error injection. the testcells were a problem for operating systems ... besides the purposeful error injection, hardware under development could have large variety of error conditions and failure modes ... including numerous that would normally be considered forbotten and in violation of i/o architecture.
one of the issues was that attempting to run MVS on the connected processors resulted in MTBF for the operating system. As a result, testcell testing with processor was limited to stand-alone time using a custom monitor that did nothing but interact with (and report about) the hardware being tested.
so one of the things I undertook to do was rewrite the kernel i/o
subsystem (device drivers, interrupt handlers, error recovery, error
recording, RAS, etc) to be absolute bullet proof ... never cause the
operating system to fail or hang (this allowed concurrent testing of
several testcells simulateously connected to the same processor)
misc. past posts about disk engineering (bldg. 14) and disk product
test (bldg. 15) labs.
http://www.garlic.com/~lynn/subtopic.html#disk
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: 21st century =?utf-8?Q?pyramids=E2=80=93super?= datacenters Newsgroups: alt.folklore.computers Date: Mon, 18 Sep 2006 12:37:09 -0600"The guys are building the pyramids, but they don't know what for. Is it for searching? No. An Internet Assistant delivered on a custom basis that tells us how to run our business and lives -- how to get an edge is the ultimate best use of the real estate going forward," Mark said.
21st century pyramids--super datacenters
http://blogs.zdnet.com/BTL/?p=3625
from above:
Mark talked about 21st century pyramids, referring to the super datacenters Google, Amazon, Microsoft, Yahoo and others are building in energy-friendly territories.
misc. past posts in related threads:
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006l.html#6 Google Architecture
http://www.garlic.com/~lynn/2006l.html#7 Google Architecture
http://www.garlic.com/~lynn/2006l.html#8 Google Architecture
http://www.garlic.com/~lynn/2006l.html#24 Google Architecture
http://www.garlic.com/~lynn/2006l.html#26 Google Architecture
http://www.garlic.com/~lynn/2006l.html#27 Google Architecture
http://www.garlic.com/~lynn/2006l.html#28 Google Architecture
http://www.garlic.com/~lynn/2006l.html#31 Google Architecture
http://www.garlic.com/~lynn/2006l.html#32 Google Architecture
http://www.garlic.com/~lynn/2006l.html#33 Google Architecture
http://www.garlic.com/~lynn/2006l.html#37 Google Architecture
http://www.garlic.com/~lynn/2006m.html#43 Google Architecture
http://www.garlic.com/~lynn/2006n.html#12 Google Architecture
http://www.garlic.com/~lynn/2006n.html#56 AT&T Labs vs. Google Labs - R&D History
http://www.garlic.com/~lynn/2006o.html#15 Google Architecture
http://www.garlic.com/~lynn/2006o.html#28 Google Architecture
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: The not-so-little shop of 747s Newsgroups: alt.folklore.computers Date: Mon, 18 Sep 2006 17:44:09 -0600The not-so-little shop of 747s
the renton datacenter was replicated in everett, among other things for disaster survivability. at one point there was study that if the datacenter was out of operation for a week, it would cost the business more than the cost of the datacenter.
recent post mentioning renton datacenter
http://www.garlic.com/~lynn/2006q.html#37 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#38 Was FORTRAN buggy?
for other drift ... we coined the terms disaster survivability and
geographic survivability when we were doing ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Mon, 18 Sep 2006 21:48:10 -0600jmfbahciv writes:
there were easily several hundred internal datacenters with eventually a couple thousand processors running the software (across an extremely large range of configurations and workloads). at one point there was a study that internal locations had source modifications to vm370 kernel that in aggregate was approx. twice as many lines-of-code as in the shipped product.
share/waterloo had similar contributed library of customer kernel software modifications ... in aggregate which was also about twice the number of lines of code in the base, shipped product (i.e. customer datacenters had contributed their source kernel modifications to the share/waterloo library ... the total source lines of code changes were approx. the same aggregate lines of code as aggregate number of lines of code changes done by internal datacenters).
recent post about complete source distribution and source maintenance
http://www.garlic.com/~lynn/2006q.html#34 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#36 Was FORTRAN buggy?
including having done resource manager ... which was also complete source distribution (as updates/changes to base system).
Melinda has long paper on here web site titled VM and the VM
Community: Past, Present, and Future. At the same site there is also
a paper WHAT MOTHER NEVER TOLD YOU ABOUT VM SERVICE (talks
about source maintenance/update process).
http://www.leeandmelindavarian.com/Melinda/
http://www.leeandmelindavarian.com/Melinda#VMHist
there have been some number of posts/threads this year describing the
origins of vm370 multi-level source update process ... starting back
with cp67 with the (single level) source UPDATE program. This evolved
into the multi-level update process, originally in support of the
cp67h & cp67i effort to support 370 virtual machines under cp67,
original post:
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
later editor applications were enhanced to apply set of multi-level
UPDATE changes to the base source before starting edit process ...
and then to save all new deletes, updates, replaces, and inserts as a
new update (as an option ... as opposed to saving the complete modify
file). a few posts mentioning the multi-level source update process
http://www.garlic.com/~lynn/2006b.html#10 IBM 3090/VM Humor
http://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006f.html#38 Over my head in a JES exit
http://www.garlic.com/~lynn/2006n.html#45 sorting
http://www.garlic.com/~lynn/2006o.html#14 SEQUENCE NUMBERS
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Mon, 18 Sep 2006 22:07:35 -0600Anne & Lynn Wheeler <lynn@garlic.com> writes:
oh, and as to my "hobby" ... the resource manager ...
it passed 1000 paid licenses in less than six months after first
customer ship. not only was i providing development, maintenance,
documentation, classes, testing, product ship, etc ... as per earlier
post
http://www.garlic.com/~lynn/2006q.html#34 Was FORTRAN buggy
http://www.garlic.com/~lynn/2006q.html#36 Was FORTRAN buggy
but for the first six months i also answered all problem calls.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Smartcard reader with certificate inside the reader. Newsgroups: alt.technology.smartcards Date: Tue, 19 Sep 2006 10:29:53 -0600gerlach <mpx@nospam.hoga.pl> writes:
to have private key that co-signs transactions w/o actually requiring
PKI and/or digital certificates
http://www.garlic.com/~lynn/subpubkey.html#certless
in part because certificate-based operation can result in enormous
payload bloat for some transactions (in addition to being redundant
and superfluous)
http://www.garlic.com/~lynn/subpubkey.html#bloat
EU Finread terminal has its own pinpad and display as countermeasure to various exploits & vulnerabilities ... virus/trojans on PCs, keyloggers, displaying information different than what is being signed, using logged pins to perform signed transactions w/o the victims knowledge, etc.
the issue for the relying party is how do they actually know that a card is being used in a normal PC environment or is actually being done in conjunction with a certified (eu finread?) terminal ... w/o having the terminal actually co-signing the transactions and attesting to the higher integrity key-signing transaction environment.
part of this was in conjunction with the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the result was x9.59 financial standard.
the x9.59 standard doesn't require that a terminal (and/or other environment that the transaction is performed in) actually co-sign every transaction, however the standard was crafted such that it allows a terminal (or other device) to co-sign a transaction, as an indication of possible higher integrity (or physical location or other characteristics that a relying party might be interested in when evaluated risk related to a transaction).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Smartcard reader with certificate inside the reader. Newsgroups: alt.technology.smartcards Date: Tue, 19 Sep 2006 11:58:33 -0600re:
independent of whether the terminal has a private key and can perform digital signing operations ... there are terminals which may include a PKI stack for doing digital signature verification operations.
an example would be point-of-sale financial terminals supporting chip&pin.
chip&pin has had static data authentication deployments for going on ten years(?). this is where the chip can present something akin to a digital ceritificate (w/o performing its own signing operation) to the terminal ... and the terminal can verify the digital certificate.
however, since it is static data ... it turned out to be subject to skimming, in much the same way that magstripe data can be skimmed and which is then used to produce a counterfeit card.
chip&pin is nominally two-factor authentication ... from the 3-factor
authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are
where the chip/card is something you have authentication and the pin
is something you know authentication. normally, multi-factor
authentication is considered higher security and integrity when the
different factors have independent faulure and exploits. pin
(something you know) is frequently considered countermeasure to
lost/stolen cards ("somehting you have").
the issue in some of the magstripe skimming scenarios is that the magstripe information and the pin information are skimmed at the same time (resulting in a common exploit, and invalidating assumption about independent failure/exploits).
the "static data" chip&pin had a different kind of exploit with
counterfeit yes cards ... see last paragraph of this archived
information from 2002
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
where it mentions that yes cards have been well known for some time and the details on creating yes cards were widely available from the internet.
the issue in the yes card exploit is that the authentication "static data" is skimmed and loading into a counterfeit card.
the terminal, once it had validated the authentication information would then "ask" (a supposedly valid card): 1) whether the entered pin was correct, 2) whether the transaction should be offline, and 3) whether the transaction was within the account's credit limit. as you might guess from the yes card label ... a counterfeit yes card would answer YES to such questions. in this scenario, there was not an independent exploit with regard to the entered pin ... once the counterfeit yes card had been created ... it would answer YES to whatever pin was entered (no longer requiring the attacker to know valid pins ... and negating any assumption regarding multi-factor authentication).
lots of collected posts mentioning exploits, threats, vulnerabilities
and fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud
the countermeasure to the "static data" authentication yes card exploit ... is to possibly have the chip sign some random data presented by the terminal. the chip then returns both the (dynamic data) digital signature and the digital certificate. the terminal then validates the digital certificate (like it does now) and then uses the certificate's public key to validate the chip's (dynamic data) digital signature.
note that this might still be vulnerable to a MITM-attack
http://www.garlic.com/~lynn/subintegrity.html#mitm
where a counterfeit yes card is paired with some valid card ... the yes card passes the initial authentication sequence transparently between the valid card and the terminal ... and then performs the YES response to all subsequent operations.
misc. collected posts discussing yes cards
http://www.garlic.com/~lynn/subintegrity.html#yescard
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Tue, 19 Sep 2006 16:59:16 -0600Peter Flass <Peter_Flass@Yahoo.com> writes:
this was running regularly at cambridge a year before first 370 engineering model was operational. when endicott had an engineering model 370/145 ready to boot (lore is that ipl/boot button was actually a knife switch) ... cp67i kernel was brought in to boot as test of the machine.
the initial boot failed ... after a little diagnostic, it was determined that the engineering machine had reversed the "B2" opcodes for two instructions (i believe PTLB and RRB). the cp67i kernel was quickly patched and reboot then went successfully.
since this was the first engineering prototype machine ... it was quickly patched to correspond to the official architecture definition.
recent posts mentioning cp67h and cp67i updates for the cp67 kernel
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
I've also mentioned another problem with getting vm370 up and
running on 370/125 ... recent post mentioning the effort
http://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
360 instructions would pretest starting and ending addresses for argument ... for things like protection (fetch & store) or page fault (at least on 360/67) ... and indicate exception before even starting the instruction. 370 introduced a couple (long) instructions that executed incrementally. machine would process "long" (compare, move) instruction argument locations incrementally and only indicate fault/exception when it encountered storage access problem (for storage address being directly processed).
move long had two pair of registers, with origin start&length and destination start&length. on instruction completion (or exception) the registers would indicate how far processing had gotten (incrementing argument addresses and decrementing remaining length). move long also provide for "pad" byte for scenario where origin length was less than destination length. it was possible to use this for clearing storage by setting the pad byte to zero, the origin length to zero and the destination length to the desired amount.
early vm370 kernel used mvcl early in the boot process to both clear memory and test for size of memory (by setting destination length to max). when the instruction encountered end-of-memory would would result in exception and the registers would be update to reflect where end-of-memory was.
early 370/125s were shipped to customers with a "bug" in the long instructions microcode ... it would "pretest" starting and ending argument addresses and cause an exception interrupt if there was a problem before even starting the instruction (instead of executing the instructions incrementally and only generate exception when it got to argument storage address with an issue).
as a result, vm370 would think there was no real storage on 370/125 to execute in and fail.
besides having to optimize vm370 kernel size to fit it into 370/125 256kbytes, it also had to be modified to get around the 125 mvcl microcode "bug" (at least until 125s were retrofitted with fix).
misc. past posts mentioning the MVCL bug on 370/125
http://www.garlic.com/~lynn/2000c.html#49 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000g.html#8 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001f.html#69 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2002i.html#2 Where did text file line ending characters begin?
http://www.garlic.com/~lynn/2002i.html#9 More about SUN and CICS
http://www.garlic.com/~lynn/2003.html#13 FlexEs and IVSK instruction
http://www.garlic.com/~lynn/2003j.html#27 A Dark Day
http://www.garlic.com/~lynn/2004b.html#26 determining memory size
http://www.garlic.com/~lynn/2004c.html#33 separate MMU chips
http://www.garlic.com/~lynn/2004g.html#54 effeciently resetting a block of memory
http://www.garlic.com/~lynn/2006.html#12 Zeroing core
http://www.garlic.com/~lynn/2006n.html#46 Why is z series so CPU poor?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Tue, 19 Sep 2006 17:45:45 -0600re:
I had a similar but different problem with 3880 disk controller.
I recently made a post about doing a bullet proof i/o subsystem
for bldg. 14 & bldg. 15
http://www.garlic.com/~lynn/2006q.html#42 Was FORTRAN buggy?
and have mentioned in the past that now being responsible for the
operating systems in this environment ... I would frequently be the
first person blamed if there was a problem. numerous collected
past posts
http://www.garlic.com/~lynn/subtopic.html#disk
I've posted before about an incident in bldg. 15 when the engineers
had replaced a 3830 disk controller (for a string of disks used for
internal time-sharing) with a 3880 disk controller ... and performance
significantly degraded ... and I was first to blame as possibly having
made a kernel change over the weekend (since they hadn't changed any
hardware).
http://www.garlic.com/~lynn/2000c.html#75 Does the word "mainframe" still have a meaning?>
http://www.garlic.com/~lynn/2001h.html#28 checking some myths.
http://www.garlic.com/~lynn/2002b.html#2 Microcode? (& index searching)
http://www.garlic.com/~lynn/2004p.html#61 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
earlier I had gotten embroiled in a similar but different problem with the same 3880 disk controller engineering effort. as mentioned in the above posts ... the 3830 had switched from a (fast) horizontal microcode engine to 3880 with a much slower vertical microcode engine ... that was dedicated to control operation with a spearate data path to handle pure data transfer (including the increase to 3mbytes/sec transfer).
part of the issue was that new hardware had to be at least plus/minus five percent of the previous hardware. the slower jib-prime in the 3880 was taking longer to get an operation started and longer to clean-up an operation after data transfer completed. while operations with 3380 had 3mbyte transfer offsetting the slower control operations. however, if 3880 controller was just replacing 3830 with existing disks ... all operations appeared to take longer. the "performance" problem mentioned above involved situation where they had the 3880 telling the processor that operation was complete before it had finished all the cleanup operation.
there was actually a similar problem with 3880 several months earlier. at this time, they had the 3880 presenting i/o operation complete before they had started cleanup and hadn't check for some specific i/o errors. if they found i/o errors at this point they were forced to present "unsolicited unit check" interrupt condition to the processor.
I periodically reviewed what was going on and noticed the "unsolicated unit checks" ... and informed the 3880 controller engineers that this was a violation of the i/o architecture ... i.e. "unit check" conditions (i.e. i/o errors) always had to be presented with an operation that they were associated with ... and "unsolited unit checks" (i.e. unit check interrupt not associated with any operation) were violation of I/O architecture.
This got me dragged into conference calls between the san jose disk controller engineers and the POK channel engineers ... as sort of intermediary. Eventually it was resolved, that unsolicited unit checks were violation of channel I/O architecture and the disk controller engineers had to fix the 3880. They had to move signal completion of operation until after they had finished checking for all possible i/o error conditions (so any possible i/o error condition could be included in ending status). In a few rare instances, they saved them and presented them the next time a new operation was initiated.
Afterwards I asked why was I being dragged into it. the answer was that i apparently was one of the few people in san jose who understood channel i/o architecture. this had been handled in the past by the senior engineers ... but so many senior engineers had been hired away over the years ... that almost none were left.
I had to know channel i/o architecture ... not only for the rewrite of the i/o supervisor to make it bullet proof ... but also for the correct operation of the virtual machine emulated i/o
old post detailing some of the defections
http://www.garlic.com/~lynn/2002.html#17 index searching
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Intel abandons USEnet news Newsgroups: comp.arch Date: Wed, 20 Sep 2006 08:22:33 -0600"Seongbae Park" <Seongbae.Park@gmail.com> writes:
misc. old post on using browser tab support:
http://www.garlic.com/~lynn/2004e.html#54 Is there a way to configure your web browser to use multiple
http://www.garlic.com/~lynn/2005e.html#48 Mozilla v Firefox
http://www.garlic.com/~lynn/2005e.html#50 Mozilla v Firefox
http://www.garlic.com/~lynn/2005e.html#55 Mozilla v Firefox
http://www.garlic.com/~lynn/2005e.html#60 Mozilla v Firefox
http://www.garlic.com/~lynn/2005e.html#66 Mozilla v Firefox
http://www.garlic.com/~lynn/2005n.html#8 big endian vs. little endian, why?
http://www.garlic.com/~lynn/2005n.html#15 1.8b2 / 1.7.11 tab performance
http://www.garlic.com/~lynn/2005n.html#41 Moz 1.8 performance dramatically improved
http://www.garlic.com/~lynn/2005o.html#13 RFC 2616 change proposal to increase speed
even with significant higher bandwidth (dialed vis-a-vis broadband) there can still be issue with remote site load and/or infrastructure congestion.
i've mostly used emacs gnus for quiet awhile for newsreading ... and it tries to do some heuristic asynchronous read-ahead (and does support offline processing).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Smartcard reader with certificate inside the reader. Newsgroups: alt.technology.smartcards Date: Wed, 20 Sep 2006 09:38:33 -0600gerlach <mpx@nospam.hoga.pl> writes:
check some of the eu standards sites ... like:
http://istresults.cordis.europa.eu/index.cfm/section/news/tpl/article/BrowsingType/Features/ID/579
http://cordis.europa.eu/fetch?ACTION=D&CALLER=PROJ_IST&QM_EP_RCN_A=58338
http://cordis.europa.eu/fetch?ACTION=D&CALLER=PROJ_IST&QM_EP_RCN_A=58404
are you talking about windows only enabling/allowing use of a certified reader/terminal ... or the card/token verifying that it is interacting with a certified reader/terminal?
the original kerberos pk-init
http://www.garlic.com/~lynn/subpubkey.html#kerberos
(underlying authentication mechanism in windows and several other
platforms) originally only specified a certificate-less mode of
operation for public key and digital signature authentication
http://www.garlic.com/~lynn/subpubkey.html#certless
i.e. public key is registered in lieu of password ... and kerberos verifies digital signature on some random data (dynamic data authentication as countermeasure to replay attacks).
there was some effort applied then to include certificate-mode of operation in the kerberos pk-init specification (in addition to certificate less).
a couple years ago, i got email from the person claiming primary
responsibility for forcing certificate operation into the kerberos
pk-init specification ... and apologizing (finally realizing that it
was redundant and superfluous). he was associated with some of the
GRID activities and invited me to give a certificate-less talk at the
next annual grid forum.
http://forge.ggf.org/sf/docman/do/listDocuments/projects.ogsa-wg/docman.root.meeting_materials_and_minutes.ggf_meetings.ggf11
http://forge.ggf.org/sf/go/doc12899;jsessionid=E86ACAF7A29F2E1FC2575AD0CD04E39E?nav=1
various kerberos rfcs ... from my ietf rfc index
http://www.garlic.com/~lynn/rfcietff.htm
select Term (term->RFC#) in the RFCs listed by section ... and then
scroll/find "Kerberos" ... i.e.
kerberos
see also authentication , generic security service , security
4559 4557 4556 4537 4430 4402 4121 4120 3962 3961 3244 3129 2942
2712 2623 1964 1510 1411
clicking on an RFC number brings up the summary for that RFC. in
the summary field, clicking on the ".txt=nnnn" field, retrieves
the actual RFC.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Wed, 20 Sep 2006 10:04:04 -0600Steve O'Hara-Smith <steveo@eircom.net> writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Wed, 20 Sep 2006 12:20:27 -0600Steve O'Hara-Smith <steveo@eircom.net> writes:
a couple recent postings mentioning 747 and everett
http://www.garlic.com/~lynn/2006q.html#37 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#38 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#44 The not-so-little shop of 747s
one of the problems with autopilot flying 747 was that the glide path into seatac airport was automatically acquired and followed ... resulting in 747 landings all happening within a couple feet of each other ... resulting in severe strain and cracking in the runway at that position. they had to modify the software so that it slightly randomized the path so it spread out the actual landings over wider area.
one of the claims for the 757/767/777 was that the requirement for faa certification flights were significantly reduced (compared to the 747) by the use of advanced design and modeling software (besides use of software used in controlling the plane).
one of the other issues was that much of the design software came from a french company and there were some concerns about industrial espionage and/or competitive advantage with possibility that airbus would get the most/more advanced software features.
for additional topic drift ... recent comment
http://www.garlic.com/~lynn/aadsm25.htm#29
in thread mentioning 787 and some software and other issues
https://financialcryptography.com/mt/archives/000678.html
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Wed, 20 Sep 2006 13:07:40 -0600"Rostyslaw J. Lewyckyj" <urjlew@bellsouth.net> writes:
my first student programming job was to port a 1401 tape<->unitrecord application (which provided front-end to 709) to 360. the 360/30 was brought in and replaced the 1401 and initially ran in 1401 emulation much of the time (if somebody has access to 360/30 front panel or picture that can be blown up in enuf detail ... you should find the rotory switch setting for emulation mode).
i was to design and implement a 360 monitor that did everything the 1401 program did (card->tape, tape->printer/punch). i got to design and implement my own monitor, dispatcher, storage manager, interrupt handler, device drivers, etc.
eventually the 709 and 360/30 was replaced with 360/67 supposedly to run tss/360 ... but actual ran in 360/65 (non-virtual memory) mode most of the time with os/360.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Thu, 21 Sep 2006 08:37:56 -0600"Rostyslaw J. Lewyckyj" <urjlew@bellsouth.net> writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Thu, 21 Sep 2006 08:51:27 -0600Peter Flass <Peter_Flass@Yahoo.com> writes:
there was switch on front panel that put the machine into 1401 mode, you put a 1401 program card deck into the 2540 card reader and hit load button. 360/30 didn't have separate microcode dynamic storage and microcode instructions were physically encoded in the machine.
litle search engine and found this
http://mail.computerhistory.org/pipermail/1401_team/2006q1/000062.html
370 was initially announced and shipped to customers w/o virtual memory. as a result you couldn't use virtual memory to provide partitioning as part of virtual machine support. the 370 emulation assist support had a DIL(?) instruction which provided base/bound address relocation ... physical contiguous area of real storage. one of the IBM SEs on the Boeing account did a highly modified version of cp67 on early 370s that provided virtual machine support (more like modern LPAR stuff) w/o any paging.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Intel abandons USEnet news Newsgroups: comp.arch Date: Thu, 21 Sep 2006 09:07:21 -0600"Del Cecchi" <delcecchiofthenorth@gmail.com> writes:
the original mainframe display terminal was 3272 controller and 3277 terminal. this was updated to 3274 controller and other 327x terminals (when then moved a lot of the electronics that had been in the 3277 terminal back into the controller ... cutting down on terminal manufacturing cost).
a lot of uptake for ibm/pc was in commercial/business ... where terminal emulation allowed a single keyboard/display footprint on the desk to provide both terminal emulation mainframe access as well as some local computing capability (and in same price range as an ibm 327x terminal).
the local computing capability then saw some involvement with more sophisticated terminal emulation applications that did some amount of automated stuff using technology like "screen scraping" ... i.e. software providing automated capture and input. as applications evolved, the screen scaping technology got to be more and more of a bottleneck ... and there were two directions: 1) move to much more efficient interfaces and protocol between mainframe and desktop and 2) replicate more and more of the glasshouse data at the desktop (and/or local department servers).
#1 was strongly opposed by the communication division because it replaced their installed terminal controller hardware base with other products. the result was that there started a period of huge leakage of data out of the glasshouse. SAA was somewhat the communication divisions attempt to counter dataprocessing leaving the glasshouse (while still preserving there installed hardware base).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: TCPA compatible smarcard readers? Newsgroups: alt.technology.smartcards Date: Thu, 21 Sep 2006 12:35:21 -0600gerlach <mpx@nospam.hoga.pl> writes:
note that the certificate becomes redundant and superfluous once the
public key has been registered.
http://www.garlic.com/~lynn/subpubkey.html#certless
somewhat related thread regarding being able to determine chip
integrity using similar approach
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP: snake oil or good idea?
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#2 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#5 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#6 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#10 Crypto to defend chip IP: snake oil or good idea?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Was FORTRAN buggy? Newsgroups: alt.folklore.computers Date: Fri, 22 Sep 2006 08:13:25 -0600KR Williams <krw@att.bizzzz> writes:
with ibm being the only company achieving the single, most important business requirement .... they could have all sorts of other short comings and still come out dominant.
... one could conjecture back then that a lot of companies were undergoing rapid growth ... they would get into dataprocessing to achieve certain level of efficiencies ... but then find that with the rapid growth .. they would constantly needing to upgrade their computer. the cost of having to continually having to do conversion ... and possibly having to be severely limited during conversion ... by far dominated many other factors.
misc. past posts mentioning the BUNCH and/or the single most important
business requirement to be successful in the computer business
http://www.garlic.com/~lynn/2001j.html#38 Big black helicopters
http://www.garlic.com/~lynn/2001j.html#39 Big black helicopters
http://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
http://www.garlic.com/~lynn/2002c.html#0 Did Intel Bite Off More Than It Can Chew?
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
http://www.garlic.com/~lynn/2003.html#36 mainframe
http://www.garlic.com/~lynn/2003b.html#61 difference between itanium and alpha
http://www.garlic.com/~lynn/2003o.html#43 Computer folklore - forecasting Sputnik's orbit with
http://www.garlic.com/~lynn/2004h.html#15 Possibly stupid question for you IBM mainframers... :-)
http://www.garlic.com/~lynn/2004l.html#14 Xah Lee's Unixism
http://www.garlic.com/~lynn/2005k.html#0 IBM/Watson autobiography--thoughts on?
http://www.garlic.com/~lynn/2005k.html#4 IBM/Watson autobiography--thoughts on?
http://www.garlic.com/~lynn/2005o.html#23 Collins C-8401 computer?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Wars and Allies Newsgroups: alt.folklore.computers Date: Fri, 22 Sep 2006 12:00:45 -0600CBFalconer <cbfalconer@yahoo.com> writes:
from above:
The influenza pandemic of 1918-1919 killed more people than the Great
War, known today as World War I (WWI), at somewhere between 20 and 40
million people. It has been cited as the most devastating epidemic in
recorded world history. More people died of influenza in a single
year than in four-years of the Black Death Bubonic Plague from 1347
to 1351. Known as "Spanish Flu" or "La Grippe" the influenza of
1918-1919 was a global disaster.
... snip, and a little more
The pandemic affected everyone. With one-quarter of the US and
one-fifth of the world infected with the influenza, it was impossible
to escape from the illness. Even President Woodrow Wilson suffered
from the flu in early 1919 while negotiating the crucial treaty of
Versailles to end the World War (Tice). Those who were lucky enough
to avoid infection had to deal with the public health ordinances to
restrain the spread of the disease. The public health departments
distributed gauze masks to be worn in public. Stores could not hold
sales, funerals were limited to 15 minutes. Some towns required a
signed certificate to enter and railroads would not accept passengers
without them. Those who ignored the flu ordinances had to pay steep
fines enforced by extra officers (Deseret News). Bodies pilled up as
the massive deaths of the epidemic ensued. Besides the lack of health
care workers and medical supplies, there was a shortage of coffins,
morticians and gravediggers (Knox). The conditions in 1918 were not
so far removed from the Black Death in the era of the bubonic plague
of the Middle Ages.
... snip ...
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Cray-1 Anniversary Event - September 21st Newsgroups: alt.folklore.computers Date: Fri, 22 Sep 2006 12:25:26 -0600stanb45@dial.pipex.com (Stan Barr) writes:
in the mid-80s, i remember comming back from a business trip across the pacific (to contract for some hardware) and making the observation that a $300 cdrom drive had much better technology than various pieces of "computer gear" costing fifty times as much.
in the late 80s and early 90s similar observations somewhat led to the
commerce dept. backing some of the hdtv format wars. misc. past
posts mentioning the hdtv format wars
http://www.garlic.com/~lynn/2000e.html#11 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2001.html#73 how old are you guys
http://www.garlic.com/~lynn/2001b.html#2 FCC rulemakings on HDTV
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2005k.html#25 The 8008
http://www.garlic.com/~lynn/2006.html#45 IBM 610 workstation computer
misc. past posts making some reference to the same business trip:
http://www.garlic.com/~lynn/94.html#33b High Speed Data Transport (HSDT)
http://www.garlic.com/~lynn/2000b.html#69 oddly portable machines
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001k.html#57 SMP idea for the future
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002g.html#76 Pipelining in the past
http://www.garlic.com/~lynn/2003b.html#67 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003d.html#23 CPU Impact of degraded I/O
http://www.garlic.com/~lynn/2003m.html#59 SR 15,15
http://www.garlic.com/~lynn/2003n.html#33 Cray to commercialize Red Storm
http://www.garlic.com/~lynn/2004g.html#12 network history
http://www.garlic.com/~lynn/2004n.html#29 Is Fast Path headed nowhere?
http://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
http://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005n.html#25 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005r.html#9 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005u.html#57 IPCS Standard Print Service
http://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006i.html#17 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006n.html#56 AT&T Labs vs. Google Labs - R&D History