List of Archived Posts

2006 Newsgroup Postings (07/27 - 08/23)

System/360 Prototype

harris

the more things change, the more things stay the same

MTS, Emacs, and... WYLBUR?

How Many 360/195s and 370/195s were shipped?

Gould, not Harris

Article on Painted Post, NY

Pa Tpk spends $30 million for "Duet" system; but benefits are unknown

Pa Tpk spends $30 million for "Duet" system; but benefits are unknown

Pa Tpk spends $30 million for "Duet" system; but benefits are unknown

Article on Painted Post, NY

Article on Painted Post, NY

Article on Painted Post, NY

The SEL 840 computer

SEQUENCE NUMBERS

Google Architecture

Gen 2 EPC Protocol Approved as ISO 18000-6C

Gen 2 EPC Protocol Approved as ISO 18000-6C

RAMAC 305(?)

Source maintenance was Re: SEQUENCE NUMBERS

Gen 2 EPC Protocol Approved as ISO 18000-6C

Source maintenance was Re: SEQUENCE NUMBERS

Cache-Size vs Performance

Strobe equivalents

computational model of transactions

CPU usage for paging

Cache-Size vs Performance

oops

Google Architecture

oops, cics

The Question of Braces in APL-ASCII

Metroliner telephone article

When Does Folklore Begin???

When Does Folklore Begin???

Source maintenance was Re: SEQUENCE NUMBERS

the personal data theft pandemic continues

Metroliner telephone article

the personal data theft pandemic continues

hardware virtualization slower than software?

sorting

the personal data theft pandemic continues

When Does Folklore Begin???

Metroliner telephone article

"25th Anniversary of the Personal Computer"

When Does Folklore Begin???

"25th Anniversary of the Personal Computer"

"25th Anniversary of the Personal Computer"

the personal data theft pandemic continues

sorting

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

When Does Folklore Begin???

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

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

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

When Does Folklore Begin???

When Does Folklore Begin???

Greatest Software Ever Written?

Greatest Software Ever Written?

Greatest Software Ever Written?

Why no double wide compare and swap on Sparc?

Greatest Software?

Health Care

Greatest Software, System R

Greatest Software, System R

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

"25th Anniversary of the Personal Computer"

"25th Anniversary of the Personal Computer"

How the Pentium Fell Short of a 360/195

DASD Response Time (on antique 3390?)

System/360 Prototype

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System/360 Prototype
Newsgroups: alt.folklore.computers
Date: Thu, 27 Jul 2006 13:21:26 -0600

hancock4 writes:

While in a sense the above is correct, I think it'd be more accurate to
say Watsons' (both) compensation was based on total sales of the
company.  If the company did well, he did well and vice versa.

the person was very explicit about the wording of the executive
compensation plan ... as saying that watson got a specific straight
sales commission on everything ibm sold (he said that he found it a
little odd since the straight sales commission percent (of everything
sold) was specified to four decimal places ... i.e. x.yyyy percent).

a lot of executive compensation plans have been based on profit (as a
measure of how well the company does) as opposed to gross sales (which
may or may indicate how well a company is doing). for instance, in
1992, ibm reported a couple billion dollar loss on several tens of
billions in sales.

ibm, in the time-frame mentioned as obtaining ibm's 10k
http://www.garlic.com/~lynn/2006n.html#59 System/360 Prototype

had moved salesmen to quota system ... not straight sales commission
... i.e. salesmen were given sales target and base (maybe
20-40percent) of target compensation. If they sold one hundred percent
of their quota ... they got reminder of their pay.  if they were on
20percent base, and made twice their quota ... then they got .2 + 2*.8
= 1.8 times their target compenstation. Note it also wasn't unusual if
somebody were to make 100percent of their annual quota by mid-year
... to have they quota retro-actively adjusted for the year.

this prevented salesman, that might sell a couple hundred million
dollars of computer equipment, from getting several million dollar
commission (which could happen if there was a straight sales
commission plan; which apparently what Watson was getting; but the
salesmen were on this quota plan).

As to general corporate activity in the last 50 years ... some number
of companies modeled their sales operations after ibm, quotas, sales
promotions, annual award meetings, etc. IBM had an annual event called
the 100percent club ... for salesmen that made at least one hundred
percent of their quota. I know of one company in the early 80s with
200 hundred salesmen that didn't have a single sales and lost a
billion dollars. that year they sent all the salesmen and their SOs on
one week trip to Hawaii ... and had to come up with alternative name
for the event (as opposed to the "zero percent club" award meeting).

harris

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: harris
Newsgroups: alt.folklore.computers
Date: Thu, 27 Jul 2006 13:32:13 -0600

"Tim Shoppa" writes:

IIRC it was a (or multiple) RISC-like CPU, not too different than the
MIPS stuff coming out of everywhere in the early 90's, except that the
Harris brand made it a lot more expensive! None of those IMHO falls
into minisuper (which for me means things like bolt-on array
processors, Convex, FPS, etc.)

old mini-super posting giving number of machines
http://www.garlic.com/~lynn/2001b.html#56 Why SMP at all anymore?

the above reposts a '88 supercomputing report that lists 850
minisupercomputers having been installed since 1981 (it also mentions
that there were rumors about a Harris minisuper). It also lists
installs for Alliant, Convex, ELXSI, FPS, Gould, Multiflow, and
Scientific Computer (and that Celerity was just shipping and Supertek
hadn't shipped yet).

posting repeating above numbers
http://www.garlic.com/~lynn/2001d.html#32 Imitation..

the more things change, the more things stay the same

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: the more things change, the more things stay the same
Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l
Date: Thu, 27 Jul 2006 14:32:06 -0600

re:
http://www.garlic.com/~lynn/2006n.html#52 the more things change, the more things stay the same
http://www.garlic.com/~lynn/2006n.html#53 the more things change, the more things stay the same

the following article:

How Secure Is That Device?  As device software joins the larger world,
security becomes ever more vital
http://dso.com/news/showArticle.jhtml?articleID=191501076

Has statements that are almost exact quotes of some statements about
virtualization made in the late 60s, nearly 40 years ago.

the article is also related to the thread raised in this crypto topic drift
http://www.garlic.com/~lynn/2006n.html#57 The very first text editor

started with this article
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=190900759

the most recent in that thread
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypt to defend chip IP: snake oil or good idea?

and even more thread drift related to the subject
http://www.garlic.com/~lynn/aadsm24.htm#53

MTS, Emacs, and... WYLBUR?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MTS, Emacs, and... WYLBUR?
Newsgroups: alt.folklore.computers
Date: Thu, 27 Jul 2006 16:46:46 -0600

scott@slp53.sl.home (Scott Lurndal) writes:

We used to call it, TSO and Burroughs CANDE "Batch with a Patch".

Wylbur was useful, as compared with punching cards and waiting a day
or two for your output.

i had done tty support in cp67 ... slightly related about doing
our own clone telecommunication controller
http://www.garlic.com/~lynn/subtopic.html#360pcm

and played with the cms editor to get it to do "full-screen" displays
on 2250m1 ....

but I also supported the university os360 mft/hasp (and transition to
os360 mvt/hasp) system.  hasp managed "job" submission and files
... for cards and printed out.

i hacked hasp on mvt release18 .... putting in 2741 and tty terminal
support along with writing an "editor" from scratch that supported cms
editor command syntax .... for a "CRJE" system (i.e. conversational
remote job entry).

misc. past posts mentioning crje:
http://www.garlic.com/~lynn/93.html#15 unit record & other controllers
http://www.garlic.com/~lynn/96.html#12 IBM song
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/98.html#29 Drive letters
http://www.garlic.com/~lynn/99.html#76 Mainframes at Universities
http://www.garlic.com/~lynn/99.html#77 Are mainframes relevant ??
http://www.garlic.com/~lynn/99.html#92 MVS vs HASP vs JES (was 2821)
http://www.garlic.com/~lynn/99.html#109 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000f.html#71 HASP vs. "Straight OS," not vs. ASP
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001n.html#37 Hercules etc. IBM not just missing a great opportunity...
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#38 Playing Cards was Re: looking for information on the IBM
http://www.garlic.com/~lynn/2002h.html#14 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2003g.html#64 UT200 (CDC RJE) Software for TOPS-10?
http://www.garlic.com/~lynn/2003k.html#13 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003m.html#53 model 91/CRJE and IKJLEW
http://www.garlic.com/~lynn/2003m.html#56 model 91/CRJE and IKJLEW
http://www.garlic.com/~lynn/2003o.html#64 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004b.html#53 origin of the UNIX dd command
http://www.garlic.com/~lynn/2004c.html#10 XDS Sigma vs IBM 370 was Re: I/O Selectric on eBay: How to use?
http://www.garlic.com/~lynn/2004c.html#27 Moribund TSO/E
http://www.garlic.com/~lynn/2004c.html#28 Moribund TSO/E
http://www.garlic.com/~lynn/2004c.html#32 Moribund TSO/E
http://www.garlic.com/~lynn/2004g.html#11 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#39 spool
http://www.garlic.com/~lynn/2004j.html#17 Wars against bad things
http://www.garlic.com/~lynn/2004l.html#20 Is the solution FBA was Re: FW: Looking for Disk Calc
http://www.garlic.com/~lynn/2004l.html#29 FW: Looking for Disk Calc program/Exec
http://www.garlic.com/~lynn/2004n.html#0 RISCs too close to hardware?
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#13 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#52 CKD Disks?
http://www.garlic.com/~lynn/2005n.html#45 Anyone know whether VM/370 EDGAR is still available anywhere?
http://www.garlic.com/~lynn/2005p.html#34 What is CRJE
http://www.garlic.com/~lynn/2005p.html#37 CRJE and CRBE
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#2 Article in Information week: Mainframe Programmers Wanted
http://www.garlic.com/~lynn/2005s.html#26 IEH/IEB/... names?
http://www.garlic.com/~lynn/2005u.html#21 3390-81
http://www.garlic.com/~lynn/2006f.html#3 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#20 Old PCs--environmental hazard

How Many 360/195s and 370/195s were shipped?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How Many 360/195s and 370/195s were shipped?
Newsgroups: alt.folklore.computers
Date: Thu, 27 Jul 2006 18:08:23 -0600

eugene@cse.ucsc.edu (Eugene Miya) writes:

Nope.  LLL didn't buy one, they had a stable of CDC machines.  I
suspect LASL didn't either.  I know there was 1978ish paper on their
stable but my MSS is offline for work.  I think the 7094 was the
last IBM until the SP clusters excepting the administrative
mainframe.  They had a custom IBM storage system.  I doubt weather,
word size was small.  The Fort, probably.  Maybe a bank like BofA or
2.  Not many.

eastern's system one airline res system (one of the precursors
to amadeus) ran 370/195. past reference mentioning eastern's
system, amadeus, future system, etc:
http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back

