List of Archived Posts

2007 Newsgroup Postings (02/23 - 03/08)

ISA Support for Multithreading

Designing database tables for performance?

Securing financial transactions a high priority for 2007

The Genealogy of the IBM PC

The Genealogy of the IBM PC

Is computer history taugh now?

GCN at 25: VAX for the memory

A way to speed up level 1 caches

ISA Support for Multithreading

The Genealogy of the IBM PC

A way to speed up level 1 caches

A way to speed up level 1 caches

Securing financial transactions a high priority for 2007

time spent/day on a computer

Cycles per ASM instruction

The Genealogy of the IBM PC

Attractive Alternatives to Mainframes

A way to speed up level 1 caches

Is computer history taught now?

Cycles per ASM instruction

Securing financial transactions a high priority for 2007

A way to speed up level 1 caches

A way to speed up level 1 caches

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

A way to speed up level 1 caches

Securing financial transactions a high priority for 2007

IBM S/360 series operating systems history

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Health Care

Quote from comp.object

I/O in Emulated Mainframes

IBM S/360 series operating systems history

Is computer history taught now?

FBA rant

Quote from comp.object

Quote from comp.object

FBA rant

FBA rant

FBA rant

IBM S/360 series operating systems history

FBA rant

FBA rant

Is computer history taught now?

time spent/day on a computer

FBA rant

time spent/day on a computer

time spent/day on a computer

Is computer history taught now?

Is computer history taught now?

FBA rant

US Air computers delay psgrs

time spent/day on a computer

time spent/day on a computer

time spent/day on a computer

Grilled Turkey

Health Care

Securing financial transactions a high priority for 2007

FBA rant

FBA rant

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

FBA rant

FBA rant

Securing financial transactions a high priority for 2007

ISA Support for Multithreading

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ISA Support for Multithreading
Newsgroups: comp.arch,comp.arch.embedded
Date: Fri, 23 Feb 2007 10:00:31 -0700

"Chris Thomasson" <cristom@comcast.net> writes:

DWCAS instruction and a hardware generated "heartbeat-like" interrupt
per-synchronization epoch should be all you need to create lock-free
algorithms that scale up to many thousands of cores...

prev. post in thread
http://www.garlic.com/~lynn/2007d.html#67 ISA Support for Multithreading

CAS was invented by Charlie when he was doing work on fine-grain
locking for cp67 (CAS was chosen because they are Charlie's initials
... afterwards had to come up with mnemonic that matched his
initials).

the initial attempts to get CAS as part of 370 was met with some
amount of resistance ... claiming that a smp specific instruction
couldn't be justified for 370 (test&set was sufficient) ... and to
get inclusion in 370 ... a non-SMP justification needed to be
created. As a result, came up with the use of CAS as atomic update in
a (software) multi-threaded environment (whether running single
processor or multi-processor environment) ... along with the various
programming notes that were included (originally) in the 370 principle
of operations. Also as part of that exercise, both single word and
double word version was done and the mnemonics changed to CS
(compare&swap) and CDS (compare double and swap).

since then instructions have been extended for both 32bit and 64bit
mode ... more recent compare and swap
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/7.5.28?DT=20040504121320

and compare double and swap
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/7.5.28?DT=20040504121320

appendix "Multiprogramming and Multiprocessing Examples" programming notes
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/A.6?DT=20040504121320

• A.6.1 Example of a Program Failure Using OR Immediate
• A.6.2 Conditional Swapping Instructions (CS, CDS)
• A.6.3 Bypassing Post and Wait
• A.6.4 Lock/Unlock
• A.6.5 Free-Pool Manipulation
• A.6.6 PERFORM LOCKED OPERATION (PLO)

... snip ...

and as above ... compare&swap has since been augmented with the "PERFORM
LOCKED OPERATION (PLO)" instruction

described here:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/7.5.107?DT=20040504121320

collected past posts mentioning multiprocessor and/or CAS instruction
http://www.garlic.com/~lynn/subtopic.html#smp

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Designing database tables for performance?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Designing database tables for performance?
Newsgroups: comp.databases.theory
Date: Fri, 23 Feb 2007 16:48:21 -0700

paul c <toledobythesea@oohay.ac> writes:

I don't remember when I first heard or read the term "logical I/O".
It might have been the in the early 1970's when IBM's VSAM access
method first hit the streets.  I'm pretty sure it was current in some
circles then.  Codd had written his first papers then but practically
nobody in industry was even aware of them as IBM was pushing IMS and
Vandl hard and people who knew him then told me later that there were
big marketing forces at IBM that made working at the same company very
difficult for him both personally and professionally.  The term is a
very unfortunate one since I'm sure misleads many newcomers to IT.  As
we can see here, it misleads many others.

(Anybody who was programming then has an historical advantage over
younger people because it is so much easier to see what a revolution
Codd started.)

original relational/sql implementation was system/r done all on
vm370 ... misc. collected posts mentioning system/r activity:
http://www.garlic.com/~lynn/submain.html#systemr

recent thread mentioning various things from system/r days:
http://www.garlic.com/~lynn/2007d.html#4 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#6 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#8 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#33 Jim Gray Is Missing

vm370 was a follow-on to cp67 ... which had implemented both virtual
memory and virtual machines in the mid-60s ... done at the cambridge
science center. some of the people from CTSS had gone to the science
center on the 4th flr of tech sq (worked on cp67, cms and other things)
http://www.garlic.com/~lynn/subtopic.html#545tech

GML (precursor to sgml, html, xml, etc) was also invented at the
science center in 1969.

others from CTSS went to the 5th flr and worked on multics. the
multics group managed to bring out the first commercial relational
database product (MRDS):
http://www.multicians.org/mgm.html#MRDS

it was into the 80s before tech. transfer from SJR to Endicott
succeeded with SQL/DS product ... and even longer for tech. transfer of
SQL/DS from Endicott back to STL for DB2.

when virtual memory for 370 was announced, for whatever reason, they
chose the term "virtual storage" (instead of virtual memory) ... from
that comes dos/vs, vs1, vs2, svs, mvs, vsam, etc (all the "VSs")

various past posts mentioning quote from the mid-60s about "A system
of that period that had implemented virtual memory was the Ferranti
Atlas computer, and that was known not to be working well"
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001h.html#10 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2002.html#42 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2003b.html#1 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003m.html#34 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2005o.html#4 Robert Creasy, RIP
http://www.garlic.com/~lynn/2006i.html#30 virtual memory

lots of collected posts mentioning virtual memory, demand paging, and
replacement algorithms (virtual memory and/or various kinds of "caches")
http://www.garlic.com/~lynn/subtopic.html#wsclock

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Sat, 24 Feb 2007 07:33:36 -0700

jmfbahciv writes:

