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
https://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
https://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
https://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
https://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
https://www.garlic.com/~lynn/2006d.html#21 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006j.html#21 virtual memory
https://www.garlic.com/~lynn/2006k.html#30 PDP-1
https://www.garlic.com/~lynn/2006m.html#21 The very first text editor
https://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
https://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
https://www.garlic.com/~lynn/2006m.html#41 Why Didn't The Cent Sign or the Exclamation Mark Print?
https://www.garlic.com/~lynn/2006m.html#42 Why Didn't The Cent Sign or the Exclamation Mark Print?
https://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.
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
https://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
https://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2004q.html#0 Single User: Password or Certificate
https://www.garlic.com/~lynn/2005g.html#8 On smartcards and card readers
https://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2005m.html#37 public key authentication
https://www.garlic.com/~lynn/2005p.html#6 Innovative password security
https://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
https://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
https://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
https://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
https://www.garlic.com/~lynn/2006p.html#31 25th Anniversary of the Personal Computer
https://www.garlic.com/~lynn/2006p.html#34 25th Anniversary of the Personal Computer
https://www.garlic.com/~lynn/2006p.html#36 25th Anniversary of the Personal Computer
https://www.garlic.com/~lynn/2006p.html#39 25th Anniversary of the Personal Computer
semi-related post
https://www.garlic.com/~lynn/2001h.html#64 UUCP email
lots of collected past postings on 3-tier computing
https://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
https://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:
https://www.garlic.com/~lynn/2006p.html#49 Materiel and graft
https://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:
https://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
https://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
https://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#25 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#33 Threatwatch - 2-factor tokens attacked by phishers
https://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#16 Fraudwatch - Chip&PIN one-sided story, banks and deception and liability shifts
https://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006e.html#4 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006e.html#10 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#30 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
https://www.garlic.com/~lynn/2006g.html#38 Why are smart cards so dumb?
https://www.garlic.com/~lynn/2006h.html#13 Security
https://www.garlic.com/~lynn/2006h.html#15 Security
https://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor
https://www.garlic.com/~lynn/2006i.html#3 Spoofing fingerprint scanners - NEWBIE()
https://www.garlic.com/~lynn/2006k.html#0 Passwords for bank sites - change or not?
https://www.garlic.com/~lynn/2006l.html#27 Google Architecture
https://www.garlic.com/~lynn/2006l.html#33 Google Architecture
https://www.garlic.com/~lynn/2006o.html#40 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006o.html#47 the personal data theft pandemic continues
https://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)
https://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
https://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
https://www.garlic.com/~lynn/2006p.html#43 Slow-Going For Next-Generation Threat-Scoring System
older post looking at the categorizing of exploits
https://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE
and slightly more recent post discussing the categorizing of exploits
https://www.garlic.com/~lynn/2005b.html#20 Buffer overruns
and lots of collected posts on the subject of exploits, vulnerabilities,
threats and fraud
https://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):
https://www.garlic.com/~lynn/2006.html#39 What happens if CR's are directly changed?
https://www.garlic.com/~lynn/2006e.html#1 About TLB in lower-level caches
https://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
https://www.garlic.com/~lynn/2003d.html#57 Another light on the map going out
https://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
https://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
https://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/99.html#28 IBM S/360
https://www.garlic.com/~lynn/99.html#69 System/1 ?
https://www.garlic.com/~lynn/99.html#193 Back to the original mainframe model?
https://www.garlic.com/~lynn/2000c.html#63 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#66 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000c.html#67 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000g.html#23 IBM's mess
https://www.garlic.com/~lynn/2001k.html#30 3270 protocol
https://www.garlic.com/~lynn/2001k.html#33 3270 protocol
https://www.garlic.com/~lynn/2001k.html#46 3270 protocol
https://www.garlic.com/~lynn/2001l.html#32 mainframe question
https://www.garlic.com/~lynn/2001m.html#17 3270 protocol
https://www.garlic.com/~lynn/2001m.html#19 3270 protocol
https://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#48 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#50 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
https://www.garlic.com/~lynn/2002j.html#74 Itanium2 power limited?
https://www.garlic.com/~lynn/2002j.html#77 IBM 327x terminals and controllers (was Re: Itanium2 power
https://www.garlic.com/~lynn/2002k.html#2 IBM 327x terminals and controllers (was Re: Itanium2 power
https://www.garlic.com/~lynn/2002k.html#6 IBM 327x terminals and controllers (was Re: Itanium2 power
https://www.garlic.com/~lynn/2002q.html#51 windows office xp
https://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
https://www.garlic.com/~lynn/2003c.html#69 OT: One for the historians - 360/91
https://www.garlic.com/~lynn/2003c.html#72 OT: One for the historians - 360/91
https://www.garlic.com/~lynn/2003d.html#23 CPU Impact of degraded I/O
https://www.garlic.com/~lynn/2003d.html#24 CPU Impact of degraded I/O
https://www.garlic.com/~lynn/2003e.html#43 IBM 3174
https://www.garlic.com/~lynn/2003h.html#15 Mainframe Tape Drive Usage Metrics
https://www.garlic.com/~lynn/2003i.html#30 A Dark Day
https://www.garlic.com/~lynn/2003j.html#24 Red Phosphor Terminal?
https://www.garlic.com/~lynn/2003k.html#20 What is timesharing, anyway?
https://www.garlic.com/~lynn/2003k.html#22 What is timesharing, anyway?
https://www.garlic.com/~lynn/2003o.html#14 When nerds were nerds
https://www.garlic.com/~lynn/2003o.html#36 When nerds were nerds
https://www.garlic.com/~lynn/2003p.html#44 Mainframe Emulation Solutions
https://www.garlic.com/~lynn/2004c.html#30 Moribund TSO/E
https://www.garlic.com/~lynn/2004e.html#0 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2004f.html#54 [HTTP/1.0] Content-Type Header
https://www.garlic.com/~lynn/2004g.html#11 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#24 |d|i|g|i|t|a|l| questions
https://www.garlic.com/~lynn/2004g.html#27 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#13 Device and channel
https://www.garlic.com/~lynn/2005h.html#40 Software for IBM 360/30
https://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#14 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#15 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#17 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#20 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#28 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005s.html#17 winscape?
https://www.garlic.com/~lynn/2005s.html#45 winscape?
https://www.garlic.com/~lynn/2005u.html#22 Channel Distances
https://www.garlic.com/~lynn/2006b.html#21 IBM 3090/VM Humor
https://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
https://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)
https://www.garlic.com/~lynn/2003c.html#35 difference between itanium and alpha
some other posts mentioning full-screen operation and performance
https://www.garlic.com/~lynn/2001h.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
https://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).
https://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
https://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.
https://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
https://www.garlic.com/~lynn/subboyd.html#boyd
and various URLs from around the web mentioning Boyd
https://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:
https://www.garlic.com/~lynn/2004e.html#19 Message To America's Students: The War, The Draft, Your Future
https://www.garlic.com/~lynn/2005r.html#3 The 8008
https://www.garlic.com/~lynn/2006b.html#27 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006b.html#33 IBM 610 workstation computer
https://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
https://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
https://www.garlic.com/~lynn/2001i.html#51 DARPA was: Short Watson Biography
https://www.garlic.com/~lynn/2002p.html#29 Vector display systems
https://www.garlic.com/~lynn/2004l.html#27 Shipwrecks
https://www.garlic.com/~lynn/2004l.html#32 Shipwrecks
https://www.garlic.com/~lynn/2004m.html#8 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"
https://www.garlic.com/~lynn/2006e.html#28 MCTS
https://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:
https://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
https://www.garlic.com/~lynn/2005r.html#24 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005u.html#6 Fast action games on System/360+?
https://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"
https://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
https://www.garlic.com/~lynn/subboyd.html#boyd
and various URL web pages mentioning Boyd
https://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
https://www.garlic.com/~lynn/2006i.html#28 virtual memory
https://www.garlic.com/~lynn/2006i.html#30 virtual memory
https://www.garlic.com/~lynn/2006i.html#31 virtual memory
https://www.garlic.com/~lynn/2006i.html#32 virtual memory
https://www.garlic.com/~lynn/2006i.html#33 virtual memory
https://www.garlic.com/~lynn/2006i.html#36 virtual memory
https://www.garlic.com/~lynn/2006i.html#37 virtual memory
https://www.garlic.com/~lynn/2006i.html#38 virtual memory
https://www.garlic.com/~lynn/2006i.html#39 virtual memory
https://www.garlic.com/~lynn/2006i.html#40 virtual memory
https://www.garlic.com/~lynn/2006j.html#0 virtual memory
https://www.garlic.com/~lynn/2006j.html#1 virtual memory
https://www.garlic.com/~lynn/2006j.html#2 virtual memory
https://www.garlic.com/~lynn/2006j.html#3 virtual memory
https://www.garlic.com/~lynn/2006j.html#4 virtual memory
https://www.garlic.com/~lynn/2006j.html#5 virtual memory
https://www.garlic.com/~lynn/2006j.html#7 virtual memory
https://www.garlic.com/~lynn/2006j.html#13 virtual memory
https://www.garlic.com/~lynn/2006j.html#14 virtual memory
https://www.garlic.com/~lynn/2006j.html#17 virtual memory
https://www.garlic.com/~lynn/2006j.html#18 virtual memory
https://www.garlic.com/~lynn/2006j.html#19 virtual memory
https://www.garlic.com/~lynn/2006j.html#20 virtual memory
https://www.garlic.com/~lynn/2006j.html#21 virtual memory
https://www.garlic.com/~lynn/2006j.html#22 virtual memory
https://www.garlic.com/~lynn/2006j.html#23 virtual memory
https://www.garlic.com/~lynn/2006j.html#24 virtual memory
https://www.garlic.com/~lynn/2006j.html#25 virtual memory
https://www.garlic.com/~lynn/2006j.html#26 virtual memory
https://www.garlic.com/~lynn/2006j.html#27 virtual memory
https://www.garlic.com/~lynn/2006j.html#30 virtual memory
https://www.garlic.com/~lynn/2006j.html#31 virtual memory
https://www.garlic.com/~lynn/2006j.html#37 virtual memory
https://www.garlic.com/~lynn/2006j.html#39 virtual memory
https://www.garlic.com/~lynn/2006j.html#40 virtual memory
https://www.garlic.com/~lynn/2006j.html#41 virtual memory
https://www.garlic.com/~lynn/2006j.html#43 virtual memory
https://www.garlic.com/~lynn/2006j.html#44 virtual memory
https://www.garlic.com/~lynn/2006k.html#44 virtual memory
https://www.garlic.com/~lynn/2006k.html#57 virtual memory
https://www.garlic.com/~lynn/2006l.html#2 virtual memory
https://www.garlic.com/~lynn/2006l.html#3 virtual memory
https://www.garlic.com/~lynn/2006l.html#5 virtual memory
https://www.garlic.com/~lynn/2006l.html#9 virtual memory
https://www.garlic.com/~lynn/2006l.html#10 virtual memory
https://www.garlic.com/~lynn/2006l.html#11 virtual memory
https://www.garlic.com/~lynn/2006l.html#12 virtual memory
https://www.garlic.com/~lynn/2006l.html#13 virtual memory
https://www.garlic.com/~lynn/2006l.html#14 virtual memory
https://www.garlic.com/~lynn/2006l.html#15 virtual memory
https://www.garlic.com/~lynn/2006l.html#16 virtual memory
https://www.garlic.com/~lynn/2006l.html#17 virtual memory
https://www.garlic.com/~lynn/2006l.html#18 virtual memory
https://www.garlic.com/~lynn/2006l.html#19 virtual memory
https://www.garlic.com/~lynn/2006l.html#40 virtual memory
https://www.garlic.com/~lynn/2006l.html#48 virtual memory
https://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
https://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:
https://www.garlic.com/~lynn/2006.html#7 EREP , sense ... manual
https://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
https://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:
https://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
https://www.garlic.com/~lynn/2003g.html#40 How to cope with missing values - NULLS?
https://www.garlic.com/~lynn/2004f.html#2 Quote of the Week
https://www.garlic.com/~lynn/2004l.html#75 NULL
https://www.garlic.com/~lynn/2005.html#15 Amusing acronym
https://www.garlic.com/~lynn/2005b.html#17 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005i.html#35 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005m.html#19 Implementation of boolean types
https://www.garlic.com/~lynn/2005t.html#20 So what's null then if it's not nothing?
https://www.garlic.com/~lynn/2005t.html#23 So what's null then if it's not nothing?
https://www.garlic.com/~lynn/2005t.html#33 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005u.html#12 3vl 2vl and NULL
https://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)
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000f.html#20 Competitors to SABRE?
https://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
https://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
https://www.garlic.com/~lynn/2002j.html#83 Summary: Robots of Doom
https://www.garlic.com/~lynn/2003o.html#17 Rationale for Supercomputers
https://www.garlic.com/~lynn/2004b.html#6 Mainframe not a good architecture for interactive workloads
https://www.garlic.com/~lynn/2004o.html#23 Demo: Things in Hierarchies (w/o RM/SQL)
https://www.garlic.com/~lynn/2004q.html#85 The TransRelational Model: Performance Concerns
https://www.garlic.com/~lynn/2005o.html#24 is a computer like an airport?
https://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back
https://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
https://www.garlic.com/~lynn/2006p.html#55 PowerPC or PARISC
https://www.garlic.com/~lynn/2006q.html#8 Is no one reading the article?
https://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
https://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, HSDT email
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)
https://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
https://www.garlic.com/~lynn/rfcietff.htm
and note on the merged taxonomies and glossaries
https://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.
https://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
https://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
https://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.
https://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
https://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
https://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
https://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
https://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
https://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
https://www.garlic.com/~lynn/subnetwork.html#hsdt
recent posts discussing spool file system rewrite
https://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006o.html#64 The Fate of VM - was: Baby MVS???
https://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
https://www.garlic.com/~lynn/subboyd.html#boyd
and misc. URLs from around the web mentioning boyd
https://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:
https://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
https://www.garlic.com/~lynn/2000d.html#46 Charging for time-share CPU time
https://www.garlic.com/~lynn/2002o.html#1 Home mainframes
https://www.garlic.com/~lynn/2002o.html#2 Home mainframes
https://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
https://www.garlic.com/~lynn/2004c.html#19 IT jobs move to India
https://www.garlic.com/~lynn/2004e.html#45 going w/o sleep
https://www.garlic.com/~lynn/2004g.html#0 Usenet invented 30 years ago by a Swede?
https://www.garlic.com/~lynn/2004k.html#41 Vintage computers are better than modern crap !
https://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:
https://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
https://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
https://www.garlic.com/~lynn/95.html#1 pathlengths
https://www.garlic.com/~lynn/98.html#11 S/360 operating systems geneaology
https://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology
https://www.garlic.com/~lynn/2000f.html#18 OT?
https://www.garlic.com/~lynn/2000f.html#56 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001f.html#47 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
https://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
https://www.garlic.com/~lynn/2001l.html#5 mainframe question
https://www.garlic.com/~lynn/2001l.html#6 mainframe question
https://www.garlic.com/~lynn/2001l.html#7 mainframe question
https://www.garlic.com/~lynn/2001l.html#8 mainframe question
https://www.garlic.com/~lynn/2001m.html#49 TSS/360
https://www.garlic.com/~lynn/2002.html#36 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
https://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software
https://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
https://www.garlic.com/~lynn/2002d.html#23 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002d.html#36 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002f.html#36 Blade architectures
https://www.garlic.com/~lynn/2002f.html#37 Playing Cards was Re: looking for information on the IBM 7090
https://www.garlic.com/~lynn/2002f.html#42 Blade architectures
https://www.garlic.com/~lynn/2002f.html#53 WATFOR's Silver Anniversary
https://www.garlic.com/~lynn/2002j.html#27 Unisys A11 worth keeping?
https://www.garlic.com/~lynn/2002n.html#32 why does wait state exist?
https://www.garlic.com/~lynn/2002n.html#57 SHARE MVT Project anniversary
https://www.garlic.com/~lynn/2002n.html#62 PLX
https://www.garlic.com/~lynn/2002n.html#64 PLX
https://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
https://www.garlic.com/~lynn/2003d.html#58 POWER hashes vs tree
https://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
https://www.garlic.com/~lynn/2003f.html#41 SLAC 370 Pascal compiler found
https://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
https://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
https://www.garlic.com/~lynn/2003g.html#31 Lisp Machines
https://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
https://www.garlic.com/~lynn/2003l.html#30 Secure OS Thoughts
https://www.garlic.com/~lynn/2003m.html#16 OSI not quite dead yet
https://www.garlic.com/~lynn/2003m.html#31 SR 15,15 was: IEFBR14 Problems
https://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
https://www.garlic.com/~lynn/2003n.html#34 Macros and base register question
https://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
https://www.garlic.com/~lynn/2003p.html#14 64 bits vs non-coherent MPP was: Re: Itanium strikes again
https://www.garlic.com/~lynn/2003p.html#24 Mainframe Training
https://www.garlic.com/~lynn/2004c.html#9 TSS/370 binary distribution now available
https://www.garlic.com/~lynn/2004c.html#26 Moribund TSO/E
https://www.garlic.com/~lynn/2004c.html#47 IBM 360 memory
https://www.garlic.com/~lynn/2004c.html#60 IBM 360 memory
https://www.garlic.com/~lynn/2004c.html#61 IBM 360 memory
https://www.garlic.com/~lynn/2004d.html#0 IBM 360 memory
https://www.garlic.com/~lynn/2004d.html#5 IBM 360 memory
https://www.garlic.com/~lynn/2004d.html#10 IBM 360 memory
https://www.garlic.com/~lynn/2004d.html#21 REXX still going strong after 25 years
https://www.garlic.com/~lynn/2004d.html#66 System/360 40 years old today
https://www.garlic.com/~lynn/2004g.html#4 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#15 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#16 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004m.html#5 Tera
https://www.garlic.com/~lynn/2004n.html#3 Shipwrecks
https://www.garlic.com/~lynn/2004n.html#4 RISCs too close to hardware?
https://www.garlic.com/~lynn/2004n.html#5 RISCs too close to hardware?
https://www.garlic.com/~lynn/2004n.html#25 Shipwrecks
https://www.garlic.com/~lynn/2004n.html#55 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004o.html#2 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004o.html#5 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#2 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005b.html#4 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005b.html#9 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005b.html#11 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005b.html#27 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005b.html#41 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#44 The mid-seventies SHARE survey
https://www.garlic.com/~lynn/2005c.html#18 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005j.html#16 Performance and Capacity Planning
https://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005k.html#8 virtual 360/67 support in cp67
https://www.garlic.com/~lynn/2005n.html#31 Code density and performance?
https://www.garlic.com/~lynn/2005n.html#35 PART 3. Why it seems difficult to make an OOO VAX competitive
https://www.garlic.com/~lynn/2005o.html#43 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
https://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005s.html#17 winscape?
https://www.garlic.com/~lynn/2006.html#13 VM maclib reference
https://www.garlic.com/~lynn/2006.html#41 Is VIO mandatory?
https://www.garlic.com/~lynn/2006b.html#4 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
https://www.garlic.com/~lynn/2006d.html#6 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006e.html#31 MCTS
https://www.garlic.com/~lynn/2006e.html#33 MCTS
https://www.garlic.com/~lynn/2006f.html#19 Over my head in a JES exit
https://www.garlic.com/~lynn/2006g.html#3 The Pankian Metaphor
https://www.garlic.com/~lynn/2006i.html#22 virtual memory
https://www.garlic.com/~lynn/2006j.html#17 virtual memory
https://www.garlic.com/~lynn/2006j.html#38 The Pankian Metaphor
https://www.garlic.com/~lynn/2006k.html#14 The Pankian Metaphor
https://www.garlic.com/~lynn/2006k.html#41 PDP-1
https://www.garlic.com/~lynn/2006l.html#34 Dual Core CPUs are slower than Dual Single core CPUs ??
https://www.garlic.com/~lynn/2006m.html#30 Old Hashing Routine
https://www.garlic.com/~lynn/2006o.html#29 oops, cics
https://www.garlic.com/~lynn/2006o.html#51 The Fate of VM - was: Re: Baby MVS???
https://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
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://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)
https://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.
https://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
https://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
https://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
https://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)
https://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that rans as slow as today's supercomputers
https://www.garlic.com/~lynn/2004m.html#50 EAL5
also when i did dumprx
https://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
https://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
https://www.garlic.com/~lynn/2002j.html#43 Killer Hard Drives - Shrapnel?
https://www.garlic.com/~lynn/2003.html#51 Top Gun
https://www.garlic.com/~lynn/2003d.html#77 'Boyd': A military Strategist's Emphasis on Speed
https://www.garlic.com/~lynn/2004.html#2 The BASIC Variations
https://www.garlic.com/~lynn/2005m.html#22 Old Computers and Moisture don't mix - fairly OT
https://www.garlic.com/~lynn/2005m.html#23 Old Computers and Moisture don't mix - fairly OT
https://www.garlic.com/~lynn/2005m.html#24 Old Computers and Moisture don't mix - fairly OT
https://www.garlic.com/~lynn/2005t.html#1 Dangerous Hardware
https://www.garlic.com/~lynn/2005t.html#2 Dangerous Hardware
https://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
https://www.garlic.com/~lynn/94.html#8 scheduling & dynamic adaptive ... long posting warning
and lots of other postings mentioning boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
and misc. URLs from around the web mentioning boyd
https://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)
https://www.garlic.com/~lynn/2006q.html#13 Was FORTRAN buggy?
https://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:
https://www.garlic.com/~lynn/2006q.html#13 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006q.html#17 Was FORTRAN buggy?
https://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:
https://www.garlic.com/~lynn/99.html#120 atomic History
https://www.garlic.com/~lynn/2001.html#29 Review of Steve McConnell's AFTER THE GOLD RUSH
https://www.garlic.com/~lynn/2001m.html#16 mainframe question
https://www.garlic.com/~lynn/2002d.html#36 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002d.html#38 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002q.html#33 Star Trek: TNG reference
https://www.garlic.com/~lynn/2003h.html#51 employee motivation & executive compensation
https://www.garlic.com/~lynn/2003p.html#27 The BASIC Variations
https://www.garlic.com/~lynn/2004k.html#24 Timeless Classics of Software Engineering
https://www.garlic.com/~lynn/2004q.html#86 Organizations with two or more Managers
https://www.garlic.com/~lynn/2006f.html#14 The Pankian Metaphor
https://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.
https://www.garlic.com/~lynn/subboyd.html#boyd
https://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
https://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)
https://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
the disk engineering lab had these "testcells" ... a recent post
mentioning
https://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.
https://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:
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
https://www.garlic.com/~lynn/2006l.html#6 Google Architecture
https://www.garlic.com/~lynn/2006l.html#7 Google Architecture
https://www.garlic.com/~lynn/2006l.html#8 Google Architecture
https://www.garlic.com/~lynn/2006l.html#24 Google Architecture
https://www.garlic.com/~lynn/2006l.html#26 Google Architecture
https://www.garlic.com/~lynn/2006l.html#27 Google Architecture
https://www.garlic.com/~lynn/2006l.html#28 Google Architecture
https://www.garlic.com/~lynn/2006l.html#31 Google Architecture
https://www.garlic.com/~lynn/2006l.html#32 Google Architecture
https://www.garlic.com/~lynn/2006l.html#33 Google Architecture
https://www.garlic.com/~lynn/2006l.html#37 Google Architecture
https://www.garlic.com/~lynn/2006m.html#43 Google Architecture
https://www.garlic.com/~lynn/2006n.html#12 Google Architecture
https://www.garlic.com/~lynn/2006n.html#56 AT&T Labs vs. Google Labs - R&D History
https://www.garlic.com/~lynn/2006o.html#15 Google Architecture
https://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
https://www.garlic.com/~lynn/2006q.html#37 Was FORTRAN buggy?
https://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
https://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
https://www.garlic.com/~lynn/2006q.html#34 Was FORTRAN buggy?
https://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).
https://www.leeandmelindavarian.com/Melinda/
https://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:
https://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
https://www.garlic.com/~lynn/2006b.html#10 IBM 3090/VM Humor
https://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
https://www.garlic.com/~lynn/2006f.html#38 Over my head in a JES exit
https://www.garlic.com/~lynn/2006n.html#45 sorting
https://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
https://www.garlic.com/~lynn/2006q.html#34 Was FORTRAN buggy
https://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
https://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)
https://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
https://www.garlic.com/~lynn/x959.html#x959
https://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
https://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
https://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
https://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
https://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
https://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
https://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
https://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
https://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
https://www.garlic.com/~lynn/2000c.html#49 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000g.html#8 360/370 instruction cycle time
https://www.garlic.com/~lynn/2001f.html#69 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2002i.html#2 Where did text file line ending characters begin?
https://www.garlic.com/~lynn/2002i.html#9 More about SUN and CICS
https://www.garlic.com/~lynn/2003.html#13 FlexEs and IVSK instruction
https://www.garlic.com/~lynn/2003j.html#27 A Dark Day
https://www.garlic.com/~lynn/2004b.html#26 determining memory size
https://www.garlic.com/~lynn/2004c.html#33 separate MMU chips
https://www.garlic.com/~lynn/2004g.html#54 effeciently resetting a block of memory
https://www.garlic.com/~lynn/2006.html#12 Zeroing core
https://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
https://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
https://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).
https://www.garlic.com/~lynn/2000c.html#75 Does the word "mainframe" still have a meaning?>
https://www.garlic.com/~lynn/2001h.html#28 checking some myths.
https://www.garlic.com/~lynn/2002b.html#2 Microcode? (& index searching)
https://www.garlic.com/~lynn/2004p.html#61 IBM 3614 and 3624 ATM's
https://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
https://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:
https://www.garlic.com/~lynn/2004e.html#54 Is there a way to configure your web browser to use multiple
https://www.garlic.com/~lynn/2005e.html#48 Mozilla v Firefox
https://www.garlic.com/~lynn/2005e.html#50 Mozilla v Firefox
https://www.garlic.com/~lynn/2005e.html#55 Mozilla v Firefox
https://www.garlic.com/~lynn/2005e.html#60 Mozilla v Firefox
https://www.garlic.com/~lynn/2005e.html#66 Mozilla v Firefox
https://www.garlic.com/~lynn/2005n.html#8 big endian vs. little endian, why?
https://www.garlic.com/~lynn/2005n.html#15 1.8b2 / 1.7.11 tab performance
https://www.garlic.com/~lynn/2005n.html#41 Moz 1.8 performance dramatically improved
https://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
https://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
https://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
https://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
https://www.garlic.com/~lynn/2006q.html#37 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006q.html#38 Was FORTRAN buggy?
https://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
https://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.
https://www.garlic.com/~lynn/subpubkey.html#certless
somewhat related thread regarding being able to determine chip
integrity using similar approach
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#5 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#6 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
https://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
https://www.garlic.com/~lynn/2001j.html#38 Big black helicopters
https://www.garlic.com/~lynn/2001j.html#39 Big black helicopters
https://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
https://www.garlic.com/~lynn/2002c.html#0 Did Intel Bite Off More Than It Can Chew?
https://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
https://www.garlic.com/~lynn/2003.html#36 mainframe
https://www.garlic.com/~lynn/2003b.html#61 difference between itanium and alpha
https://www.garlic.com/~lynn/2003o.html#43 Computer folklore - forecasting Sputnik's orbit with
https://www.garlic.com/~lynn/2004h.html#15 Possibly stupid question for you IBM mainframers... :-)
https://www.garlic.com/~lynn/2004l.html#14 Xah Lee's Unixism
https://www.garlic.com/~lynn/2005k.html#0 IBM/Watson autobiography--thoughts on?
https://www.garlic.com/~lynn/2005k.html#4 IBM/Watson autobiography--thoughts on?
https://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
https://www.garlic.com/~lynn/2000e.html#11 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2001.html#73 how old are you guys
https://www.garlic.com/~lynn/2001b.html#2 FCC rulemakings on HDTV
https://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2005k.html#25 The 8008
https://www.garlic.com/~lynn/2006.html#45 IBM 610 workstation computer
misc. past posts making some reference to the same business trip:
https://www.garlic.com/~lynn/94.html#33b High Speed Data Transport (HSDT)
https://www.garlic.com/~lynn/2000b.html#69 oddly portable machines
https://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2001k.html#57 SMP idea for the future
https://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
https://www.garlic.com/~lynn/2002g.html#76 Pipelining in the past
https://www.garlic.com/~lynn/2003b.html#67 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003d.html#23 CPU Impact of degraded I/O
https://www.garlic.com/~lynn/2003m.html#59 SR 15,15
https://www.garlic.com/~lynn/2003n.html#33 Cray to commercialize Red Storm
https://www.garlic.com/~lynn/2004g.html#12 network history
https://www.garlic.com/~lynn/2004n.html#29 Is Fast Path headed nowhere?
https://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
https://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005n.html#25 Data communications over telegraph circuits
https://www.garlic.com/~lynn/2005r.html#9 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005u.html#57 IPCS Standard Print Service
https://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006i.html#17 blast from the past on reliable communication
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
https://www.garlic.com/~lynn/2006n.html#56 AT&T Labs vs. Google Labs - R&D History