url talking about history of airline online systems, including
eastern's system one, amadeus, etc:
http://www.atwonline.com/channels/informationTechnology/article.html?articleID=1163

amadeus url
http://www.amadeus.net/home/index_toplevel.htm
https://www.us.amadeus.com/

note that amadeus was both system design started 1987 (somewhat drew
on eartern system one, my wife served a brief stint as amadeus chief
architect) and a business. this states amadeus (business) absorbed
system one on 1995:
http://airinfo.aero/services.html

misc. past posts mentioning amadeus:
http://www.garlic.com/~lynn/2001g.html#50 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2003d.html#67 unix
http://www.garlic.com/~lynn/2004b.html#6 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004m.html#27 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#23 Demo: Things in Hierarchies (w/o RM/SQL)
http://www.garlic.com/~lynn/2004o.html#29 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005f.html#22 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2006b.html#23 Seeking Info on XDS Sigma 7 APL

Gould, not Harris

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Gould, not Harris
Newsgroups: alt.folklore.computers
Date: Thu, 27 Jul 2006 21:39:17 -0600

"Al Kossow" writes:

Re. Harris thread

http://www.ccur.com/corp_companyhistory.asp

Datacraft -> Harris -> Concurrent

from above:

1988    Concurrent Computer Corporation merged with MASSCOMP.
1985    Concurrent Computer Corporation spun off from the Perkin-Elmer Corporation.
1974    Datacraft acquired by Harris Corporation.
1973    Interdata acquired by the Perkin-Elmer Corporation.
1967    Harris Computer Systems founded as Datacraft.
1966    Concurrent founded as Interdata, Inc.

as undergraduate (late 60s) ... we reversed engineered ibm channel i/o
interface and built a channel interface board (originally) for
interdata/3 ... which was programmed to emulate a ibm
telecommunication controller. lots of past posts mentioning the
project http://www.garlic.com/~lynn/subtopic.html#360pcm

later the project upgraded to a interdata/4 (w/channel interface
board and programmed to emulate the ibm telecommunication controller)
and several embedded interdata/3 processors dedicated to line-scanner
function.

in the late 90s i ran into somebody that said they made an extremely
good living in the early 80s selling the (by then perkin-elmer) boxes
to nasa.  the ibm mainframe channel board was still wire-wrap and he
conjectured that it could have still been our original design and
implementation done at the univ. nasa was apparently using the
line-scanner for serial interfaces other than just terminals
... various kinds of data collection and other devices where the data
was passed on to ibm mainframe.

Article on Painted Post, NY

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Article on Painted Post, NY
Newsgroups: alt.folklore.computers
Date: Thu, 27 Jul 2006 23:40:46 -0600

Al Balmer writes:

And overseas. There were stories about a confrontation between Watson
and the French operation about serving wine in the company cafeteria.

in the early 70s, i did a number trips to europe for installs or
helping with various and sundry things. one my first trips started out
in germany (put up in small hotel where nobody spoke english). at the
plant site somebody pointed out one of the unions(?) had gotten beer
in the vending machines (i have some vague recollection that there may
be been some recommended guidelines about the max number of beers per
day per person).

then on to paris for a "HONE" install as part of emea hdqtrs moving
from westchester county to brand new complex in la defense.

lots of past posts mentioning HONE (and/or apl)
http://www.garlic.com/~lynn/subtopic.html#hone

some specific posts mentioning the move of emea hdqtrs to la defense
http://www.garlic.com/~lynn/2002c.html#30 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002h.html#67 history of CMS
http://www.garlic.com/~lynn/2004b.html#58 Oldest running code
http://www.garlic.com/~lynn/2004c.html#7 IBM operating systems
http://www.garlic.com/~lynn/2005o.html#34 Not enough parallelism in programming

... i.e. WTC was divided into EMEA (europe, middle east, and africa) and
AFE (americas and far east; americas was everyplace except usa). afe
hdqtrs remained in terrytown (for all i know afe hdqtrs is still
in terrytown).

Pa Tpk spends $30 million for "Duet" system; but benefits are unknown

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pa Tpk spends $30 million for "Duet" system; but benefits are unknown
Newsgroups: misc.transport.road,alt.folklore.computers
Date: Fri, 28 Jul 2006 08:53:52 -0600

John Varela writes:

It's all guesswork and black magic.  The same goes for military systems.  How
many more enemy tanks will a new rocket kill, and what's the value of a dead
enemy tank?

for a little topic drift, old boyd tale about evaluation of air-to-air
missile
http://www.garlic.com/~lynn/99.html#120 atomic History
http://www.garlic.com/~lynn/2003j.html#13 A Dark Day
http://www.garlic.com/~lynn/2003j.html#67 Dealing with complexity
http://www.garlic.com/~lynn/2003m.html#22 Seven of Nine
http://www.garlic.com/~lynn/2005t.html#10 Dangerous Hardware

collected boyd postings
http://www.garlic.com/~lynn/subboyd.html#boyd

and various boyd related urls from around the web
http://www.garlic.com/~lynn/subboyd.html#boyd2

Pa Tpk spends $30 million for "Duet" system; but benefits are unknown

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pa Tpk spends $30 million for "Duet" system; but benefits are unknown
Newsgroups: misc.transport.road,alt.folklore.computers
Date: Fri, 28 Jul 2006 09:12:01 -0600

John Varela writes:

If this is an administrative system, I agree.  However, having spent many
years working on embedded systems for air traffic control, I must add that
there are systems for which cost benefit is absurd but you have to go through
the motions anyway to keep GAO happy.

any of the people from this activity?
http://www.garlic.com/~lynn/2001h.html#15 IBM 9020 FAA/ATC Systems from 1960's

some number of them turned up in a new company (including former fsd
president). about ten years ago we did a joint project with them
totally unrelated to atc. however, they had (also) developed a new atc
system that was being sold into other countries.

Pa Tpk spends $30 million for "Duet" system; but benefits are unknown

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pa Tpk spends $30 million for "Duet" system; but benefits are unknown
Newsgroups: misc.transport.road,alt.folklore.computers
Date: Fri, 28 Jul 2006 11:45:38 -0600

hancock4 writes:

Considering how expensive new ATC systems are to design, build, and
implement, it does make sense to do a cost/benefit analysis.  Certainly
there is guesswork in the value of human life and in risk analysis (as
well as the overall social costs to society of losing people and lost
revenue from people afraid to fly).  However, the cost of a mid-air
collision is terribly high.

system test & certification can dominate ... especially systems that
can involve human life.

old y2k posting that mentioned certification costs with respect to
human life related system
http://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese Solve Y2K)
http://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...

we got called into review on one of the ATC modernization projects when
we were doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

turned out that there had been a high-level strategic design decision
that all faults could be masked/recovered by low-level system
facilities and as a result the domain specific application code didn't
have to worry about any kind of fault and/or associated retries,
recoveries, etc.

turns out there are numerous domain specific possible "faults"
... totally unrelated to hardware or software glitches. one example
that I remember is traffic hand-off between regional control centers.
the controller receiving the hand-off can fail to notice the hand-off
and the controller doing the hand-off needs to retry the hand-off
(however the base design had assumed that application level software
required no retry provisions ... since all faults were either
low-level hardware or software glitches and could be addressed by
hardware dedundancy and operating system recovery/retry).

all of this in ada.

Article on Painted Post, NY

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Article on Painted Post, NY
Newsgroups: alt.folklore.computers
Date: Fri, 28 Jul 2006 12:43:29 -0600

eugene@cse.ucsc.edu (Eugene Miya) writes:

I think IBM had bigger cultural problems than wine with the French when
attempting to impose a hierarchical SNA network and did not want to be
below the USA.

still in the early 70s, there could be significant issues trying to
coordinate english, french, and germans all in the same emea business
operation. it was actually easier to get any of them to defer to
americans than it was for any of them to defer to each other.

Article on Painted Post, NY

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Article on Painted Post, NY
Newsgroups: alt.folklore.computers
Date: Fri, 28 Jul 2006 13:15:04 -0600

Anne & Lynn Wheeler writes:

especially in the early 70s, there could be significant issues trying
to coordinate english, french, and germans all in the same emea
business operation. it was actually easier to get any of them to
defer to americans than it was for any of them to defer to each
other.

i met to type "still" ... not "especially".

friction didn't even require national boundaries ... i was at one all
day meeting in paris at "ibm france" (as opposed to emea hdqtrs over
in la defense). it was conducted in french and there was a long
presentation by a frenchman from la guade (southern france ... maybe
20km? from nice). i was surprised that a parisian interrupted the
speaker a couple dozen times to correct pronunciation.

i think this was possibly after the grenoble science center had been
relocated to paris.

Article on Painted Post, NY

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Article on Painted Post, NY
Newsgroups: alt.folklore.computers
Date: Fri, 28 Jul 2006 16:12:17 -0600

eugene@cse.ucsc.edu (Eugene Miya) writes:

I think you mean defer twice here.

also in the followup ... brain check ... busy thinking about something
else ... however, had corrected it in the archive
http://www.garlic.com/~lynn/2006o.html#10
http://www.garlic.com/~lynn/2006o.html#11

The SEL 840 computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The SEL 840 computer
Newsgroups: alt.folklore.computers
Date: Fri, 28 Jul 2006 21:36:34 -0600

jsavard writes:

In addition to thanking you for *them*, as it happens, I see that among
the new items you've recently added is something else both I, and
someone else rather more significant, had recently expressed interest
in in another newsgroup, comp.lang.apl.

Yes... the reference card for APL/700, the historic Burroughs dialect
with extra file handling overstrikes.

one apl/700 ref:
http://www.hbingham.com/technical/apl/arm.htm

in the very early 70s, the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