If you haven't heard about it, you might find the news about
Stop&Shop grocery stores last week.  Not the strike but the
ones about some transmitter put into the card swipe machines
if they were movable.  (I didn't understand this one.)

isn't so much if they are movable ... but how easy it is to replace
the original with one that has been compromised (say a couple minutes
of fiddling at a empty/vacant check lane)

i do a weekday morning small mailing list of news URLs ...

small sample from yesterday morning, stop&shop hasn't been getting
nearly the play that TJX has received

Data Thieves Hit Stop & Shop
http://www.consumeraffairs.com/news04/2007/02/stop_n_shop.html
Update: TJX says Data breach worse than previously believed
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9011655
Customer Data Breach Began in 2005, TJX Says
http://www.washingtonpost.com/wp-dyn/content/article/2007/02/21/AR2007022102039.html
TJX: Data breach worse than previously believed
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9011655&intsrc=hm_list
Retailers to Hold Data-Breach Bag?
http://www.internetnews.com/bus-news/article.php/3661516
TJX Reveals Further Data breaches
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=117223242421320215117&block=
Mass. bill wants stores to pay more in data breaches
http://news.com.com/Mass.+bill+wants+stores+to+pay+more+in+data+breaches/2100-7348_3-6161536.html
Mass. bill wants stores to pay more in data breaches
http://news.zdnet.com/2100-1009_22-6161536.html
TJX security breach fears grow
http://www.theregister.co.uk/2007/02/22/tjx_security_breach/
TJX Data Breach Worse than Previously Believed
http://www.pcworld.com/article/id,129291-c,privacysecurity/article.html
Data Breach Hits Close to Home
http://blog.washingtonpost.com/securityfix/2007/02/johns_hopkins_data_breach_stri_1.html?nav=rss_blog
Mass. Bill Would Make Retailers Pay for Data breaches
http://blog.washingtonpost.com/securityfix/2007/02/bill_would_make_retailers_pay.html?nav=rss_blog
Pharming Attack Slams 65 Financial Targets
http://www.informationweek.com/showArticle.jhtml?articleID=197008230
Bearing the Cost of Stolen Data - The Checkout
http://blog.washingtonpost.com/thecheckout/2007/02/bearing_the_cost_of_stolen_dat.html?nav=rss_blog
TJX: Data Theft Began in 2005; Data Taken from 2003
http://www.baselinemag.com/article2/0,1540,2097672,00.asp
ID Security: Is That Really You? ID Theft and Multifactor
Authentication, Part 1
http://www.technewsworld.com/story/OOdTQ59zkfNJj1/Is-That-Really-You-ID-Theft-and-Multifactor-Authentication-Part-1.xhtml

... snip ...

a few stop & shop items from earlier in the week

Stop & Shop PIN Pads Breached As Conn. Removes Worker Data From Site
http://www.informationweek.com/showArticle.jhtml?articleID=197007473
Stop & Shop's PIN Pad Breach Follows Similar Cases in Canada
http://www.digitaltransactions.net/newsstory.cfm?newsid=1254
Stop & Shop(lifters) swipe card data
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9011580&intsrc=hm_list
Stop & Shop acknowledges security breach
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1244190,00.html
Stop & Shop reports credit data was stolen
http://www.boston.com/business/globe/articles/2007/02/19/stop__shop_reports_credit_data_was_stolen/
Data Thieves Hit Stop & Shop
http://www.consumeraffairs.com/news04/2007/02/stop_n_shop.html

... snip ...

and of course, my oft referenced security proportional to risk posting
http://www.garlic.com/~lynn/2001h.html#61

and lots of past posts in this thread:
http://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#6 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#8 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#15 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#17 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#18 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#22 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#26 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#27 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#28 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#30 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#31 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#32 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#33 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#35 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#36 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#37 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#39 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#40 Point-of-Sale security
http://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#44 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#46 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#51 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#52 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#53 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007d.html#0 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007d.html#5 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007d.html#11 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007d.html#26 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007d.html#68 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007d.html#70 Securing financial transactions a high priority for 2007

The Genealogy of the IBM PC

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Genealogy of the IBM PC
Newsgroups: alt.folklore.computers
Date: Sat, 24 Feb 2007 08:27:28 -0700

Charlton Wilbur <cwilbur@chromatico.net> writes:

More succinctly: the thing that made the IBM PC so wildly successful
was (and is) the thing that's making it so unprofitable.

The IBM PC was easily duplicated, and by the mid-1980s was widely
cloned.  IBM had pretty much lost control by 1987 or so when the PS/2
line of computers came out: they attempted to regain control by
introducing a new, incompatible expansion bus, but the market fairly
decisively went the other way to PCI.

I've repeatedly claim that PC had to break into the general market
first ... and out of the hobbyist/techno/nerd market segment. there
was huge chicken & egg problem. why would anybody (in the general
market) pay out quite a bit of money for something they never bought
before, never seen before and had no real idea what it was.

Until there was substantial market base and market demand ... the
clone makers weren't going to apply all the commoditization to even
further fuel the market.

my brother use to be regional marketing rep for apple ... and i
attended a couple of dinners with some of the mac developers (before
the mac was announced) and we would have this argument/discussion
(what was needed for personal computing device to break into the
general market).

as before, my claim has been that 3270 terminal emulation ... was a
relatively no-brainer financial decision. person (or corporation)
could decide to pay-out money for something they had already to
decided to buy anyway ... and get a model with a few extra bells &
whistles ... these "extras" (that except for a small number of
computer nerds) nobody had any idea what it was ... desktop/personal
computing ... however, it appeared to come as a nearly no-cost,
no-risk add-on.

once a large number of these devices were out there ... and same of
the general public had experience using them (as corporate terminals)
and had also got exposed a little to what desktop computing seemed to
be ... it became much easier for somebody in the general public (as
opposed to the computer nerd community) to make a decision to pay out
significant amount of money.

recent posts on this subject
http://www.garlic.com/~lynn/2007d.html#43 Is computer history taugh now?
http://www.garlic.com/~lynn/2007d.html#44 Is computer history taugh now?
http://www.garlic.com/~lynn/2007d.html#50 Is computer history taugh now?
http://www.garlic.com/~lynn/2007d.html#56 Is computer history taugh now?
http://www.garlic.com/~lynn/2007d.html#59 Is computer history taugh now?

The Genealogy of the IBM PC

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Genealogy of the IBM PC
Newsgroups: alt.folklore.computers
Date: Sat, 24 Feb 2007 09:05:00 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:

my brother use to be regional marketing rep for apple ... and i
attended a couple of dinners with some of the mac developers (before
the mac was announced) and we would have this argument/discussion
(what was needed for personal computing device to break into the
general market).

re:
http://www.garlic.com/~lynn/2007e.html#3 The Genealogy of the IBM PC

Jim Gray, some others and I had gone down a similar path a couple
years earlier about how to attract the general corporate community to
(CMS online) personal computing ... and out of the mostly small number
of programmers (i.e. from small tens of thousands to rest of the
corporation, couple hundred thousand).

Obvious was to try and promote internal network and electronic mail
communication ... and referenced in this post
http://www.garlic.com/~lynn/2007d.html#17 Jim Gray is Missing

a late night session we came up with providing online telephone books
... which could appeal to corporate executives.

There was an interesting "tipping" point that snowballed. It had been
that there was semi-annual budget process that included allocation of
3270s terminal for internal use. Individuals wanting their own desktop
3270 needed vp-level executive approval (that had to come out of the
specific organization's allocation). There was this one quarter where
it became known that a small number of top corporate executives had
started using email for communication. This was observed by the
mid-level executives ... which created an immediate demand for 3270
terminals for doing CMS email (mostly in the form of PROFS). There was
six month period which saw nearly the complete internal allocation of
3270s for programmers and engineers (to do their job) being preempted
and redirected by executives ... because it became the "in-thing" for
executives to have email.  Actually, normally two 3270 terminals were
needed, one for the executive (so they could claim they had online
email) and one for their secretary (for the most part was the person
that actually handled the email).

It was also in that six month period that I did the business case
justification which showed that the 3-year fully amortized cost of
3270 terminal was nearly identical to the monthly cost of a business
phone that was standard for each employees desk. That business phones
were supplied as a normal matter (w/o requiring vp sign-off) ... so
why couldn't 3270 terminals also be supplied for every employees desk
(w/o needing an executive to approve every individual 3270).

Is computer history taugh now?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is computer history taugh now?
Newsgroups: alt.folklore.computers
Date: Sat, 24 Feb 2007 11:10:10 -0700

krw <krw@att.bizzzz> writes:

No Fairchild was the manufacturer of the test equipment.  The VAX
was purchased through Fairchild, along with hardware and software,
to control the test floor.  IBM owned the hardware.  The division
was rather clear. For various reasons we didn't want to (but were
forced to, in the end) purchase a service contract for the
hardware.  Fairchild suggested we buy the contract (less the 20%
uplift) directly from DEC, but they refused our querys. Blue money
was no good.

At least we could get Tektronix to service our PDP-11s.  They had
to call DEC once and that was a mess too, but was resoled.

there was also the tektronix "3277-GA" ... i.e. tektronix display that
hung off the side of 3277 terminal.

the "instrument division" (in conn) sold a 68k lab machine ... old
passing reference
http://www.garlic.com/~lynn/2003b.html#5 Card Columns

a reference here
http://www.old-computers.com/museum/computer.asp?st=1&c=623

there are a few web pages that mention boca had considered 68k for
acorn ... but among other things, motorola couldn't commit to the
volumes.

some old email ... this talks about both the TSS "unix" prpq
for at&t ... i.e. stripped down TSS kernel with UNIX layered
on top ... as well as a reference to early work on what became
xt/370:


To: wheeler
Date: 80/04/04  10:04:35

what i heard yesterday from a fellow in communications industry
marketing who is the connection between ibm and the labs prpq people
is that they expected to be done by august, and will probably be done
by the end of the year instead.  XXXXXX from bell said they hadn't
started writing code yet at share.  the fellow at amdahl is named
YYYYYY.  by the way, i think they are seriously considering doing
it.. they want the benefits of a relatively large address space and
nonflakey hardware.  the tss supervisor isn't a terribly large price
to pay for this, and they feel comfortable with it, being one of the
last strongholds of tss anyway.

what the fellow from comm ind was interested in was whether there was
a c compiler anywhere within ibm.  answer, no.  he said several people
have expressed interest to him, including the people in endicott who
are using 68000 to emulate 360/370, and want to write microcode in c.
some recent developments lead me to believe that we can do a unix port
effort somewhere within ibm around now..  the time is ripe, lots of
people are interested and we have some unix expertise around.

will send more mail on this later.

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

a few other old emails on the tss prpq (for unix) subject
http://www.garlic.com/~lynn/2006b.html#email800310
http://www.garlic.com/~lynn/2006t.html#email800327
http://www.garlic.com/~lynn/2006f.html#email800404
http://www.garlic.com/~lynn/2007b.html#email800408

lots of past posts on washington (code name for xt370)
http://www.garlic.com/~lynn/94.html#42 bloat
http://www.garlic.com/~lynn/96.html#23 Old IBM's
http://www.garlic.com/~lynn/2000.html#5 IBM XT/370 and AT/370 (was Re: Computer of the century)
http://www.garlic.com/~lynn/2000.html#29 Operating systems, guest and actual
http://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#55 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2001c.html#89 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001f.html#28 IBM's "VM for the PC" c.1984??
http://www.garlic.com/~lynn/2001i.html#19 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001k.html#24 HP Compaq merger, here we go again.
http://www.garlic.com/~lynn/2002b.html#43 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#45 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002i.html#76 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2003f.html#8 Alpha performance, why?
http://www.garlic.com/~lynn/2003h.html#40 IBM system 370
http://www.garlic.com/~lynn/2004h.html#29 BLKSIZE question
http://www.garlic.com/~lynn/2004m.html#7 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#10 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#11 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#13 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2005f.html#6 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped files on z/VM V5.1
http://www.garlic.com/~lynn/2006f.html#2 using 3390 mod-9s
http://www.garlic.com/~lynn/2006j.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006m.html#56 DCSS
http://www.garlic.com/~lynn/2006n.html#5 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006n.html#14 RCA Spectra 70/25: Another Mystery Computer?
http://www.garlic.com/~lynn/2006y.html#29 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2006y.html#30 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007d.html#7 Has anyone ever used self-modifying microcode? Would it even be useful?
http://www.garlic.com/~lynn/2007d.html#25 modern paging

GCN at 25: VAX for the memory

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: GCN at 25: VAX for the memory
Newsgroups: alt.folklore.computers
Date: Sat, 24 Feb 2007 11:41:59 -0700

GCN at 25: VAX for the memory
http://www.gcn.com/print/26_04/43159-1.html

from above:

With a 32-bit architecture and the use of virtual memory to manage its
address space, the VAX (which stood for Virtual Address eXtension) was
a pioneer when the first one was released in 1977. By 1988, it had
become so common at agencies that GCN devoted five pages to a Buyers
Guide ( 11 vendors, 124 products) on add-in memory for 'your VAX
computer.' Yes, you too could add 8 MB for a mere $3,395, give or take
a couple hundred depending on the product.

... snip ...

dare i mention 360/67 shipping ten years earlier? ... supported 32bit
(and 24bit) virtual memory addressing; slight topic drift:
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm

other slight topic drift
http://www.garlic.com/~lynn/2007e.html#1 Designing database tables for performance

A way to speed up level 1 caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A way to speed up level 1 caches
Newsgroups: comp.arch
Date: Sat, 24 Feb 2007 16:20:10 -0700

Maynard Handley <name99@name99.org> writes:

Each L1 cache is now two identical such caches.
Which one is used is gated by whether the system is in user or system
mode. This is a simple extra bit line, so doesn't hurt your cycle time,
unlike doubling associativity to double the cache size.
Now we get the system material segregated in its world, the user
material segregated in its world, and the two aren't stumbling over each
other.

we claimed about something similar in the 168 (and follow-ons)
... most of the stuff for virtual memory ... at least with the early
virtual memory system started at zero and grew upwards. starting at
least with 168, they chose the "8mbyte" virtual address bit for one of
the indexes. the issue was that the mainline batch system of the time
was MVS with 24bit (16mbyte) virtual address spaces ... with the
kernel occupying the first 8mbytes of every (application) virtual
address space ... nominally leaving 8mbytes in every application
virtual address space for application code.

Purposefully choosing the 8mbyte virtual address bit for one of the
index bits ... resulting in partitioning half for application code and
half for kernel code. there was some amount of complaints from other
operating systems that didn't have that way of organizing code.

Actually for the 168 ... where the cache was real address indexed
... it only applied to TLB entries ... and not the processor cache.
You didn't start having virtual address indexing for cache entries
until 3090 ... although it was a dual-index scheme discussed in an old
email
http://www.garlic.com/~lynn/2003j.html#email831118

in general, all studies i've seen or done ... when all other things
being equal ... a global cache strategy is more efficient than a
partitioned cache strategy. The exceptions are where processing is
ongoing and distinct ... like strategies involving separate
instruction and data cache. The issue is execution patterns can be
quite bursty ... and the downside of a partitioned cache strategy is
the reduced cache hit rate because some piece of code that is heavily
executing at a specific moment could have made use of the extra cache
that isn't available in a partitioned strategy. lots of past posts
discussing replacement algorithms ... frequently contrasting global
LRU (unpartitioned) vis-a-vis local LRU (partitioned) strategy.
http://www.garlic.com/~lynn/subtopic.html#wsclock

an issue is whether or not kernel/application execution patterns are
frequently intermixed to the point that eliminating their interaction
provides some benefit. another way of dealing with an aspect of this
that I played with in the mid-70s was changing the dispatching of
applications to be disabled for asynchronous i/o interrupts (for
limited periods) ...  as a mechanism for dealing with random (kernel)
processing of asynchronous interrupts(impacting application cache hit
ratios). there was some tuning trade-offs regarding responsiveness of
delaying interrupt processing vis-a-vis improved cache hit ratios. in
large systems, there were even situations where delayed interrupt
processing tended to batch the handling of several interrupts
... improving both kernel processing cache hit ratio at the same time
improving application cache hit ratio; slight delays even improved
timeliness of overall interrupt processing since both kernel and
application thruput improved. Basically it made kernel and application
cache use take turns ... but if there was no kernel processing to be
done ... there was no turn to take and application code could continue
to use the whole cache. In that sense, it was more dynamically
adaptive compared to any fixed physical partitioning implementation.

aka it only showed an improvement if they were actually stumbling over
each other. if they weren't actually stumbling over each other ...
then there was no improvement ... but there was also no penalty.

for other drift ... I have written a fairly large application ... and
for some amount of processing ... the application runs nearly twice as
fast on 1.7ghz pentium-M with 2mbyte processor cache as it does on a
3.4ghz pentium-4 with 512k processor cache (i.e. the reverse of what
one might expect purely based on processor cycle time).

ISA Support for Multithreading

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ISA Support for Multithreading
Newsgroups: comp.arch,comp.arch.embedded
Date: Sat, 24 Feb 2007 23:03:10 -0700

"Chris Thomasson" <cristom@comcast.net> writes:

Just to clarify, DWCAS == CDS... BTW... Do you why the doubleword version of
CAS was created? Did its ability to implement many different kinds of
lock-free algorithms influence any decisions?

previous post:
http://www.garlic.com/~lynn/2007d.html#61 ISA Support for Multithreading
http://www.garlic.com/~lynn/2007r.html#0 ISA Support for Multithreading

see the referenced programming notes for CDS example

example for "free-pool manipulation" using CDS
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.6.5?SHELF=DZ9ZBK03&DT=20040504121320

bitsaver has copy of 370 principle of operations ga22-7000-4, 1sep75
http://www.bitsavers.org/pdf/ibm/370/princOps/GA22-7000-4_370_Principles_Of_Operation_Sep75.pdf

with basically has identical CDS free-pool manipulation description

The Genealogy of the IBM PC

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Genealogy of the IBM PC
Newsgroups: alt.folklore.computers
Date: Sun, 25 Feb 2007 09:38:30 -0700

"Quadibloc" <jsavard@ecn.ab.ca> writes:

Making the IBM an open system didn't *necessarily* invite cloning; IBM
did *not* expect the BIOS to be imitated quite as quickly as it was.

re:
http://www.garlic.com/~lynn/2007e.html#3 The Genealogy of the IBM PC
http://www.garlic.com/~lynn/2007e.html#4 The Genealogy of the IBM PC

if it was being thot of as personal computing market ... it would
probably be unlikely that it would be thot of as a several billion per
annum cloning opportunity ... however if it was thot of as a 3270 dumb
terminal with lots of bells and whistles ... then the whole attitude
would be changed (cloners would see a significantly different business
case).

clones were well established part of mainframe market all thru the 70s
... it was tens of billions per annum. i've even mentioned that there
was some write-up blaming a project that i was part of as an
undergraduate in the 60s (with 3 others) starting the whole
thing. lots of past posts about doing a mainframe controller clone as
an undergraduate in the 60s.
http://www.garlic.com/~lynn/subtopic.html#360pcm

there was sort of expectation that any mainframe thing would be cloned
within six months of product availability ... even things enormously
more complex than BIOS or the whole PC.

there was theft of trade-secret case that i've mentioned before circa
1980. damages were claimed for a couple billion ... based on six month
difference in clone revenue ... i.e. being able to market clone same
day as mainframe product availability as opposed to starting to ship
a clone six months later.

for a little drift ... one of the things that the judge brought up in
the case ... given that it was worth at least a couple billion ...
could it be demonstrated that the security (to prevent such theft) was
proportional to the value of what was stolen.

misc. past posts industrial espionage and attractive nuisance (if you
left a couple billion laying around ... people couldn't be blamed for
trying to walk away with it)
http://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
http://www.garlic.com/~lynn/2005f.html#60 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005r.html#7 DDJ Article on "Secure" Dongle
http://www.garlic.com/~lynn/2006q.html#36 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#29 Intel abandons USEnet news

A way to speed up level 1 caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A way to speed up level 1 caches
Newsgroups: comp.arch
Date: Sun, 25 Feb 2007 10:08:16 -0700

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

We had a performance problem, and I analysed IBM's cache measurements
on the 370/165.  The data were inadaequate to draw many conclusions,
but that aspect was one where I felt that there was a possibility of
improvement.  The cache hit rate in system code was low enough that
we might have got better performance overall if it had bypassed the
cache entirely.

re:
http://www.garlic.com/~lynn/2007e.html#7 A way to speed up level 1 caches

one might conjecture that entry into the kernel was somewhat
unpredictable and random ... especially for things like asynchronous
i/o interrupts ..  and the processing was straight-thru the kernel
with little "re-use" (very little locality of use). then the main
effect of kernel execution on cache operation would be to flush
application stuff out of the cache.

a much more glaring example of something similar was when the 3880-13
track cache was introduced in the early 80s. they claimed a 90% hit
rate for typical i/o operations to 3380. my counter claim (which i
took some heat for pointing out) was that sequentially reading a 3380
... which typically had ten records per track ... would result in
"miss" on the read for the first record on a track ... and then a
"hit" for reading the remaining nine records on a track (90 percent
cache hit rate).  I claimed that a much simpler full-track buffer
would achieve the same benefit ...  since no records were actually
being "re-used" once they were in the cache.

my observation about running applications disabled for i/o interrupts
... tended to somewhat minimize randomness of kernel flushing
application stuff out of cache ... and also created small increase in
probability of kernel cache re-use if multiple pending i/o interrupts
were processed in batch/burst.

... aka caches (and lru replacement algorithms) have assumption that
something used in recent history is the most likely to be (re-)used in
the future. there are significant kinds of patterns ... like various
kinds of sequential and/or straight through processing that may not
correspond to that.

A way to speed up level 1 caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A way to speed up level 1 caches
Newsgroups: comp.arch
Date: Sun, 25 Feb 2007 13:17:38 -0700

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

Precisely.  Whether that was so, I can't say.  But it matched the
data I had, and is definitely a plausible hypothesis.  It might
well be true today.

re:
http://www.garlic.com/~lynn/2007e.html#7 A way to speed up level 1 caches
http://www.garlic.com/~lynn/2007e.html#10 A way to speed up level 1 caches

one of the places where partitioned caches show benefit ...  is
limiting the damage that some operation that has sequential/serial,
non-reuse pattern activity might have on other activity using the
cache (it wasn't that it improved good cache activity ... it just
bounded the effects of bad cache activity).

another "kernel" example has been tcp/ip stack kernel implementations.
some of the implementations have had large number of buffer copy
operations ...  and w/o special non-caching support for data copies
... easily wipes out any useful stuff in the cache(s) (especially when
dealing with larger buffer sizes). the processor cycles involved in
buffer copy cache effects can turn out to be larger than the processor
cycles involved in direct instruction execution.

one of the suggested benefits for posix asynchronous i/o ... besides
enabling various multi-threaded operations ... was being able to set
up direct i/o transfer into/out-of application space buffers ...
avoiding all buffer copy operations. this somewhat wanders into the
recent thread on multithreading
http://www.garlic.com/~lynn/2007d.html#61 ISA Support for Multithreading
http://www.garlic.com/~lynn/2007e.html#0 ISA Support for Multithreading
http://www.garlic.com/~lynn/2007e.html#8 ISA Support for Multithreading

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Sun, 25 Feb 2007 14:02:03 -0700

jmfbahciv writes:

Oh!  Replacement.  The reports didn't say that; the reports said
that a chip or something had been added to the original device.
It just make any sense about the reported requirement that only
movable scanners were affected.

it could have been "an" original device ... as opposed to "the"
original device. it is somewhat easier to take a device apart and
insert skimmer/recorder and some sort of wireless transmitter
... offsite ... and then swap devices. they could both be original
devices ... the issue is whether the actual compromise takes place in
real-time or offsite at some other location (and only the swap has to
be performed in real-time). Many of the devices have some degree of
armoring ... making real-time compromise somewhat more problematical.

However, if the armoring was minimal and there was trivial access
permitting insertion of recorder/transmitter in real time ... bolting
the machine might make such access more difficult (as opposed to being
countermeasure to swapping "original" devices ... where one has been
compromised offsite and swapped for one that hasn't "yet" been
modified).

re:
http://www.garlic.com/~lynn/2007e.html#2 Securing financial transactions a high priority for 2007

for other drift ...

Fraud, embezzling and financial crime
http://business.scotsman.com/topics.cfm?tid=946
Chip and pin fails to halt card fraud rise
http://edinburghnews.scotsman.com/edinburgh.cfm?id=291732007
Card-skim criminals have police stumped
http://www.portsmouthtoday.co.uk/ViewArticle.aspx?ArticleID=2075455&SectionID=455
Plans to cut card fraud 'too complex'
http://www.itnews.com.au/newsstory.aspx?CIaNID=46197&src=site-marq
Plans to cut card fraud 'too complex'
http://www.itweek.co.uk/vnunet/news/2183738/plans-cut-card-fraud-slammed
Plans to cut card fraud 'too complex'
http://www.whatpc.co.uk/vnunet/news/2183738/plans-cut-card-fraud-slammed
Warnings over 'complicated' anti-fraud card systems
http://www.tuvps.co.uk/news/articles/warnings-over-complicated-anti-fraud-card-systems-18065845.asp

a possible claim from the x9a10 financial standard working group
perspective was that there was a failure to perform end-to-end threat
analysis. in the mid-90s time-frame that some of these things were
being invented ... the x9a10 financial standard working group had been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments ... resulting in x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959

rather than coming up with a variety of piece-meal point solutions
(none of which adequately addressed all the threats), provide a
comprehensive end-to-end solution.

time spent/day on a computer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: time spent/day on a computer
Newsgroups: alt.folklore.computers
Date: Mon, 26 Feb 2007 09:04:06 -0700

Roger Blake <rogblake10@iname10.com> writes:

I've been working in data processing for about 30 years now, which makes
me a newbie compared to many here. I've already reached the point where
I don't code any more, aside from shell scripts and small utilities
for my own use. (Have transitioned from software development to network
administration and maintenance.)

i got terminal at home in mar70 and have had online connectivity at
home ever since ... of course back then it was only 134.5 baud.

recent reference to programming
http://www.garlic.com/~lynn/2007d.html#25 modern paging
http://www.garlic.com/~lynn/2007e.html#7 A way to speed up level 1 caches

Cycles per ASM instruction

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cycles per ASM instruction
Newsgroups: comp.lang.asm370
Date: Mon, 26 Feb 2007 09:44:55 -0700

Sparky Spartacus <Sparky@universalexports.org> writes:

Thus taking an enormous hit for using ISAM, a true hog.

ISAM sprang out of the same philosophy as the design of VTOC and PDS
... which used multi-track search to find members; basically I/O
resources were traded off to compensate for real memory
resource constraint ...  a serious issue in the 60s.

The trade-off of using I/O resources to compensate for constrained
real memory continued for VTOC/PDS long after the trade-off had
shifted by at least the mid-70s.

Basically the index for "finding" what you wanted was stored on the
disk ... and channel programs were built that could scan the on-disk
structures looking for target information. ISAM had structures that
were more complex that the simple linear search used for VTOC/PDS
... being able to fetch information from disk that would change the
channel (i/o) program "on the fly" (somewhat the equivalent of
self-modifying instruction streams ... which were frequently done in
the same period ... compensate for constrained real storage).

In the case of VTOC/PDS implementation ... the profligate "burning" of
i/o resources continued long after primary system bottleneck had
shifted from being real storage constrained to being I/O resource
constrained ... and frequently could represent an enormous system
bottleneck ... collected past posts mentioning CKD and VTOC/PDS
implementation representing a serious system system thruput bottleneck
(as system configurations changed from being primarily real storage
constrained to being primarily i/o constrained)
http://www.garlic.com/~lynn/submain.html#dasd

in the early 80s i got into a little trouble with the disk development
organization ... in the late 70s ... I started making statements about
system configurations shifting from being memory constrained to being
disk constrained. Part of this was noting that disk relative system
thruput had declined by better than an order of magnitude over a
period of years (cpu & memory got 50 times bigger/faster, while disks
only got 3-5 times faster) ... as a result there was a significant
requirement to change implementation paradigms to use memory to
compensate for disk thruput (caching and other paradigm changes).  the
disk division assigned their performance organization to refute my
statements. However after several weeks, the group came back and noted
that I had actually somewhat understated the situation. a few
past posts mentioning the subject:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#53 Performance and Capacity Planning
http://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
http://www.garlic.com/~lynn/2006o.html#27 oops
http://www.garlic.com/~lynn/2006x.html#13 The Future of CPUs: What's After Multi-Core?

For a slightly different drift ... some number of posts mentioning
the original relational/sql implementation, System/R
http://www.garlic.com/~lynn/submain.html#systemr

in the system/r time-frame there was some number of arguments about
benefits/trade-offs between the IMS people in STL and the System/R
people in SJR. IMS used direct record pointers embedded as part of the
information. System/R used a index structure built "under the covers"
to abstract away direct record pointers from explicit representation
as part of the data. IMS pointed out that the System/R index structure
typically doubled the physical disk requirements ... and significantly
increased the number of disk I/Os (as part of processing the index).
System/R people pointed out the enormous manual costs maintaining the
exposed record pointers. effectively in the 80s, with ever increasing
real storage availability, it was possible to cache the majority of
the RDBMS index ... eliminating the costly disk I/O overhead
processing the index ... and the significant increase in disk
capacities and significant increase in disk price/mbyte ... somewhat
made the issue of the size of the on-disk index structure mute. This
changed the trade-off of increased System/R computing resource
requirements vis-a-vis the significant manual resource requirements
for IMS ... making RDBMS implementations a lot more attractive for
many people (although there are claims that still today there may be
more mbytes stored in IMS databases than RDBMS databases).

misc. past posts mentioning the the IMS/RDBMS discussions
http://www.garlic.com/~lynn/2004e.html#22 Pre-relational, post-relational, 1968 CODASYL "Survey of Data  Base Systems"
http://www.garlic.com/~lynn/2004o.html#67 Relational vs network vs hierarchic databases
http://www.garlic.com/~lynn/2004q.html#23 1GB  Tables as Classes, or Tables as Types, and all that
http://www.garlic.com/~lynn/2004q.html#79 Athlon cache question
http://www.garlic.com/~lynn/2005b.html#1 Foreign key in Oracle Sql
http://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
http://www.garlic.com/~lynn/2006w.html#27 Generalised approach to storing address details

for other drift, a couple other posts about that period
http://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing

for other drift ... recent thread on self-modifying instruction streams
http://www.garlic.com/~lynn/2007d.html#1 Has anyone ever used self-modifying microcode? Would it even be useful?
http://www.garlic.com/~lynn/2007d.html#3 Has anyone ever used self-modifying microcode? Would it even be useful?
http://www.garlic.com/~lynn/2007d.html#7 Has anyone ever used self-modifying microcode? Would it even be useful?
http://www.garlic.com/~lynn/2007d.html#9 Has anyone ever used self-modifying microcode? Would it even be useful?
http://www.garlic.com/~lynn/2007d.html#46 Has anyone ever used self-modifying microcode? Would it even be useful?

The Genealogy of the IBM PC

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Genealogy of the IBM PC
Newsgroups: alt.folklore.computers
Date: Mon, 26 Feb 2007 10:57:52 -0700

Walter Bushell <proto@panix.com> writes:

This was before glass TTY's, or at least when they became widely
available, early 70's. I didn't become aware of glass TTY's until the
mid 80s. Too new fangled for me, you have to relearn all your habits,
which I had to do anyway for the leap to micros.

some old email mentioning topaz/3101 ... it replaced a cdi miniterm (thermal
paper) for home terminal
 http://www.garlic.com/~lynn/2006y.html#791011,
 http://www.garlic.com/~lynn/2006y.html#791011,
 http://www.garlic.com/~lynn/2006y.html#800301,
 http://www.garlic.com/~lynn/2006y.html#800311,
 http://www.garlic.com/~lynn/2006y.html#800312,
 http://www.garlic.com/~lynn/2006y.html#800314,
 http://www.garlic.com/~lynn/2006y.html#810820,

an general past posts mentioning 3101
http://www.garlic.com/~lynn/99.html#69 System/1 ?
http://www.garlic.com/~lynn/2000g.html#17 IBM's mess (was: Re: What the hell is an MSX?)
http://www.garlic.com/~lynn/2001b.html#12 Now early Arpanet security
http://www.garlic.com/~lynn/2001b.html#13 Now early Arpanet security
http://www.garlic.com/~lynn/2001h.html#32 Wanted: pictures of green-screen text
http://www.garlic.com/~lynn/2001m.html#1 ASR33/35 Controls
http://www.garlic.com/~lynn/2001m.html#54 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2003c.html#34 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#35 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003n.html#7 3270 terminal keyboard??
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2005p.html#28 Canon Cat for Sale
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006n.html#56 AT&T Labs vs. Google Labs - R&D History
http://www.garlic.com/~lynn/2006y.html#0 Why so little parallelism?
http://www.garlic.com/~lynn/2006y.html#4 Why so little parallelism?
http://www.garlic.com/~lynn/2006y.html#24 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2006y.html#31 "The Elements of Programming Style"

Attractive Alternatives to Mainframes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Attractive Alternatives to Mainframes
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 26 Feb 2007 12:19:40 -0700

Dave Kopischke wrote:

Because I want to know if it worked or not. As you imply, it will be next
to impossible to get an objective answer, but SIAC is a high visibility
company and process within the industry. They won't fail without someone
knowing it.

when we were doing ha/cmp ... we talked quite a bit to SIAC, which was
using a number of tandem computers at the time ... misc posts
mentioning ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

in that period, i had been asked to write part of the corporate
continuous availability strategy document (based on ha/cmp work we
were doing in geographic survivability) ...  however both Rochester
and POK non-concurred with what I had written ... and it got pulled
(at the time, they didn't have any offerings that could meet the
criteria); we had coined the terms disaster survivability (as an
alternative to disaster/recover) and geographic survivability
... misc. posts on geographic operation and continuous availability
http://www.garlic.com/~lynn/submain.html#available

later we also talked to one of the big financial transaction
operations running IMS hot-standby in a geographic separated operation
... they attributed their 100 percent availability over a period of
several years to 1) IMS hot-standby and 2) automated operator
(i.e. people make mistakes)

