List of Archived Posts

2006 Newsgroup Postings (09/06 - 06/22)

PowerPC or PARISC?
Materiel and graft
Your Mother Saves Data on Eight-Track Tapes
Device Authentication - The answer to attacks lauched using stolen passwords?
Another BIG Mainframe Bites the Dust
Materiel and graft
SAT Reading and Math Scores Show Decline
Linux More Secure on System z?
Is no one reading the article?
Is no one reading the article?
what's the difference between LF(Line Fee) and NL (New line) ?
what's the difference between LF(Line Fee) and NL (New line) ?
Another BIG Mainframe Bites the Dust
Was FORTRAN buggy?
Greatest Software Ever Written?
The Fate of VM - was: Re: Baby MVS???
what's the difference between LF(Line Fee) and NL (New line) ?
Was FORTRAN buggy?
Difference between server and workstation
virtual memory
virtual memory
virtual memory
3 value logic. Why is SQL so special?
3 value logic. Why is SQL so special?
"25th Anniversary of the Personal Computer"
garlic.com
garlic.com
dcss and page mapped filesystem
was change headers: The Fate of VM - was: Re: Baby MVS???
3 value logic. Why is SQL so special?
what's the difference between LF (Line Fee) and NL (New line) ?
VAXen with switchmode power supplies?
Very slow booting and running and brain-dead OS's?
SHARE attendance
Was FORTRAN buggy?
Admired designs / designs to study
Was FORTRAN buggy?
Was FORTRAN buggy?
Was FORTRAN buggy?
Was FORTRAN buggy?
Was FORTRAN buggy?
was change headers: The Fate of VM - was: Re: Baby MVS???
Was FORTRAN buggy?
21st century pyramids--super datacenters
The not-so-little shop of 747s
Was FORTRAN buggy?
Was FORTRAN buggy?
Smartcard reader with certificate inside the reader
Smartcard reader with certificate inside the reader
Was FORTRAN buggy?
Was FORTRAN buggy?
Intel abandons USEnet news
Smartcard reader with certificate inside the reader
Was FORTRAN buggy?
Was FORTRAN buggy?
Was FORTRAN buggy?
Was FORTRAN buggy?
Was FORTRAN buggy?
Intel abandons USEnet news
TCPA compatible smarcard readers?
Was FORTRAN buggy?
Wars and Allies
Cray-1 Anniversary Event - September 21st

PowerPC or PARISC?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PowerPC or PARISC?
Newsgroups: comp.arch
Date: Wed, 06 Sep 2006 14:58:02 -0600
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Thanks. The trouble with SQL, TPC-C etc. is that they all work perfectly well with more-or-less incoherent shared memory, and therefore don't prove whether the coherence is enough for things like OpenMP and POSIX threads. As you know, I regard that less-coherent model as what vendors SHOULD be providing, but it is important to know what a design does and what it doesn't.

re:
http://www.garlic.com/~lynn/2006p.html#55 PowerPC or PARISC?

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.

Materiel and graft

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Materiel and graft
Newsgroups: alt.folklore.computers
Date: Wed, 06 Sep 2006 16:05:09 -0600
re:
http://www.garlic.com/~lynn/2006p.html#49 Materiel and graft

After success of 360, the technical gurus were really riding high, and they were given some latitude for FS
http://www.garlic.com/~lynn/submain.html#futuresys

(which i somewhat characterized as the inmates being in charge of the institution). when FS failed ... the pendulum somewhat started to swing in the other direction (non-technical, business types taking over more control of the company). a recent post mentioning FS
http://www.garlic.com/~lynn/2006p.html#50 what's the difference between LF(Line Fee) and NL (New line) ?

for whatever reason, the disk division got a new non-engineer, non-technical president in the late 70s.

The los gatos lab (bldg. 29) had been built in the 60s on 200 acres of undeveloped land and was a award winning showcase location. They later had problems because some amount of the construction was custom ... like custom sized redwood plywood (instead of standard 4x8) ... and it was effectively impossible to get any new replacement.

the new president had a house over near the los gatos lab and decided that his office should be near his house ... rather than over in the hdqtrs building on the san jose plant site. he had the back part of the los gatos lab redone for him and small set of his executive staff; executive area got carpeted floors, the exterior walls and windows were redone with countermeasures for various kinds of evesdropping and snooping, and the corridor that executives might take from their area to the lab lunch room also got carpeting (the lab somewhat taking on dual personality, the engineer and hardware areas retained their tile floors while the executive areas were all differentiated by their carpeted floors). there was also going to be a special executive drive-way, small executive parking area, and special executive entrance (for the executive area).

before the drive-way, parking area, and private executive entrance was constructed (but after the interior changes had been made), the disk division got a new president with hardware background ... who wanted his office to be on the main plant site, in the middle of the business.

This happened about the time I was getting HSDT project going
http://www.garlic.com/~lynn/subnetwork.html#hsdt

and I was able to somewhat take advantage of the situation to acquire much of the vacant "executive" office space in los gatos lab (that never even saw any of its new occupants).

so, how does this all tie-in with the referenced post (mentioning sherpa, apa6670)?

I had first met Pete Sih in the early 70s as part of the cp67 "h" and "i" effort (develop support for 370 virtual memory on cp67 360/67 infrastructure). The cp67i system was designed to run on real 370s (but original run in 370 virtual machine under cp67h running on real 360/67 for the first year of its existance). Pete was one of three people that came out from the san jose disk division ... to add block-mux channel along with 3330 and 2305 device support to the "cp67i" system ... later sometimes referred to as the "cp67sj" system (enabling cp67sj system to run on real 370/145s supporting real 3330 and real 2305 devices).

Later, Pete was (still) living not too far from the los gatos lab ... but having to commute up to the palo alto science center. So a deal was cut for Pete to have one of the vacant "executive" offices (in the back of the los gatos lab) and minimize his having to commute to the palo alto science center.

Even later, Pete, my wife, and I departed the company on the same day. Bldg. 29 was eventually demolished and the 200 acres sold off for housing development.

a few recent posts mentioning cp67h and cp67i systems
http://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
http://www.garlic.com/~lynn/2006d.html#21 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006j.html#21 virtual memory
http://www.garlic.com/~lynn/2006k.html#30 PDP-1
http://www.garlic.com/~lynn/2006m.html#21 The very first text editor
http://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
http://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
http://www.garlic.com/~lynn/2006m.html#41 Why Didn't The Cent Sign or the Exclamation Mark Print?
http://www.garlic.com/~lynn/2006m.html#42 Why Didn't The Cent Sign or the Exclamation Mark Print?
http://www.garlic.com/~lynn/2006n.html#21 The System/360 Model 20 Wasn't As Bad As All That

Your Mother Saves Data on Eight-Track Tapes

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 -0600
Al Kossow writes:
Haven't checked to see if it matches the format of Whirlwind

somebody mentioned sizes of radar domes ... so doing some web searching ....
http://www.garlic.com/~lynn/aadsm25.htm#23Introducing the new HavenCo location

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

Device Authentication - The answer to attacks lauched using stolen passwords?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Lassi Hippeläinen writes:
If you loose the device, you are in trouble, because you loose all services that are bound to that device.

It might be possible to subscribe to services with several redundant devices, but that will cause problems with synchronization, DRM, subscription cost, or any combination of the above.


re:
http://www.garlic.com/~lynn/2006p.html#41 Device Authentication - The answer to attacks lauched using stolen passwords?
http://www.garlic.com/~lynn/2006p.html#48 Device Authentication - The answer to attacks lauched using stolen passwords?

there have been numerous discussions in the past regarding unique authentication tokens per service ... vis-a-vis a single (or small number) of authentication tokens ... where an individual token is used for multiple different services.

frequently this is associated with an institutional-centric paradigm ... where each institution/service provides their own unique token ... w/o even offering the end-user a choice.

however, some number of studies have turned up that in the majority of the institutional centric paradigms ... the end-users are managing their tokens as a unit ... and the most common failure mode will involve all such tokens aka credit cards all in the same wallet/purse (the most common lost/stolen scenario is the wallet/purse involving all such authentication tokens).

various past posts on institutional-centric paradigms vis-a-vis person-centric paradigm ... where the individual has a choice on how many tokens they choose to carry ... and which services are bound to which tokens.
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2004q.html#0 Single User: Password or Certificate
http://www.garlic.com/~lynn/2005g.html#8 On smartcards and card readers
http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005p.html#6 Innovative password security
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
http://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security

Another BIG Mainframe Bites the Dust

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Daniel_McLaughlin writes:
I think a lot of it boils back down to what is needed. I'm not a huge fan of server technology (20,000 chickens pulling a plow) but since we don't run PROFS any longer, Locust notes is how I do e-mail.

recent post about some early 2-tier (mainframe) operations ... justifying server plus distributed operation
http://www.garlic.com/~lynn/2006p.html#40 25th Anniversary of the Personal Computer

some of the other posts in the thread on early evoluation of 2-tier & 3-tier computing
http://www.garlic.com/~lynn/2006p.html#31 25th Anniversary of the Personal Computer
http://www.garlic.com/~lynn/2006p.html#34 25th Anniversary of the Personal Computer
http://www.garlic.com/~lynn/2006p.html#36 25th Anniversary of the Personal Computer
http://www.garlic.com/~lynn/2006p.html#39 25th Anniversary of the Personal Computer

semi-related post
http://www.garlic.com/~lynn/2001h.html#64 UUCP email

lots of collected past postings on 3-tier computing
http://www.garlic.com/~lynn/subnetwork.html#3tier

especially during the hey day of SAA when we were out doing customer executive presentations on 3-tier ... and lots of SAA was much more oriented towards the preservation of the terminal emulation paradigm
http://www.garlic.com/~lynn/subnetwork.html#emulation

Materiel and graft

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Materiel and graft
Newsgroups: alt.folklore.computers
Date: Thu, 07 Sep 2006 12:39:19 -0600
Anne & Lynn Wheeler writes:
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.

warning ... lots more drift ...

re:
http://www.garlic.com/~lynn/2006p.html#49 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft

a few web references mentioning los gatos lab turned up by search engine

An early microcomputer (Was: Original Origins of Intel 4004)
http://mail.computerhistory.org/pipermail/inforoots/2004-November/000761.html
IBM 3624
https://en.wikipedia.org/wiki/IBM_3624
IBM slices 135 acres from 'bank account'
http://sanjose.bizjournals.com/sanjose/stories/1996/09/02/story3.html?page=2
People Involved with ACS
http://www.cs.clemson.edu/~mark/acs_people.html

which also found a number of my old posts mentioning the los gatos lab (even the wikipedia article has reference to one of my posts).

part of the original land for the los gatos lab was hillside (that had the san jose dump behind it) ... which may or may not have been included in the 135 acres sold off for housing development (that or what I was told in the dark past about it being 200 acres was off, or maybe the hillside was donated to the city or county).

the wikipedia article mentions that 3624 introduced PIN block format for the transmission of encrypted PINs. which then points at the entry for PINs:
https://en.wikipedia.org/wiki/Personal_identification_number

the "intel 4004" reference also discusses early 2984 ATM machine work at the lab.

other reference list 1972 for 2984, 1973 for 3614, and 1979 for 3624

the above also discusses a weakness discovered in 2002 in the 3624 PIN block format.

the wikipedia PIN artile also references EMV "Chip and PIN" using PIN
https://en.wikipedia.org/wiki/Chip_and_PIN

a few recent posts mentioning "Chip and PIN", yes cards, and/or issues with multi-factor authentication:
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
http://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#25 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#33 Threatwatch - 2-factor tokens attacked by phishers
http://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#16 Fraudwatch - Chip&PIN one-sided story, banks and deception and liability shifts
http://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#4 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006e.html#10 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#30 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006g.html#38 Why are smart cards so dumb?
http://www.garlic.com/~lynn/2006h.html#13 Security
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor
http://www.garlic.com/~lynn/2006i.html#3 Spoofing fingerprint scanners - NEWBIE()
http://www.garlic.com/~lynn/2006k.html#0 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006l.html#27 Google Architecture
http://www.garlic.com/~lynn/2006l.html#33 Google Architecture
http://www.garlic.com/~lynn/2006o.html#40 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006o.html#47 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security

SAT Reading and Math Scores Show Decline

Refed: **, - **, - **, - **, - **
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 -0600
A new SAT study hot off the presses?
Males have greater G: sex differences in general mental ability
http://www.eurekalert.org/pub_releases/2006-09/uowo-mhg090506.php

A study of 100,000 17- to 18-year-olds on the Scholastic Assessment Test published in the September 2006 issue of the journal Intelligence, has confirmed a surprising new finding-that men have a 4- to 5-point IQ advantage over women by adulthood. Because girls mature faster than boys, the sex difference is masked during the school years, which explains why the sex difference was missed for 100 years.


Linux More Secure on System z?

Refed: **, - **, - **
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 -0600
timothy.sipples@ibm-main.lst (Timothy Sipples) writes:
The first thing to say is that Linux is Linux, so for anyone who still thinks that Linux is somehow emulated on System z, it's not. When you run Linux on the mainframe it's a 31-bit or 64-bit Linux kernel (and programs) running native ESA/390 or z/Architecture processor instructions.

lots of past posts discussing typical c language programming and execution ... resulting in lots of buffer related vulnerabilities. part of this is that implicit string and buffer lengths tend to be extremely prevelent in c programming styles, programmers make assumptions that no buffer operations will exceed the buffer target ... and these assumptions can be used by attackers
http://www.garlic.com/~lynn/subintegrity.html#overflow

at one point the majority of exploits (in c language environments) were length related. attackers would include machine executable instructions (would be tailored for the victim machine) in various incoming data ... and manage to contrive the processor to transfer to those instructions. the problem became so serious on many platforms that hardware countermeasure was introduced in the past couple years ... somewhat akin to 360 storage protection. however, instead of data store/fetch protection ... it is i-stream fetch protection. standard data store/fetch operations work ... but if the processor attempts to fetch instructions from the protected location there is a fault (as countermeasure to attackers introducing malicious instructions hidden in data streams and leverage short comings in data length handling). a past post mentioning hardware no-execute storage protection (with some web references)
http://www.garlic.com/~lynn/2005.html#1 Buffer overruns