had taken apl\360 (from phili science center, iverson, falkoff, etc)
and ported to cp67/cms virtual memory environment (apl\360 had
its own multitasking monitor that could be thrown away for cms and
operated typically with 16kbyte to 32kbyte real memory work spaces).
the storage allocation and garbage collection had to be redone for
(large) virtual memory work spaces. this was cms\apl for cp67/cms

the other thing done was adding support for cms system APIs
(filesystem calls, network transfers, etc). this caused some amount of
conflict with phili and the apl people because cambridge had violated
the purity of apl with the way it implemented system api support.

palo alto science center then upgraded cms\apl to apl\cms for vm370/cms
as well as doing the 370/145 apl microcode assist. here is acm
paper from '75 on the apl microcode assist for cms\apl.
http://portal.acm.org/citation.cfm?id=803802&coll=portal&dl=ACM

in the mean time the apl "purists" came up with shared variable
paradigm (apl/sv) for accessing generalized system functions.

eventually everything merged with vs/apl (virtual storage, apl)

the following has some apl references ... (8) was at the (cambridge)
science center during the days of cms\apl (and worked on various apl
applications) ... later left IBM and went to BCS (guess who his father
was)
http://www.math.uwaterloo.ca/apl_archives/apl/translit.schemes

SEQUENCE NUMBERS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SEQUENCE NUMBERS
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers,bit.listserv.vmesa-l
Date: Sat, 29 Jul 2006 08:14:20 -0600

R.S. wrote:

Even some mainframe programs interpret it as data, with funny effects
somtimes. For example SYSIN DD * for FTP program cannot contain the
numbers. AFAIK some TCPIP config files as well.

AFAIK the sequence numbers are completely useless nowadays. It was used
for punched card sorter. Is there any other application ?

they were also used for a long time as part of the cp67/cms multilevel
source update infrastructure (later vm370/cms). since it was the
pervasive internal platform for a long time ... even some number of
mvs components would start life with cms multilevel source update and
then have to morph to smp for external release (there were some
folktales of mvs components having periodic difficulty converting
their cms source development and maintained environment to smp as part
of customer ship).

in vm/cms ... before the oco-wars, not only did source ship as standard,
but maint. was done by shipping the source changes.

recent thread that started out discussing card sorting but drifted into
description of cms multi-level source update:
http://www.garlic.com/~lynn/2006n.html#45 sorting

Google Architecture

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Google Architecture
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 30 Jul 2006 08:39:26 -0600

Anne & Lynn Wheeler wrote:

Google runs on hundreds of thousands of servers-by one estimate, in
excess of 450,000-racked up in thousands of clusters in dozens of data
centers around the world.

re:
http://www.garlic.com/~lynn/2006n.html#12 Google Architecture

... in somewhat similar vein

Grid Is 'It' at eBay
http://www.eweek.com/article2/0,1895,1995124,00.asp

The dramatic growth and high exposure of eBay's Web presence make it a
rare example of a grid computing platform and application portfolio that
are well past the pilot-project stage.

... snip ...

and for a little drift
http://www.garlic.com/~lynn/95.html#13

Gen 2 EPC Protocol Approved as ISO 18000-6C

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Gen 2 EPC Protocol Approved as ISO 18000-6C
Newsgroups: alt.technology.smartcards
Date: Sun, 30 Jul 2006 08:55:46 -0600

Bruce Barnett <spamhater113+U060729232659@grymoire.com> writes:

Friends tell me that some contactless cards in Asia sign a challenge
with a private key in 300 ms. I haven't personally verified this, but
that sounds like the right start.

in 1999 time-frame we were looking at proximity card doing a signing
in approx. 100ms (at the time, requirements for transit gates)

separately, there can be an issue with MITM-attack ... if you do
something like authenticate a card (with signature on a challenge)
separate from performing a transaction ... as opposed to having the
card directly sign a transaction (and contactless/proximity may
exaserbate the situation).

threat/vulnerability discussed somewhat in thread on "naked
transactions"
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV
http://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV
http://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV
http://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II

in the mid-90s, the financial standard x9a10 working group was given
the requirement to preserve the integrity of the financial
infrastructure for all financial transactions ... this met ALL and in
credit, debit, stored-value, internet, non-internet, point-of-sale,
contact, contactless, etc.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

one of the considerations was various MITM-attacks in various
different circumstances
http://www.garlic.com/~lynn/subintegrity.html#mitm

somewhat related was the work on the aads chip strawman in the late
90s that included being able to do fast signature signing within
power-profile of contactless and timing requirements for transit gates
http://www.garlic.com/~lynn/x959.html#aads

another issue looked at for aads chip strawman in the late 90s has shown
up recelntly in this press release

Crypto model plugs leaky fabs
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=190900759

and more in this thread:
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#5 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#6 Crypto to defend chip IP: snake oil or good idea?

Gen 2 EPC Protocol Approved as ISO 18000-6C

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Gen 2 EPC Protocol Approved as ISO 18000-6C
Newsgroups: alt.technology.smartcards
Date: Sun, 30 Jul 2006 10:26:27 -0600

Bruce Barnett <spamhater113+U060729232659@grymoire.com> writes:

Friends tell me that some contactless cards in Asia sign a challenge
with a private key in 300 ms. I haven't personally verified this, but
that sounds like the right start.

re:
http://www.garlic.com/~lynn/2006o.html#16 Gen 2 EPC Protocol Approved as ISO 18000-6C

some old email from the fall of 99
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?

the 20,000 circuit custom design was not only extremely low power draw
(making it easy fit for contactless ... even starting to move down
into even lower power rfid range) ... but there was some work with the
custom circuit design being able to do a signing with a private key in
10ms (putting it easily into the transit gate range).

RAMAC 305(?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RAMAC 305(?)
Newsgroups: alt.folklore.computers
Date: Mon, 31 Jul 2006 09:00:13 -0600

hancock4 writes:

The disk drive that came with it went on to big things and before
S/360.  The biggest well known application was SABRE which used pre-360
machines and disk drives to store airline reservations.  Soon other
companies did likewise with both IBM and Univac machines.

past post in another thread:
http://www.garlic.com/~lynn/2006o.html#4 How Many 360/195s and 370/195s were shipped?

has this history of airline online res system
http://www.atwonline.com/channels/informationTechnology/article.html?articleID=1163

from above:

As ATW's first issue was being prepared for its debut in 1964, another
baby was born to the commercial aviation industry: The Semi-Automatic
Business Research Environment went live on March 4, 1964. It was an
unwieldy name, inevitably shortened to Sabre, and it indeed would
prove to be a sharp-edged weapon. It also would revolutionize the
travel industry.

... snip ...

tail end of the above history talks about current status of various
of the res. systems .. recent news on that front:
http://www.breakingtravelnews.com/article/20060724103803551

...

I used to have several DASD "historical" URLs that were at the san
jose plant webserver ... but they went 404 when the business was sold
off.
http://www.bizjournals.com/sanjose/stories/2002/04/22/story6.html

and more current status:
http://www.hitachigst.com/portal/site/sanjosesite/menuitem.0aa94b6327c5360dacd3d307aac4f0a0/

...

for a little different drift:

in the mid-90s we were asked to look at some of the applications in
one of the large res. system. started with routes ... which
accounted for something like a quarter of the processing load. they
had list of ten impossible things that they weren't able to do. we
came back two months later and demonstrated a new implementation,
including doing all ten impossible things. this became an unresovable
problem for them ... part of the reason for the ten impossible things
was that there were certain manual infrastructure operations that
involved several hundred people. in part, the new implementation was
able to address all ten impossible things by automating all the manual
operations (actually deploying the new implemetation would have
resulted in a major organizational impact).

we then wanted to move on to fares ... which accounted for something
like 40percent of the system load. however, after appearing to have
botched routes (at least from an organizational perspective), there
was no interest in letting us have a try at fares.

misc. past posts mentioning routes activity
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

Source maintenance was Re: SEQUENCE NUMBERS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Source maintenance was Re: SEQUENCE NUMBERS
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers,bit.listserv.vmesa-l
Date: Mon, 31 Jul 2006 09:40:44 -0600

cfmpublic@ibm-main.lst (Clark Morris) writes:

How do the various source maintenance packages for other platforms
such as Unix handle the problem.  I'm thinking of CVS and the various
Itegrated Development Environments.  There are differential upgrades
and other techniques.  I am not familiar with them but realize that I
am not familiar with most of the tools in the non-MVS environment.

rcs, cvs, etc ... tend to be "down-dates" ... you have the complete
source for the current version ... with control information how to
regress to earlier versions.

cms had "update" command from mid-60s ... which applied an update
control file to source, resulting in "temporary" file to be updated
recent refs:
http://www.garlic.com/~lynn/2006o.html#14 SEQUENCE NUMBERS

this provides a short description of the evoluation of the CMS
update command into multi-level source maintenance updates
http://www.garlic.com/~lynn/2006n.html#45 sorting

one of the things that fell by the wayside was an application
that attempting to merge potentially parallel update activity.

during the early days at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

evolving the cms multi-level source maintenance process ... there was
an application written that attempted to merge and resolve parallel
update/maint. operations.

the infrastructure evolved out of a joint project between cambridge
and endicott to add 370 virtual machine support to cp67. cp67 provide
virtual 360 and virtual 360/67 (i.e. virtual memory) virtual machines
... but 370 was going to announce virtual memory (it was something
like two years away). 370 virtual memory definition had various
differences from 360/67. the idea was quickly implement 370 virtual
machines (with 370 defined virtual memory hardware tables) under cp67
(running on 360/67).

the multi-level initially consisted of

1) normal set of updates and enhancements built on base cp67 source,
("cp67l" system)

2) set of updates applied to normal cp67 that added support for 370
virtual machine option ("cp67h" system)

3) set of updates that modified cp67 kernel to run on 370 hardware
(rather than 360/67 hardware; "cp67i" system)

part of the issue was that the cambridge cp67 system hosted some
number of students (mit, bu, harvard, etc) and other non-employees in
the boston area. since 370 virtual memory hadn't been announced yet,
it was being treated as super sensitive corporate information and
there was no desire for it to leak to non-employees.