for a little drift ... my wife had been con'ed into serving a stint in
POK in charge of loosely-coupled architecture where she originated
peer-coupled shared data architecture
http://www.garlic.com/~lynn/submain.html#shareddata

except for IMS hot-standby, the architecture saw very little uptake
until sysplex (one of the reasons she didn't stay in that position for
very long).

for small amount of other IMS topic drift ... in this old email
http://www.garlic.com/~lynn/2007.html#email801016

in this post
http://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"

for other topic drift, collection of email discussing ha/cmp scale-up
http://www.garlic.com/~lynn/lhwemail.html#medusa

A way to speed up level 1 caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A way to speed up level 1 caches
Newsgroups: comp.arch
Date: Mon, 26 Feb 2007 12:33:08 -0700

"Stephen Sprunk" <stephen@sprunk.org> writes:

True.  Disk data should only arrive in the amount you ask for, when you ask
for it.  Network data can arrive in any size and at any time.  However, on
POSIX systems the two look about the same once you've created an fd; that's
one of the downsides to UNIX's "everything's a file" philosophy.

cms had similar problem running under cp67 in the mid-60s
... basically cp67 kernel scanned the channel programs making a
"shadow" version (with real addresses) and fixing the appropriate
pages ... and the "shadow" channel program was what actually got
executed. later in the early 70s, I did an enhancement for the cms
filesystem that used page mapping capability ... that eliminated most
of that overhead (and the related page fixing) ... since the
operations mapped directly to page transfers (which were
aligned). misc. past posts mentioning implementing paged mapped
filesystem in the early 70s
http://www.garlic.com/~lynn/submain.html#mmap

