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

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/subtopic.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?

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

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

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
http://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:
http://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
http://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

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?

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?

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?

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).
http://en.wikipedia.org/wiki/RISC_Single_Chip

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: 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) ?

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/subtopic.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?

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/

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 attached to
patton. 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) ?

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

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

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
aug68 share user group meeting held in boston
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

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?

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?

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"

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


From: wheeler
Date: 92/06/30  22:43:04
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

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

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/marchapril05/stoprun/10020p1.aspx

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

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/subtopic.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/subtopic.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???

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?

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?

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?

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?

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/subtopic.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 rewritting the whole kernel serialization/syncronization
infrastructure (to eliminate all observed failure modes) ... which was
more code and significant more module hits ... than the