as a result only #1 kernel typically ran on the real hardware.  #2
kernel would run in a 360/67 virtual machine, isolated from prying
eyes of the students and other non-employees. for testing of #2, #3
would then run in a 370 virtual machine (under #2 kernel, running in
360/67 virtual machine under #1 kernel, which ran on real machine).

so potential problem was that there might be new updates introduced at
the "#1 level" (earlier in the update sequence) which might impact the
updates applied later in the update sequence (i.e. updates to the base
system that was going on independently supporting changes for 370
virtual machines).

as an aside, "cp67i" was up and running as normal operation a year
before the first engineering 370 machine with virtual memory support was
operational. then as 370 real machines with virtual memory support
became available internally (still well before customer first customer
ship), the "cp67i" was standard operating system running on those (real)
machines ... at least until the vm370 morph became available (and some
of the other operating system development got far enuf along to move
from testing in virtual machine to real machine operation).

Gen 2 EPC Protocol Approved as ISO 18000-6C

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Gen 2 EPC Protocol Approved as ISO 18000-6C
Newsgroups: alt.technology.smartcards
Date: Mon, 31 Jul 2006 10:06:51 -0600

"Ali" writes:

New gadgets are VLSI design so signaling protocol is quite robust like
4-millionths of a second wide. And though still there is no concept of
public/private key infrastructure but RN16 (A unique Identifier in
single tag and reader at any given time) is almost the same thing if
not exactly which ensures quite secure communication path.

Folks, I do agree that there is still way to go to secure wireless
communication but as Bruce pointed in his post that it depends on
solution to solution. Com'on,  you are not gonna put all your assets
on a contact-card (not contact-less) or on a single chip will you? Its
something related to human psychology. We believe what we see.

ref:
http://www.garlic.com/~lynn/2006o.html#16 Gen 2 EPC Protocol Approved as ISO 18000-6C
http://www.garlic.com/~lynn/2006o.html#17 Gen 2 EPC Protocol Approved as ISO 18000-6C

as mentioned in the ref,
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defined chip IP; snake oil or good idea?

the work in 1999 (20k circuits for private key digital signature in
possible 10ms) was during the period that there was transition from
.6micron to .2micron (i was co-chair of some sessions at recent ieee
chip conference where there was discussion of issues moving from
.06micron to .045micron).

the issue of person-centric vis-a-vis institutional-centric ... is
that institutions are claiming they have to issue the hardware token
because they can't otherwise be assured of the devices integrity
(i.e. if hardware tokens became more than a fad, then people might
wind up with scores of unique hardware tokens from multitude of
different institutions ... starting to verge on the current password
management nightmare).

the referenced 1999 email mentions processes that would allow
institutions to validate integrity level of a person presented token
...  enabling the change-over to a person-centric paradigm
(from an institutional centric paradigm). in a person-centric
paradigm ...  the person could then have the choice of how many tokens
they needed to manage ... modulo institutional requirements that they
meet specified integrity criteria. specific integrity critieria then
starts to move off into the area of parameterised risk
management and security proportional to risk.

a recent (long) post discussing person-centric paradigm
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?

a recent (long) post discussing parameterised risk management
http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?

the issue of contactless ... vis-a-vis contact ... is in some ways
similar to the issue of internet vis-a-vis contact. there is sometimes
assumptions that direct contact may have less vulnerabilities ... and
that contactless, wireless, and the internet may open the way for
additional vulnerabilities (possibility various kinds of evesdropping,
skimming, etc, that may be much less difficult than with straight
direct contact).

this is somewhat what we had to look at in the mid-90s for x9.59
financial standard protocol. the x9a10 financial standard working
group had been given the requirement to preserve the integrity of the
financial infrastructure for all retail payments ... regardless of the
type of payment or the infrastructure/environment that the payment
might occur in. that met that x9.59 had to work equally well in possibly
less vulnerable physical point-of-sale with contact card ... or in
possible more vulnerable internet and/or wireless environment.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

Source maintenance was Re: SEQUENCE NUMBERS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Source maintenance was Re: SEQUENCE NUMBERS
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers,bit.listserv.vmesa-l
Date: Mon, 31 Jul 2006 13:48:38 -0600

Shmuel Metz , Seymour J. wrote:

I'm not sure when it came along, but by VM/SE there was a somewhat
more sophisticated UPDATE facility[1] with aux files, control files
and update files. I'd love to see a similar facility integrated with
ISPF.

[1] Not only could the XEDIT editor process them, but it could
    generate update files to reproduce the effects of an edit
    session. That's one of the CMS facilities I miss the most.

re:
http://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS

the aux files, control files, update files scheme was what was created
for the effort for building 370 virtual machine support into a cp67
kernel (running on 360/67). however, it was implemented all in EXEC with
EXEC processing figuring out the control & aux files and making
interative calls to UPDATE command.

this was picked up as part of the original vm370 release and update
command was enhanced to directly process control, aux, and update files
(in one pass) and spitting out the (temporary, working) source file for
compile/assemble.

a little later, editors were enhanced to directly support the control,
aux, and update files as part of loading a source file for editing ...
with option that all changes made in the edit session resulted in an
"update" file (as opposed to a new complete source).

this recent posting, in a different thread, has more detailed
description of some of the operations ... as well as URLs to current CMS
documentation (including an example "update" from an internal editor
that predated xedit).
http://www.garlic.com/~lynn/2006n.html#45 sorting

a few other recent postings that happen to also mention xedit:
http://www.garlic.com/~lynn/2006n.html#34 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006n.html#43 MTS, Emacs, and... WYLBUR?
http://www.garlic.com/~lynn/2006n.html#55 The very first text editor

Cache-Size vs Performance

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cache-Size vs Performance
Newsgroups: comp.arch
Date: Mon, 31 Jul 2006 15:54:22 -0600

MitchAlsup writes:

So for normal PC/workstatioin like applications you will see a
logarithmic decrese in the miss rate as the cache size grows
logarithmecally. I leave it as an excercise to figur out what rate this
curve moves at.

For normal big data base applications the mis rate decreases similarly
but at a much lower rate (typically 1/4 to 1/5 as fast as the
PC/workstation rate) and starts to decrease at a different place.

in big database applications ... there is the processor cache (used to
compensate for memory access latency) and there is database cache
... where the database uses real storage to compensate for disk record
access latency.

the major database vendors tend to have very detailed models of their
internal operation and processing ... and tend to work with server
vendors to make sure that processor cache sizes are sufficient for
efficient dbms execution.

dbms may have a little more variety with different databases requiring
adequate real storage to be used for caching (disk) records in
transactions.

for a little drift ... i've posted before about the evolution in
system real storage sizes and that effect on the uptake with the
(emerging?) RDBMS technology.

in the 70s there was some discord between some of the "60s" physical
database people in stl/bldg90 and the relational/sql system/r people
in sjr/bldg28 ... misc. past posts mentioning system/r
http://www.garlic.com/~lynn/submain.html#systemr

the physical databases tended to have record pointers as part of data
and exposed as part of the normal programming paradigm ... i.e.
application fetched some record, operated on that record and then had
direct pointer to one or more other records.

the stl people somewhat argued that the relational/sql paradigm
abstracted away the direct record pointer paradigm by the relational
schema and using large indexes inside the dbms implementation.  for
many databases, the indexes doubled the physical disk
requirements (compared to the 60s physical database implementation)
and significantly increased the number of disk access to retrieve a
record (physically processing the index before getting to the pointers
to the desired records).

on the other hand, with physical pointers no longer exposed in the
standard database paradigm, relational significantly reduced the
administrative and human overhead compared to the 60s paradigm.

one of the things that started to tip the balance in the 80s was that
1) disk space became significantly cheaper, the disk space for the
index was reduced as a cost issue and 2) the amount of real memory
increased significantly ... which allowed "caching" of much of the
relational index (eliminating the significant disk i/o penalty
processing the index to find a specific record or records). And then
with further increases in real storage sizes, not only could
relational indexes be cached ... and frequently much of the actual
database records.

however, some of these databases may have cache operations that have a
wide variation. bank accounts might see very little database cache
benefit ... i.e. if you make an ATM withdrawal ... the probability may
be very low that there will be another hit on the same bank account
while the record is still in the database cache (over a broad range of
database cache sizes). significant changes in real storage for
database cache hit rate may see little benefit until it is nearly as
large as the whole database.

Strobe equivalents

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Strobe equivalents
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 01 Aug 2006 11:28:36 -0600

Gilbert Saint-Flour wrote:

I keep a list here:

http://gsf-soft.com/Documents/MVS-APPL-DEBUGGING.shtml

for some drift ... in the early 70s, the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

had done a lot of work on performance monitoring and measurement
technologies ... some of it later evolved into capacity planning.

there were sort of three kinds of technology

• monitoring & sampling
• simulation & modeling
• multiple regression analysis

all had their strengths and weaknesses and there were various
situations were one of the technologies could identify an issue when
the other two couldn't.

there were both software and hardware monitors. when work was being
done for selecting what should go into the ecps microcode assist, the
kernel was instrumented with a software monitor and then the person at
the palo alto science center responsible for the apl microcode assist
did a microcode based PSW sampler. old standby posting describing
ecps microcode assist analysis
http://www.garlic.com/~lynn/94.html#21

for other drift ... recent post mentioning the apl microcode assist
http://www.garlic.com/~lynn/2006o.html#13

there were two or three different simulation and modeling projects at
the science center. there was an event driven system model written in
PLI ... used among other things for modeling paging behavior ...  and
an analytical system model written in apl.

we used a variation on the apl system model in the automated
benchmarking for validating the resource manager before release.
http://www.garlic.com/~lynn/subtopic.html#fairshare

basically in excess of two thousand benchmarks were run taking three
months elapsed time. initially there were something like 1000
different benchmarks defined that had wide range of configuration,
workload, and system parameters. the the modified apl system model was
feed all results and allowed to select the set of conditions for the
next benchmark. these results were fed back into the apl system model
and it repeated the condition selection settings for the next set
of benchmarks. this was repeated for another 1000 or so benchmarks
http://www.garlic.com/~lynn/submain.html#bench

the apl system model was also adapted to the HONE system (world wide
vm-based system that supported all field, sales, and marketing, by the
mid-70s, salesmen couldn't even place a mainframe order w/o having first
run it thru one of the HONE configurators)
http://www.garlic.com/~lynn/subtopic.html#hone

where it was called the performance predictor and allowed marketing
people to input customer configuration and workload information and
ask "what-if" questions (what happens if amount of memory is doubled
or the workload changes, etc).