there was some speculation about moving the channel program
translation outboard to the channels with the introduction of 370s (in
the early 70s). there had been a recently issued patent on "virtual"
channels (in the late 60s) ... however, production channel hardware
never actually shipped.

with regard to tcp/ip and buffer overrun ... it is actually only a
problem for incoming data ... you can still easily use scatter/gather
technique for outgoing data. then for incoming data ... you may select
to trade-off between extremely high-performance transfers by forcing
data to relatively structured organization ... vis-a-vis lower
performance and less structured transfers.

Is computer history taught now?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is computer history taught now?
Newsgroups: alt.folklore.computers
Date: Tue, 27 Feb 2007 08:08:40 -0700

jmfbahciv writes:

Wouldn't there be a maximum number of levels before the
organization stopped working efficiently?  I think Lynn
has talked about this and said that anything above four
levels creates inertia.

i've posted about traditional 6-7 reports/manager having 14 levels for
the size of the organization ... however a new business where some
number of people transferred in 78-79, they tried to emulate the 14
level organization ... even tho there were only 2000 people; the
result was a top heavy operation with half the organization having
titles of at least "director" or above (that organization lasted until
the mid-80s when it was dissolved):
http://www.garlic.com/~lynn/2000b.html#69 oddly portable machines
http://www.garlic.com/~lynn/2003j.html#76 1950s AT&T/IBM lack of collaboration?
http://www.garlic.com/~lynn/2004o.html#63 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2006m.html#17 Why I use a Mac, anno 2006