trivial search engine use looking for references to various kinds of hardware support for no-execute will turn up lots more.

however, the rise in the use of automatic scripting associated with many application environments has somewhat changed the exploits. this attack pattern was identified on the internal network in the 70s. lots of past posts about the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

note that scripting exploits tend to be machine architecture neutral since its tends to involve interpreted code.

as various applications added support for automatic execution of embedded scripts in data files (email, etc) ... the ratio changed. At one point studies found exploits to be broken down: 1/3rd automatic scripting, 1/3rd (still) buffer related, and 1/3rd social engineering (manipulating humans to divulge sensitive information or perform questionable operations). social engineering has since expanded into things like phishing.

recent post on the topic of identifying and categorizing exploits and vulnerabilities
http://www.garlic.com/~lynn/2006p.html#43 Slow-Going For Next-Generation Threat-Scoring System

older post looking at the categorizing of exploits
http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE

and slightly more recent post discussing the categorizing of exploits
http://www.garlic.com/~lynn/2005b.html#20 Buffer overruns

and lots of collected posts on the subject of exploits, vulnerabilities, threats and fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud

Is no one reading the article?

Refed: **, - **, - **, - **, - **, - **, - **, - **
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 -0600
phil@ibm-main.lst (Phil Payne) writes:
READ what the article says - 7,000 zSeries MIPS have been replaced by just TWO HP Superdomes. This is not in any way a vote against mainframe concepts. It may be that their 7,000 MIPS was on more than two zSeries - but in any case this decision is very much a vote for mainframes and their underlying advantages.

from not quite so long ago and far away??
From: Edward Gould
Subject: HP to compete with S/390
Newsgroups: bit.listserv.ibm-main
Date: 12 Sep 2000 13:52:18 -0700

Hewlett-Packard will face the S/390 head on when it unveils today its new Superdome computer in a bid to up its standing in the lucrative Unix server market. HP is expected to position Superdome with a host of "e-services" to appeal to customers wishing to link business operations housed on different servers, something it says IBM is unwilling to do with its Unix servers lest it undermine sales of its S/390 mainframe line.

"HP hopes to unseat mainframe with Superdome"
http://news.cnet.com/news/0-1003-200-2757613.html


... snip ...

pre-itanium

part of the issue had been that HP had acquired Convex. Convex had done the scalable Exemplar using "64-port" sci memory coherent with two hp pa-risc chips/board (128 chips, processor in numa configuration).

my understanding from the hp engineers was that superdome would be somewhat smaller and more efficient (to implement, 32 processors) box that they would move into the (convex) exemplar customer segment ... as well as moving out into the more commercial world.

also from 9/12/2000 (same as the referenced item).

HP thinks big with Superdome servers
http://news.com.com/2100-1001-245591.html

there was some comment about ibm being wary of pushing ibm's competitive unix offerings too hard with commercial customers because it might take market away from traditional mainframes.

initially announced with 32 processors but with promise of 64 processors to come soon. also promised being able to upgrade to itanium ... except itanium hadn't seen any update (late 90s had various of the 370/390 software emulators thinking itanium would offer significant emulation thruput).

one of your articles:
http://www.isham-research.co.uk/platslns4.html

there is possible more progress now going on with itanium-2.

from 7/8/2002 ...

HP touts advantages of Itanium 2
http://news.com.com/HP+touts+advantages+of+Itanium+2/2100-1001_3-942252.html

...

current superdome page
http://www.hp.com/products1/servers/scalableservers/superdome/index.html

various benchmarks
http://www.hp.com/products1/servers/scalableservers/superdome/index.html

64-way pa-risc superdome specint (june 2002)
http://www.spec.org/cpu2000/results/res2002q3/cpu2000-20020715-01481.html

tpc-c
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp

above lists superdome as 4th ... with ibm (non-mainframes) holding top three positions.

and a few additional historical oriented posts involving mainframe, 801, risk, and itanium tie-ins (there used to be a joke that there were actually only 200 people in the business):
http://www.garlic.com/~lynn/2006.html#39 What happens if CR's are directly changed?
http://www.garlic.com/~lynn/2006e.html#1 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006p.html#42 old hypervisor email

Is no one reading the article?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Anne & Lynn Wheeler writes:
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.


re:
http://www.garlic.com/~lynn/2006q.html#8 Is no one reading the article?

note that in the same time-frame (mid-90s), both dg & sequent also did a "64-port" SCI cache consistent implementation, but using four intel processors on a board (for a 256 processor configuration, instead of the two pa-risc processors on a board done by convex).

the sci design with multiple processors on board are somewhat analogous to current multiple chip implementations with multiple cores in a chip.

ibm inherited one of the implementations (NUMA-Q) when it bought sequent.

minor ref:
http://www.scizzl.com/

a couple other past posts in this n.g. that mention superdome
http://www.garlic.com/~lynn/2003d.html#57 Another light on the map going out
http://www.garlic.com/~lynn/2006l.html#28 Google Architecture

for some other historical, at the time ibm bought sequent, steve chen was cto and evp of product development at sequent. Steve had previously worked at cray and then formed chen supercomputers ... which got a lot of funding from ibm.
http://www.taipeitimes.com/News/biz/archives/2004/11/08/2003210211
http://www.ahaventures.net/index.php?option=com_content&task=view&id=17&Itemid=32

one of the people that worked at cray and chen, hired into kingston, but later transferred to austin. he was behind the four RSC (rios 0.9 or rios single chip) chip machine ... OAK, shared memory but w/o cache consistency (he later went to HP for superdome).
https://en.wikipedia.org/wiki/RISC_Single_Chip

what's the difference between LF(Line Fee) and NL (New line) ?

Refed: **, - **, - **, - **, - **, - **, - **
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 -0600
jmfbahciv writes:
The reason I was able to work so fast was because of typeahead features. However, you had to know when to let the system catch up; life could become <ahem>very interesting if one of the type aheads got an error and the TTY pipe didn't get flushed. In olden days there were flush bugs. Some days I was really good at predicting the future. :-)

local connected 3270 were significantly faster (hundreds of kbytes/sec) ... however interactions were half-duplex and the keyboard was locked during the interactions.

we had a couple hardware patches for the 3277 ... one was a FIFO box that fit where the keyboard plugged into the displayhead which would buffer keystrokes during the period that the keyboard would normally be locked. another was piggypacking some resisters inside the keyboard that controlled repeat key startup delay and rate of repeat. this was useful for the cursor movement keys, for positioning the cursor on the screen. one problem was that you could increase the rate to higher than the screen update ... so the cursor position would lag ... and then still "coast" after you had released the key. if you had your keyboard modified for very high repeat rate ... it could take some practice getting feel for releasing the key and still have the cursor stop at the desired position.

these fixes were obsoleted in the switch-over from 3272 controller and 3277 terminals to 3274 controllers and 3278/3279/etc terminals ... since much of the 3277 electronics were moved back into the 3274 controller (reducing per terminal manufacturing costs).

misc. past posts mentioning 3272 and/or 3274 terminal cotnrollers
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#28 IBM S/360
http://www.garlic.com/~lynn/99.html#69 System/1 ?
http://www.garlic.com/~lynn/99.html#193 Back to the original mainframe model?
http://www.garlic.com/~lynn/2000c.html#63 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#66 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#67 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000g.html#23 IBM's mess
http://www.garlic.com/~lynn/2001k.html#30 3270 protocol
http://www.garlic.com/~lynn/2001k.html#33 3270 protocol
http://www.garlic.com/~lynn/2001k.html#46 3270 protocol
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2001m.html#17 3270 protocol
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#48 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#50 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2002j.html#74 Itanium2 power limited?
http://www.garlic.com/~lynn/2002j.html#77 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2002k.html#2 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2002k.html#6 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2002q.html#51 windows office xp
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003c.html#69 OT: One for the historians - 360/91
http://www.garlic.com/~lynn/2003c.html#72 OT: One for the historians - 360/91
http://www.garlic.com/~lynn/2003d.html#23 CPU Impact of degraded I/O
http://www.garlic.com/~lynn/2003d.html#24 CPU Impact of degraded I/O
http://www.garlic.com/~lynn/2003e.html#43 IBM 3174
http://www.garlic.com/~lynn/2003h.html#15 Mainframe Tape Drive Usage Metrics
http://www.garlic.com/~lynn/2003i.html#30 A Dark Day
http://www.garlic.com/~lynn/2003j.html#24 Red Phosphor Terminal?
http://www.garlic.com/~lynn/2003k.html#20 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#22 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003o.html#14 When nerds were nerds
http://www.garlic.com/~lynn/2003o.html#36 When nerds were nerds
http://www.garlic.com/~lynn/2003p.html#44 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2004c.html#30 Moribund TSO/E
http://www.garlic.com/~lynn/2004e.html#0 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2004f.html#54 [HTTP/1.0] Content-Type Header
http://www.garlic.com/~lynn/2004g.html#11 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#24 |d|i|g|i|t|a|l| questions
http://www.garlic.com/~lynn/2004g.html#27 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2005h.html#40 Software for IBM 360/30
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#14 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#15 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#17 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#20 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#28 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005s.html#17 winscape?
http://www.garlic.com/~lynn/2005s.html#45 winscape?
http://www.garlic.com/~lynn/2005u.html#22 Channel Distances
http://www.garlic.com/~lynn/2006b.html#21 IBM 3090/VM Humor
http://www.garlic.com/~lynn/2006i.html#34 TOD clock discussion

what's the difference between LF(Line Fee) and NL (New line) ?

Refed: **, - **, - **, - **
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 -0600
Brian Inglis writes:
I greatly speeded up interaction with a remote TOPS-10 system from a TTY over a slow link, by telling the system that the terminal echoed, and the terminal that the system echoed: had to be careful using TECO though. ;^>

re:
http://www.garlic.com/~lynn/2006q.html#10 what's the difference between LF(Line Fee) and NL (New line) ?

a large portion of cms retained 1052 line terminal input/output paradigm ... with hypervisor emulating 1052 line operation on 327x terminals (some applications, like various editors, were enhanced for full-screen operation).

in the real line-terminal days ... cms would output a single line at a time. the hypervisor had some scheduling sensitivity for terminal i/o in support of "faster" interactive operation. moving to emulated line terminals on very fast screen terminals (hundreds of kilobytes/sec) placed some unnecessary overhead on resource scheduling. misc. collected posts about resource scheduling
http://www.garlic.com/~lynn/subtopic.html#fairshare

so one of the things i did was modifying cms dmscit to perform single write (batched) operation for all/any queued lines. past post (including email copy from long ago and far away)
http://www.garlic.com/~lynn/2003c.html#35 diffence between itanium and alpha

some other posts mentioning full-screen operation and performance
http://www.garlic.com/~lynn/2001h.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2005h.html#22 Today's mainframe--anything to new?

Another BIG Mainframe Bites the Dust

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 -0600
bernd.oppolzer@ibm-main.lst (Bernd Oppolzer) writes:
BTW, on older machines (not IBM) there were concepts like storage tags, which allowed to detect the use of uninitialized variables even for binary values. I don't understand why these concepts never reached the market. This would make software development and testing easier and maybe cheaper.

re:
http://www.garlic.com/~lynn/2006q.html#4 Another BIG Mainframe Bites the Dust
http://www.garlic.com/~lynn/2006q.html#8 Is no one reading the article?
http://www.garlic.com/~lynn/2006q.html#9 Is no one reading the article?

the future system project was going to have lots of stuff like that (as well as gobs of other stuff) ... and would have replaced 360 (and early 370).
http://www.garlic.com/~lynn/submain.html#futuresys

however as repeatedly noted ... FS was canceled (excessively ambitious?) and there was a lot of effort pushed into getting 370 activities moving again. recent post in another thread with various other detail
http://www.garlic.com/~lynn/2006p.html#50 what's the difference between LF(Line Fee) and NL (New line) ?

i've frequently commented that the FS example contributed significantly to the 801/risc philosiphy ... to do the exact opposite (of what was attempted in FS). much of the 801/risc effort was whenever there might be hardware/software trade-off ... you could make perfect software that would do it better than hardware (allowing the hardware to be made much simpler). cp.r operating system and pl.8 compiler were to provide the basis for that philosiphy.
http://www.garlic.com/~lynn/subtopic.html#801

one such simplification was that there was no hardware protection domains (i.e. supervisor/problem state differentiation). pl.8 compiler would generate perfect software ... and cp.r operating system would guarantee that only correctly compiled pl.8 code would be loaded for execution.

this resulted in a little hiccup. ROMP (16bit 801/risc) was targeted as an austin GSD effort for displaywriter follow-on (implemented on cp.r with pl.8). it was canceled in the early 80s and there was activity looking around to salvage the effort ... and observed that lots of hardware platforms were being shipped with minimal extra effort by leveraging a port of the unix operating system.

a decision to retarget ROMP to unix workstation market forced retrofitting bits & pieces to ROMP to try and compensate for not having an enhanced perfect software environment ... but having to rely on the UNIX/C operational paradigm (like needing hardware privilege/non-privilege execution states).

the company that had been hired to do the AT&T unix port for PC/IX ... was then hired to do a similar AT&T unix port to ROMP. This was announced as AIX (and PC/RT).

Was FORTRAN buggy?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Sun, 10 Sep 2006 08:28:16 -0600
krw writes:
Isn't this just another version of "top-down" design? I generally try to do top-down, but it usually ends up "ends in".

one of my favorite graphics (the frameworks quagmire):
http://www.software.org/quagmire/
moved to MEMBERS ONLY; w/o graphics:
http://web.archive.org/web/20060831110450/http://www.software.org/quagmire/

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

Greatest Software Ever Written?

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 -0600
Peter Flass writes:
Actually, RFID tags make sense. Have you seen the IBM ad where the scruffy-looking guy goes through the supermakket stuffing things under his coat and then walks out? Store security catches up with him in the parking lot and says "hey, you forgot your receipt"?

for some recent discussion on some of the possible vulnerabilities:
http://www.garlic.com/~lynn/aadsm24.htm#28 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#9 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm25.htm#11 And another cloning tale

The Fate of VM - was: Re: Baby MVS???

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 -0600
Peter Flass writes:
He's right, I just hadn't thought this way, but the strategy was "Europe first." Most of the resources went to the ETO, if the Pacific didn't eaxctly have to "make do with what was left", it did have a lower priority.