another instruction analysis tool was "REDCAP" which had been developed
in POK for doing workload instruction traces ... for studying detailed
workload instruction execution characteristics as aid in processor
design.  the science center adapted REDCAP for analyzing application
execution in virtual memory environments. this was used to analyze the
port of apl\360 to cms\apl (and execution characteristics of the memory
allocation and garbage collection change from small 16k-32k byte real
memory workspaces to very large virtual memory workspaces). It was
also used by a number of application development groups to study their
application in the transition from real storage to virtual memory
operation (applications like IMS). It was also released as a product
called Vs/Repack. Vs/Repack would also perform cluster analysis of
program operation and attempt semi-automated program reorganization
for improved execution in virtual memory environment.

some recent references to old vs/repack
http://www.garlic.com/~lynn/2006i.html#37 virtual memory
http://www.garlic.com/~lynn/2006j.html#18 virtual memory
http://www.garlic.com/~lynn/2006j.html#22 virtual memory
http://www.garlic.com/~lynn/2006j.html#24 virtual memory
http://www.garlic.com/~lynn/2006l.html#11 virtual memory

A few years ago, I ran into a consultant (european) that was doing
work using a descendant of the performance predictor (with nearly 20
years of enhancements). During the corporate troubles in 1992, the
vendor had acquired the rights to the software and had run it through
an APL-to-C language converter ... and then subsequently made
additional enhancements.

He was doing some consulting at a large datacenter that had an
enormous application that ran across a large number of mainframes ($$
value in the 8-9 digit range). Even a few percentage performance
improvements in the application translated into large number of
hardware dollars. The application had been studied extensively using
standard mainframe monitoring tools and heavily optimized. The
consultant, using his enhanced performance modeling tool had
identified additional areas that resulted in another ten percent
optimization savings.

Remembering the science center experience from the early 70s (nearly
35 years earlier), i wondered if multiple regression analysis could
identify opportunities; in fact it turned up something accounting for
over 20% of total usage. The issue has been that things like instruction
sampling and event modeling tend to turn up things at the micro level
... while multiple regression analysis frequently can highlight more
macro level issues. The identified feature was a complex, spaghetti
combination of low-level stuff ... which turned out could be optimized
(at the macro level) and resulted in 14% total system savings.

computational model of transactions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: computational model of transactions
Newsgroups: comp.databases.theory
Date: Tue, 01 Aug 2006 13:50:58 -0600

paul c writes:

Also, in the interest of preserving Marshall's sanity, I must mention
that somewhere I think Gray mentioned that lock managers can be a
bottomless pit.  I once hired an assistant professor to implement more
thorough predicate locks.  Before he finished he had a nervous
breakdown.  The last time I saw him the secret police were tailing
him. Then I got ordered to hire a professor.  The walk-throughs were
okay but he prompted only code that wouldn't compile.  I thought it
best to get out with my own sanity.  After that the whole thing was
handed over to a system programmer who knew nothing about db.  He
ignored predicates but being an expert in system resource monitoring
for accounting purposes and having heard that lock managers could be
performance hotspots, he added system calls to record things like cpu
utilization which I thought  was a self-fulfilling prophecy and proved
Gray's point.

i had worked with jim in system/r days
http://www.garlic.com/~lynn/submain.html#systemr

and then when my wife and i were doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

i designed and did ha/cmp's initial dlm implementation; minor
reference
http://www.garlic.com/~lynn/95.html#13

i actually had difference of opinion with jim during '91 sigops
conference in asilomor about whether (ha/cmp) commodity clusters could
be used in business critical settings.

for a little drift ... recent post about performance management
http://www.garlic.com/~lynn/2006o.html#23 Strobe equivalents

CPU usage for paging

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CPU usage for paging
Newsgroups: bit.listserv.ibm-main
Date: Wed, 02 Aug 2006 11:20:33 -0600

Craig Dudley wrote:

I am looking for the RMF report(s) where I can find out how much CPU time
my system (2066-0A2 w/8 GB) to perform paging. I am trying to determine
how much CPU I will "get back" if we buy more memory.
WAS on z is involved ;>)
performance predictor
on the HONE system was used to answer ... i.e. how much paging would be
reduced by adding amounts of real storage based on current configuration
and workload profiles ... previous post
http://www.garlic.com/~lynn/2006o.html#23 Strobe equivalents

as mention before, HONE was the world-wide online (vm-based) internal
system supporting marketing, sales, and field people:
http://www.garlic.com/~lynn/subtopic.html#hone

Cache-Size vs Performance

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cache-Size vs Performance
Newsgroups: comp.arch
Date: Wed, 02 Aug 2006 11:36:31 -0600

me writes:

Not necessarily true. Let's say you have a terabyte sized table
that's randomly looked up. If it is on a CPU with more cache, it
would be because cache lines from the first few levels of the
indexing tree would be less frequently evicted from cache, not
because there is very little data.

note that the first order stuff for processor cache design with
respect to large database was the execution/instruction working set
... and then you moved into the index tree items (and other data
structures ... like data structure dealing with what is currently in
the database memory cache) ... which is the corresponding thing that
happened with real-memory/disk caching in the early 80s ... i.e. a lot
of the real memory sizes from the early 80s were on the order of
current processor cache sizes (and were becoming large enuf to contain
the rdbms indexes to offset having to do disk reads to walk the
indexes).

... previous post
http://www.garlic.com/~lynn/2006o.html#22 Cache-Size vs Performance

for some drift collected past posts mentioning original relational/sql
work
http://www.garlic.com/~lynn/submain.html#systemr

and other collected past posts mentioning lru replacement algorithms
and working set type stuff ... dating back to 60s
http://www.garlic.com/~lynn/subtopic.html#wsclock

recent post on some performance management tools
http://www.garlic.com/~lynn/2006o.html#23 Strobe equivalents

including some discussion of vs/repack technology ... which was used
internally in the early 70s to do detailed studies of
applicationoperation in virtual memory environments (and replacement
strategies). In the mid-70s, it was released as a product. part of the
vs/repack technology did detailed studies of application instruction
and storage references and attempted semi-automated program
re-organization for improved operation in environments involving
lru-type replacement strategies. Some of the large dbms products made
extensive use of vs/repack as part of transition from real-storage
environments to virtual memory plactforms.

oops

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: oops
Date: Sun, 06 Aug 2006 05:49:16 -0600
Newsgroups: bit.listserv.vmesa-l

Phil Smith III wrote:

Gabe reminds me that the 360 didn't run VM; I did use it, but it was
the 370/158 with 2MB that I used to use VM on.

360/67 was the only (standard) 360 with virtual memory support. it had
both 24-bit and 32-bit virtual addressing options (you didn't see more
than 24-bit again until 370-xa with 3081). 360/67 multiprocessor also
had channel director ... which supported all processors accessing all
channels (standard 360 & 370 multiprocessors only provided for common
memory addressing ... the rest of the infrastructure, including
channels, were partitioned, specific to processors).

cp67 was developed by the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

... supporting virtual machines and virtual memory. cp67 was released to
customers. there had been an earlier cp40 developed on a custom modified
360/40 with virtual memory ... pending availability of a 360/67.

there was joint project between cambridge and endicott to add a lot of
370 stuff to cp67 kernel ... this was discussed recently in the series
of posts on "sequence numbers" and cms multi-level source maintenance
... which mostly evolved out of the cp67 cambridge/endicott 370 effort
(CMS originally stood for the cambridge monitor system, but morphed to
conversational monitor system for vm370)

modified version of cp67 ran internally extensively on 370s ... pending
availability of vm370. also CP67's CCWTRANS (supporting virtual memory ccws
translated to shadow real CCWs) was used in initial prototype of os/vs2
(i.e. mvt hacked to directly support 370 virtual memory).