I also have mentioned that (at least part of) the company in the very
early 90s ... significantly flattened the organization to 12-14
reports/manager ... resulting in large number of mid-level
managers/executives having to look for other opportunities ... some
number possibly finding new positions in Marlborough
http://www.garlic.com/~lynn/2007b.html#29 was: How many 36-bit Unix ports in the old days?

there was somewhat unrelated recent news item:

Meetings make us dumber, study shows
http://www.msnbc.msn.com/id/17279961/

there was a different thread about threat of gov. action can create
business decision paralysis ... since everything has to be handled at
very high level constantly trying to anticipate gov. response
http://www.garlic.com/~lynn/2001j.html#33 Big black helicopters
http://www.garlic.com/~lynn/2001j.html#51 Big black helicopters

there is a related issue ... also from Boyd ... about pushing
decisions as low as possible (i.e. it isn't so directly the number of
levels ... it is how far away from any direct involvement are
decisions being made):
http://www.garlic.com/~lynn/99.html#120 atomic History
http://www.garlic.com/~lynn/2001.html#29 Review of Steve McConnell's AFTER THE GOLD RUSH
http://www.garlic.com/~lynn/2001.html#30 Review of Steve McConnell's AFTER THE GOLD RUSH
http://www.garlic.com/~lynn/2001m.html#16 mainframe question
http://www.garlic.com/~lynn/2002d.html#36 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#38 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002q.html#33 Star Trek: TNG reference
http://www.garlic.com/~lynn/2002q.html#43 Star Trek: TNG reference
http://www.garlic.com/~lynn/2003h.html#51 employee motivation & executive compensation
http://www.garlic.com/~lynn/2003p.html#27 The BASIC Variations
http://www.garlic.com/~lynn/2004k.html#24 Timeless Classics of Software Engineering
http://www.garlic.com/~lynn/2004q.html#86 Organizations with two or more Managers
http://www.garlic.com/~lynn/2005e.html#3 Computerworld Article: Dress for Success?
http://www.garlic.com/~lynn/2006f.html#14 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#9 The Pankian Metaphor
http://www.garlic.com/~lynn/2006q.html#41 was change headers: The Fate of VM - was: Re: Baby MVS???
http://www.garlic.com/~lynn/2007b.html#37 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007c.html#25 Special characters in passwords was Re: RACF - Password rules

Cycles per ASM instruction

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cycles per ASM instruction
Newsgroups: comp.lang.asm370
Date: Tue, 27 Feb 2007 08:34:51 -0700

"robertwessel2@yahoo.com" <robertwessel2@yahoo.com> writes:

When you turned the option on, CP would basically look at channel
programs to see if they looked like the ISAM ones that were self
modifying, and would them simulate them separately.  This was none too
secure, at least in early versions of VM, where real self-modification
was allowed on a partially virtualized channel program.

ref:
http://www.garlic.com/~lynn/2007e.html#14 Cycles per ASM instruction

one of my first assignments after graduation and going to the science
center
http://www.garlic.com/~lynn/subtopic.html#545tech