some number of past comments about Boyd's observation regarding ww2 and strategy to win with overwhelming resources:
http://www.garlic.com/~lynn/2000c.html#85 V-Man's Patton Quote (LONG) (Pronafity)
http://www.garlic.com/~lynn/2001.html#30 Review of Steve McConnell's AFTER THE GOLD RUSH
http://www.garlic.com/~lynn/2001m.html#3 mainframe question
http://www.garlic.com/~lynn/2001m.html#10 mainframe question
http://www.garlic.com/~lynn/2001m.html#11 mainframe question
http://www.garlic.com/~lynn/2001m.html#16 mainframe question
http://www.garlic.com/~lynn/2003n.html#27 Controversial paper - Good response article on ZDNet
http://www.garlic.com/~lynn/2004b.html#24 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004g.html#53 Chained I/O's
http://www.garlic.com/~lynn/2004l.html#19 FW: Looking for Disk Calc program/Exec (long)
http://www.garlic.com/~lynn/2005j.html#11 The 8008
http://www.garlic.com/~lynn/2005j.html#14 The 8008
http://www.garlic.com/~lynn/2006f.html#14 The Pankian Metaphor

collected past posts referencing boyd
http://www.garlic.com/~lynn/subboyd.html#boyd

and various URLs from around the web mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

note i just scanned some of boyd's old presentations and trying it out as html background.

I've mentioned before that my wife's father was engineers combat group. near the end they were frequently first group into enemy territory ... he had acquired a collection of officer's daggers ... being the ranking officer in various surrenders. he then was assigned as advisor in the far east. a few past posts:
http://www.garlic.com/~lynn/2004e.html#19 Message To America's Students: The War, The Draft, Your Future
http://www.garlic.com/~lynn/2005r.html#3 The 8008
http://www.garlic.com/~lynn/2006b.html#27 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006b.html#33 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#27 Mount DASD as read-only

what's the difference between LF(Line Fee) and NL (New line) ?

Refed: **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Roger Ivie writes:
Don't forget the mighty Tek 4010!

and the 3277ga (graphics attachment) which was a big rebanded tektronics display that had special adaptor into the side of 3277.

it handled a lot of stuff that had been previously been done on 2250 (and even some calma stuff)

a few past posts mentioning 3277ga
http://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
http://www.garlic.com/~lynn/2001i.html#51 DARPA was: Short Watson Biography
http://www.garlic.com/~lynn/2002p.html#29 Vector display systems
http://www.garlic.com/~lynn/2004l.html#27 Shipwrecks
http://www.garlic.com/~lynn/2004l.html#32 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#8 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#28 MCTS
http://www.garlic.com/~lynn/2006n.html#24 sorting was: The System/360 Model 20 Wasn't As Bad As All That

a few past posts mentioning calma:
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2005r.html#24 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005u.html#6 Fast action games on System/360+?
http://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"
http://www.garlic.com/~lynn/2006n.html#41 Tek 4010, info and prices

Was FORTRAN buggy?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Sun, 10 Sep 2006 16:15:53 -0600
re:
http://www.garlic.com/~lynn/2006q.html#13 Was FORTRAN buggy?

and a software development/boyd tie-in

What Lessons Can the Agile Community learn from A Maverick Fighter
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?isnumber=34909&arnumber=1667567&count=62&index=18

misc. collected posts mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd

and various URL web pages mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

(web pages updated with scans of old presentations as background).

Difference between server and workstation

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 -0600
jsavard writes:
Well, as you already know, then, a workstation is the computer you sit at, and type on the keyboard and look at the monitor - and a server is the computer that stays alone in a room, with the other computers connecting to it by the network, to access the files it keeps on the hard disk.

before aggresive commoditization ... price was optimized by only including/using things targeted for specific task ... as commoditization progressed ... there were more and more situations where there was trade-off between price/performance of specialized components/configurations and generalized commodity components ... and the use of specialized components/configurations became less prevalent.

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.

virtual memory

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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:
I was unable to send this back when we were discussing this in the summer because my ISP dropped newsgroup support and it took a while to find a free server that allows posting. Belated as it is, since I put in the effort I figured I might as well send it anyway.

....

I finally got a copy of this paper. The description is a bit vague and confusing. While I accept your assertion that Cambridge outperformed Grenoble, after reading this paper I see no basis for generalizing from those results to conclude "global is superior to local".

This paper discusses adding a Denning style working set to their existing system. A Denning working set manager is similar to ***swapping*** and independent of global vs local issues.

This paper only shows that Grenoble's working set dispatcher, a combination of scheduler and bulk memory manager, improved on the CP67 scheduler and eliminated CP67's tendency to thrash. In fact they explicitly state that this dispatcher can be applied to many page replacement policies: random, FIFO, LRU or other. Though the mechanism is quite different, the result looks similar to VMS swapping.

IIUC their working set is determined by scanning, at regular intervals, a process's PTE Used bits, then resetting the bits. Pages not used are candidates for replacement and the PTE is marked Invalid. If touched again it soft-faults back into the address space. By this it dynamically estimates the WS size for each process. If the free list gets too small, a victim process is selected from a FIFO list and the whole working set is tossed onto the free list (equivalent to outswapping). If there is enough free pages for a process WS size to fit, an outswapped process is inswapped.