gobs of posts just this year mentioning cp/67
http://www.garlic.com/~lynn/2006.html#5 Page fault question (zero-filling)
http://www.garlic.com/~lynn/2006.html#7 EREP , sense ... manual
http://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped files on z/VM V5.1
http://www.garlic.com/~lynn/2006.html#13 VM maclib reference
http://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006.html#40 All Good Things
http://www.garlic.com/~lynn/2006b.html#7 Mount a tape
http://www.garlic.com/~lynn/2006b.html#8 Free to good home: IBM RT UNIX
http://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Re: Expanded Storage
http://www.garlic.com/~lynn/2006b.html#16 {SPAM?} Re: Expanded Storage
http://www.garlic.com/~lynn/2006b.html#23 Seeking Info on XDS Sigma 7 APL
http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
http://www.garlic.com/~lynn/2006b.html#32 Multiple address spaces
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
http://www.garlic.com/~lynn/2006b.html#40 another blast from the past ... VAMPS
http://www.garlic.com/~lynn/2006c.html#2 Multiple address spaces
http://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
http://www.garlic.com/~lynn/2006c.html#21 Military Time?
http://www.garlic.com/~lynn/2006c.html#22 Military Time?
http://www.garlic.com/~lynn/2006c.html#28 Mount DASD as read-only
http://www.garlic.com/~lynn/2006c.html#45 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#18 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#21 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#35 Fw: Tax chooses dead language - Austalia
http://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#28 MCTS
http://www.garlic.com/~lynn/2006e.html#40 transputers again was: The demise of Commodore
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#0 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#1 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006f.html#21 Over my head in a JES exit
http://www.garlic.com/~lynn/2006g.html#1 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#3 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#18 TOD Clock the same as the BIOS clock in PCs?
http://www.garlic.com/~lynn/2006g.html#58 REP cards
http://www.garlic.com/~lynn/2006h.html#7 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#20 Binder REP Cards (Was: What's the linkage editor really wants?)
http://www.garlic.com/~lynn/2006h.html#22 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#30 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#55 History of first use of all-computerized typesetting?
http://www.garlic.com/~lynn/2006h.html#57 PDS Directory Question
http://www.garlic.com/~lynn/2006i.html#4 Mainframe vs. xSeries
http://www.garlic.com/~lynn/2006i.html#9 Hadware Support for Protection Bits: what does it really mean?
http://www.garlic.com/~lynn/2006i.html#10 Hadware Support for Protection Bits: what does it really mean?
http://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370
http://www.garlic.com/~lynn/2006i.html#26 11may76, 30 years, (re-)release of resource manager
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#33 virtual memory
http://www.garlic.com/~lynn/2006i.html#36 virtual memory
http://www.garlic.com/~lynn/2006i.html#42 virtual memory
http://www.garlic.com/~lynn/2006i.html#43 virtual memory
http://www.garlic.com/~lynn/2006j.html#2 virtual memory
http://www.garlic.com/~lynn/2006j.html#5 virtual memory
http://www.garlic.com/~lynn/2006j.html#17 virtual memory
http://www.garlic.com/~lynn/2006j.html#19 virtual memory
http://www.garlic.com/~lynn/2006j.html#21 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#27 virtual memory
http://www.garlic.com/~lynn/2006j.html#29 How to implement Lpars within Linux
http://www.garlic.com/~lynn/2006j.html#33 How to implement Lpars within Linux
http://www.garlic.com/~lynn/2006j.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006j.html#38 The Pankian Metaphor
http://www.garlic.com/~lynn/2006j.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#44 virtual memory
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#13 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#14 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#29 PDP-1
http://www.garlic.com/~lynn/2006k.html#30 PDP-1
http://www.garlic.com/~lynn/2006k.html#31 PDP-1
http://www.garlic.com/~lynn/2006k.html#32 PDP-1
http://www.garlic.com/~lynn/2006k.html#34 PDP-1
http://www.garlic.com/~lynn/2006k.html#35 PDP-1
http://www.garlic.com/~lynn/2006k.html#36 PDP-1
http://www.garlic.com/~lynn/2006k.html#41 PDP-1
http://www.garlic.com/~lynn/2006k.html#42 Arpa address
http://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
http://www.garlic.com/~lynn/2006l.html#22 Virtual Virtualizers
http://www.garlic.com/~lynn/2006l.html#43 One or two CPUs - the pros & cons
http://www.garlic.com/~lynn/2006l.html#55 virtual memory
http://www.garlic.com/~lynn/2006m.html#2 An Out-of-the-Main Activity
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#28 Mainframe Limericks
http://www.garlic.com/~lynn/2006m.html#29 Mainframe Limericks
http://www.garlic.com/~lynn/2006m.html#30 Old Hashing Routine
http://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
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/2006m.html#47 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006m.html#53 DCSS
http://www.garlic.com/~lynn/2006m.html#56 DCSS
http://www.garlic.com/~lynn/2006n.html#11 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006n.html#13 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006n.html#21 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006n.html#42 Why is zSeries so CPU poor?
http://www.garlic.com/~lynn/2006n.html#45 sorting
http://www.garlic.com/~lynn/2006n.html#49 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006o.html#3 MTS, Emacs, and... WYLBUR?
http://www.garlic.com/~lynn/2006o.html#13 The SEL 840 computer
http://www.garlic.com/~lynn/2006o.html#14 SEQUENCE NUMBERS
http://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
http://www.garlic.com/~lynn/2006o.html#21 Source maintenance was Re: SEQUENCE NUMBERS

Google Architecture

From: lynn@garlic.com
Subject: Re: Google Architecture
Date: Sun, 06 Aug 2006 11:13:12 -0700
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers

somewhat keeping this thread going ...

Another Operating System Expert Goes to Google
http://www.microsoft-watch.com/article2/0,1995,1999763,00.asp?kc=MWRSS02129TX1K0000535

The State of the Mainframe Today
http://www.osnews.com/story.php?news_id=15398

past posts in thread:
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006l.html#6 Google Architecture
http://www.garlic.com/~lynn/2006l.html#7 Google Architecture
http://www.garlic.com/~lynn/2006l.html#8 Google Architecture
http://www.garlic.com/~lynn/2006l.html#24 Google Architecture
http://www.garlic.com/~lynn/2006l.html#26 Google Architecture
http://www.garlic.com/~lynn/2006l.html#27 Google Architecture
http://www.garlic.com/~lynn/2006l.html#28 Google Architecture
http://www.garlic.com/~lynn/2006l.html#31 Google Architecture
http://www.garlic.com/~lynn/2006l.html#32 Google Architecture
http://www.garlic.com/~lynn/2006l.html#33 Google Architecture
http://www.garlic.com/~lynn/2006l.html#37 Google Architecture
http://www.garlic.com/~lynn/2006m.html#43 Google Architecture
http://www.garlic.com/~lynn/2006n.html#12 Google Architecture
http://www.garlic.com/~lynn/2006o.html#15 Google Architecture

oops, cics

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: oops, cics
Newsgroups: alt.folklore.computers, bit.listserv.vmesa-l
Date: Tue, 08 Aug 2006 06:28:29 -0600

bob shair wrote:

That 360/40, serial number 2040-x0002, made two outstanding
contributions to IBM.  After serving as the first 360 testbed for CP
(CP/40), it went on to be the primary development machine for CICS!

ref:
http://www.garlic.com/~lynn/2006o.html#27 oops

the university i was at had a 360/67 (originally installed for
tss/360) ... and with all the tss/360 problems started looking for
other uses (besides running it in 360/65 mode with os/360). they
stumbled across the cp/67 sometime in 1967 and had three people from
the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

come out the last week in jan68 to install cp67. i got to play with cp67
  (as an undergraduate) in addition to supporting os/360.

part of that also led to us doing our own clone controller ... recent
topic drift on cloning
http://www.garlic.com/~lynn/aadsm25.htm#10 Crypto to defend chip IP: snake oil or good idea?

above mentions the university cloning project ... and cloned
controllers also motivating FS project.

however, the university library also had an ONR grant and was selected
to be a CICS beta test site ... and i got roped into shooting some
number of early CICS bugs. misc. past post mentioning early CICS (and/or
BDAM)
http://www.garlic.com/~lynn/submain.html#bdam

The Question of Braces in APL-ASCII

From: lynn@garlic.com
Subject: Re: The Question of Braces in APL-ASCII
Date: Wed, 09 Aug 2006 14:01:23 -0700
Newsgroups: comp.lang.apl,alt.folklore.computers

Kenneth Brody wrote:

I believe the APL terminal I used was a Selectric model.  It had
one of those metal (or, sometimes, plastic) balls for printing.
Watching the head spin could make your head spin.

there is a 2741/selectric APL typeball sitting on my desk ... something
of reminder.

misc past posts mentioning apl and/or hone .... hone was the internal
world-wide online service supporting field, marketing, & sales ....
majority of applications written in apl (originally cp67 with cms\apl
... and then migrated to vm370, first with apl\cms and then vs\apl).
http://www.garlic.com/~lynn/subtopic.html#hone

Metroliner telephone article

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Metroliner telephone article
Newsgroups: misc.transport.rail.americas,nyc.transit,alt.folklore.computers
Date: Fri, 11 Aug 2006 10:35:09 -0600

"Sancho Panza" writes:

What difference does that make? The point is balance sheets are fictions
drawn up to placate stockholders and the SEC, among others and certified by
compliant yes-men and yes-women at accounting firms. The real value of a
company is assessed in the free and open market.

related recent thread on sox
http://www.garlic.com/~lynn/aadsm25.htm#12 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#13 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#14 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#15 Sarbanes-Oxley is what you get when you don't do FC

slightly earlier thread on the same subject:
http://www.garlic.com/~lynn/aadsm24.htm#35 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#36 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#39 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#40 Interesting bit of a quote

When Does Folklore Begin???

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When Does Folklore Begin???
Newsgroups: alt.folklore.computers
Date: Fri, 11 Aug 2006 11:25:17 -0600

sidd@situ.com () writes:

i am reminded, for some reason, of an incident a long time ago,
when a VAX (that was being retired) woke up after a power
outage and rejoined a cluster. since the quorum rules had not
been designed with this in mind, much tumult ensued.

early in ha/cmp effort
http://www.garlic.com/~lynn/subtopic.html#hacmp

we had a number of meetings with some of the major dbms vendors that
had cluster implementations that ran on vax/cluster. we got a list of
the 8-10 things that they felt could be improved about vax/cluster
... as well as the vax/cluster distributed lock manager. one of the
things was the long time that it took vax/cluster to recover to a
stable state after change in cluster membership.

so one of the things that i did in the original design and
implementation of the ha/cmp dlm was significantly shorten the time it
took to recover to stable state.

random ha/cmp posting
http://www.garlic.com/~lynn/95.html#13

misc past postings mentioning ha/cmp dlm
http://www.garlic.com/~lynn/aadsm16.htm#22 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
http://www.garlic.com/~lynn/aadsm21.htm#29 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
http://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001j.html#47 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2002e.html#67 Blade architectures
http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders?
http://www.garlic.com/~lynn/2004i.html#2 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#8 Hard disk architecture: are outer cylinders still faster than inner cylinders?
http://www.garlic.com/~lynn/2004m.html#0 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004m.html#5 Tera
http://www.garlic.com/~lynn/2004q.html#10 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#70 CAS and LL/SC
http://www.garlic.com/~lynn/2005.html#40 clusters vs shared-memory (was: Re: CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE))
http://www.garlic.com/~lynn/2005b.html#1 Foreign key in Oracle Sql
http://www.garlic.com/~lynn/2005f.html#18 Is Supercomputing Possible?
http://www.garlic.com/~lynn/2005h.html#26 Crash detection by OS
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#41 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006j.html#20 virtual memory
http://www.garlic.com/~lynn/2006o.html#24 computational model of transactions

When Does Folklore Begin???

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When Does Folklore Begin???
Newsgroups: alt.folklore.computers
Date: Fri, 11 Aug 2006 12:15:13 -0600

sidd@situ.com () writes:

would you care to expand on the differences between the VMS DLM
and the ha/cmp DLM ? and on their similarities...?

ref:
http://www.garlic.com/~lynn/2006o.html#32 When Does Folklore Begin???

it had support for the same api/semantics as offered by vms dlm
... but internally it kept/piggybacked state in more places so that it
shorten recovery time (slightly more upfront work but shortened any
fault/recovery time).

some of the dbms vendors had fast commit or something similar in
non-cluster environment ... but was disabled for any cluster
operation. as part of the dlm work, i had also worked out the
conventions for doing fast commit type operations across a cluster
operation. however, originally it was considered somewhat too
advanced ... although I've had follow-up in the past couple years
about implementations for doing fast commit type operation in cluster
environment.

misc. past posts mentioning fast commit stuff:
http://www.garlic.com/~lynn/2001.html#40 Disk drive behavior
http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2003i.html#70 A few Z990 Gee-Wiz stats
http://www.garlic.com/~lynn/2003j.html#7 A few Z990 Gee-Wiz stats
http://www.garlic.com/~lynn/2004q.html#70 CAS and LL/SC
http://www.garlic.com/~lynn/2005f.html#32 the relational model of data objects *and* program objects
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer

other ha/cmp posts
http://www.garlic.com/~lynn/subtopic.html#hacmp

and other posts on continuous availability, disaster survivability, and
geographic survivability
http://www.garlic.com/~lynn/submain.html#available

and other drift misc. past posts mentioning original relational/sql
implementation
http://www.garlic.com/~lynn/submain.html#systemr

note, some amount of the work also drew on my wife's experience doing
a stint (long ago and far away) in POK responsible for mainframe
loosely-coupled architecture (i.e. loosely-coupled is mainframe speak
for cluster, dates back to at least 360 cluster operation in the
60s). while there, she developed peer-coupled shared data
architecture
http://www.garlic.com/~lynn/submain.html#shareddata

which didn't see much uptake at the time ... but eventually used by
IMS hot-standby ... and since has evolved into (mainframe) parallel
sysplex.

a parallel sysplex URL:
http://www-03.ibm.com/servers/eserver/zseries/pso/

misc. past posts mentioning parallel sysplex:
http://www.garlic.com/~lynn/98.html#30 Drive letters
http://www.garlic.com/~lynn/98.html#35a Drive letters
http://www.garlic.com/~lynn/98.html#36 What is MVS/ESA?
http://www.garlic.com/~lynn/98.html#37 What is MVS/ESA?
http://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP?
http://www.garlic.com/~lynn/98.html#57 Reliability and SMPs
http://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
http://www.garlic.com/~lynn/99.html#77 Are mainframes relevant ??
http://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
http://www.garlic.com/~lynn/2000.html#13 Computer of the century
http://www.garlic.com/~lynn/2000.html#31 Computer of the century
http://www.garlic.com/~lynn/2000f.html#29 OT?
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
http://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#69 Wheeler and Wheeler
http://www.garlic.com/~lynn/2001g.html#46 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001n.html#47 Sysplex Info
http://www.garlic.com/~lynn/2002e.html#25 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002f.html#6 Blade architectures
http://www.garlic.com/~lynn/2002o.html#68 META: Newsgroup cliques?
http://www.garlic.com/~lynn/2003h.html#60 The figures of merit that make mainframes worth the price
http://www.garlic.com/~lynn/2004m.html#24 IBM Spells Out Mainframe Strategy
http://www.garlic.com/~lynn/2004n.html#16 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#38 RS/6000 in Sysplex Environment
http://www.garlic.com/~lynn/2005d.html#25 The future of the Mainframe
http://www.garlic.com/~lynn/2005i.html#43 Development as Configuration
http://www.garlic.com/~lynn/2005n.html#0 Cluster computing drawbacks
http://www.garlic.com/~lynn/2005n.html#7 54 Processors?
http://www.garlic.com/~lynn/2005n.html#25 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005o.html#30 auto reIPL
http://www.garlic.com/~lynn/2005o.html#37 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
http://www.garlic.com/~lynn/2005u.html#23 Channel Distances
http://www.garlic.com/~lynn/2005v.html#0 DMV systems?
http://www.garlic.com/~lynn/2006.html#32 UMA vs SMP? Clarification of terminology
http://www.garlic.com/~lynn/2006d.html#24 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#19 Over my head in a JES exit
http://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe
http://www.garlic.com/~lynn/2006i.html#2 The Pankian Metaphor
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006l.html#6 Google Architecture
http://www.garlic.com/~lynn/2006l.html#45 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

Source maintenance was Re: SEQUENCE NUMBERS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Source maintenance was Re: SEQUENCE NUMBERS
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers,bit.listserv.vmesa-l
Date: Sat, 12 Aug 2006 08:37:05 -0600

ref:
http://www.garlic.com/~lynn/2006o.html#14 SEQUENCE NUMBERS
http://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
http://www.garlic.com/~lynn/2006o.html#21 Source maintenance was Re: SEQUENCE NUMBERS

for some additional drift, old history about requiring source for
application distribution on the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

               ***** Extract from VM Newsletter 5 *****

                 V M  Newsletter Issue 5 ... May 1977

Welcome to the fifth issue of the newsletter.

                          E D I T O R I A L

I recently received a contribution for the newsletter which, in
addition to the usual description, mentioned that no source code for
the item described would be made available.  I have withheld its
publication for the time being.  I feel that, in the absence of a very
good reason to the contrary, contributors should always make the
source for their programs available to the requesters.  Aside from
the fact that in many cases it may be essential for the proper
installation of a program to have the source, it seems to me a matter
of courtesy that it should be provided.  I would like to establish a
policy for the newsletter regarding this question, but I solicit your
opinion to help me do so.

               ***** Extract from VM Newsletter 6 *****

                V M  Newsletter Issue 6 ... June 1977

Welcome to the sixth issue of the newsletter.

The response to the first editorial in the last issue is quite
satisfying.  Most of you feel that source should, in general, be made
available.  But a number of readers pointed out some other
considerations, most of which seem to me to be valid.  Among them:

        * Sometimes the source is really not available; it seems
unreasonable to lose what might be an otherwise valuable contribution
and of use to someone in spite of the lack of source.

        * Sometimes the source is really part of, or related to, some
product being developed and the source can't be made available until
the corresponding product is announced or shipped.  This was the
situation with the contribution which prompted the editorial.

        * When the program is under continuing development, it is a
considerable burden to the developer to provide a complete set of
source.  In this situation, some people felt, at least idle requests
for the source code should be discouraged.  Furthermore, there appears
to be a conflict between letting many early versions of the program
propagate widely, and getting a number of early "guinea-pig" users.

        * When the contribution is the installation of some OS-based
processor on CMS, it is inappropriate to distribute the source of the
entire processor.  In these cases, however, the source for any
interface and installation programs should be provided.

        * There are a few unusual cases in which the integrity of a
lot of data depends on the integrity of programs which access or
maintain it.  A specific example of this is a file system which was
developed at Yorktown.  In such cases, a small bug could be introduced
by someone casually changing the program, and not have its effects
realized until long afterwards.  In cases like this, perhaps the
burden is on the requester to demonstrate that providing the source
will not lead to a bad situation.

The policy I have decided to implement for the newsletter is to
publish any contribution, but to require that the contributor state
explicitly that the source is not available, and that he explain why
this is the case.

the personal data theft pandemic continues

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: the personal data theft pandemic continues
Newsgroups: bit.listserv.ibm-main
Date: Sat, 12 Aug 2006 11:50:04 -0600

Efinnell15@ibm-main.lst wrote:

Maybe they'll add it to SOX.%-)

recent sox thread:
http://www.garlic.com/~lynn/aadsm25.htm#12 Sarbanes-Oxley is what you
get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#13 Sarbanes-Oxley is what you
get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#14 Sarbanes-Oxley is what you
get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#15 Sarbanes-Oxley is what you
get when you don't do FC

and mention of another sox thread here:
http://www.garlic.com/~lynn/2006o.html#31

there is the generic category of Identity Theft ... which FTC and some
other organizations have been trying to differentiate into identity
theft and account theft/fraud.

the account theft/fraud is obtaining sufficient information to perform
fraudulent transactions against existing accounts. the other is
obtaining sufficient information to create fraudulent new accounts or
records in the name of the victim.

part of the issue discussed here
http://www.garlic.com/~lynn/aadsm25.htm#13

is security breaches and/or data breaches involving
account related information ... where just knowing the account number
is sufficient to perform fraudulent transaction. the problem in such
situations is that the account number needs to be readily available
for correct operation of scores of business processes. however, at the
same time, because of the fraudulent transaction vulnerability, the
account number needs to be kept strictly confidential and never
divulged or made available. the diametrically opposing requirements in
the treatment of account numbers creates quite a bit of conflict.

in the mid-90s, the x9a10 financial standards working group was given
the requirement to preserve the integrity of the financial
infrastructure for all retail payments. one of the items in the
resulting x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

was to remove knowledge of account number as a fraudulent transaction
vulnerability (i.e. account numbers used in x9.59 financial standards
couldn't be used in other kinds of transactions w/o the required
authentication).

this is somewhat related to my old post on security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

a similar tread related to account theft/fraud discusses the
vulnerability of "naked transactions" (transactions that don't carry
individual authentication/armoring)
http://www.garlic.com/~lynn/aadsm24.htm#5
http://www.garlic.com/~lynn/aadsm24.htm#7
http://www.garlic.com/~lynn/aadsm24.htm#9
http://www.garlic.com/~lynn/aadsm24.htm#10
http://www.garlic.com/~lynn/aadsm24.htm#12
http://www.garlic.com/~lynn/aadsm24.htm#14
http://www.garlic.com/~lynn/aadsm24.htm#26
http://www.garlic.com/~lynn/aadsm24.htm#41
http://www.garlic.com/~lynn/aadsm24.htm#42

also in the 90s, we had been called in to help word smith the cal. (and
later the federal) electronic signature legislation. one of the industry
groups involved was also looking at privacy issues and had done a survey
about factors motivating privacy legislation ... they found the two
major driving factors behind privacy legislation were

1) Identity Theft (including account fraud/theft)
2) "denial of service" (against individuals by institutions and
organizations)

at the time, cal. was also working on a data breach
notification law, in part because any subsequent fraud (including
fraudulent account transactions) was frequently against individuals,
as opposed to the institution that had the security/data
breach.

misc. past posts mentioning electronic signature related stuff
http://www.garlic.com/~lynn/subpubkey.html#signature

Metroliner telephone article

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Metroliner telephone article
Newsgroups: misc.transport.rail.americas,nyc.transit,alt.folklore.computers
Date: Sat, 12 Aug 2006 15:33:18 -0600

floyd@apaflo.com (Floyd L. Davidson) writes:

Eventually yes.  After divestiture AT&T had MCI and SPRINT to compete
with.

from archive long ago and far away:


To: wheeler
Date: 01/11/82  13:46:04
Subject: Techno-trivia