was a week onsite at a customer account trying to get ISAM support
working ... rewriting parts of CCWTRANS ... module in cp67 that
scanned channel program and created "shadow" ... which was actually
executed.

most of ISAM self-modifying wasn't actually modifying the CCWs but the
seek arguments (arm position on the disk). CP67 in addition to translated
the CCWs ... in part to handle virtual->real addresses ... recent thread
in another n.g.
http://www.garlic.com/~lynn/2007e.html#17 A way to speed up level 1 caches

but also to convert the seek arguments for minidisks (i.e. minidisks
where virtual cylinder zero was actually at some other cylinder
position). Setting the "ISAM" option for a "full-pack" minidisk (i.e.
all the virtual arm/seek positions were identical to the real arm/seek
positions) ... would change CCWTRANS so that instead of using a
"shadow" seek argument ... it used the (untranslated) seek argument
located in the virtual address space (instead of translated/shadow
seek argument).

in the standard shadow CCW translation, the seek argument was copied
to a shadow location for use by the shadow seek CCW. When the ISAM
channel program read a new seek argument into its virtual address
space, a normal shadow channel program wouldn't see it; however an
ISAM option (full pack minidisk) shadow channel program would have all
the seek CCWs pointing at the seek arguments in the virtual address
space (rather than a shadow version) and so would pick-up the
dynamically read seek argument. There wasn't a "real" security issue
for full-pack minidisk ... since there was no place the arm could be
moved that would result in a position belonging to some other virtual
machine.

There was another feature added for VTAM ... where VTAM was
modifying a "live" channel program, on-the-fly ... as part of dynamic
buffer allocation related to reading input from terminals ... where
VTAM would execute a diagnose instruction (after modifying the channel
program) as an indication for CP to retranslate the channel program,
updating the shadow channel program (which is the real live running
version). This characteristic was also somewhat referenced in the
thread about speeding up level 1 caches ... how to (dynamically)
handle an indeterminate amount of incoming data.

other posts in this thread:
http://www.garlic.com/~lynn/2007d.html#62 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007d.html#63 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007d.html#71 Cycles per ASM instruction

and other posts in the thread about speeding up level 1 caches
http://www.garlic.com/~lynn/2007e.html#7 A way to speed up level 1 caches
http://www.garlic.com/~lynn/2007e.html#10 A way to speed up level 1 caches
http://www.garlic.com/~lynn/2007e.html#11 A way to speed up level 1 caches

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Tue, 27 Feb 2007 11:26:29 -0700

Morten Reistad <first@last.name> writes:

This is the problem with my bank's network banking changes. They
used to have a 6-digit signing "mouse" for login and transcations,
and otherwise stick to "dumb" https.I can then take action to use
a secure machine; using e.g. lynx on an openbsd machine as the
browser.

Now they 1) insist on windows 2) put trust in the OS by downloading
a huge user side Java blob 3) Only have a single logon, no signing of
transaction batches before payment 4) Botch certificate issuance, so
I have to accept a certificate that appears "out of the blue".

I now have to change my bank. New cards are picked up friday.
Old cards will be instructed to have a maximum limit of $100 for
all payments. I will enjoy to see them implement that on the
software side.

All of this is from adoption of "chip cards solves all" thinking,
and lack of security and threat analysis.

there is some amount in the press about public being on the lookout
for external overlays that perform skimming/recording operations in
support of replay attacks (information used to create
counterfeit cards) ... however, there are some newer generation of
skimming/recording that are being placed inside the terminals (and
therefor a lot harder to detect).

note that the "chip cards solves all" ... is the subject of
the series of posts about yes card exploit
http://www.garlic.com/~lynn/subintegrity.html#yescard

where I once heard somebody comment about there having been billions
of dollars spent proving that chips were less secure than magstripe.
even some suggested countermeasure to chipcard counterfeit
yes card vulnerability still may be subject to
man-in-the-middle attacks ... misc.  past posts mentioning
various kinds of MITM-attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

also as a countermeasure to wide variety of compromises for (mostly
personal/home) machines ... the EU had created the "finread" terminal
standard
http://www.garlic.com/~lynn/subintegrity.html#finread

... included

1) external pinpad ... as countermeasure to keylogger + trojan
horse (in the PC) recording the chipcard's PIN ... and possibly even
replaying the PIN to the chipcard for a stealth transaction w/o the
owner's knowledge and

2) external display ... as countermeasure to trojan horse
representing one transaction on the (PC's) screen and presenting a
totally different transaction to the chipcard.

the emerging (40yr old, new) virtualization (virtual machine)
technology is being pushed as a cure ... but it can also be used as
part of the disease. As part of a countermeasure/cure ... all
downloads are kept in an isolated "sandbox" ... separated and
partitioned from more secure operations. As part of the disease,
infections that manage to get into the virtualization infrastructure
can go totally undetected by all scanning/checking software (and from
their stealth position perform all sorts of activities that leave no
trace)

lots of posts mentioning all kinds of fraud, exploits,
vulnerabilities, threats, risks, etc
http://www.garlic.com/~lynn/subintegrity.html#threat

recent, somewhat related thread ... comment here
http://www.garlic.com/~lynn/aadsm26.htm#38 Usable Security 2007
and also in this thread
http://www.garlic.com/~lynn/2007e.html#12 Securing financial transactions a high priority for 2007

that includes news article mentioning that "card and chip fails to halt
card fraud rise"

and news item referenced here
http://www.garlic.com/~lynn/aadsm26.htm#39 Usable Security 2007

about changing gov. regulations where card & check fraud is no longer
reported to the authorities ... but instead reported to the financial
institution ... and then it is the responsibility of the financial
institution to make any reports to the authorities.

and recent threads mentioning various kinds of ssl vulnerabilities
http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle SSL
http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle SSL
http://www.garlic.com/~lynn/aadsm26.htm#28 man in the middle SSL
http://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle SSL
http://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle SSL
http://www.garlic.com/~lynn/2007d.html#35 MAC and SSL
http://www.garlic.com/~lynn/2007d.html#36 MAC and SSL
http://www.garlic.com/~lynn/2007d.html#37 MAC and SSL
http://www.garlic.com/~lynn/2007d.html#38 Question on Network Security
http://www.garlic.com/~lynn/aadsm26.htm#32 Failure of PKI in messaging
http://www.garlic.com/~lynn/aadsm26.htm#33 Failure of PKI in messaging
http://www.garlic.com/~lynn/aadsm26.htm#34 Failure of PKI in messaging
http://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging

A way to speed up level 1 caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A way to speed up level 1 caches
Newsgroups: comp.arch
Date: Tue, 27 Feb 2007 11:37:02 -0700

Jan Vorbrüggen <jvorbrueggen@not-mediasec.de> writes:

Such pages are locked down for good, until the I/O completes - nothing
at all is allowed to change in that period of time. VMS did it that
way, and got it right (well, mostly 8-)) from day 1. Reference
counting, and all that. Oh, and when the reference count finally goes
to zero, the delayed action(s) finally take place. (And that's where
most of the bugs were/are.)

over the years ... I got to rewrite sections of that code in the cp
(virtual machine) kernel 3 or 4 times ... to fix bugs and other
features that would creep in during the intervening years ... starting
first with cp67 in the 60s.

then later when I got to release the resource manager for vm370 ...
well over half the code in the resource manager ... wasn't actually
involved in managing resources ... but major restructuring of the
whole kernel serialization operation. misc. posts mentioning resource
manager
http://www.garlic.com/~lynn/subtopic.html#fairshare
which also included a bunch of stuff involving replacement algorithms
http://www.garlic.com/~lynn/subtopic.html#wsclock

i then got to got another opportunity when I rewrote the i/o subsystem
for the disk engineering labs. they were doing dedicated testing of
individual development devices in scheduled "stand alone" environment
... they had found that attempting to do testing in an operating
system ... that systems like MVS (at the time) had a MTBF of 15
minutes (with a single development device). I undertook to rewrite the
whole infrastructure so that multiple concurrent development devices
could be tested "on demand" in an operating system environment. misc.
posts mentioning work in the disk engineering labs
http://www.garlic.com/~lynn/subtopic.html#disk

A way to speed up level 1 caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A way to speed up level 1 caches
Newsgroups: comp.arch
Date: Tue, 27 Feb 2007 13:21:40 -0700

Morten Reistad <first@last.name> writes:

For some reason, multprocessor machines have always seemed
a lot more responsive than what benchmarks show. The segmented
cache may be a reason, one cache per 1/2 processor streams, and
processes (including kernel) are usually somewhat processor-sticky
at least in the short term.

This should give a similar effect. The OS not only has a cache
for itself, there is a whole processor attached.

4way and over can also schedule dedicated hardware to interrupts,
file system, network and user space. This may explain the responsiveness.

early on as an undergraduate in the 60s ... i found that
responsiveness could be improved if you could do preemption at nearly
zero cost (and make reasonable judgment about what should be used for
preemption) ... all part of dynamic adaptive scheduling (periodically
also referred to as fair share scheduling since the default scheduling
policy was fair share). this started before cache machines ... which
changes the trade-off guidelines on what would represent nearly zero
cost for preemption. in any case, things related to preemption
decisions (and responsiveness) have since gotten a lot more complex.

for responsiveness in the multiprocessor scenario, it may be that
there are a number of processors that are either idle (and no
preemption logic gets involved) or doing something that easily meets
the preemption criteria.