As for the page replacement algorithm, they state their design options were restricted by CP67 v3.0 existing structure. Prior to the Grenoble modifications, on a page fault it would look for an unused page, and if not available selects one from any active process at _Random_. ("it will choose the first page it finds in what essentially amounts to random replacement"). (They also don't say how the unused page is selected, which is as important as the selection of stealing page).

Their wording is somewhat vague but if it does steal pages from any processes, then this is a ***global*** replacement policy.

With Grenoble mods, in order to track the process working sets it does not use a linked list. It uses the working set determined above to decide which pages are in use and which are not. Shared pages are not part of this mechanism and are locked down. This separates the pages into two piles, those in the working sets and those not. IIUC replacement pages are still chosen at random from the free pile or the active pile (based in interactive or batch class).

Suffice it to say that this is so different to VMS or WNT paging that I certainly wouldn't extrapolate Grenoble's results to them.

> basically running same kind of workload, cambridge ran approx. 80 > users with the same interactive response and thruput as grenoble did > with 35 users i.e. cambridge system with 1/3rd less real storage for > application paging was able to support more than twice as many users > with comperable thruput and no worse interactive response > ... typically much better. the interactive response was somewhat more > sensitive to latency associated with the "working dispatcher" > attempting to avoid page thrashing and how effective local LRU was in > selecting pages for replacement ... so the cambridge system response > ... even with more than twice as many users typically had better > interactive response and lower latency delays.

The following looks like it might be a write up of those Cambridge tests (it includes an acknowledgment to L. Wheeler at the end) where they compare two page replacement algorithms.

Experimental evaluation of system performance
http://www.research.ibm.com/journal/sj/123/ibmsj1203F.pdf

<quote> CP-67 maintains a table of all pages in main storage and a pointer Item 1 that cycles around this table. CP-67 also maintains, at any given moment, a list of .in-queue. users, and these are the only ones eligible to receive service at that time. The manner in which this list is maintained is further discussed below.

The two algorithms may now be described as follows:

Algorithm 1 (used in CP67 v3.0): Move the pointer around the table until a page belonging to a user not in queue is found. If no such page is found in a complete trip around the table, select the next page for removal.

Algorithm 2 (used in CP67 v3.1): Select the next page if its reference bit is off. Otherwise, turn the reference bit off, move the pointer down one page, and repeat. Note: The reference bit is turned on whenever the user references the page in the course of running his program. The bit is turned off when the user is removed from inqueue status. <end quote>

Algorithm 1 sounds like a global random mechanism. Algorithm 2 sounds like a global clock variant.

Rodriquez-Rosell states that they started from CP67 v3.0 (Algorithm 1) which seems to confirm that Grenoble CP67 started from a global random replacement policy and modified it to add the Denning working set dispatching (aka swapping).

Again this is quite different from VMS or WNT paging.


again ... i did the original stuff when i was an undergraduate for cp67 release 2 in the 60s ... the changes weren't picked up and distributed in the product until release 3.1 (effectively the implementation stayed the same between release 2 and release 3)
http://www.garlic.com/~lynn/subtopic.html#wsclock

with any load on the system (i.e. all pages in memory belonged to "in-queue" uses, having quickly swept out pages belonging to users that weren't running) ... algorithm 1 quickly degenerated to FIFO ... since it would always re-search all memory for a non-running user page ... and then select the next page belonging to a running user. Except for typically swift transition when user was descheduled ... the algoritm would sequently move one page at a time around real memory replacing the next encountered page with a newly faulted page. by the time it made one complete circuit of real storage, it would have replaced each page ... and be back to the first/oldest page that it had started with. effectively algorithm would always sweep all of memory, searching for any non-running user page ... and then quickly falls back to effectively FIFO (NOT random) replacement of pages for running users.

Among other things, under any load, the majority of the time, the search for pages for non-running users wouldn't find anything (since non-running user pages were quickly swept from memory under any sort of load) ... resulting in very high-overhead to scan all real memory pages on every fault. then (under any sort of system load), after the overhead of looking at every page in real memory ... it would fall back to FIFO replacement of pages belonging to running users. It was both an extremely high overhead implementation coupled with an extremely poor replacement strategy (i.e. choice of running user page effectively degenerated to the order that they had been fetched into memory).

so i had done global LRU replacement as an undergraduate in the 60s. by the time, the "single" bit replacement code was shipping in cp67 3.1 ... we were investigating 2, 3, 4, ... 8bit ... variations as well as moving the reset of the reference bit offset from the examination of the reference bit.

the cp67 release 3 distributed implementation didn't differ from the release 2 distributed implementation. the implementation that grenoble started with (in release 3) and modified to implement local LRU ... was the same implementation that I started with as an undergraduate in the 60s for cp67 release 2 and modified to implement global LRU. My global LRU implementation existed concurrently with the grenoble local LRU implementation as modification against the same base implementation (both release 2 and release 3).

My global LRU implementation was then selected to ship in cp67 release 3.1 (which was the single reference bit reset at the same time as the examination). However, about the time it started shipping, we were also starting to look at issues like multiple bits and offsetting the reset from the examination. However, on 360/67, the examination of the bit used the ISK instruction and the resetting of the bit used the SSK instruction. For 370, the synchronous examination and reset strategy resulted in the new RRB instruction ... which examined and reset in a single instruction.

past posts in this thread
http://www.garlic.com/~lynn/2006i.html#28 virtual memory
http://www.garlic.com/~lynn/2006i.html#30 virtual memory
http://www.garlic.com/~lynn/2006i.html#31 virtual memory
http://www.garlic.com/~lynn/2006i.html#32 virtual memory
http://www.garlic.com/~lynn/2006i.html#33 virtual memory
http://www.garlic.com/~lynn/2006i.html#36 virtual memory
http://www.garlic.com/~lynn/2006i.html#37 virtual memory
http://www.garlic.com/~lynn/2006i.html#38 virtual memory
http://www.garlic.com/~lynn/2006i.html#39 virtual memory
http://www.garlic.com/~lynn/2006i.html#40 virtual memory
http://www.garlic.com/~lynn/2006j.html#0 virtual memory
http://www.garlic.com/~lynn/2006j.html#1 virtual memory
http://www.garlic.com/~lynn/2006j.html#2 virtual memory
http://www.garlic.com/~lynn/2006j.html#3 virtual memory
http://www.garlic.com/~lynn/2006j.html#4 virtual memory
http://www.garlic.com/~lynn/2006j.html#5 virtual memory
http://www.garlic.com/~lynn/2006j.html#7 virtual memory
http://www.garlic.com/~lynn/2006j.html#13 virtual memory
http://www.garlic.com/~lynn/2006j.html#14 virtual memory
http://www.garlic.com/~lynn/2006j.html#17 virtual memory
http://www.garlic.com/~lynn/2006j.html#18 virtual memory
http://www.garlic.com/~lynn/2006j.html#19 virtual memory
http://www.garlic.com/~lynn/2006j.html#20 virtual memory
http://www.garlic.com/~lynn/2006j.html#21 virtual memory
http://www.garlic.com/~lynn/2006j.html#22 virtual memory
http://www.garlic.com/~lynn/2006j.html#23 virtual memory
http://www.garlic.com/~lynn/2006j.html#24 virtual memory
http://www.garlic.com/~lynn/2006j.html#25 virtual memory
http://www.garlic.com/~lynn/2006j.html#26 virtual memory
http://www.garlic.com/~lynn/2006j.html#27 virtual memory
http://www.garlic.com/~lynn/2006j.html#30 virtual memory
http://www.garlic.com/~lynn/2006j.html#31 virtual memory
http://www.garlic.com/~lynn/2006j.html#37 virtual memory
http://www.garlic.com/~lynn/2006j.html#39 virtual memory
http://www.garlic.com/~lynn/2006j.html#40 virtual memory
http://www.garlic.com/~lynn/2006j.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#43 virtual memory
http://www.garlic.com/~lynn/2006j.html#44 virtual memory
http://www.garlic.com/~lynn/2006k.html#44 virtual memory
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006l.html#2 virtual memory
http://www.garlic.com/~lynn/2006l.html#3 virtual memory
http://www.garlic.com/~lynn/2006l.html#5 virtual memory
http://www.garlic.com/~lynn/2006l.html#9 virtual memory
http://www.garlic.com/~lynn/2006l.html#10 virtual memory
http://www.garlic.com/~lynn/2006l.html#11 virtual memory
http://www.garlic.com/~lynn/2006l.html#12 virtual memory
http://www.garlic.com/~lynn/2006l.html#13 virtual memory
http://www.garlic.com/~lynn/2006l.html#14 virtual memory
http://www.garlic.com/~lynn/2006l.html#15 virtual memory
http://www.garlic.com/~lynn/2006l.html#16 virtual memory
http://www.garlic.com/~lynn/2006l.html#17 virtual memory
http://www.garlic.com/~lynn/2006l.html#18 virtual memory
http://www.garlic.com/~lynn/2006l.html#19 virtual memory
http://www.garlic.com/~lynn/2006l.html#40 virtual memory
http://www.garlic.com/~lynn/2006l.html#48 virtual memory
http://www.garlic.com/~lynn/2006l.html#55 virtual memory

virtual memory

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: virtual memory
Newsgroups: comp.arch
Date: Mon, 11 Sep 2006 12:05:04 -0600
Anne & Lynn Wheeler writes:
again ... i did the original stuff when i was an undergraduate for cp67 release 2 in the 60s ... the changes weren't picked up and distributed in the product until release 3.1 (effectively the implementation stayed the same between release 2 and release 3)
http://www.garlic.com/~lynn/subtopic.html#wsclock


re:
http://www.garlic.com/~lynn/2006q.html#19 virtual memory

while the global LRU stuff that I had done as an undergraduate in the 60s (against release 1 and release 2 cp67 systems), didn't ship in cp67 release 3 ... gobs of other stuff that I had done did ship in release 3 (lots of kernel rewrite, pathlengths, fastpath, etc).

repeat reference to part of an old presentation that i gave at the fall68 share user group meeting held in Atlantic City
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14

a couple more recent references to that presentation ... mostly concerned large amount of pathlength rewrites for reducing processor kernel overhead:
http://www.garlic.com/~lynn/2006.html#7 EREP , sense ... manual
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006h.html#57 PDS Directory Question

virtual memory

Refed: **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Anne & Lynn Wheeler writes:
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 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 operation.


re:
http://www.garlic.com/~lynn/2006q.html#19 virtual memory
http://www.garlic.com/~lynn/2006q.html#20 virtual memory

one of the issues with cycling around real memory for global LRU was that it tended to be naturally adaptive (self-regulating) over a relatively broad range of environments and configurations.

the point of LRU replacement ... is that least recently used is supposedly predictive of future use ... pages used in the recent past have a high probability being used in the near future (than pages that haven't been used in the recent past).

the interval between the reset of the reference bit and the next examination of the reference bit is supposed to represent a "recent interval" that retains the predictive characteristics associated with least recently used observations (pages that have the reference bit off haven't been used in the recent interval and pages that have the reference bit on have been used in the recent interval).

the naturally adaptive characteristics is that if the implementation has cycled memory too quickly (cycled around storage once) ... then there will be a larger precentage of pages with the reference bit off ... which means on the next pass it will take much longer to make one complete cycle through all of memory (increasing the interval that allows pages to have their reference bit set). if the implemenation has cycled memory too slowly ... then there will be a larger percentage of pages with the reference bit on ... which means that it will take much shorter time to make one complete cycle through all of memory (one complete cycle of memory is a function by the rate of page/faults and the percentage of pages with their reference bits off).

so naturally adaptive worked over a fairly broad range ... but not completely. In page thrashing scenario (severe over commitment of real storage), everybody is waiting for page fault and not executing ... so nobody is getting any page reference bit set. majority of reference bits are always off and the algorithm degenerates to pretty much FIFO (as in the case of "alogorithm 1" for cp67 which had effectively assumed all the reference bits were the same and didn't even both to check).

the other situation where the natural adaptive starts to break down is where there was increasing amounts of available real storage and the time it takes to cycle around all storage begins to consistently exceed any common definition of "recent" ... as applied to least recently used algorithms. large percentage of pages may have their reference bit on (because the interval since reset was so long) and there was no differentiation between pages that had been "recently used" and pages that hadn't been used for quite some time.

this is where the "offset reset" started to appear. you can think of the original implementation as having a "offset reset" exactly equal to one complete cycle of all storage. however, with increasing real storage sizes the avg. interval to cycle around all pages (interval between reset and examiniation) was becoming excesively larger and no longer conformed to any reasonable definition of "recent". so a new variation was introduced to offset the resetting the reference bit from the examination of the reference bit. this offset could be adjusted based on reasonable definition and expectation of "recent" having some valid prediction of future page reference behavior. This could possibly be one-half of all memory .... so the pages being reset were effectively "half of real pages" away from the pages being examined (cutting the average interval between reset and examination in half).

re:
http://www.garlic.com/~lynn/subtopic.html#wsclock

3 value logic. Why is SQL so special?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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:
So an aircraft might not take off and yet it has a departure time attribute? That makes absolutely no sense at all.

i think the characteristic was scheduled departure time. scheduled departure time can be useful for a number of things.

commercial aircraft tend to have scheduled departure times (helps give you an approx idea when to show up at the airport) ... as well as scheduled arrival times.

at one time the FAA didn't interfer with departure times ... and let aircraft circle if weather cut down on capacity of airfield landing rates. at some point the FAA started holding plane departures if there was predictions about reduced capacity to land the plane.

you frequently hear pilots making announcements about particular arrival being ahead of time or late ... which is the difference between the scheduled arrival time and the actual arrival time. both the actual arrival time and the difference (early/late) between the actual arrival time and the scheduled arrival time ... aren't actually known until near to the time that the plane actually arrives.

in the routes database used for scheduling reservations involving connecting flights ... there typically is an attempt to match scheduled arrival time to connecting scheduled departure time (within some fudge factor).

however as anybody who has had a late arrival and missed their connecting flight ... the scheduled arrival time and the actual arrival time may be different. also some carriers when they see that their are a significant connecting passengers ... on a flight that is starting to show a predicted late arrival time ... may attempt to delay the departure of some number of flights as convinience to connecting passengers. however, this can have cascading effects if the connecting departing flight then impacts other passengers that have connecting flights at the next arrival.

lots of flights that have significant, long term differences between scheduled arrival and actual arrival may indicate various loading and capacity issues and reason to update projected schedules. changes in projected specific schedules then can have cascading effects with regard to scheduling departure/arrivals for purposes of route and load planning involving connecting flights.

various past posts mentioning 3-value logic
http://www.garlic.com/~lynn/2003g.html#40 How to cope with missing values - NULLS?
http://www.garlic.com/~lynn/2004f.html#2 Quote of the Week
http://www.garlic.com/~lynn/2004l.html#75 NULL
http://www.garlic.com/~lynn/2005.html#15 Amusing acronym
http://www.garlic.com/~lynn/2005b.html#17 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005i.html#35 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005m.html#19 Implementation of boolean types
http://www.garlic.com/~lynn/2005t.html#20 So what's null then if it's not nothing?
http://www.garlic.com/~lynn/2005t.html#23 So what's null then if it's not nothing?
http://www.garlic.com/~lynn/2005t.html#33 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005u.html#12 3vl 2vl and NULL
http://www.garlic.com/~lynn/2006e.html#34 CJ Date on Missing Information

various past posts mentiong working with OAG database of all (world-wide) commercial schedule flight segments as part of airline res system (over 4k airports and over 400k commercial scheduled flight segments)
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000f.html#20 Competitors to SABRE?
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
http://www.garlic.com/~lynn/2002j.html#83 Summary: Robots of Doom
http://www.garlic.com/~lynn/2003o.html#17 Rationale for Supercomputers
http://www.garlic.com/~lynn/2004b.html#6 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004o.html#23 Demo: Things in Hierarchies (w/o RM/SQL)
http://www.garlic.com/~lynn/2004q.html#85 The TransRelational Model: Performance Concerns
http://www.garlic.com/~lynn/2005o.html#24 is a computer like an airport?
http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back
http://www.garlic.com/~lynn/2006o.html#18 RAMAC 305(?)

3 value logic. Why is SQL so special?

Refed: **, - **, - **, - **, - **, - **
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 -0600
Bob Badour writes:
How is null easier than not inserting anything into an actual departures relation?

re:
http://www.garlic.com/~lynn/2006q.html#22 3 value logic. Why is SQL so special?

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.

"25th Anniversary of the Personal Computer"

Refed: **, - **, - **, - **, - **, - **, - **
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 -0600
Anne & Lynn Wheeler writes:
both FCS (fiber channel standard) and SCI (scallable coherent interface) provided for asynchronous operation.

re:
http://www.garlic.com/~lynn/2006p.html#46 25th Anniversary of the Personal Computer

other recent posts mentioning sci
http://www.garlic.com/~lynn/2006p.html#55 PowerPC or PARISC
http://www.garlic.com/~lynn/2006q.html#8 Is no one reading the article?
http://www.garlic.com/~lynn/2006q.html#9 Is no one reading the article?

harrier mentioned in the following later became ssa (also mentioned in this thread) ... an old ssa post
http://www.garlic.com/~lynn/95.html#13 SSA

some other sci drift ....

Date: 92/06/30 22:43:04
From: wheeler
Subject: slac sci meeting

The sci meeting at slac today included people from slac, two from hp, one from apple, ibm branch rep, somebody from IBM Houston, my wife and I.

The ibm branch rep turns out to really be an ibm "business" partner that ibm has turned the slac account over to. this guy also mentioned that he has the nasa/ames account.

Gustavson (SLAC & IEEE SCI committee chairman) gave introduction to SCI and talked about possible application. He had reprints of the IEEE Micro article "The Scalable Coherent Interface and Related Standards Projects".

As an aside, I was recently reviewing cache coherency papers in 19th proceedings of sigarch ... & had ran across the sci ring paper ... and brought it along. Nobody at the meeting had been aware that it was published.

Also it turns out that the ring architecture model (Figure C in the feb92 IEEE Micro article) is almost identical to the ring insertion patent that Anne received in '78. Also the dual simplex architecture is the same as the HSDT work we were doing in the early '80s.

The person that was suppsoed to be there from Convex didn't make it. It was re-iterated that Convex has signed an aggreement 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

garlic.com

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: re: garlic.com
Newsgroups: bit.listserv.ibm-main
Date: Tue, 12 Sep 2006 10:12:07 -0600
tony babonas wrote:
Whatever their site is I'm deeply envious of how comprehensive its contents are. The design must be such that:

1. It's readily update-able. 2. It's readily search-able, in that a reference to the 1978 version of the ABC Frammis get quoted rather instantly. 3. Seeming non-redundant, though I must admit I only read a few additional peripheral links.

Anyway, it impresses me.......


as noted here
http://www.garlic.com/~lynn/index.html

much of the website information is maintained in some technology that i originally worked on about the same time I was doing some system/r stuff (original relational/sql)
http://www.garlic.com/~lynn/submain.html#systemr

which i've since rewritten from scratch a number of times.

the information is maintained and managed in the technology and then (static) html files are periodically regenerated and changes copied to the garlic web pages.

as i've mentioned a number of times before (and also referenced in the attached comments) most of the html files have an exceptionally high ratio of hrefs to amount of content (as well as attempting to simulate bi-directional links) ... which possibly is the reason that many of the major web crawlers appear to use it for regression case (hits to all the files from the same crawlers several times per day).

the ietf index
http://www.garlic.com/~lynn/rfcietff.htm

and note on the merged taxonomies and glossaries
http://www.garlic.com/~lynn/index.html#glosnote

for instance ... the privacy taxonomy/glossary was done in support of working as co-author of the x9.99 financial standard

i.e. notes on various merged taxonomies and glossaries
Payment
Terms merged from: ACH, FACSNET, FRBC, FRBM, FRBSF, GAO, NSCC, and misc.
http://www.garlic.com/~lynn/payment.htm

Security
Terms merged from: AFSEC, AJP, CC1, CC2, CC21 (CC site), CIAO, FCv1, FFIEC, FJC, FTC, IATF V3 (IATF site), IEEE610, ITSEC, Intel, JTC1/SC27 (SC27 site), KeyAll, MSC, NIST 800-30, 800-33, 800-37, 800-53, 800-61, 800-77, 800-83, FIPS140, NASA, NCSC/TG004, NIAP, NSA Intrusion, CNSSI 4009, online security study, RFC1983, RFC2504, RFC2647, RFC2828, TCSEC, TDI, TNI, vulnerability testing and misc. Updated 20060701 with NIST IR 7298 Glossary containing terms from the following FIPS documents: 140-2, 181, 185, 188, 191, 196, 197, 198, 200, 201; and the following 800 documents: 12, 15, 16, 18, 19, 21, 24, 26, 27, 28, 30, 32, 33, 34, 35, 36, 37, 38, 40, 41, 44, 46, 47, 48, 49, 50, 53, 55, 56, 57, 58, 59, 60, 61, 63, 64, 65, 66, 67, 72, 79, 83, 88, 90
http://www.garlic.com/~lynn/secure.htm

Privacy
Privacy terms from merged Security Taxonomy & Glossary combined with EU-DPD, FTC, GLBA, HIPAA, OECD, and OMB. Updated 20040222 with terms from OMB. Somewhat related, X9.99, Privacy Impact Assessment standard is now also available at ANSI X9.99
http://www.garlic.com/~lynn/privacy.htm

X9F
Terms merged from X9F document glossaries: WD15782, X509, X9.8, X9.24, X9.31, X9.42, X9.45, X9.49, X9.52, X9.62, X9.65, X9.69. Terms from ABA/ASC X9 TR1-1999 replace terms from X9F TG-16 glossary (identified by lower case x9 instead of upper-case X9). Original source documents include: X3.92, X3.106, x9.1, x9.5, x9.6, x9.8, x9.9, x9.17, x9.19, x9.23, x9.24, x9.26, x9.28, x9.30, x9.31, x9.41, x9.42, x9.44, x9.45, x9.49, x9.52, x9.55, x9.57, x9.62, x9.69 x9.74, x9.76, x9.78, x9.80, x9.82, and TG-17.
http://www.garlic.com/~lynn/x9f.htm

Financial
Warning: Not for light of heart, the combined glossary and taxonomy is over 3.5 megabytes and has been known to lock up some browser versions on some platforms (more because of the number of links than size of files). There are >6600 terms, >8500 definitions and >35,500 href links. Terms merged from Payment Taxonomy & Glossary with Bureau of Economic Analysis, Chicago Board of Trade, Commodity Futures Trading Commission, C Harvey at Duke (Copyright, for non-commercial use only), Environmental Protection Agency, Federal Deposit Insurance Corporation, International Trade Data System, International Trade Resource Center, MidAmerica Commodity Exchange, New York Merchantile Exchange, New York Stock Exchange, Office Thrift Supervision, Securities Exchange Commission, Treasury Management Association of Canada, UN Office on Drugs and Crime and Western Connecticut State University. Updated 20050320 with FIDC international terms
http://www.garlic.com/~lynn/financial.htm

garlic.com

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: garlic.com
Newsgroups: bit.listserv.ibm-main
Date: Tue, 12 Sep 2006 10:46:13 -0600
re:
http://www.garlic.com/~lynn/2006q.html#25 garlic.com

oh, and the e-server magazine article
http://www.ibmsystemsmag.com/mainframe/stoprun/Stop-Run/Making-History/

as an aside to the comment about having been around ... my wife served her time also ... worked on FS, was in the gburg JES group (one of the catchers for ASP turning into JES3 ... and worked on a design for merging JES2/JES3 into a single product) ... and then was con'ed into going to POK to be in charge of loosely-coupled architecture. while there, she did peer-coupled shared data architecture
http://www.garlic.com/~lynn/submain.html#shareddata

except for the IMS hot standby effort ... didn't see a lot of uptake until parallel sysplex.

recent posting of old email in a.f.c newsgroup mentioning patent she got on token protocol while she was doing her stint in POK
http://www.garlic.com/~lynn/2006q.html#24

dcss and page mapped filesystem

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Rob van der Heij wrote:
That's compatibility. I'd imagine the "old way" with saveseg would still create the spool file. If the named DCSS is not on the disks that CP has accessed, CP would find the one on spool. But if you would DCSSBKUP the file and store the file on the CP disk, it would find it there first. We had a similar approach to phase out the override file. The spool file is not flattened out either. When a userid issues a diag64 against a yet unused DCSS, CP will need to walk the map in the warmstart area and build segment and page tables to map the blocks. I don't think walking the hyperblocks of a CMS file system is any harder.

the real, original "old way" was with cms & cp supporting cms page mapped filesystem ... that I had originally done on cp67 and then ported to vm370. with page mapped filesystem ... then it was straight forward to have all sort of shared segment feature/function mapped directly to the stuff in cms filesystem.

they decided to pickup a very small piece of the cms & cp changes for vm370 release3 and call it DCSS ... lots of past posts with much more detailed description
http://www.garlic.com/~lynn/submain.html#mmap

one of the tricks was an added enhancement that i had done for location free code ... so memory images could be mapped from filesystem to arbitrary (possibly shared segment) virtual addresses. lots of past posts discussing some of the issues
http://www.garlic.com/~lynn/submain.html#adcon

later i did an enhancement for the spool file system to operate similarly ... i needed to speed up the spool system by minimum of factor of 10 times for VNET participation in HSDT backbone
http://www.garlic.com/~lynn/subnetwork.html#hsdt

recent posts discussing spool file system rewrite
http://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006o.html#64 The Fate of VM - was: Baby MVS???
http://www.garlic.com/~lynn/2006p.html#10 What part of Z/OS is the OS?

was change headers: The Fate of VM - was: Re: Baby MVS???

Refed: **, - **, - **, - **, - **
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 -0600
CBFalconer writes:
No, that was the US Sherman tank, in WWII.

Boyd's WWII thesis/analysis of winning with overwhelming resources, attrition and superior logistics.
http://www.garlic.com/~lynn/2000c.html#85 V-Man's Patton Quote (LONG) (Pronafity)
http://www.garlic.com/~lynn/2001.html#30 Review of Steve McConnell's AFTER THE GOLD RUSH
http://www.garlic.com/~lynn/2001m.html#3 mainframe question
http://www.garlic.com/~lynn/2001m.html#10 mainframe question
http://www.garlic.com/~lynn/2001m.html#11 mainframe question
http://www.garlic.com/~lynn/2001m.html#16 mainframe question
http://www.garlic.com/~lynn/2003n.html#27 Controversial paper - Good response article on ZDNet
http://www.garlic.com/~lynn/2004b.html#24 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2005j.html#11 The 8008
http://www.garlic.com/~lynn/2005j.html#14 The 8008
http://www.garlic.com/~lynn/2006f.html#14 The Pankian Metaphor

lots of past posts mentioning boyd
http://www.garlic.com/~lynn/subboyd.html#boyd

and misc. URLs from around the web mentioning boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

3 value logic. Why is SQL so special?

Refed: **, - **, - **, - **, - **, - **
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:
And many other information... This is a purely pedagogical case (far from being complete) to demonstrate that it is perfectly possible to build some logical design in minutes (took me 20 of them) WITHOUT using NULLS...while sticking to the God Damn Real World (lazyness) excuse...

small matter ... scheduled arrival, projected arrival, actual arrival can have different business uses. the scheduled arrival ... for scheduled flights have all sorts of issues for reservations, planning, etc. the projected arrival may be used in real time for things like decisions about holding other flights for the convinence of other connecting passengers. actual arrival may be used for long term planning purposes ... as well as computed values like difference between scheduled and actual.

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-occuring flights every day ... but there are also re-occuring flight segments specified just for weekdays ... with different re-occuring 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.

what's the difference between LF (Line Fee) and NL (New line) ?

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 -0600
CBFalconer <cbfalconer@yahoo.com> writes:
I was out of high school at 15, and took a year off before going to college, working for Canadian Pacific Railways as an office boy and then 'junior clerk'. It all meant filing things. There was a typewriter on my desk, considerably older than I was, with two inch key travel. The powers had an attitude towards idle personnel, so I took a book for a typing course and taught myself, thus looking extremely busy, and never getting caught reading science fiction. Those were the days when you worked on Saturday mornings. That armored me later for Saturday morning classes, but I could skip those with fewer evil consequences.

old thread from last year:
http://www.garlic.com/~lynn/2005e.html#63 Mozilla v Firefox
http://www.garlic.com/~lynn/2005f.html#2 Mozilla v Firefox

and thread/posts mentioning school:
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/2000d.html#46 Charging for time-share CPU time
http://www.garlic.com/~lynn/2002o.html#1 Home mainframes
http://www.garlic.com/~lynn/2002o.html#2 Home mainframes
http://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
http://www.garlic.com/~lynn/2004c.html#19 IT jobs move to India
http://www.garlic.com/~lynn/2004e.html#45 going w/o sleep
http://www.garlic.com/~lynn/2004g.html#0 Usenet invented 30 years ago by a Swede?
http://www.garlic.com/~lynn/2004k.html#41 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2006j.html#26 virtual memory

VAXen with switchmode power supplies?

Refed: **, - **, - **, - **, - **
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 -0600
Rob <intabits@optushome.com.au> writes:
3031's had a weird type of switching rectifier system. A motor/generator set converted mains to some lower 3-phase voltage at 400Hz, which was then distributed to local (very heavy) regulator units that used six big SCR's and a very large filtering inductor.

the 3031 were just a repackaged pair of 370/158 engines. the 158 had microengine with programming that did both 370 instruction set emulation and also the integrated i/o channels. for the 303x line (3031, 3032, and 3033), they took a 158 engine with ONLY the programming for the integrated channels and packaged it as the "channel director" (i.e. independent engine providing channel function for all processors in the 303x line.

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

Very slow booting and running and brain-dead OS's?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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:
TSS-360 I seem to have a faint memory that TSS/360 was a bit of a dog. 1200 programmers were thrown into the coding frenzy and apparently little restraint was used. Many wonderful advanced features led to really poor performance-- like it could only support two users if they had a lot of patience.

it had lots of other issues ... very complex algorithms. when a task became runnable (say somebody doing input editing) ... the virtual pages would be read into memory from 2311 (or 2314) and written to 2301 before starting. when it finished the line-edit ... any pages on 2301 would be read into memory and written to 2311 (or 2314).

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 30 simulated users.

another issue was that with the modern benefits of tss/360 one level store ... applications no longer had to worry about memory localities. compilers, applications, etc ... were laid out linearly in virtual memory. 768k real memory with a hog of tss/360 kernel taking maybe 512k ... and almost anything requiring much more than 256k to run decently.

cms remapped os/360 fortran-g ... which ran comfortably in 60k-80k.

there was a tss/360 uniprocessor (360/67, 1mbyte memory) / multiprocessor (two processors, 2mbyte memory) ... where the smp test had 3.8 times the thruput of the uniprocessor on the same workload. this was written up as the tss/360 advanced algorithms being able to scale (twice) multiprocessor at better than linear (more than twice the thruput, lot of hype?). in actual fact, the uniprocessor had less than 512k memory for applications (after fixed kernel) ... while the multiprocessor had a little over 1.5mbytes for applications (after fixed kernel). since tss/360 was actually severely real-storage constrained for those environments ... having nearly four times as much real storage available for applications (between the 1mbyte uniprocessor and the 2mbyte two processor) resulted in nearly four times the thruput.

misc. past mentioning tss/360:
http://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/95.html#1 pathlengths
http://www.garlic.com/~lynn/98.html#11 S/360 operating systems geneaology
http://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology
http://www.garlic.com/~lynn/2000f.html#18 OT?
http://www.garlic.com/~lynn/2000f.html#56 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001f.html#47 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#39 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001l.html#6 mainframe question
http://www.garlic.com/~lynn/2001l.html#7 mainframe question
http://www.garlic.com/~lynn/2001l.html#8 mainframe question
http://www.garlic.com/~lynn/2001m.html#49 TSS/360
http://www.garlic.com/~lynn/2002.html#36 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software
http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002d.html#23 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#36 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002f.html#36 Blade architectures
http://www.garlic.com/~lynn/2002f.html#37 Playing Cards was Re: looking for information on the IBM 7090
http://www.garlic.com/~lynn/2002f.html#42 Blade architectures
http://www.garlic.com/~lynn/2002f.html#53 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2002j.html#27 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002n.html#32 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#57 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002n.html#62 PLX
http://www.garlic.com/~lynn/2002n.html#64 PLX
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003d.html#58 POWER hashes vs tree
http://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003f.html#41 SLAC 370 Pascal compiler found
http://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
http://www.garlic.com/~lynn/2003g.html#31 Lisp Machines
http://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
http://www.garlic.com/~lynn/2003l.html#30 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#16 OSI not quite dead yet
http://www.garlic.com/~lynn/2003m.html#31 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003n.html#34 Macros and base register question
http://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
http://www.garlic.com/~lynn/2003p.html#14 64 bits vs non-coherent MPP was: Re: Itanium strikes again
http://www.garlic.com/~lynn/2003p.html#24 Mainframe Training
http://www.garlic.com/~lynn/2004c.html#9 TSS/370 binary distribution now available
http://www.garlic.com/~lynn/2004c.html#26 Moribund TSO/E
http://www.garlic.com/~lynn/2004c.html#47 IBM 360 memory
http://www.garlic.com/~lynn/2004c.html#60 IBM 360 memory
http://www.garlic.com/~lynn/2004c.html#61 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#0 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#5 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#10 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#21 REXX still going strong after 25 years
http://www.garlic.com/~lynn/2004d.html#66 System/360 40 years old today
http://www.garlic.com/~lynn/2004g.html#4 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#15 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#16 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004m.html#5 Tera
http://www.garlic.com/~lynn/2004n.html#3 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#4 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#5 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#25 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#55 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#2 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#5 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#2 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#4 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#9 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#11 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#27 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005b.html#41 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#44 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005c.html#18 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005j.html#16 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005k.html#8 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2005n.html#31 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#35 PART 3. Why it seems difficult to make an OOO VAX competitive
http://www.garlic.com/~lynn/2005o.html#43 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
http://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005s.html#17 winscape?
http://www.garlic.com/~lynn/2006.html#13 VM maclib reference
http://www.garlic.com/~lynn/2006.html#41 Is VIO mandatory?
http://www.garlic.com/~lynn/2006b.html#4 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
http://www.garlic.com/~lynn/2006d.html#6 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006e.html#31 MCTS
http://www.garlic.com/~lynn/2006e.html#33 MCTS
http://www.garlic.com/~lynn/2006f.html#19 Over my head in a JES exit
http://www.garlic.com/~lynn/2006g.html#3 The Pankian Metaphor
http://www.garlic.com/~lynn/2006i.html#22 virtual memory
http://www.garlic.com/~lynn/2006j.html#17 virtual memory
http://www.garlic.com/~lynn/2006j.html#38 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#14 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#41 PDP-1
http://www.garlic.com/~lynn/2006l.html#34 Dual Core CPUs are slower than Dual Single core CPUs ??
http://www.garlic.com/~lynn/2006m.html#30 Old Hashing Routine
http://www.garlic.com/~lynn/2006o.html#29 oops, cics
http://www.garlic.com/~lynn/2006o.html#51 The Fate of VM - was: Re: Baby MVS???
http://www.garlic.com/~lynn/2006p.html#22 Admired designs / designs to study

SHARE attendance

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SHARE attendance
Newsgroups: bit.listserv.ibm-main
Date: Fri, 15 Sep 2006 08:25:39 -0600
patrick.okeefe@ibm-main.lst (Patrick O'Keefe) writes:
I hate to argue with furniture (and hate even more when it argues back) but I'm pretty sure there was a SHARE in eithr L.A. or San Francisco that was around 5000. I remember it being commented on at the General Session.

Considering the decline in the number of mainframe shops, the decline in SHARE attendance is understandable. And lamentable.


i remember several shares being regularly on the order of 5000 and comments about the size limiting the locations available for the meetings. then there were a couple combined guide/share meetings that were a little larger (maybe around 6000?)

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.

Was FORTRAN buggy?

Refed: **, - **, - **, - **
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:
/BAH worked for DEC/DIGITAL . Does the same kind of thing with regression testing prevail in other companies as well? I would surely think that either the bugs being revealed by the test suite would be addressed. (After all they must have been reported by someone, in order for that particular test to have been put in the test suite) OR the test case would be purged from the test suite, since it any fix would not be attempted as an intentional decision.

i've told stories before about automated regression tests
http://www.garlic.com/~lynn/submain.html#bench

for resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

but that included a lot of validation of the resource management algorithms and control functions (under broad range of conditions, configurations, and workload ... aka including a lot of dynamic adaptive stuff) ... in addition to various kinds of failure modes.

early heavy stress testing resulted in numerous kernel failures. the result was rewriting the whole kernel serialization/syncronization 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, syncronization and other code, like a bunch of stuff for kernel organization for supporting smp)
http://www.garlic.com/~lynn/subtopic.html#smp

code out of the resource manager into the base system, there was a separate issue.

the original unbundling and starting to charge for software on 23jun69 (as a result of various gov. and other litigation efforts) argued that it should only be for application code ... and that kernel code should continue to be free.
http://www.garlic.com/~lynn/submain.html#unbundle

as things evolved during the 70s, there was beginning to be pressure to start charging for more and more code. the resource manager got chosen to be guinea pig for charging for specific kernel components (which eventually evolved into charging for all kernel components) ... and i got to spend time with business people working on policies for charging for kernel software components.

so in this transition period, the resource manager (and eventually other pieces) were charged for ... while the base kernel was free. moving over half of the code that had been in the initial resource manager into the base system ... wasn't just a packaging issue ... since it also met that the code went from "charged for" to "free".

Admired designs / designs to study

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 -0600
eugene@cse.ucsc.edu (Eugene Miya) writes:
My impression is that what we have collected, even in one case attempting to extract more indepth information, justified throwing ideas out and doing RISC. This is clearly not the case of what happened in this Wintel world. Our experiences (biases) show. And we don't know how to evaluate our ignorance w/o experiencing features. It's hard (complex) to be systematic because complete enumeration is too time consuming and frought with personal values (taste: how those who have different tastes hate the world we are now in).

i've periodically commented that the early 801/risc activity in the 70s
http://www.garlic.com/~lynn/subtopic.html#801

might be interpreted as an adverse reaction to the failure of Future System
http://www.garlic.com/~lynn/submain.html#futuresys

where FS appeared to try and include every admired feature that had ever been thot of ... 801 was trying to do the exact opposite.

a couple recent posts mentioning the subject
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#12 Another BIG Mainframe Bites the Dust

Was FORTRAN buggy?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Sat, 16 Sep 2006 07:20:18 -0600
Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
On site crash analysis with someone else doing the typing and reading, probably blindfolded with a locked cage around the system. ISTR someone posting about that: Lynn?

one of the reasons a lot of locations liked cp67 (and vm370) was full source distribution (and in fact, even monthly PLC maintenance was full source). recent post
http://www.garlic.com/~lynn/2006q.html#34 Was FORTRAN buggy?

they tended to have their own on-site people that did stuff like that ... sometimes they would even admit who they were at classes. some past posts making reference to TLA (agency as opposed to acronym)
http://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that rans as slow as today's supercomputers
http://www.garlic.com/~lynn/2004m.html#50 EAL5

also when i did dumprx
http://www.garlic.com/~lynn/submain.html#dumprx

i tried to automate most of the most common examination sequences and categorize/classify what was being looked at and why for signatures of common failure modes (for some common things, dumprx would examine various things and then based on what it found look at certain other things).

i've posted before about locked cages ... but they were totally different ... the "testcells" in the disk engineering labs
http://www.garlic.com/~lynn/subtopic.html#disk

this was somewhat security proportional to risk ... at one point there was some civil litigation (damages for several billion) over theft of industrial information and the judge made some statement that security surrounding that information needed to be proportional to the value/risk ... otherwise it is supposedly something like the swimming pool attractive nuisance, your can be liable if somebody trespasses and drowns in your swimming pool; aka people can't be blamed for being naturally thieves and walking away with valuable stuff.

engineering development hardware and the associated design documents had multiple layers of security (included these heavy gage steal wire-mesh cages with combination locks).

Was FORTRAN buggy?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Sat, 16 Sep 2006 08:49:14 -0600
Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
On site crash analysis with someone else doing the typing and reading, probably blindfolded with a locked cage around the system. ISTR someone posting about that: Lynn?

there was also field people that were specially assigned to such places.

in the late 60s, i thot that renton field datacenter might be the largest in the world ... but Boyd was assigned at one time to run one in far east that may have been larger. past post referencing
http://www.garlic.com/~lynn/2002j.html#43 Killer Hard Drives - Shrapnel?
http://www.garlic.com/~lynn/2003.html#51 Top Gun
http://www.garlic.com/~lynn/2003d.html#77 'Boyd': A military Strategist's Emphasis on Speed
http://www.garlic.com/~lynn/2004.html#2 The BASIC Variations
http://www.garlic.com/~lynn/2005m.html#22 Old Computers and Moisture don't mix - fairly OT
http://www.garlic.com/~lynn/2005m.html#23 Old Computers and Moisture don't mix - fairly OT
http://www.garlic.com/~lynn/2005m.html#24 Old Computers and Moisture don't mix - fairly OT
http://www.garlic.com/~lynn/2005t.html#1 Dangerous Hardware
http://www.garlic.com/~lynn/2005t.html#2 Dangerous Hardware
http://www.garlic.com/~lynn/2005t.html#5 Dangerous Hardware

one of the above references make mention that the far east nkp datacenter was a $2.5b windfall for ibm.

boyd had mentioned running nkp in his Pattern's of Conflict talk
http://www.garlic.com/~lynn/94.html#8 scheduling & dynamic adaptive ... long posting warning

and lots of other postings mentioning boyd
http://www.garlic.com/~lynn/subboyd.html#boyd

and misc. URLs from around the web mentioning boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

i recently did scan of parts of some of his briefings (from '83) and a couple of the scanned pages I use as background for the subboyd.html file.

Was FORTRAN buggy?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Sat, 16 Sep 2006 09:23:13 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
one of the above references make mention that the far east nkp datacenter was a $2.5b windfall for ibm.

re:
http://www.garlic.com/~lynn/2006q.html#36 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#37 Was FORTRAN buggy?

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?

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:17:58 -0600
Charlton Wilbur <cwilbur@mithril.chromatico.net> writes:
I need the software to do a certain thing. Once I've figured out what that is, I write a test for it, run the test to be sure it fails, write the code for the thing, run the test to be sure it succeeds, and call it done.

description of waterfall approach
http://www1.jsc.nasa.gov/bu2/PCEHHTML/pceh90.htm

where other approaches may be somewhat more iterative (and what can be learned from a Maverick Fighter)
http://www.garlic.com/~lynn/2006q.html#13 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#17 Was FORTRAN buggy?

Was FORTRAN buggy?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Sat, 16 Sep 2006 13:23:12 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
description of waterfall approach
http://www1.jsc.nasa.gov/bu2/PCEHHTML/pceh90.htm


oh, and from above ...
The process is usually considered non-iterative. Each phase requires the delivery of particular documentation products (Contract Data Requirements List - CDRL Items). Many of the phases require successful completion of a government review process. Critics of the "Waterfall" Model, in fact, find that the model is geared to recognize documents as a measure of progress rather than actual results.

The nine major activities described in 2167A/498 are as follows:

1. Systems Concept/System Requirements Analysis
2. Software Requirements Analysis
3. Software Parametric Cost Estimating
4. Preliminary Design
5. Detailed Design
6. Coding and Computer Software unit (CSU) Testing
7. Computer Software Component (CSC) Integration and Testing
8. Computer Software Configuration Item (CSCI) Testing
9. System Integration and Operational Testing


... snip ...

re:
http://www.garlic.com/~lynn/2006q.html#13 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#17 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#39 Was FORTRAN buggy?

was change headers: The Fate of VM - was: Re: Baby MVS???

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Larry Elmore <ljelmore@verizon.spammenot.net> writes:
Yeah, the Germans were much more flexible and aggressive than the Allies were. German officers disobeying orders and getting away with it because they were the people on the spot with the most accurate view of the situation was not at all uncommon. It happened in 1866, 1870, WWI and WWII. Sometimes it led to bad things happening, but far more often that quality led to surprising successes because the German army was so much more flexible and adaptable than their enemies, who ended up confounded and confused by the pace of events.

Boyd described it slightly differently ... he described Guderian as giving a directive before the blitzkrieg for verbal orders only

misc. past posts:
http://www.garlic.com/~lynn/99.html#120 atomic History
http://www.garlic.com/~lynn/2001.html#29 Review of Steve McConnell's AFTER THE GOLD RUSH
http://www.garlic.com/~lynn/2001m.html#16 mainframe question
http://www.garlic.com/~lynn/2002d.html#36 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#38 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002q.html#33 Star Trek: TNG reference
http://www.garlic.com/~lynn/2003h.html#51 employee motivation & executive compensation
http://www.garlic.com/~lynn/2003p.html#27 The BASIC Variations
http://www.garlic.com/~lynn/2004k.html#24 Timeless Classics of Software Engineering
http://www.garlic.com/~lynn/2004q.html#86 Organizations with two or more Managers
http://www.garlic.com/~lynn/2006f.html#14 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#9 The Pankian Metaphor

Boyd characterized the German army as being composed of professional soldiers ... he contrasted that with the american army on entry into the war as being mostly inexperienced. the american strategy was then to leverage the relatively little experience by having a heavy, top-down direction of masses of inexperenced troops ... and rely on massive overwhelming resources, logistics and control.

Boyd characterized large US companies in the 80s as reflecting this training for managing large operations that many of the executives were indoctrinated in during the war.

This contrast somewhat permeated his organic design for command and control briefing.
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

This was also reflected in Boyd's battle plan for desert storm. there was supposedly some comment that a problem going into the most recent conflict that Boyd had died in 1997. During desert storm there was a US news&report article that characterized the new generation of majors and colonels as Boyd's Jedi Knights.

Was FORTRAN buggy?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Mon, 18 Sep 2006 12:13:04 -0600
Andrew Swallow <am.swallow@btopenworld.com> writes:
This Depends which decade you are working in. They were not available in the 1950s but there were by the late 1970s. The hardware emulators were written whilst the electronic engineers designed the circuit boards. The emulator for the microprocessor ran on a ICL 1900.

course we had virtual machines with cp67 on 360/67 in the 60s ... and I've commented before about custom modifications to cp67 to simulate 370 architecture ... allowing 370 operating system development and other stuff well before real 370s became available. a recent post on the subject:
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft

the LSM was built at the los gatos lab ... used for circuit design logic simulation (LSM originally stood for "los gatos state machine" ... but was changed to "logic simulation machine" for outside publications). many of the logic verification techniques down thru the years have assumed synchronous block design. LSM provided for clock specification ... allow simulation of asynchronous clock designs ... as well as digital chips with analog circuits (i.e. was used for thinfilm/floating disk head designs). post earlier this year mentioning LSM
http://www.garlic.com/~lynn/2006.html#29 IBM microwave application--early data communications

LSM was rated at running circuit logic simulation 50,000 times faster than equivalent software on 3033. older post mentioning LSM (compared to 3033 for logic simulation)
http://www.garlic.com/~lynn/2004o.html#25 CKD Disks?

the disk engineering lab had these "testcells" ... a recent post mentioning
http://www.garlic.com/~lynn/2006q.html#36 Was FORTRAN buggy?

they had custom hardware boxes that would do numerous kinds of error injection. the testcells were a problem for operating systems ... besides the purposeful error injection, hardware under development could have large variety of error conditions and failure modes ... including numerous that would normally be considered forbotten and in violation of i/o architecture.

one of the issues was that attempting to run MVS on the connected processors resulted in MTBF for the operating system. As a result, testcell testing with processor was limited to stand-alone time using a custom monitor that did nothing but interact with (and report about) the hardware being tested.

so one of the things I undertook to do was rewrite the kernel i/o subsystem (device drivers, interrupt handlers, error recovery, error recording, RAS, etc) to be absolute bullet proof ... never cause the operating system to fail or hang (this allowed concurrent testing of several testcells simulateously connected to the same processor) misc. past posts about disk engineering (bldg. 14) and disk product test (bldg. 15) labs.
http://www.garlic.com/~lynn/subtopic.html#disk

21st century pyramids--super datacenters

Refed: **, - **, - **, - **
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

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

... snip ...

misc. past posts in related threads:
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006l.html#6 Google Architecture
http://www.garlic.com/~lynn/2006l.html#7 Google Architecture
http://www.garlic.com/~lynn/2006l.html#8 Google Architecture
http://www.garlic.com/~lynn/2006l.html#24 Google Architecture
http://www.garlic.com/~lynn/2006l.html#26 Google Architecture
http://www.garlic.com/~lynn/2006l.html#27 Google Architecture
http://www.garlic.com/~lynn/2006l.html#28 Google Architecture
http://www.garlic.com/~lynn/2006l.html#31 Google Architecture
http://www.garlic.com/~lynn/2006l.html#32 Google Architecture
http://www.garlic.com/~lynn/2006l.html#33 Google Architecture
http://www.garlic.com/~lynn/2006l.html#37 Google Architecture
http://www.garlic.com/~lynn/2006m.html#43 Google Architecture
http://www.garlic.com/~lynn/2006n.html#12 Google Architecture
http://www.garlic.com/~lynn/2006n.html#56 AT&T Labs vs. Google Labs - R&D History
http://www.garlic.com/~lynn/2006o.html#15 Google Architecture
http://www.garlic.com/~lynn/2006o.html#28 Google Architecture

The not-so-little shop of 747s

Refed: **, - **, - **, - **, - **
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 -0600
The not-so-little shop of 747s
http://news.com.com/The+not-so-little+shop+of+747s/2100-11395_3-6116778.html?tag=nefd.lede
The not-so-little shop of 747s
http://news.zdnet.com/2100-9584_22-6116778.html
The not-so-little shop of 747s
http://news.com.com/2100-11395_3-6116778.html?part=rss&tag=6116778&subj=news


from above:
EVERETT, Wash.--I stand in the middle of what I've been told is the largest building in the world, looking across the cavernous space at two nearly finished 747 jumbo jets.

... snip ...

Boeing brought me in the summer of '69 to help set up dataprocessing for newly formed BCS. 747 serial #3 was doing FAA certification test flights in the skies above Seattle. I rented a basement apt from one of the 747 engineers. old post:
http://www.garlic.com/~lynn/99.html#32

the renton datacenter was replicated in everett, among other things for disaster survivability. at one point there was study that if the datacenter was out of operation for a week, it would cost the business more than the cost of the datacenter.

recent post mentioning renton datacenter
http://www.garlic.com/~lynn/2006q.html#37 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#38 Was FORTRAN buggy?

for other drift ... we coined the terms disaster survivability and geographic survivability when we were doing ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

Was FORTRAN buggy?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Mon, 18 Sep 2006 21:48:10 -0600
jmfbahciv writes:
I don't think Lynn had to deal with as many variations as we did. Most of IBM's software (sources) stayed under their control. We didn't have that with TOPS-10. Until the new BLISS edicts, we did not keep our knowledge to ourselves; we shipped most sources. The only thing I can remember being restricted was MACY11.

vm370 was completely shipped and maintained in source form. it officially ran on 370/135 thru 370/168 (maybe .2 to 3.0mips, better than order magnitude rnage in processor speed). it wasn't officially supported on 370/125 ... about 100kips and max. real storage 256kbytes ... however, i did a custom modification so a customer (datacenter in nyc for a Norwegian shipping company) did have a 370/125 vm370 install. 3033 was added pushing the processor mips to 4.5 (and two processor smp to about 8mips). then 3081k two processor @7mips for 14mips (two orders of magnitude between 370/125 100kips and 3081 two processor smp at 14mips).

there were easily several hundred internal datacenters with eventually a couple thousand processors running the software (across an extremely large range of configurations and workloads). at one point there was a study that internal locations had source modifications to vm370 kernel that in aggregate was approx. twice as many lines-of-code as in the shipped product.

share/waterloo had similar contributed library of customer kernel software modifications ... in aggregate which was also about twice the number of lines of code in the base, shipped product (i.e. customer datacenters had contributed their source kernel modifications to the share/waterloo library ... the total source lines of code changes were approx. the same aggregate lines of code as aggregate number of lines of code changes done by internal datacenters).

recent post about complete source distribution and source maintenance
http://www.garlic.com/~lynn/2006q.html#34 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#36 Was FORTRAN buggy?

including having done resource manager ... which was also complete source distribution (as updates/changes to base system).

Melinda has long paper on here web site titled VM and the VM Community: Past, Present, and Future. At the same site there is also a paper WHAT MOTHER NEVER TOLD YOU ABOUT VM SERVICE (talks about source maintenance/update process).
http://www.leeandmelindavarian.com/Melinda/
http://www.leeandmelindavarian.com/Melinda/

there have been some number of posts/threads this year describing the origins of vm370 multi-level source update process ... starting back with cp67 with the (single level) source UPDATE program. This evolved into the multi-level update process, originally in support of the cp67h & cp67i effort to support 370 virtual machines under cp67, original post:
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft

later editor applications were enhanced to apply set of multi-level UPDATE changes to the base source before starting edit process ... and then to save all new deletes, updates, replaces, and inserts as a new update (as an option ... as opposed to saving the complete modify file). a few posts mentioning the multi-level source update process
http://www.garlic.com/~lynn/2006b.html#10 IBM 3090/VM Humor
http://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006f.html#38 Over my head in a JES exit
http://www.garlic.com/~lynn/2006n.html#45 sorting
http://www.garlic.com/~lynn/2006o.html#14 SEQUENCE NUMBERS

Was FORTRAN buggy?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Mon, 18 Sep 2006 22:07:35 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
recent post about complete source distribution and source maintenance
http://www.garlic.com/~lynn/2006q.html#34 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#36 Was FORTRAN buggy?


re:
http://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?

oh, and as to my "hobby" ... the resource manager ...

it passed 1000 paid licenses in less than six months after first customer ship. not only was i providing development, maintenance, documentation, classes, testing, product ship, etc ... as per earlier post
http://www.garlic.com/~lynn/2006q.html#34 Was FORTRAN buggy
http://www.garlic.com/~lynn/2006q.html#36 Was FORTRAN buggy

but for the first six months i also answered all problem calls.

Smartcard reader with certificate inside the reader

Refed: **, - **, - **
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 -0600
gerlach <mpx@nospam.hoga.pl> writes:
Does anyone know if there are smartcard readers that have their own reader certificates with private keys that allow to authorize reader by using PKI?

These certificate/keys should be a permanent part of the device, so that no changes are possible.


we have proposed option for EU Finread like terminals
http://www.garlic.com/~lynn/subintegrity.html#finread

to have private key that co-signs transactions w/o actually requiring PKI and/or digital certificates
http://www.garlic.com/~lynn/subpubkey.html#certless

in part because certificate-based operation can result in enormous payload bloat for some transactions (in addition to being redundant and superfluous)
http://www.garlic.com/~lynn/subpubkey.html#bloat

EU Finread terminal has its own pinpad and display as countermeasure to various exploits & vulnerabilities ... virus/trojans on PCs, keyloggers, displaying information different than what is being signed, using logged pins to perform signed transactions w/o the victims knowledge, etc.

the issue for the relying party is how do they actually know that a card is being used in a normal PC environment or is actually being done in conjunction with a certified (eu finread?) terminal ... w/o having the terminal actually co-signing the transactions and attesting to the higher integrity key-signing transaction environment.

part of this was in conjunction with the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the result was x9.59 financial standard.

the x9.59 standard doesn't require that a terminal (and/or other environment that the transaction is performed in) actually co-sign every transaction, however the standard was crafted such that it allows a terminal (or other device) to co-sign a transaction, as an indication of possible higher integrity (or physical location or other characteristics that a relying party might be interested in when evaluated risk related to a transaction).

Smartcard reader with certificate inside the reader

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 -0600
re:
http://www.garlic.com/~lynn/2006q.html#47 Smartcard reader with certificate inside the reader.

independent of whether the terminal has a private key and can perform digital signing operations ... there are terminals which may include a PKI stack for doing digital signature verification operations.

an example would be point-of-sale financial terminals supporting chip&pin.

chip&pin has had static data authentication deployments for going on ten years(?). this is where the chip can present something akin to a digital ceritificate (w/o performing its own signing operation) to the terminal ... and the terminal can verify the digital certificate.

however, since it is static data ... it turned out to be subject to skimming, in much the same way that magstripe data can be skimmed and which is then used to produce a counterfeit card.

chip&pin is nominally two-factor authentication ... from the 3-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor
something you have
something you know
something you are


where the chip/card is something you have authentication and the pin is something you know authentication. normally, multi-factor authentication is considered higher security and integrity when the different factors have independent faulure and exploits. pin (something you know) is frequently considered countermeasure to lost/stolen cards ("somehting you have").

the issue in some of the magstripe skimming scenarios is that the magstripe information and the pin information are skimmed at the same time (resulting in a common exploit, and invalidating assumption about independent failure/exploits).

the "static data" chip&pin had a different kind of exploit with counterfeit yes cards ... see last paragraph of this archived information from 2002
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

where it mentions that yes cards have been well known for some time and the details on creating yes cards were widely available from the internet.

the issue in the yes card exploit is that the authentication "static data" is skimmed and loading into a counterfeit card.

the terminal, once it had validated the authentication information would then "ask" (a supposedly valid card): 1) whether the entered pin was correct, 2) whether the transaction should be offline, and 3) whether the transaction was within the account's credit limit. as you might guess from the yes card label ... a counterfeit yes card would answer YES to such questions. in this scenario, there was not an independent exploit with regard to the entered pin ... once the counterfeit yes card had been created ... it would answer YES to whatever pin was entered (no longer requiring the attacker to know valid pins ... and negating any assumption regarding multi-factor authentication).

lots of collected posts mentioning exploits, threats, vulnerabilities and fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud

the countermeasure to the "static data" authentication yes card exploit ... is to possibly have the chip sign some random data presented by the terminal. the chip then returns both the (dynamic data) digital signature and the digital certificate. the terminal then validates the digital certificate (like it does now) and then uses the certificate's public key to validate the chip's (dynamic data) digital signature.

note that this might still be vulnerable to a MITM-attack
http://www.garlic.com/~lynn/subintegrity.html#mitm

where a counterfeit yes card is paired with some valid card ... the yes card passes the initial authentication sequence transparently between the valid card and the terminal ... and then performs the YES response to all subsequent operations.

misc. collected posts discussing yes cards
http://www.garlic.com/~lynn/subintegrity.html#yescard

Was FORTRAN buggy?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Tue, 19 Sep 2006 16:59:16 -0600
Peter Flass <Peter_Flass@Yahoo.com> writes:
Sometimes true. Didn't Lynne post some stuff about some new 370 CPUs not agreeing with the emulated CPU under VM? I can't remember what the outcome was.

the cp67h updates to cp67 kernel (runs on 360/67, provides 360 virtual machines, and 370 virtual machines as an option). cp67i updates to cp67 (at least thinks it is running on 370, provides 370 virtual machines).

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

since this was the first engineering prototype machine ... it was quickly patched to correspond to the official architecture definition.

recent posts mentioning cp67h and cp67i updates for the cp67 kernel
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?

I've also mentioned another problem with getting vm370 up and running on 370/125 ... recent post mentioning the effort
http://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?

360 instructions would pretest starting and ending addresses for argument ... for things like protection (fetch & store) or page fault (at least on 360/67) ... and indicate exception before even starting the instruction. 370 introduced a couple (long) instructions that executed incrementally. machine would process "long" (compare, move) instruction argument locations incrementally and only indicate fault/exception when it encountered storage access problem (for storage address being directly processed).

move long had two pair of registers, with origin start&length and destination start&length. on instruction completion (or exception) the registers would indicate how far processing had gotten (incrementing argument addresses and decrementing remaining length). move long also provide for "pad" byte for scenario where origin length was less than destination length. it was possible to use this for clearing storage by setting the pad byte to zero, the origin length to zero and the destination length to the desired amount.

early vm370 kernel used mvcl early in the boot process to both clear memory and test for size of memory (by setting destination length to max). when the instruction encountered end-of-memory would would result in exception and the registers would be update to reflect where end-of-memory was.

early 370/125s were shipped to customers with a "bug" in the long instructions microcode ... it would "pretest" starting and ending argument addresses and cause an exception interrupt if there was a problem before even starting the instruction (instead of executing the instructions incrementally and only generate exception when it got to argument storage address with an issue).

as a result, vm370 would think there was no real storage on 370/125 to execute in and fail.

besides having to optimize vm370 kernel size to fit it into 370/125 256kbytes, it also had to be modified to get around the 125 mvcl microcode "bug" (at least until 125s were retrofitted with fix).

misc. past posts mentioning the MVCL bug on 370/125
http://www.garlic.com/~lynn/2000c.html#49 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000g.html#8 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001f.html#69 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2002i.html#2 Where did text file line ending characters begin?
http://www.garlic.com/~lynn/2002i.html#9 More about SUN and CICS
http://www.garlic.com/~lynn/2003.html#13 FlexEs and IVSK instruction
http://www.garlic.com/~lynn/2003j.html#27 A Dark Day
http://www.garlic.com/~lynn/2004b.html#26 determining memory size
http://www.garlic.com/~lynn/2004c.html#33 separate MMU chips
http://www.garlic.com/~lynn/2004g.html#54 effeciently resetting a block of memory
http://www.garlic.com/~lynn/2006.html#12 Zeroing core
http://www.garlic.com/~lynn/2006n.html#46 Why is z series so CPU poor?

Was FORTRAN buggy?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Tue, 19 Sep 2006 17:45:45 -0600
re:
http://www.garlic.com/~lynn/2006q.html#49 Was FORTRAN buggy?

I had a similar but different problem with 3880 disk controller.

I recently made a post about doing a bullet proof i/o subsystem for bldg. 14 & bldg. 15
http://www.garlic.com/~lynn/2006q.html#42 Was FORTRAN buggy?

and have mentioned in the past that now being responsible for the operating systems in this environment ... I would frequently be the first person blamed if there was a problem. numerous collected past posts
http://www.garlic.com/~lynn/subtopic.html#disk

I've posted before about an incident in bldg. 15 when the engineers had replaced a 3830 disk controller (for a string of disks used for internal time-sharing) with a 3880 disk controller ... and performance significantly degraded ... and I was first to blame as possibly having made a kernel change over the weekend (since they hadn't changed any hardware).
http://www.garlic.com/~lynn/2000c.html#75 Does the word "mainframe" still have a meaning?>
http://www.garlic.com/~lynn/2001h.html#28 checking some myths.
http://www.garlic.com/~lynn/2002b.html#2 Microcode? (& index searching)
http://www.garlic.com/~lynn/2004p.html#61 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer

earlier I had gotten embroiled in a similar but different problem with the same 3880 disk controller engineering effort. as mentioned in the above posts ... the 3830 had switched from a (fast) horizontal microcode engine to 3880 with a much slower vertical microcode engine ... that was dedicated to control operation with a spearate data path to handle pure data transfer (including the increase to 3mbytes/sec transfer).

part of the issue was that new hardware had to be at least plus/minus five percent of the previous hardware. the slower jib-prime in the 3880 was taking longer to get an operation started and longer to clean-up an operation after data transfer completed. while operations with 3380 had 3mbyte transfer offsetting the slower control operations. however, if 3880 controller was just replacing 3830 with existing disks ... all operations appeared to take longer. the "performance" problem mentioned above involved situation where they had the 3880 telling the processor that operation was complete before it had finished all the cleanup operation.

there was actually a similar problem with 3880 several months earlier. at this time, they had the 3880 presenting i/o operation complete before they had started cleanup and hadn't check for some specific i/o errors. if they found i/o errors at this point they were forced to present "unsolicited unit check" interrupt condition to the processor.

I periodically reviewed what was going on and noticed the "unsolicated unit checks" ... and informed the 3880 controller engineers that this was a violation of the i/o architecture ... i.e. "unit check" conditions (i.e. i/o errors) always had to be presented with an operation that they were associated with ... and "unsolited unit checks" (i.e. unit check interrupt not associated with any operation) were violation of I/O architecture.

This got me dragged into conference calls between the san jose disk controller engineers and the POK channel engineers ... as sort of intermediary. Eventually it was resolved, that unsolicited unit checks were violation of channel I/O architecture and the disk controller engineers had to fix the 3880. They had to move signal completion of operation until after they had finished checking for all possible i/o error conditions (so any possible i/o error condition could be included in ending status). In a few rare instances, they saved them and presented them the next time a new operation was initiated.

Afterwards I asked why was I being dragged into it. the answer was that i apparently was one of the few people in san jose who understood channel i/o architecture. this had been handled in the past by the senior engineers ... but so many senior engineers had been hired away over the years ... that almost none were left.

I had to know channel i/o architecture ... not only for the rewrite of the i/o supervisor to make it bullet proof ... but also for the correct operation of the virtual machine emulated i/o

old post detailing some of the defections
http://www.garlic.com/~lynn/2002.html#17 index searching

Intel abandons USEnet news

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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:
I think it's a matter of time before somebody makes use of "intelligent" proxies running locally in your computer when disconnected from the internet to service all those online services offline. For static content that are cached, mozilla/firefox offline mode does that already - so hosted SVG won't be a problem if we add some way to make sure certain data are cached and not purged. With aggressive prefetching and sufficiently large local scratch disk space, it won't be a big problem once people have sufficient bandwidth.

for a couple years now, i've been using mozilla/firefox tab folders to read news. i have a bookmark tab folder with a 100 or so news sites. i click on the folder and it starts fetching all 100 URLs concurrently into different tabs. i can go get another cup of coffee while it is doing its thing. i no longer into vageries of synchronous click/delay. as i'm scanning news, i can click on news story url ... which is brought asynchronously into background tab. when i'm finished scanning the news sites (deleting the tab as i finish) ... i then have all the specific news stories ready (having been brought asynchronously into the background tabs). early on, there were some performance issues with having several hundred open tabs ... but tab support has gotten quite a bit better.

misc. old post on using browser tab support:
http://www.garlic.com/~lynn/2004e.html#54 Is there a way to configure your web browser to use multiple
http://www.garlic.com/~lynn/2005e.html#48 Mozilla v Firefox
http://www.garlic.com/~lynn/2005e.html#50 Mozilla v Firefox
http://www.garlic.com/~lynn/2005e.html#55 Mozilla v Firefox
http://www.garlic.com/~lynn/2005e.html#60 Mozilla v Firefox
http://www.garlic.com/~lynn/2005e.html#66 Mozilla v Firefox
http://www.garlic.com/~lynn/2005n.html#8 big endian vs. little endian, why?
http://www.garlic.com/~lynn/2005n.html#15 1.8b2 / 1.7.11 tab performance
http://www.garlic.com/~lynn/2005n.html#41 Moz 1.8 performance dramatically improved
http://www.garlic.com/~lynn/2005o.html#13 RFC 2616 change proposal to increase speed

even with significant higher bandwidth (dialed vis-a-vis broadband) there can still be issue with remote site load and/or infrastructure congestion.

i've mostly used emacs gnus for quiet awhile for newsreading ... and it tries to do some heuristic asynchronous read-ahead (and does support offline processing).

Smartcard reader with certificate inside the reader

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 -0600
gerlach <mpx@nospam.hoga.pl> writes:
The idea is to have the usual USB smartcard reader for PC computer functionality for Windows (like doing signature, perhaps also logon). With the addition of assuring that only allowed readers are used, by checking signature of the reader before accessing smartcard.

re:
http://www.garlic.com/~lynn/2006q.html#47 Smartcard reader with certificate inside the reader.
http://www.garlic.com/~lynn/2006q.html#48 Smartcard reader with certificate inside the reader.

check some of the eu standards sites ... like:
http://istresults.cordis.europa.eu/index.cfm/section/news/tpl/article/BrowsingType/Features/ID/579
http://cordis.europa.eu/fetch?ACTION=D&CALLER=PROJ_IST&QM_EP_RCN_A=58338
http://cordis.europa.eu/fetch?ACTION=D&CALLER=PROJ_IST&QM_EP_RCN_A=58404

are you talking about windows only enabling/allowing use of a certified reader/terminal ... or the card/token verifying that it is interacting with a certified reader/terminal?

the original kerberos pk-init
http://www.garlic.com/~lynn/subpubkey.html#kerberos

(underlying authentication mechanism in windows and several other platforms) originally only specified a certificate-less mode of operation for public key and digital signature authentication
http://www.garlic.com/~lynn/subpubkey.html#certless

i.e. public key is registered in lieu of password ... and kerberos verifies digital signature on some random data (dynamic data authentication as countermeasure to replay attacks).

there was some effort applied then to include certificate-mode of operation in the kerberos pk-init specification (in addition to certificate less).

a couple years ago, i got email from the person claiming primary responsibility for forcing certificate operation into the kerberos pk-init specification ... and apologizing (finally realizing that it was redundant and superfluous). he was associated with some of the GRID activities and invited me to give a certificate-less talk at the next annual grid forum.
http://forge.ggf.org/sf/docman/do/listDocuments/projects.ogsa-wg/docman.root.meeting_materials_and_minutes.ggf_meetings.ggf11
http://forge.ggf.org/sf/go/doc12899;jsessionid=E86ACAF7A29F2E1FC2575AD0CD04E39E?nav=1

various kerberos rfcs ... from my ietf rfc index
http://www.garlic.com/~lynn/rfcietff.htm

select Term (term->RFC#) in the RFCs listed by section ... and then scroll/find "Kerberos" ... i.e.
kerberos
see also authentication , generic security service , security
4559 4557 4556 4537 4430 4402 4121 4120 3962 3961 3244 3129 2942 2712 2623 1964 1510 1411


clicking on an RFC number brings up the summary for that RFC. in the summary field, clicking on the ".txt=nnnn" field, retrieves the actual RFC.

Was FORTRAN buggy?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Wed, 20 Sep 2006 10:04:04 -0600
Steve O'Hara-Smith <steveo@eircom.net> writes:
Is this really true ? ISTR the first shuttle was lifted into the air on the back of a modified 747 and test flown. OTOH I also note that said test harness no longer seems to exist so any changes to that software can only be tested in emulation and then live use.

i think the same plane is used for ferrying the shuttle back to kennedy if it has to use the alternative landing site at edwards?

Was FORTRAN buggy?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Wed, 20 Sep 2006 12:20:27 -0600
Steve O'Hara-Smith <steveo@eircom.net> writes:
Is this really true ? ISTR the first shuttle was lifted into the air on the back of a modified 747 and test flown. OTOH I also note that said test harness no longer seems to exist so any changes to that software can only be tested in emulation and then live use.

old posting mentioning shuttle software in context of calenders and y2k
http://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese Solve Y2K)
http://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...
http://www.garlic.com/~lynn/2003p.html#21 Sun researchers: Computers do bad math ;)

a couple recent postings mentioning 747 and everett
http://www.garlic.com/~lynn/2006q.html#37 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#38 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#44 The not-so-little shop of 747s

one of the problems with autopilot flying 747 was that the glide path into seatac airport was automatically acquired and followed ... resulting in 747 landings all happening within a couple feet of each other ... resulting in severe strain and cracking in the runway at that position. they had to modify the software so that it slightly randomized the path so it spread out the actual landings over wider area.

one of the claims for the 757/767/777 was that the requirement for faa certification flights were significantly reduced (compared to the 747) by the use of advanced design and modeling software (besides use of software used in controlling the plane).

one of the other issues was that much of the design software came from a french company and there were some concerns about industrial espionage and/or competitive advantage with possibility that airbus would get the most/more advanced software features.

for additional topic drift ... recent comment
http://www.garlic.com/~lynn/aadsm25.htm#29

in thread mentioning 787 and some software and other issues
https://financialcryptography.com/mt/archives/000678.html

Was FORTRAN buggy?

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:
Well,.. In the case of the IBM 360 mod 30, the unifying 360 architecture definition existed. But the architecture was only implemented for that model via emulation on a different micro engine. i.e. no mod 30, 360 hardware, ever existed as such. In the: architecture, implementation, realization, description model of computers, 360 architecture of the mod 30 was implemented via emulation on the ??? micro engine, and the realization was (some family of electronic transistor building blocks technology). In the case of the 1401 emulator on the IBM 360 mod 40 and the 7090 emulator on the IBM 360 mod 50 the computers being emulated did exist as separate independant hardware products. None of these three that I mentioned were preproduction development simulations of a future devices to be implemented and realized in another form.

the 360/30 had 1401 emulation (in addition to 360 emulation)

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.

Was FORTRAN buggy?

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:
Hmmm. Was this 1401 emulation emulated directly on the hardware same as the 360 architecture was emulated on the hardware? Or was it emulated on the resulting mod 30. ie. a two step, (two deep) emulation?

microcode ... one of the switches on front panel put in into 1401 emulation mode, you put a 1401 program card deck into the 2540 card reader and hit the load button.

Was FORTRAN buggy?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Thu, 21 Sep 2006 08:51:27 -0600
Peter Flass <Peter_Flass@Yahoo.com> writes:
I believe the 1401 emulation on a /30 required a microcode load. Was it either/or 360 or 1401? I also believe the 1401's 1311 disks were emulated on 2311's. I believe it was 1:1, not "minidisks", so you'd lose half a pack in emulation mode. Of course this is all memories of long ago.

re:
http://www.garlic.com/~lynn/2006q.html#55 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#56 Was FORTRAN buggy?

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.

Intel abandons USEnet news

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:
You just rerereinvented the thin client, or maybe the terminal/mainframe. A cheap box with a browser hooked to a big server. Hmmm.... The circle of life just went back to about 1975. Only it was a 3279 or equivilent and not a browser.

can you say SAA? ... and return to terminal emulation paradigm
http://www.garlic.com/~lynn/subnetwork.html#emulation

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

TCPA compatible smarcard readers?

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 -0600
gerlach <mpx@nospam.hoga.pl> writes:
Are there any? From what I know about TCPA every device has to have a certificate inside, and signature capabilities.

it could be useful for every device/chip to have a private key and digital signature capability ... enabling authentication. one of the uses is allowing a relying party to do risk assesement about the integrity of the originating environment. discussed recently in one of your other threads ... mentioning EU FINREAD
http://www.garlic.com/~lynn/2006q.html#47 Smartcard reader with certificate inside the reader

note that the certificate becomes redundant and superfluous once the public key has been registered.
http://www.garlic.com/~lynn/subpubkey.html#certless

somewhat related thread regarding being able to determine chip integrity using similar approach
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#5 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#6 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#10 Crypto to defend chip IP: snake oil or good idea?

Was FORTRAN buggy?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Was FORTRAN buggy?
Newsgroups: alt.folklore.computers
Date: Fri, 22 Sep 2006 08:13:25 -0600
KR Williams <krw@att.bizzzz> writes:
How did you maintain compatibility between processors? If the hardware doesn't meet the spec (in any significant way; eratta seems to be a given) it has to be changed.

i was told a tale about the gov. anti-trust trial ... supposedly the bunch testified that by the late 50s, they had all determined that the single most important factor in being succesful in the computer business was to have a compatible line of computers. supposedly each of them had set out to do it ... but only IBM was succesful in enforcing the rule. supposedly there was constant pressure from plant managers responsible for each specific product ... that their specific product could be made more efficient if they were allowed to deviate from complete compatibility ... by optimizing something or another that was specific to their hardware components. corporate hdqtrs in the other companies were never fully succesful in forcing the different plant locations (responsible for different parts of the product line) to maintain compatibility.

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 succesful in the computer business
http://www.garlic.com/~lynn/2001j.html#38 Big black helicopters
http://www.garlic.com/~lynn/2001j.html#39 Big black helicopters
http://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
http://www.garlic.com/~lynn/2002c.html#0 Did Intel Bite Off More Than It Can Chew?
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
http://www.garlic.com/~lynn/2003.html#36 mainframe
http://www.garlic.com/~lynn/2003b.html#61 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003o.html#43 Computer folklore - forecasting Sputnik's orbit with
http://www.garlic.com/~lynn/2004h.html#15 Possibly stupid question for you IBM mainframers... :-)
http://www.garlic.com/~lynn/2004l.html#14 Xah Lee's Unixism
http://www.garlic.com/~lynn/2005k.html#0 IBM/Watson autobiography--thoughts on?
http://www.garlic.com/~lynn/2005k.html#4 IBM/Watson autobiography--thoughts on?
http://www.garlic.com/~lynn/2005o.html#23 Collins C-8401 computer?

Wars and Allies

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Wars and Allies
Newsgroups: alt.folklore.computers
Date: Fri, 22 Sep 2006 12:00:45 -0600
CBFalconer <cbfalconer@yahoo.com> writes:
Remember the context. France and Britain were exhausted from WWI, and had lost a very significant portion of their younger generation of men in it. Their primary interest was in avoiding war. It is unfortunate that the characteristics of Hitler and the National Socialists brought on Munich, and that the attempted war avoidance didn't work.

a little drift:
http://virus.stanford.edu/uda/

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

Cray-1 Anniversary Event - September 21st

Refed: **, - **, - **, - **, - **, - **, - **
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 -0600
stanb45@dial.pipex.com (Stan Barr) writes:
The first commercial transistors were used in audio applications, they wouldn't work at high enough frequencies for radio until some time later, 1956/7 IIRC. It was the ready availablilty of mass-produced transistors for consumer applications that kick-started their use in computers in 1953 at Manchester University and 1954 in the US with Bell Labs' TRADIC.

in the mid-80s, i remember comming back from a business trip across the pacific (to contract for some hardware) and making the observation that a $300 cdrom drive had much better technology than various pieces of "computer gear" costing fifty times as much.

in the late 80s and early 90s similar observations somewhat led to the commerce dept. backing some of the hdtv format wars. misc. past posts mentioning the hdtv format wars
http://www.garlic.com/~lynn/2000e.html#11 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2001.html#73 how old are you guys
http://www.garlic.com/~lynn/2001b.html#2 FCC rulemakings on HDTV
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2005k.html#25 The 8008
http://www.garlic.com/~lynn/2006.html#45 IBM 610 workstation computer

misc. past posts making some reference to the same business trip:
http://www.garlic.com/~lynn/94.html#33b High Speed Data Transport (HSDT)
http://www.garlic.com/~lynn/2000b.html#69 oddly portable machines
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001k.html#57 SMP idea for the future
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002g.html#76 Pipelining in the past
http://www.garlic.com/~lynn/2003b.html#67 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003d.html#23 CPU Impact of degraded I/O
http://www.garlic.com/~lynn/2003m.html#59 SR 15,15
http://www.garlic.com/~lynn/2003n.html#33 Cray to commercialize Red Storm
http://www.garlic.com/~lynn/2004g.html#12 network history
http://www.garlic.com/~lynn/2004n.html#29 Is Fast Path headed nowhere?
http://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
http://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005n.html#25 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005r.html#9 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005u.html#57 IPCS Standard Print Service
http://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006i.html#17 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006n.html#56 AT&T Labs vs. Google Labs - R&D History




previous, next, index - home