Note that AT&T has started divesting itself of the 22 wholly owned
local phone companies (over half of "Ma Bell") in order to compete
freely in any market it wishes.  Two predictions:

  a) The use of integrated MODEMs in PCs to obviate the need for
     bigger DASD is doomed to failure.  The local rates are going
     to take a big jump now that long lines no longer subsidize
     them.  Because of the unwillingness of cable television companies
     to share standards much less technology, cable TV is not
     likely to offer much of a solution.
  b) Bell Labs brought us UNIX.  What can they do now that they
     are allowed to make money?  Is this likely to make them a
     super-competitor or are their accountants going to completely
     stifle anything which might affect us?

... snip ... top of post, old email index


To: wheeler
Date: 02/10/82   00:51:10
Subject: rumors

Latest rumor from AT&T... they're going to buy DEC.  (xxxxx's version
of that says buy Amdahl.  Both seem possible.)

... snip ... top of post, old email index

and:

                               SEMINAR

Monday, June 11, 1984
10:00 a.m. - 2C-012
Dan Dvorak
AT&T Bell Laboratories
                               ABSTRACT

The Bell Laboratories Network (BLN) provides a host-to-host networking
service that has been specifically designed for the heterogeneous
computer environment at AT&T Bell Laboratories.  BLN incorporates two
important concepts: a 7-layer architecture similar to the one proposed
by ISO and CCITT, and implementation techniques that allow most of the
networking software to reside in totally portable modules.  BLN has
been operational since March 1979, and currently runs on over 25 nodes
throughout AT&T.  This talk presents an overview of the network
service requirements and the architecture and implementation that was
developed to provide those services.

                              BIOGRAPHY

Dan Dvorak joined AT&T Bell Laboratories in 1972 and was named
"Distinguished MTS" in 1984.  His current work focuses on the DATAKIT*
Virtual Circuit Switch where he is coordinating the development of a
DATAKIT central network management system and also engineering the
large internal DATAKIT VCS network for local-area and wide-area data
communications within Bell Labs.  Earlier he worked on a layered
network architecture and implementation for host-to-host networking,
and later surveyed existing LAN products.  Dan holds a MSEE in
Computer Engineering from Stanford University (1974).

... snip ...

misc. past postings mentioning osi, 7-layer architecture, and/or
other stuff
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

the personal data theft pandemic continues

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: the personal data theft pandemic continues
Newsgroups: bit.listserv.ibm-main
Date: Sun, 13 Aug 2006 06:22:50 -0600

Ed Finnell wrote:

It's sort of like the Immigration Laws. No matter what policies and
procedures are in place, if they aren't enforced or even acknowledged
by the  parties of the first part same thing happens over and over.
We've still got systems that are in violation of 1974  privacy
act that are de facto 'industry  standards'.

re:
http://www.garlic.com/~lynn/2006o.html#35 the personal data theft  pandemic continues

1974 privacy act overview (for federal executive branch agencies)
http://www.usdoj.gov/04foia/04_7_1.html
intro/overview
http://www.usdoj.gov/04foia/1974intro.htm

the popular press somewhat treats the (account fraud) situation like a
bucket that periodically springs links. the issue in the "naked
transaction" paradigm is that it is possible for information to leak at
the millions of business processes that use and process transactions.

the analogy is then much more like a giant sieve than a giant bucket
(that periodically springs leaks). in the "naked transaction" scenario
... it isn't so much that the information can be leaking from millions
of business processes ... but the vulnerability that it is possible to
turn around and use the leaked information for fraudulent transactions.
this is my scenario that even if the planet was buried under miles of
(information hiding) crypto ... that the (account) business process
information would continue to leak ... since it is required and used in
millions of different places.

the x9.59 financial standard scenario
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

... rather than trying to continue the impossible task of plugging all
the potential leakage points ... was eliminate the leaks as fraudulent
transaction vulnerability (i..e the information could continue to leak
but couldn't be turned around and used for fraudulent transactions)

for a little more drift, i was co-author of the financial industry PIA
x9.99 standard ... and had to spend an unexpected amount of time not
only looking at glba but also hipaa and eu-dpd. I also did a privacy
merged taxonomy and glossary as part of the effort
http://www.garlic.com/~lynn/index.html#glosnote

some of the fed. gov privacy officers attended some of the financial
standard privacy working group meetings. one of them commented that
the original hipaa "security" language had hardly changed since it was
originally drafted in the 70s.

Also, the OECD privacy guidelines have been around since 1980
http://www.cdt.org/privacy/guide/basic/oecdguidelines.html

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

hardware virtualization slower than software?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: hardware virtualization slower than software?
Newsgroups: alt.folklore.computers,comp.arch,bit.listserv.vmesa-l
Date: Sun, 13 Aug 2006 06:54:24 -0600

Hardware virtualization slower than software?
http://developers.slashdot.org/developers/06/08/12/2028223.shtml

... from above:

One example given is compilation of a Linux kernel under a virtualized
Linux OS. Native wall-clock time: 265 seconds. Software-assisted
virtualization: 393 seconds. Hardware-assisted virtualization: 484
seconds. Ouch. It sounds to me like a hybrid approach may be the best
answer to the virtualization problem.

... snip ...

similar, but different posting made here not too long ago
http://www.garlic.com/~lynn/2006j.html#27 virtual memory

the above has a discussion about hardware/software virtualization
trade-off in 3081 vis-a-vis 3090. note that this was pre-"PR/SM"
(which has since evolved into LPARS) ... where the microcode support
can create virtual machines ... w/o requiring separate hypervisor
monitor running (i.e. "dropping" everything into hardware was no
longer a performance trade-off issue).

for other drift, the performance characterization in the article is
reminisent of presentation i made at boston share meeting in aug68.
three people had came out from the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

the last week in jan68 to install cp67 at the university. during the
spring and summer of 68, i rewrote significant poritions of the
kernel, some cases descreasing pathlengths by factor of 10 to 100
times. past posting of parts of that presentation
http://www.garlic.com/~lynn/94.html#18 CP/67 and OS MFT14

which has a bare-machine (native wall clock) time of 322 sec.
original virtualization elapsed time 856 sec. virtualization elapsed
time (after rewrites of the spring and summer) 435 secs
(virtualization processing was reduced from 534 cpu secs. to 113 cpu
secs.).

misc. other posts repeating the same information:
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/97.html#28 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/99.html#93 MVS vs HASP vs JES (was 2821)
http://www.garlic.com/~lynn/2001h.html#12 checking some myths.
http://www.garlic.com/~lynn/2005m.html#16 CPU time and system load

sorting

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: sorting
Newsgroups: alt.folklore.computers
Date: Sun, 13 Aug 2006 09:37:31 -0600

krw writes:

Yes, it was on VM.  I don't believe it's been updated for a long
time.

I'd misread your article such that you were maintaining internal
dictionaries.  Sorry.

If I'd had that, I wouldn't have had to maintain my own SCRIPT defs!

Dunno why they didn't make such things available.  TLA and ETLA
dictionaries might have been a good business.  ;-)

Jim Gray and i was sitting around one friday night ... slightly
related ... misc. past posts mentioning original relational/sql
implementation
http://www.garlic.com/~lynn/submain.html#systemr

and came up with this idea that online phone directories would go a
long way to getting a lot of the internal non-computer users ...  to
start using online computer facilities. as a result, we started
project to do internal online phone directories. recent post (in this
thread) discussing some of that
http://www.garlic.com/~lynn/2006n.html#22 sorting was: The System/360 Model 20 Wasn't As Bad As All That

for some drift ... i maintain a few merged taxonomies and glossaries
on a number of subjects
http://www.garlic.com/~lynn/index.html#glosnote

which also includes some number of acronyms.

the personal data theft pandemic continues

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: the personal data theft pandemic continues
Newsgroups: bit.listserv.ibm-main
Date: Sun, 13 Aug 2006 10:23:19 -0600

ref:
http://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues

for some additional drift related to being able to harvest personal
information and whether or not it represents a vulnerability, risk,
threat, and/or fraud potential.

here is a lot of past postings on account number harvesting
http://www.garlic.com/~lynn/subintegrity.html#harvest

and even more posts on general fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud

... basically being able to harvest (static) information and perform
fraudulent activities ... frequently as some form of replay-attack.

x9.59 included countermeasure to skimming and
replay-attacks (i.e. simple skimming/harvesting of readily
available information and using it for fraudulent transactions)
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

another example is the recent news articles about cloning e-passport chips
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

where there have been subsequent comments that e-passport cloning
doesn't represent a vulnerability (i.e. personal information may be
captured, but it supposedly isn't subject to exploits).

this is somewhat in light of recent items about similar cloning of
financial payment chip cards ... and yes card vulnerability

first a quicky comment about 3-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor

• something you have
• something you know
• something you are

in the yes card vulnerability, the chip card represented something
you have authentication. it contained static information that is very
similar to what is found on a magstripe ... and the chip is vulnerable
to some of the same techniques used to harvest magstripe
information. then a counterfeit yes card chip card is built in
manner similar to creating a counterfeit magstripe card. presenting a
supposedly valid card is then a form of something you have
authentication.

supposedly the e-passport can be considered a form of electronic
surrogate passport. there can be a digital image, a name and a
passport number ... supposedly all protected from modification by some
form of cryptographic technique or secure hash.

if the threat model is the stealing and use of electronic passport
then the e-passport is a failure ... since it is easier to copy/steal
the e-passport information (compared to physical
passport). furthermore, the theft of a physical passport is frequently
noticed and reported ... while the "theft" of e-passport may not even
be noticed.

however, the e-passport does provide a countermeasure to modification
threat model (i.e. altering information/picture on valid passport
and/or creating purely counterfeit passport with false information).

the lack of vulnerability, somewhat supposes that there is a (trusted)
human in the loop that reads the electronic information, looks at the
digital picture and compares it against the person standing in front
of them (basically a form of something you are or biometric
authentication).

the issue with the yes card, was that the card represented purely
something you have authentication (whoever possesses the object is
authenticated). it does require a PIN (something you know
authentication) for supposedly multi-factor authentication and as a
countermeasure to lost/stolen cards.

however, a fault in the yes card scenario was that the terminal
would authenticate the (potentially counterfeit) card (with static
data vulnerable to replay attacks) and then asked the card if
the correct PIN was entered. the counterfeit yes cards were
programmed to always respond YES (that the correct pin was
entered).

Slight additional digression on yes card and multi-factor
authentication; supposedly multi-factor authentication is
considered more secure based on the different authentication factors
having independent threats and vulnerabilities (which is NOT a
valid assumption, if they have common threat/attack). A