in an earlier post ... i mentioned changing kernel dispatcher to
running application disabled for asynchronous i/o interrupts (as
mechanism for improving cache hit ratio) ... delaying operations which
might be associated with responsiveness. However, the delay might
actually result in processing several interrupts at one time ... the
cache miss (and cache turn-over) occurring on the first interrupt and
then being able to immediately process a number of interrupts that
were also pending at the same time.

in previous post,
http://www.garlic.com/~lynn/2007e.html#21 A way to speed up level 1 caches

i mentioned that a lot of my resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare

had included a lot of restructuring code ... not directly associated
with resource management ... a large part of the restructuring had to
do with fixing a whole class of problems related to correct
serialization ...  however, there was another class of kernel
restructuring that was also related to multiprocessing support.

for total topic drift ... the unbundling announcement of 23jun69 started
change-over from free software to charged for software.
http://www.garlic.com/~lynn/submain.html#unbundle

however, at the time, they used the excuse that kernel software should
still be free/bundled (because it was required for the operation of
the hardware).  by the time i was to getting ready to release the
resource manager ... that attitude was starting to change ... then my
resource manager got selected to be the guinea pig for kernel software
charging. I got to spend several months on and off with the legal and
business people about kernel software policies. That particular pass
was if it was kernel software directly related to hardware operation
(like device drivers) ... then it would still be free; but other
kernel code (like resource management algorithms) could be priced.  So
the resource manager went out as a charged-for kernel addon.

A problem came in the next release when they wanted to ship
multiprocessor support. Multiprocessor support was directly hardware
related ... so should be free. However, it was dependent on a bunch of
restructuring code that was already being shipped in the charged for
resource manager. The problem was resolved by moving a bunch of code
out of the (charged for) resource manager into the "free" kernel.

In any case, there was some slight of hand coding tricks that resulted
in multiprocessor dispatching being "processor-sticky" (attempting
some preservation/re-use of cache contents) ... w/o needing explicit
specification of processor affinity.

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Tue, 27 Feb 2007 17:48:19 -0700

Morten Reistad <first@last.name> writes:

Actually, the current "solutions" are part of the problem, not
part of the solution.

ref:
http://www.garlic.com/~lynn/2007e.html#20 Securing financial transactions a high priority for 2007

for whatever reason, i've found that creating correct security systems
is very much like creating almost any other kind of correct systems
...  in fact when we were doing the ha/cmp product ... security faults
was viewed as just another kind of bug
http://www.garlic.com/~lynn/subtopic.html#hacmp

various recent posts referring to various kinds of correct operation
http://www.garlic.com/~lynn/2007e.html#1 Designing database tables for performance?
http://www.garlic.com/~lynn/2007e.html#14 Attractive Alternatives to Mainframes
http://www.garlic.com/~lynn/2007e.html#16 Attractive Alternatives to Mainframes
http://www.garlic.com/~lynn/2007e.htmL#19 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007e.html#21 A way to speed up level 1 caches
http://www.garlic.com/~lynn/2007e.html#22 A way to speed up level 1 caches

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Wed, 28 Feb 2007 08:53:01 -0700

jmfbahciv writes:

Banks are undergoing a similar thing that happened when the S&Ls
were turned loose with no minder.

long winded discussion of the S&L situation (as well as several
other issues related to financial institutions)
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security

part of the issue was that many of the institutions didn't have people
that were very sophisticated in dealing with various kinds of
financial instruments ... i.e. they were possibly people that did the
same thing today as they did yesterday ... and could maintain the
status quo (as long as things stayed relative stable and constant).
When there were significant shifts (like when the reserve requirements
were cut in half from eight percent to four percent, freeing up a lot
of assets that required something to be done) ... they found
themselves in unfamiliar waters.

in the case of magstripe devices ... they are basically something you
have authentication. On the front there were various countermeasures
developed for counterfeit cards ... but that required people at
point-of-sale to actually pay some attention. This was a relatively
difficult burden. The "magstripe" on the back became the "real"
representation of the device. However, it was static data and attacks
quickly appeared that could create duplicate counterfeit magstripes
... either thru active recording of the magstripe (skimming) and/or
harvesting critical information stored in repositories (data breaches
and security breaches).

many of the chips out there basically have duplicated the magstripe
information ... and claimed resistance to attacks that would attempt
to extract the duplicated magstripe information stored in the chip.
however, they were still vulnerable to skimming attacks that
evesdropped and recorded the information during a standard transaction
(exploits that started to appear for magstripe by at least the late
80s) ... and/or attackers that obtained valid point-of-sale terminal
and convinced the chip that a valid transaction was being performed.

now, in a standard two-factor magstripe transaction ... a pin is also
required ... which is transmitted back to the authorizing institution
for validation. normally multi-factor authentication is considered
more secure because there is implicit assumption that the different
authentication factors are subject to different vulnerabilities
(modulo people writing their PIN on the card).

in the chip yes card scenario
http://www.garlic.com/~lynn/subintegrity.html#yescard

a PIN is also required and therefor is considered a more secure
multi-factor authentication operation. however, the point-of-sale
terminal first authenticates a chipcard by validating the information
provided by the chip (essentially an enhanced duplicate of the
magstripe information). after the terminal has "validated" the chip,
it then asks the chip if the entered PIN was correct.

The yes card reference comes from a counterfeit card responding
YES to all questions from the point-of-sale terminal. The (ersatz
magstripe) information to create a counterfeit yes card is skimmed
and/or harvested from some previous transaction (either a normal valid
transaction or an interchange that a normal card has with a
point-of-sale terminal in the attacker's possession).

A counterfeit yes card has the valid information installed ... which
it then can used for a replay attack against a point-of-sale
terminal.  Multi-factor authentication is subverted since a yes card
will always respond YES to the question of whether a valid pin was
entered (regardless of what was actually entered). As a result, an
attacker isn't required to know the original, valid PIN.

Furthermore, for the standard point-of-sale terminal deployment for
chipcards, after the chip authentication has been performed and the
chip has responded YES to the question about whether the PIN is
correct, then the POS terminal asks the chip if the transaction is to
be done offline (to which a yes card answers YES), and if it is to
be an offline transaction, the terminal then asks the chip if the
transaction is within the account's credit limit (to which a yes
card always answers YES).

The counterfeit yes card response to the offline transaction
question avoids the countermeasures that flag an account when a card
is reported lost/stolen (since it isn't an online transaction, the
terminal doesn't find out until much later whether the account number
is still valid or not). Then the counterfeit yes card response to
whether the transaction is within the account's credit limit can allow
the attacker to perform an unlimited amount of fraud.

The counterfeit yes card starts out basically as a replay attack
on the point-of-sale terminal (similar to counterfeit magstripe
replay attack) ... but then gets much worse since it manages to
bypass multi-factor authentication provisions (valid PIN) and
countermeasures to lost/stolen card reporting (by bypassing check on
whether account has been flagged).

In various referenced press announcements about yes card exploits,
http://www.garlic.com/~lynn/subintegrity.html#yescard

there are references to yes card being an SDA vulnerability (i.e.
the authentication information is static data and therefor is subject
to evesdropping/harvesting and replay attacks). The suggested
countermeasure is "DDA" or switching to dynamic data authentication
(things like digital signatures which can be unique/change for each
use).

However, it is possible that even with DDA, there still may be a yes
card man-in-the-middle attack.
http://www.garlic.com/~lynn/subintegrity.html#mitm

A lost/stolen valid card (and/or a valid card obtained under false
pretenses) is paired with a MITM yes card.  The MITM yes card
transparently passes the initial chip authentication chatter between
the terminal and the real card. After that initial interaction, the
MITM yes card handles all further communication (i.e. whether
correct PIN was entered, whether it should be an offline transaction,
and whether the transaction is within the account's credit limit).
Again multi-factor authentication has been negated and the flagging of
reported accounts countermeasure has been bypassed (by forcing offline
transaction and whether/or not the transaction is within the accounts
credit limit).

A way to speed up level 1 caches

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A way to speed up level 1 caches
Newsgroups: comp.arch
Date: Wed, 28 Feb 2007 07:43:30 -0700

Jan Vorbrüggen <jvorbrueggen@not-mediasec.de> writes:

Quite. By chance I re-read yesterday a 2001 presentation on the VMS
support for multiprocessor (and NUMA) systems. They added the
capabilities to direct all interrupts to one processor, have the lock
manager run on only one processor (which in addition to the cache
effects allows it to run in a mode where much less (spin)locking of
data strcutures is required) and to ensure that the driver code for
certain devices always executes on a given processor. You then use
performance measurement to determine whether your dedicated CPU(s)
still have some time left to do other work.

What they didn't say is what you're supposed to do when your interrupt
or lock manager load exceeds the capability of one processor.

post of old announcement of VMS adding support for "symmetric"
multiprocessing (as opposed to asymmetric multiprocessing ... where
interrupts, i/o and other things are possibly only processed on
a single processor)
http://www.garlic.com/~lynn/2007.html#46 How many 36-bit Unix ports in the old days?

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Wed, 28 Feb 2007 09:26:02 -0700

Eric Sosman <esosman@acm-dot-org.invalid> writes:

Sloppiness in handling records arises, I think, because the
records are of different levels of importance to the various
parties.  You feel that no effort should be spared to protect
your credit card numbers and so on from misuse, but the merchant
who's processing your order just wants to get the transaction
over with as quickly and inexpensively as possible.  Both views
are reasonable; it's all a matter of whose shoes you wear.

oft referenced, old posting about security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

basically the value of the information to the attacker is
significantly larger than the value (and/or resources available) to
the defender. the resources available to the defender is basically
proportional to the profit from the transaction. some fraction of the
profit from each transaction is available to the defender to protect
the information. the value of the information to the attacker is
basically proportional to the credit limit for each account.  As a
result, the attacker can almost always outspend on the attack than any
resources that the defender can afford.

the issue is further compounded by the fact that there are possibly
dozen of business processes that require a merchant's ready access to
past transaction information. the current environment requires
previous transaction information to be kept confidential and never
divulged as countermeasures to attackers using the information for
future fraudulent transactions. at the same time, standard business
processes require that the information be readily available. The
diametrically conflicting requirements has led to my periodic comments
that even if the planet was buried miles deep under encryption, it
still wouldn't prevent account/transaction information leakage.

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. the result was the x9.59
financial standard
http://www.garlic.com/~lynn/x959.html#x959

part of the x9.59 standard was eliminating the usefulness of past
transaction information for performing future fraudulent transactions.
x9.59 didn't do anything about eliminating skimming and evesdropping
attacks on valid transactions or do anything about eliminating data
breaches and security breaches on repositories of previous
transactions.  what x9.59 financial standard did was it eliminated
attackers being able to use the information from previous transactions
for performing future fraudulent transactions (replay attacks)

x9.59 standard didn't do anything about eliminating such attacks.
however, x9.59 did drastically reduced the risk of such attacks by
eliminating attackers being able to use the information for performing
fraudulent transactions (i.e. most of the value to the attacker was
eliminated).

x9.59 is resistant to replay attacks ... mentioned in previous
post:
http://www.garlic.com/~lynn/2007e.html#24 Securing financial transactions a high priority for 2007

since it uses "dynamic data authentication"

X9.59 is also resistant to man-in-the-middle attacks
http://www.garlic.com/~lynn/subintegrity.html

... mentioned in previous post
http://www.garlic.com/~lynn/2007e.html#24 Securing financial transactions a high priority for 2007

since rather than performing the authentication separate from the
transaction ... authentication is part of every transaction. Having
authentication as an operation separate from the transaction ... in
effect leaves the transaction "naked" and vulnerable.

past posts/comments about being unable to prevent account/transaction
information leakage ... even if the planet was buried under miles of
encryption
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
http://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push
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/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?
http://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006p.html#8 SSL, Apache 2 and RSA key sizes
http://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication
http://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
http://www.garlic.com/~lynn/2006y.html#25 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#33 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#53 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007d.html#34 Mixed Case Password on z/OS 1.7 and ACF 2 Version 8

...

past posts/comments raising the issue of the vulnerability of "naked" transactions:
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
http://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security -- Agriculture
http://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
http://www.garlic.com/~lynn/aadsm25.htm#25 RSA SecurID SID800 Token vulnerable by design
http://www.garlic.com/~lynn/aadsm25.htm#28 WESII - Programme - Economics of Securing the Information Infrastructure
http://www.garlic.com/~lynn/aadsm26.htm#6 Citibank e-mail looks phishy
http://www.garlic.com/~lynn/aadsm26.htm#13 Who has a Core Competency in Security?
http://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
http://www.garlic.com/~lynn/2006m.html#24 OT - J B Hunt
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
http://www.garlic.com/~lynn/2006o.html#40 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication
http://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2006y.html#25 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007

IBM S/360 series operating systems history

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM S/360 series operating systems history
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 01 Mar 2007 09:52:17 -0700

Shmuel Metz , Seymour J. wrote:

My recollection is that the original virtual storage announcement for
S/370 already used the term MVS for OS/VS2 R2. However, you will still
see remnants in the code of the original names, AOS/1 and AOS/2.

some number of customers had been doing stuff to make MVT run better
in a cp67 (on 360/67) virtual machine ... including various things
related to virtual memory.

there was a period when we were making regular trips from cambridge to
pok to participate in 370 architecture meetings ... especially related
to virtual machine and virtual memory operation ... and would
periodically knock around 706 machine room in the evenings where AOS
prototype was being built ... crafting virtual memory on the side of
MVT for what was to become SVS.

Ludlow(?, I'm pretty sure i remember his name) was doing a lot of the
work. Part of the effort involved taking the (virtual to real) channel
program translator/builder from CP67 (CCWTRANS) and cobbling it into
the side of MVT (i.e. a lot of AOS ... instead of running MVT under
cp67 virtual machine virtual memory ... was hacking various pieces of
cp67 virtual memory support into the side of a MVT kernel
... especially the channel program translator ... which was some
amount of fairly complicated code, involving interpreting the virtual
channel program, making a shadow, finding all the "data" virtual
pages, fixing them in core ... and using the "real" addresses).

recent thread discussing patching CCWTRANS to handle ISAM and other
self-modifying channel programs i.e. CCWTRANS built a "shadow" of the
"applications" virtual channel program ... with "real" addresses
... and ran the "shadow" channel program ... any dynamic modifications
that an application did to the "virtual" channel program wouldn't
actually involve the channel program being executed.
http://www.garlic.com/~lynn/2007e.html#14 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007e.html#17 A way to speed up level 1 caches
http://www.garlic.com/~lynn/2007e.html#19 Cycles per ASM instruction

A slightly different issue I had was with the POK performance modeling
group that was trying to come up with virtual page replacement
algorithms. They eventually decided on including some optimization
feature that I claimed that would totally distort "least recently
used" assumptions related to page replacement. They did it anyway
... and it wasn't until well into MVS release cycle in the late 70s
... that it dawned on them that they were selecting high-use LINKPACK
shared executable pages for replacement before private, lower-used
application data pages.

lots of past posts related to page replacement algorithms
http://www.garlic.com/~lynn/subtopic.html#wsclock
as well as old email on the same subject
http://www.garlic.com/~lynn/lhwemail.html#globallru

past posts in this thread:
http://www.garlic.com/~lynn/2007d.html#48 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007d.html#51 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007d.html#65 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007d.html#69 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007d.html#72 IBM S/360 series operating systems history

misc. pasts posts taking ludlow's name in vain:
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#36 History
http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems
http://www.garlic.com/~lynn/2002l.html#67 The problem with installable operating systems
http://www.garlic.com/~lynn/2002p.html#49 Linux paging
http://www.garlic.com/~lynn/2002p.html#51 Linux paging
http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2004e.html#40 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005b.html#49 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction
http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate volsers
http://www.garlic.com/~lynn/2006b.html#32 Multiple address spaces

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Thu, 01 Mar 2007 12:14:06 -0700

krw <krw@att.bizzzz> writes:

No, they're coded by people.

basically check readers/sorters ... would read the micr at the bottom
of the check with some coding provided by humans as to the rest of the
information on the check.

big part of check readers/sorters was to pull the routing code off the
micr ... so the piece of paper could get sorted into bins that would
eventually involve physical transportation to the correct financial
institution.

it wasn't unheard of to get a check or two every month where there had
been an extra sticky strip pasted to the bottom of the physical check
with (new) micr routing code (selected by human operator) .... because
the micr on the paper check wasn't readable (remember "do not fold,
spindle or mutilate"?) ...  peoples' handwriting was well beyond the
capability of such electronic readers (which could have problems with
the well structured, preprinted micr coding).

the lore has been that a big part of federal express business started
with overnight transportation of paper checks around the US ... for
clearing from the federal reserve. A huge bank of check sorters in
Nashville ... next to the airport ... planes from all over the country
arriving in the middle of the night ... the paper checks being sorted
and then piled back onto the planes for delivery in the morning.

check21 is designed to do away with all the transport of physical
paper ... the check being imaged at point-of-sale ... with the paper
being returned to the person. it is still necessary to electronically
read the micr routing code from the image for correct (electronic)
routing.

a few past posts/threads mentioning check sorters
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#155 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2002.html#18 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Thu, 01 Mar 2007 12:43:08 -0700

Identity Fraud: ID Theft Victims, Losses Take Welcome Nosedive
http://www.banktechnews.com/article.html?id=20070226T5LTLE8K

there has been some effort by FTC and others to differentiate types of
ID Theft ... at least into 1) Identity Fraud (where identity
information is used to do various things like opening new accounts)
and 2) Account Fraud (fraudulent transactions against existing
accounts).

The above article refers to Identity Theft loses dropping to
$49.3billion in 2006 from $55.7billion in 2005.

However, it goes on to say that most of that improvement comes from
better processing of requests to open new accounts.

while:

... "existing accounts have the highest average fraud" ... $7,560 and
"the average consumer cost from fraud rose sharply, from $431 to $535".

so, lumping all kinds of fraud together, there was an overall
reduction of about 10percent (from $55.7billion to $49.3billion)
... while, at the same time, the avg. consumer fraud costs rose
sharply by approx. 1/4th from $431 to $535.

Health Care

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Health Care
Newsgroups: alt.folklore.computers
Date: Thu, 01 Mar 2007 16:48:43 -0700

the US comptroller (appointed in the mid-90s for 15yr term) continues
tirade against the prescription drug bill ... as the most financially
irresponsible law in 40yrs ... which may have already bankrupt the US
Most recent comments are to broadcast Sunday night on CBS 60mins.

previous posts/threads in this n.g. mentioning US Comptroller comments
from last year on the same subject.
http://www.garlic.com/~lynn/2006f.html#41 The Pankian Metaphor
http://www.garlic.com/~lynn/2006f.html#44 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#9 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#14 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#27 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#2 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#3 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#4 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#17 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#19 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor
http://www.garlic.com/~lynn/2006o.html#61 Health Care
http://www.garlic.com/~lynn/2006p.html#17 Health Care
http://www.garlic.com/~lynn/2006t.html#26 Universal constants

Quote from comp.object